По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Всем привет! Мы продолжаем рассказывать про маршрутизацию в Cisco Unified Communications Manager (CUCM) и сегодня речь пойдет о Time of Day Routing – распределении звонков по времени. Эта функция позволяет распределять звонки в зависимости от времени и дня недели. Например, это позволит запретить международные звонки в нерабочее время и выходные, а междугородные звонки направлять в это время по другому транку.
Time of Day Routing используется совместно с CSS и Partitions (статью про это можно прочить здесь), и механизмами маршрутизации такими как Route Pattern (статью можно найти тут) и Route List/Route Group (да, про это у нас тоже есть статья).
При работе в связке с Partitions мы указываем желаемый временной промежуток в Time Schedule, и связываем его с разделом Partition. В результате Partition будет активным только в то время, которое мы указали. В остальное время раздел будет оставаться ”невидимым”.
Управлять маршрутами в зависимости от времени можно создав несколько Partitions и выбрав их приоритет в списке CSS (Partition в начале списке имеет наибольший приоритет). Затем создать несколько Route Patterns и поместить их в разные Partitions.
Настройка
Начнем с настройки времени. Для этого переходим во вкладку Call Routing → Class of Control → Time Period и нажимаем Add New. Здесь указываем название для нашего интервала и время его начала и конца, временную зону, а также дни недели, по которым он будет повторяться.
После сохранения диапазона переходим к созданию Time Schedule. Переходим в Call Routing → Class of Control → Time Schedule и тут тоже нажимаем Add New. Сначала указываем название в поле Name, а затем после нажатия Save появляется поле Time Period Information. В поле Available Time Periods помещаем необходимые временные промежутки.
Далее переходим к настройке Partitions. Во вкладке Call Routing → Class of Control → Partition выбираем нужный Partition, либо создаем новый. Здесь в строке Time Schedule, выбираем график, который мы создали.
После этого помещаем Partitions в CSS, во вкладке Call Routing → Class of Control → Class of Control. Приоритет раздела зависит от его позиции в списке.
Затем применяем Partitions к Route Patterns, которые находятся во вкладке Call Routing → Route/Hunt → Route Pattern.
И теперь мы можем распределять звонки в нашей системе по времени.
Перед началом, советуем почитать материал про плоскость управления.
Топология - это набор связей (или ребер) и узлов, которые описывают всю сеть. Обычно топология описывается и рисуется как граф, но она также может быть представлена в структуре данных, предназначенной для использования машинами, или в дереве, которое обычно предназначено для использования людьми.
Топологическую информацию можно обобщить, просто сделав так, чтобы пункты назначения, которые физически (или виртуально) соединены на расстоянии нескольких прыжков, казались непосредственно присоединенными к локальному узлу, а затем удалив информацию о связях и узлах в любой маршрутной информации, переносимой в плоскости управления, с точки суммирования. Рисунок 4 иллюстрирует эту концепцию.
Изучение топологии
Казалось бы, достаточно просто узнать о топологии сети: изучить подключенные каналы передачи данных. Однако то, что кажется простым в сетях, часто оказывается сложным. Изучение локального интерфейса может рассказать вам о канале, но не о других сетевых устройствах, подключенных к этому каналу. Кроме того, даже если вы можете обнаружить другое сетевое устройство, работающее с той же плоскостью управления по определенному каналу, это не означает, что другое устройство может вас обнаружить. Таким образом, необходимо изучить несколько вопросов.
Обнаружение других сетевых устройств
Если маршрутизаторы A, B и C подключены к одному каналу, как показано на рисунке 5, какие механизмы они могут использовать для обнаружения друг друга, а также для обмена информацией о своих возможностях?
Первое, что следует отметить в отношении сети, показанной в левой части рисунка 5, - это то, что интерфейсы не соответствуют соседям. Фактические отношения соседей показаны в правой части рисунка 5. У каждого маршрутизатора в этой сети есть два соседа, но только один интерфейс. Это показывает, что плоскость управления не может использовать информацию об интерфейсе для обнаружения соседей. Должен быть какой-то другой механизм, который плоскость управления может использовать для поиска соседей.
Ручная настройка - одно из широко распространенных решений этой проблемы. В частности, в плоскостях управления, предназначенных для перекрытия другой плоскости управления, или плоскостях управления, предназначенных для построения отношений соседства через несколько маршрутизируемых переходов по сети, ручная настройка часто является самым простым доступным механизмом. С точки зрения сложности, ручная настройка очень мало добавляет к самому протоколу. Например, нет необходимости в какой-либо форме многоадресного объявления соседей. С другой стороны, ручная настройка соседей требует настройки информации о соседях, что увеличивает сложность с точки зрения конфигурации. В сети, показанной на рисунке 5, маршрутизатор A должен иметь отношения соседства, настроенные с помощью B и C, маршрутизатор B должен иметь отношения соседства, настроенные с помощью A и C, а маршрутизатор C должен иметь отношения соседства, настроенные с помощью A и B. Даже если настройка соседей автоматизирована, ручная настройка углубляет и расширяет поверхности взаимодействия между плоскостями управления и контроля.
Определение соседей из маршрутных объявлений - это решение, которое когда-то было широко распространено, но стало менее распространенным. В этой схеме каждое устройство периодически объявляет информацию о доступности и / или топологии. Когда маршрутизатор впервые получает информацию о маршрутизации от другого устройства, он добавляет удаленное устройство в локальную таблицу соседей. Пока соседнее устройство продолжает отправлять информацию о маршрутизации на регулярной основе, отношения между соседями будут считаться активными или активными.
При выводе соседей из объявлений о маршрутизации важно иметь возможность определить, когда сосед вышел из строя (чтобы информация о достижимости и топологии, полученная от соседа, могла быть удалена из любых локальных таблиц). Наиболее распространенный способ решения этой проблемы - использование пары таймеров: таймера задержки или отключения и таймера обновления или объявления. Пока сосед отправляет обновление или объявление в пределах таймера отключения или задержки, он считается включенным или активным. Если весь "мертвый" период проходит без получения каких-либо обновлений, сосед считается "мертвым", и предпринимаются некоторые действия, чтобы либо проверить информацию о топологии и доступности, полученную от соседа, либо он просто удаляется из таблицы.
Нормальная взаимосвязь между таймером отключения и таймером обновления составляет 3× - таймер отключения установлен на трехкратное значение таймера обновления. Следовательно, если сосед не отправляет три подряд обновления или объявления, таймер бездействия активируется и начинает обработку неработающего соседа.
Явные приветствия являются наиболее распространенным механизмом обнаружения соседей. Пакеты приветствия передаются на основе таймера приветствия, и сосед считается "мертвым", если приветствие не получено в течение интервала таймера ожидания или объявления. Это похоже на таймеры dead и update, используемые для вывода соседей из объявлений маршрутизации. Приветствия обычно содержат информацию о соседней системе, такую как поддерживаемые возможности, идентификаторы уровня устройства и т. д.
Централизованная регистрация - это еще один механизм, который иногда используется для обнаружения и распространения информации о соседних устройствах. Каждое устройство, подключенное к сети, будет отправлять информацию о себе в какую-либо службу и, в свою очередь, узнавать о других устройствах, подключенных к сети, из этой централизованной службы. Конечно, эту централизованную службу нужно каким-то образом обнаружить, что обычно осуществляется с помощью одного из других упомянутых механизмов.
Обнаружение двусторонней связи
В плоскостях управления с более сложными процессами формирования смежности - особенно протоколами, которые полагаются на приветствия для формирования отношений соседства - важно определить, могут ли два маршрутизатора видеть друг друга (осуществлять двустороннюю связь), прежде чем формировать отношения. Обеспечение двусторонней связи не только предотвращает проникновение однонаправленных каналов в таблицу пересылки, но также предотвращает постоянный цикл формирования соседей - обнаружение нового соседа, построение правильных локальных таблиц, объявление о доступности новому соседу, тайм-аут ожидания hello или другую информацию, удаление соседа или поиск нового соседа. Существует три основных варианта управления двусторонним подключением между сетевыми устройствами.
Не утруждайте себя проверкой двусторонней связи. Некоторые протоколы не пытаются определить, существует ли двусторонняя связь между сетевыми устройствами в плоскости управления, а скорее предполагают, что сосед, от которого принимаются пакеты, также должен быть доступен.
Перенос списка доступных соседей, услышанных на линии связи. Для протоколов, которые используют приветствия для обнаружения соседей и поддержания работоспособности, перенос списка доступных соседей по одному и тому же каналу является распространенным методом обеспечения двусторонней связи. Рисунок 6 иллюстрирует это.
На рисунке 6 предположим, что маршрутизатор A включен раньше B. В этом случае:
A отправит приветствия с пустым списком соседей, поскольку он не получил приветствия от любого другого сетевого устройства по каналу.
Когда B включен, он получит приветствие A и, следовательно, включит A в список соседей, которые он слышал в своих hello пакетах.
Когда A получает приветствие B, он, в свою очередь, включает B в свой список "услышанных" соседей в своих пакетах приветствия.
Когда и A, и B сообщают друг о друге в своих списках соседей, которые "слышно от", оба маршрутизатора могут быть уверены, что двустороннее соединение установлено.
Этот процесс часто называют трехсторонним рукопожатием, состоящим из трех шагов:
A должен послать привет B, чтобы B мог включить A в свой список соседей.
B должен получить приветствие A и включить A в свой список соседей.
A должен получить приветствие B с самим собой (A) в списке соседей B.
Положитесь на базовый транспортный протокол. Наконец, плоскости управления могут полагаться на базовый транспортный механизм для обеспечения двусторонней связи. Это необычное решение, но есть некоторые широко распространенные решения. Например, протокол Border Gateway Protocol (BGP), опирается на протокол управления передачей (TCP), чтобы обеспечить двустороннюю связь между спикерами BGP.
Определение максимального размера передаваемого блока (MTU)
Для плоскости управления часто бывает полезно выйти за рамки простой проверки двусторонней связи. Многие плоскости управления также проверяют, чтобы максимальный размер передаваемого блока (MTU) на обоих интерфейсах канала был настроен с одинаковым значением MTU. На рисунке 7 показана проблема, решаемая с помощью проверки MTU на уровне канала в плоскости управления.
В ситуации, когда MTU не совпадает между двумя интерфейсами на одном канале, возможно, что соседние отношения сформируются, но маршрутизация и другая информация не будут передаваться между сетевыми устройствами. Хотя многие протоколы имеют некоторый механизм для предотвращения использования информации о результирующих однонаправленных каналах при вычислении путей без петель в сети, все же полезно обнаруживать эту ситуацию, чтобы о ней можно было явным образом сообщить и исправить. Протоколы плоскости управления обычно используют несколько методов, чтобы либо явно обнаружить это условие, либо, по крайней мере, предотвратить начальные этапы формирования соседей.
Протокол плоскости управления может включать локально настроенный MTU в поле в пакетах приветствия. Вместо того чтобы просто проверять наличие соседа во время трехстороннего рукопожатия, каждый маршрутизатор может также проверить, чтобы убедиться, что MTU на обоих концах линии связи совпадает, прежде чем добавлять новое обнаруженное сетевое устройство в качестве соседа.
Другой вариант - добавить пакеты приветствия к MTU локального интерфейса. Если дополненный пакет приветствия максимального размера не получен каким-либо другим устройством в канале связи, начальные этапы отношений соседства не будут завершены. Трехстороннее рукопожатие не может быть выполнено, если оба устройства не получают пакеты приветствия друг друга.
Наконец, протокол плоскости управления может полагаться на базовый транспорт для регулирования размеров пакетов, чтобы коммуникационные устройства могли их принимать. Этот механизм в основном используется в плоскостях управления, предназначенных для наложения какой-либо другой плоскости управления, особенно в случае междоменной маршрутизации и виртуализации сети. Плоскости управления наложением часто полагаются на обнаружение MTU пути (Path MTU) для обеспечения точного MTU между двумя устройствами, подключенными через несколько переходов.
Сам размер MTU может оказать большое влияние на производительность плоскости управления с точки зрения ее скорости сходимости. Например, предположим, что протокол должен передавать информацию, описывающую 500 000 пунктов назначения по многопоточному каналу с задержкой 500 мс, и для описания каждого пункта назначения требуется 512 бит:
Если MTU меньше 1000 бит, для плоскости управления потребуется 500 000 циклов туда и обратно для обмена всей базой данных доступных пунктов назначения, или около 500 000 × 500 мс, что составляет 250 000 секунд или около 70 часов.
Если MTU составляет 1500 октетов или 12000 битов, плоскости управления потребуется около 21000 циклов туда и обратно для описания всей базы данных доступных пунктов назначения, или около 21000 × 500 мс, что составляет около 175 минут.
Важность сжатия такой базы данных с использованием какого-либо оконного механизма для сокращения числа полных обходов, необходимых для обмена информацией о достижимости, и увеличения MTU вполне очевидна.
Далее почитайте материал о том, как происходит обнаружение соседей в сетях.
Как и множество других инструментов для управления и автоматизации на рынке программного обеспечения, Ansible был изначально open – source проектом (с открытым исходным кодом), который предназначался для автоматизации настройки и деплоймента (развертывания) ПО в сетевых контурах компаний. Чего скрывать, продукт «стрельнул» - когда компания AnsibleWorks это поняла, начала активную монетизацию через коммерческую поддержку продукта для корпоративных заказчиков.
/p>
В настоящее время их продуктовая линейка состоит из двух направлений - Ansible и Ansible Tower, причем последний обладает полноценным интерфейсом управления (UI) и возможностью реализации дашбордов.
Ansible - новые ребята в DevOps направлении, по сравнению, например, с Chef или Puppet, но успели круто зарекомендовать себя в сообществе профессионалов за простоту и скоуп возможностей. Его playbooks понятны и легко читаемы, даже без особых знаний.
Так к чему это все? В «правильных руках», где присутствует полное понимание плюсов и минусов продукта Ansible может работать еще круче :) Поэтому, хотим рассказать про 5 лучших и 5 худших свойств Ansible.
Playbooks в Ansible это файл в формате YAML, который содержит последовательность состояния ресурсов системы, задач, которые позволяет запустить то или состояние сервера.
Что такое DevOps, что нужно знать и сколько получают DevOps - специалисты?
5 лучших качеств Ansible
Легкость в изучении
По правде говоря, это одно из самых крутых качеств Ansible – изучить его можно за один вечер и уже запускать веб – сервер из YAML, например. Ansible задачи запускаются последовательно, что сильно облегчает траблшутинг конфигураций. Например, можно сделать Playbook для Ansible, который позволит получить минимальный веб сервер примерно так:
Создаем файл формата .yml и наполняем командами;
Установить через yum apache;
Запустить apache как сервис в операционной системе;
Скопировать в корень веб – сервера html страничку с заглушкой («Мы готовим информацию по сайту, скоро здесь все будет, бла бла бла..»);
Скорректировать iptables, открыв порты и сохранить конфигурацию;
Не сложно, не правда ли?
Написан на Python
Я, как автор статьи, подметил следующее: если мы возьмем 10 программистов, вероятность, что кто-то из них знает Python гораздо выше, чем то, что кто – то из них знает Ruby. Именно это делает Ansible крутым – он написан на питоне в отличие от Ruby – based конкурентов. Так же отмечу, что Python библиотека, обычно, по умолчанию присутствует в любом Linux дистрибутиве, чего не сказать о Ruby.
Продолжая экскурсию – Ansible поддерживает написание модулей на любом языке программирования. Единственное требование – формат ответа. Это должен быть JSON.
Не нужно ставить клиента (агента) на машину
Для управления узлами, Ansible обрабатывает все коммуникации между мастер – узлами и узлами – агентами по стандартному SSH, или через модуль Paramiko, который является частью Python SSH второй версии.
Не нужно ставить агентское ПО на удаленные машины – только SSH подключение. Как следствие, упрощение обслуживания и траблшутинга.
YAML плейбуки
Как мы писали ранее, плейбуки в Ансибл невероятно просты и читаемы. Все DevOps инженеры, с которыми мы обсуждали его, освоили их за один вечер. Они даже проще чем JSON :)
Портал Ansible Galaxy
Портал, на котором вы наверняка найдете решение для своей задачи. Это объединение Ansible сообщества, где люди делятся наработками и решениями той или иной задачи. Знаете, это как ответ на мэйл.ру - чтобы вам не пришло реализовать на Ансибл, то как правило, кто – то эту задачу уже решил :). Тонны плейбуков, фреймворков, дистрибутивов и сопутствующего ПО.
5 худших качеств Ansible
Настало время хорошенько пройтись по Ansible и выделить минусы продукта. Пожестим.
Проблемы с интерфейсом (UI)
Изначально Ansible разработан для работы с командной строкой. Первые наметки в сторону визуализации конфигурации Ансибл начались через AWX – графический интерфейс пользователя, который являлся первой попыткой упрощения конфигураций через интерфейсную составляющую. В последствии, AWX превратился в Anbile Tower, который дает возможность через GUI управлять Ansible, рисовать workflow и так далее.
Несмотря на улучшение Tower перед AWX, он все равно позволяет делать только 85% рабочего функционала Ansible, который можно делать через командную строку. В добавок, конфигурации внесенный через интерфейс зачастую не синхронизируются с CLI – конфигами.
Ansible Tower находится на стадии разработки и пока весьма сыроват.
Нет работы с состоянием машин/процессов
Если сравнивать с тем же Puppet, Ansible не имеет понятия «состояние» и, соответственно, не отслеживает его. Ансибл не смотрит на зависимости, а просто выполняет последовательный ряд задач/процессов. Для кого – то это нормально и удовлетворяет поставленным задачам, но есть и другие пользователи, у которых от такой работы, мягко говоря, «подгорает» :)
Слабая поддержка совместимости с Windows
С версии 1.7 Ansible умеет работать с Unix и Windows узлами, но надо признаться, работа с первыми реализована гораздо лучше. Взаимодействие с Windows машинами происходит через PowerShell, и, что важно, вам все равно потребуется Linux хост (управляющая тачка) для такой коммуникации.
Ждем, когда Ansible разрабы разгребут бэклог по работе продукта с Windows.
Поддержка крупного бизнеса
Ansible Enterprise Tower и Premiun Tower имеют 8х5х4 и 24х7х2 SLA соответственно, но имеют меньше опыта поддержки крупняков, в сравнении, например, с Chef и Puppet.
Новизна продукта
Ansible находится на рынке меньше своих конкурентов и, само собой, баги будут всплывать. К тому же, комьюнити Ансибл только растет и развивается, в отличие от более крупных игроков, упомянутых в этой статье.
Итоги
Подведем черту: Ansible это просто, гибкий и мощный инструмент, для управления конфигами и автоматизацией. Ansible Tower имеет графический веб – интерфейс, REST API, с помощью которого вы можете интегрировать свой сторонние приложения и поддержку, которая только учится и осваивает азы сопровождения крупного энтерпрайза.
Ansible – новинка, которая имеет своих ранних последователей, противников, сторонников. Сочетая в себе большое количество плюсов, он, конечно, имеет ряд недостатков или так сказать «ранних болезней», через которые уже прошли более крупные конкуренты.
Но кто знает, что покажет нам Ansible завтра?