По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В статье мы хотим рассказать про настройку функции пейдженга (Paging) в Cisco CME (CUCME).
Эта функция схожа с интеркомом, однако обеспечивает только одностороннюю автоматическую связь. Когда IP-телефон набирает номер пейджинга, то каждый телефон состоящий в группе пейджинга автоматически отвечает на звонок на громкой связи.
CMEподдерживает пейджинг в unicast и multicast конфигурации. Пейджинг в unicast конфигурации заставляет маршрутизатор CME отправлять отдельные сообщения на каждый из IP-телефонов в группе. Таким образом, если пять IP-телефонов состоят в группе пейджинга, то маршрутизатор CME будет передавать пять отдельных аудиосигналов устройствам и из-за нагрузки CME ограничивает группы до десяти телефонов. Конфигурация multicast позволяет маршрутизатору CME отправлять один аудиопоток, который будет получать только IP-телефоны состоящие в группе и это позволяет иметь в ней практически неограниченное количество IP-телефонов. Однако для поддержки multicast пейджинга необходимо настроить базовую сетевую среду для поддержки multicast трафика.
Настройка
Рассмотрим настройку unicast single-group пейджинга на CME. Для начала создадим номер DN для пейджинга:
CME(config)# ephone-dn 100
CME(config-ephone-dn)# number 55555
CME(config-ephone-dn)# paging
Если набрать номер 55555, то зазвонят все телефоны в группе пейджинга. Чтобы добавить телефон в группу необходимо выполнить команду paging-dn [номер группы]
CME(config)# ephone 1
CME(config-ephone)# paging-dn 100
CME(config-ephone)# exit
CME(config)# ephone 2
CME(config-ephone)# paging-dn 100
Чтобы настроить multicast paging нужно во время создания номера DN указать multicast IP адрес, и во время добавления телефона в группу указать аргумент multicast у команды paging-dn.
CME(config)# ephone-dn 100
CME(config-ephone-dn)# number 55555
CME(config-ephone-dn)# paging 239.1.1.1 port 2000
CME(config-ephone-dn)# exit
CME(config)# ephone 1
CME(config-ephone)# paging-dn 100 multicast
CME(config-ephone)# exit
CME(config)# ephone 2
CME(config-ephone)# paging-dn 100 multicast
Также можно создать номер, который будет распределять вызов на несколько пейджинговых групп одновременно. Для этого используется команда paging group, которая поддерживает до 10 групп. Такая настройка называется Multiple-Group Paging
CME(config)# ephone-dn 100
CME(config-ephone-dn)# number 55555
CME(config-ephone-dn)# paging
CME(config-ephone-dn)# exit
CME(config)# ephone-dn 200
CME(config-ephone-dn)# number 77777
CME(config-ephone-dn)# paging
CME(config-ephone-dn)# exit
CME(config)# ephone-dn 300
CME(config-ephone-dn)# number 99999
CME(config-ephone-dn)# paging group 100, 200
CME(config-ephone-dn)# exit
Эти настройки можно провести использую Cisco Configuration Professional (CCP) . Для этого там переходим во вкладку Unified Communications – Telephony Features – Paging Numbers и нажимаем Create. В открывшемся окне указываем номера для группы пейджинга и какие телефоны будут в нее входить. Для настройки Multiple-Group Paging нужно перейти во вкладку Unified Communications – Telephony Features – Paging Groups.
Перед вами Топ-10 преимуществ, которые виртуализация даст вашей организации. Нужна помощь убедить начальство, почему виртуализация – это верный путь? Или нужно убедить себя? Мы разобрались и делимся нашим исследованием.
Шаг 1: Аппаратная абстракция
Аппаратная абстракция упрощает человеческий труд и время простоя, связанное с заменой оборудования, поломками, модификациями и так далее. Также она помогает избежать зависимости от строго определенного оборудования и поставщиков. Хотите произвести апгрейд оперативной памяти или процессора? Нужно добавить больше места для хранения данных или дополнительный сетевой адаптер ? Это невероятно быстро и просто. Дни «корпения» над оборудованием в прошлом – больше не нужно перегружать сервер ресурсами до его использования . Можно по необходимости добавлять совместно используемые ресурсы прямо в процессе, с минимальным простоем.
Шаг 2: Простота миграции
Вернемся к первому тезису. Отсутствие привязки к строго определенному оборудованию позволяет с легкостью и быстротой перемещать виртуальную машину (или копию машины) на другой физический носитель или хостинг. Это огромный плюс для обслуживания, выравнивания нагрузки и критического восстановления.
Шаг 3: Легкость в управлении дисками
Инкапсуляция устройств хранения данных (перенос дисковых хранилищ «на лету») создает значительно упрощенные условия для полного отката системы и восстановления, что делает возможным невероятно быстрый BMR (Bare Metal Restore). Ваша машина – это набор файлов. Проще не бывает.
Bare Metal - установка гипервизора на «голое» железо. Это позволяет исключить операционную систему и поставить гипервизор (VMware, Hyper-V, Citrix и прочие) сразу на сервер без ОС.
Шаг 4: Снимки (снэпшоты)
Снэпшоты упрощают тестирование и обеспечивают защиту от изменений, которые могут поломать конфигурацию системы. Если вы напортачите с физической машиной, то проведете за ее починкой часы, дни, или и того больше. Если же вы напортачите с виртуальной машиной, то просто верните снимок в предыдущее состояние. Готово! Одно только это преимущество – бесценно.
Шаг 5: Простота в архивации
Легкость в архивации старых систем – огромный плюс. Закончили эксплуатацию машины – можно ее отключать и переносить файлы на долговременное хранилище м, например, СХД. Машина понадобилась снова? Скопируйте файлы назад и запускайте в считанные минуты.
Шаг 6: Легкость роста
Виртуализация облегчает численный рост при помощи опции платных аддонов вроде HA (high availability), vMotion и так далее. Некоторые из этих функций бесплатны в зависимости от выбора платформы (Hyper-V, Xen). С множеством гипервизоров, нужно всего лишь применить лицензионный ключ для разблокировки новых функций, которые могут ощутимо улучшить работу вашего дата-центра. Начните с малого, растите и прокладывайте себе путь. Виртуализация позволяет вам быть гибкими в вопросах реализации.
Шаг 7: Улучшенный контроль и поиск неисправностей
Большинство гипервизорных решений позволяют контролировать все физические хосты через центральную консоль, где вы можете легко сравнивать использование ресурсов и просматривать историю задач и событий. Вы можете с легкостью делать сравнения между физическими и виртуальными серверами и проводить глубокий анализ и поиск неисправностей.
Шаг 8: Консолидация нагрузки на физический сервер
На одно оборудование можно поместить от 2 до 100 (и даже больше) виртуальных машин, снизив тем самым затраты на закупки аппаратных компонентов и использование пространства стойки , при этом также упадет потребление энергии и затраты на охлаждение. Вместо того, чтобы оставлять заказ на новый сервер, вы можете запустить новую виртуальную машину в считанные минуты. Большинство физических носителей используются лишь на долю своего потенциала из-за ограничений софта (таких как необходимость разделения приложений или ролей друг от друга). Вы можете разделять их, запуская на одном и том же оборудовании.
Шаг 9: Легкость сегментации приложений
Отсылаем вас к предыдущему заявлению. Нужно запустить одну машину на базе Linux, а другую на базе Windows ОС? Запустите новую виртуальную машину на том же оборудовании. За счет минимальных изменений в использовании оборудования ваши нужды будут удовлетворены – к тому же вам не придется покупать новый носитель.
Шаг 10: Новый уровень дистанционного управления
Дистанционное управление позволяет вам полностью управлять машиной на расстоянии. Вы можете делать запросы, которые обычно приходится делать «на месте» (сидя на корточках в неудобной и холодной серверной), через удаленную консоль – например, апгрейд ресурсов, поиск сетевых неисправностей, включение/отключение операций и многое другое. Это невероятно увеличивает эффективность управления сервером и снижает затраты на поездки и простои.
Виртуализация сервера – это огромное преимущество для любой компании. Даже для отдельного хоста виртуализация имеет смысл (снимки, облегчение переноса и так далее).
Перед тем как начать: почитайте про перераспределение между плоскостями управления в сетях.
Сетевые инженеры обычно думают, что плоскость управления выполняет самые разные задачи, от вычисления кратчайшего пути через сеть до распределения политики, используемой для пересылки пакетов. Однако идея кратчайшего пути проникает в концепцию оптимального пути. Точно так же идея политики также проникает в концепцию оптимизации сетевых ресурсов. Хотя важны и политика, и кратчайший путь, ни один из них не лежит в основе того, что делает плоскость управления. Задача плоскости управления - сначала найти набор путей без петель через сеть. Оптимизация - хорошее дополнение, но оптимизация может быть "сделана" только в контексте поиска набора путей без петель.
Таким образом, в этом разделе будет дан ответ на вопрос: как плоскость управления вычисляет пути без петель через сеть?
Этот цикл статей начнется с изучения взаимосвязи между кратчайшим или наименьшим метрическим путем и безцикловыми путями. Следующая рассматриваемая тема - свободные от циклов альтернативные пути (LFA), которые не являются лучшими путями, но все же свободны от циклов. Такие пути полезны при проектировании плоскостей управления, которые быстро переключаются с наилучшего пути на альтернативный путь без петель в случае сбоев или изменений в топологии сети. Затем обсуждаются два конкретных механизма, используемых для поиска набора безцикловых путей.
Какой путь свободен от петель?
Связь между кратчайшим путем, обычно в терминах метрик, и свободными от циклов путями довольно проста: кратчайший путь всегда свободен от циклов. Причина этой связи может быть выражена наиболее просто в терминах геометрии (или, более конкретно, теории графов, которая является специализированной областью изучения в рамках дискретной математики). Рисунок 1 используется для объяснения этого.
Какие есть пути из A, B, C и D к месту назначения?
Из A: [B, H]; [C, E, H]; [D, F, G, H]
Из B: [H]; [A, C, E, H]; [A, D, F, G, H]
Из D: [F, G, H]; [A, C, E, H]; [A, B, H]
Если каждое устройство в сети должно выбирать путь, который оно будет использовать к месту назначения независимо (без привязки на путь, выбранный любым другим устройством), можно сформировать постоянные петли. Например, A может выбрать путь [D, F, G, H], а D может выбрать путь [A, C, E, H]. Затем устройство A будет перенаправлять трафик к пункту назначения в D, а D затем перенаправит трафик к пункту назначения в A. Должно быть какое-то правило, отличное от выбора пути, реализованного алгоритмом, используемым для вычисления пути на каждом устройстве, например, выбрать самый короткий (или самый дешевый) путь. Но почему выбор кратчайшего (или самого дешевого) пути предотвращает возникновение петли? Рисунок 2 иллюстрирует это.
На рисунке 2 предполагается, что A выбирает путь [D, F, G, H] к месту назначения, а D выбирает путь через A к месту назначения. Чего D не может знать, поскольку он вычисляет путь к месту назначения, не зная, что вычислил A, так это того, что A использует путь через D сам для достижения места назначения. Как может плоскость управления избежать такого цикла? Обратите внимание на то, что стоимость пути вдоль цикла всегда должна включать стоимость цикла, а также элемент пути без петель. В этом случае путь через A с точки зрения D должен включать стоимость от D до места назначения. Следовательно, стоимость через A, с точки зрения D, всегда будет больше, чем наименьшая доступная стоимость из D. Это приводит к следующему наблюдению:
Путь с наименьшей стоимостью (или кратчайший) не может содержать путь, который проходит через вычислительный узел или, скорее, кратчайший путь всегда свободен от петель.
В этом наблюдении есть два важных момента.
Во-первых, это наблюдение не говорит о том, что пути с более высокой стоимостью являются определенно петлями, а только о том, что путь с наименьшей стоимостью не должен быть петлей. Можно расширить правило, чтобы обнаружить более широкий набор путей без петель, помимо пути с наименьшей стоимостью- они называются альтернативами без петель (Loop-Free Alternates).
Во-вторых, это наблюдение справедливо, только если каждый узел в сети имеет одинаковое представление о топологии сети. Узлы могут иметь разные представления о топологии сети по ряду причин, например:
Топология сети изменилась, и все узлы еще не были уведомлены об изменении; отсюда и микропетли.
Некоторая информация о топологии сети была удалена из базы данных топологии путем суммирования или агрегирования.
Метрики настроены так, что путь с наименьшей стоимостью несовместим с разных точек зрения.
Плоскости управления, используемые в реальных сетях, тщательно продуманы, чтобы либо обойти, либо минимизировать влияние различных устройств, имеющих разные представления о топологии сети, что потенциально может привести к зацикливанию пути. Например:
Плоскости управления тщательно настраиваются, чтобы минимизировать разницу во времени между изучением изменения топологии и изменением пересылки (или отбрасывать трафик во время изменений топологии, а не пересылать его).
При обобщении топологии или агрегировании достижимости необходимо позаботиться о сохранении информации о затратах.
"Лучшие общепринятые практики" проектирования сети поощряют использование симметричных метрик, а многие реализации затрудняют или делают невозможным настройку каналов с действительно опасными показателями, такими как нулевая стоимость канала.
Часто требуется много работы, чтобы найти, обойти или предотвратить непреднамеренное нарушение правила кратчайшего пути в реальных протоколах плоскости управления.
Почему бы не использовать список узлов?
На этом этапе должен возникнуть очевидный вопрос: почему бы просто не использовать список узлов для поиска маршрутов без петель? Например, на рисунке 1, если A вычисляет путь через D, может ли D каким-то образом получить путь, вычисленный A, обнаружить, что сам D находится на пути, и, следовательно, не использовать путь через A?
Первая проблема с этим механизмом заключается в процессе обнаружения. Как D должен узнать о пути, выбранном A, и A узнать о пути, выбранном D, не вызывая состояния гонки? Два устройства могут выбрать друг друга в качестве следующего перехода к пункту назначения в один и тот же момент, а затем информировать друг друга в один и тот же момент, в результате чего оба одновременно выбирают другой путь. Результатом может быть либо стабильный набор путей без петель, когда два устройства циклически выбирают друг друга и не имеют пути к месту назначения, либо состояние насыщения, при котором нет пути к месту назначения.
Вторая проблема с этим механизмом - резюмирование - преднамеренное удаление информации о топологии сети для уменьшения количества состояний, переносимых на уровне управления. Плоскость управления будет иметь только метрики, с которыми можно работать, везде, где обобщается топология. Следовательно, лучше использовать правило, основанное на метриках или стоимости, а не на наборе узлов, через которые проходит путь.
Обратите внимание, что обе эти проблемы решаемы. На самом деле существуют алгоритмы вектора пути, которые полагаются на список узлов для вычисления путей без петель через сеть. Хотя эти системы широко распространены, они часто считаются слишком сложными для развертывания во многих ситуациях, связанных с проектированием сетей. Следовательно, широко используются системы на основе метрик или стоимости.
Теперь почитайте материал про построение деревьев в сетях