По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В предыдущих статьях были рассмотрены три обширные задачи, которые должна решать каждая плоскость управления для сети с коммутацией пакетов, и рассмотрен ряд решений для каждой из этих задач. Первой рассматриваемой задачей было определение топологии сети и ее доступности. Во-вторых, вычисление свободных от петель (и, в некоторых случаях, непересекающихся) путей через сеть. Последняя задача- это реакция на изменения топологии, на самом деле представляет собой набор задач, включая обнаружение и сообщение об изменениях в сети через плоскость управления.
В этой серии лекций мы объединим эти заждачи и решения путем изучения нескольких реализаций распределенных плоскостей управления, используемых для одноадресной пересылки в сетях с коммутацией пакетов. Реализации здесь выбраны не потому, что они широко используются, а потому, что они представляют собой ряд вариантов реализации среди решений, описанных в предыдущих лекциях. В каждом конкретном случае рассматривается базовая работа каждого протокола; в последующих статьях мы будем углубляться в вопросы сокрытия информации и другие более сложные темы в плоскостях управления, поэтому здесь они не рассматриваются.
Классификация плоскости управления
Плоскости управления обычно классифицируются по двум характеристикам. Во-первых, они разделяются в зависимости от того, где вычисляются loop-free пути, будь то на передающем устройстве или выключенном. Плоскости управления, в которых фактические коммутационные устройства непосредственно участвуют в расчете loop-free путей, затем разделяются на основе вида информации, которую они несут о сети. Классификация, основанная на алгоритме, используемом для вычисления loop-free путей, отсутствует, хотя это часто тесно связано с типом информации, передаваемой плоскостью управления.
В то время как централизованные плоскости управления часто связаны с несколькими (или одним, концептуально) контроллерами, собирающими информацию о достижимости и топологии от каждого коммутационного устройства, вычисляющими набор loop-free путей и загружающими полученную таблицу пересылки на коммутационные устройства, концепция гораздо менее строгая. Ц В более общем смысле централизованная плоскость управления означает просто вычисление некоторой части информации о пересылке где-нибудь, кроме фактического устройства пересылки. Это может означать отдельное устройство или набор устройств; это может означать набор процессов, запущенных на виртуальной машине; это может означать вычисление всей необходимой информации о пересылке или (возможно) большей ее части.
Плоскости распределенного управления обычно различаются тремя общими характеристиками:
Протокол, работающий на каждом устройстве и реализующий различные механизмы, необходимые для передачи информации о доступности и топологии между устройствами.
Набор алгоритмов, реализованных на каждом устройстве, используемый для вычисления набора loop-free путей к известным пунктам назначения.
Способность обнаруживать и реагировать на изменения доступности и топологии локально на каждом устройстве.
В распределенных плоскостях управления не только каждый прыжок (hop by hop) с коммутацией пакетов, но и каждый прыжок определяет набор loop-free путей для достижения любого конкретного пункта назначения локально. Плоскости распределенного управления обычно делятся на три широких класса протоколов: состояние канала, вектор расстояния и вектор пути.
В протоколах состояния канала каждое устройство объявляет состояние каждого подключенного канала, включая доступные пункты назначения и соседей, подключенных к каналу. Эта информация формирует базу данных топологии, содержащую каждое звено, каждый узел и каждый достижимый пункт назначения в сети, через который алгоритм, такой как Dijkstra или Suurballe, может быть использован для вычисления набора loop-free или непересекающихся путей. Протоколы состояния канала обычно заполняют свои базы данных, поэтому каждое устройство пересылки имеет копию, которая синхронизируется с каждым другим устройством пересылки.
В протоколах вектора расстояния каждое устройство объявляет набор расстояний до известных достижимых пунктов назначения. Эта информация о достижимости объявляется конкретным соседом, который предоставляет векторную информацию или, скорее, направление, через которое может быть достигнут пункт назначения. Протоколы вектора расстояния обычно реализуют либо алгоритм Bellman-Ford, либо алгоритм Garcia-Luna’s DUAL, либо аналогичный алгоритм для расчета маршрутов без петель в сети.
В протоколах вектора пути, путь к пункту назначения, записывается по мере того, как объявление о маршрутизации проходит через сеть, от узла к узлу. Другая информация, такая как показатели, может быть добавлена для выражения некоторой формы политики, но первичный, свободный от петель, характер каждого пути вычисляется на основе фактических путей, по которым объявления проходят через сеть.
На рисунке 1 показаны эти три типа распределенных плоскостей управления.
На рисунке 1:
В примере состояния связи- вверху каждое устройство объявляет, что оно может достичь любе друге устройство в сети. Следовательно, A объявляет достижимость B, C и D; в то же время D объявляет достижимость 2001:db8:3e8:100::/64 и C, B и A.
В примере вектора расстояния - в середине D объявляет достижимость до 2001:db8:3e8:100:: 24 до C с его локальной стоимостью, которая равна 1. C добавляет стоимость [D,C] и объявляет достижимость до 2001:db8:3e8:100::64 со стоимостью 2 до B.
В примере вектора пути - внизу D объявляет о достижимости до 2001:db8:3e8:100::/24 через себя. C получает это объявление и добавляет себя к [D,C].
Плоскости управления не всегда аккуратно вписываются в ту или иную категорию, особенно когда вы переходите к различным формам сокрытия информации. Некоторые протоколы состояния канала, например, используют принципы вектора расстояния с агрегированной информацией, а протоколы вектора пути часто используют некоторую форму расположения метрик вектора расстояния для увеличения пути при вычислении loop-free путей. Эти классификации - централизованный, вектор расстояния, состояние канала и вектор пути - важны для понимания и знакомства с миром сетевой инженерии.
Современные предприятия во многом доверяют технологии контейнеризации, чтобы упростить развертывания сложных приложений и управление ими.
Контейнеры собирают необходимые зависимости внутри одного пакета. Таким образом, вам не нужно беспокоится о том, что возникнут какие-либо конфликты зависимостей в эксплуатационной среде.
Контейнеры можно переносить и масштабировать, но для последнего маневра вам понадобится инструмент управления контейнерами.
На сегодняшний день Docker Swarm и Kubernetes – самые популярные платформы для оркестрации контейнеров. Они оба имеют свое конкретное назначение и определенные преимущества и недостатки.
В данной статье мы рассмотрим оба из них, чтобы помочь в выборе инструмента управления контейнерами с учетом ваших требований.
Что такое Docker Swarm?
Docker Swarm – это платформа оркестрации контейнеров с открытым исходным кодом, встроенная в Docker. Он поддерживает оркестрацию кластеров механизмов Docker.
Docker Swarm преобразует несколько экземпляров Docker в один виртуальный хост. Кластер Docker Swarm обычно состоит из трех элементов:
Node - нода
Service и Task – службы и задачи
Load balancer - балансировщик нагрузки
Ноды – это экземпляры механизма Docker, контролирующие ваш кластер, а также контейнеры, используемые для запуска ваших служб и задач.
Балансировка нагрузки также является частью кластеров Docker Swarm и используется для маршрутизации запросов между нодами.
Преимущества Docker Swarm
Docker Swarm довольно прост в установке, поэтому он хорошо подходит для тех, кто только начинает осваивать мир оркестрации контейнеров.
Он легковесный.
В контейнерах Docker Swarm обеспечивает автоматическую балансировку нагрузки.
Поскольку Docker Swarm встроен в Docker, то он работает с интерфейсом командной строки Docker. Помимо этого, он без проблем работает с существующими инструментами Docker, такими как Docker Compose.
Docker Swarm обеспечивает рациональный выбор нод, что позволяет выбрать оптимальные ноды в кластере для развертывания контейнера.
Имеет собственный Swarm API.
Недостатки Docker Swarm
Не смотря на множество преимуществ, Docker Swarm имеет также несколько недостатков.
Docker Swarm сильно привязан к Docker API, что ограничивает его функциональность в сравнении с Kubernetes.
Возможности настройки и расширения в Docker Swarm ограничены.
Что такое Kubernetes?
Kubernetes – это портативный облачный инфраструктурный инструмент с открытым кодом, изначально разработанный Google для управления своими кластерами. Поскольку он является инструментом оркестрации контейнеров, то он автоматизирует масштабирование, развертывание и управление контейнерными приложениями.
Kubernetes имеет более сложную структуру кластера, чем Docker Swarm.
Kubernetes – это многофункциональная платформа, главным образом потому, что она с выгодой для себя использует активную деятельность мирового сообщества.
Преимущества Kubernetes
Он способен поддерживать большую рабочую нагрузку и управлять ей.
У него большое сообщество разработчиков открытого ПО, поддерживаемого Google.
Поскольку он имеет открытый исходный код, то он предлагает широкую поддержку сообщества и возможность работы с разнообразными сложными сценариями развертывания.
Его предлагают все основные поставщики облачных услуг: Google Cloud Platform, Microsoft Azure, IBM Cloud и AWS.
Он автоматизирован и поддерживает автоматическое масштабирование.
Он многофункционален, имеет встроенный мониторинг и широкий спектр доступных интеграций.
Недостатки Kubernetes
Несмотря на то, что Kubernetes обладает большим набором функций, он также имеет и несколько недостатков:
Процесс обучения Kubernetes достаточно сложный, и для освоения Kubernetes требуются специальные знания.
Процесс установки достаточно сложен, особенно для новичков.
Поскольку сообщество разработчиков открытого ПО работает достаточно продуктивно, Kubernetes требует регулярной установки обновлений для поддержания последней версии технологии без прерывания рабочей нагрузки.
Для простых приложений, которые не требуют постоянного развертывания, Kubernetes слишком сложный.
Kubernetes VS Docker Swarm
Теперь, когда мы узнали все преимущества и недостатки Kubernetes и Docker Swarm, давайте посмотрим, чем же они отличаются друг от друга.
Основное различие этих двух платформ заключается в их сложности. Kubernetes хорошо подходит для сложных приложений, а Docker Swarm разработан для простоты использования, что говорит о том, что его предпочтительнее использовать с простыми приложениями.
Далее приведем подробное описание нескольких различий между Docker Swarm и Kubernetes:
Установка и настройка
Kubernetes можно настроить, но сделать это будет не так просто. Docker Swarm установить и настроить намного легче.
Kubernetes: в зависимости от операционной системы ручная установка может отличаться. Если вы пользуетесь услугами поставщика облачных технологий, то установка не требуется.
Docker Swarm: экземпляры Docker обычно одинаковы для различных операционных систем и поэтому довольно просты в настройке.
Балансировка нагрузки
Docker Swarm предлагает автоматическую балансировку нагрузки, а Kubernetes – нет. Однако в Kubernetes легко интегрировать балансировку нагрузки с помощью сторонних инструментов.
Kubernetes: службы можно обнаружить через одно DNS-имя. Kubernetes обращается к контейнерным приложениям через IP-адрес или HTTP-маршрут.
Docker Swarm: поставляется со встроенными балансировщиками нагрузки.
Мониторинг
Kubernetes: имеет встроенный мониторинг, а также поддержку интеграции со сторонними инструментами мониторинга.
Docker Swarm: нет встроенных механизмов мониторинга. Однако он поддерживает мониторинг через сторонние приложения.
Масштабируемость
Kubernetes: обеспечивает масштабирование в зависимости от трафика. Встроено горизонтальное автомасштабирование. Масштабирование Kubernetes включает в себя создание новых модулей и их планирование для узлов с имеющимися ресурсами.
Docker Swarm: обеспечивает быстрое автоматическое масштабирование экземпляров по запросу. Поскольку Docker Swarm быстрее развертывает контейнеры, то это дает инструменту оркестрации больше времени на реакцию, что позволяет масштабировать по требованию.
Какую платформу все же выбрать?
И Kubernetes, и Docker Swarm служат для конкретного назначения. Какой из них лучше, зависит от ваших текущих потребностей или потребностей вашей организации.
При запуске Docker Swarm – это простое в использовании решение для управления вашими контейнерами. Если вам или вашей компании не нужно управлять сложными рабочими нагрузками, то Docker Swarm – правильный выбор.
Если же ваши приложения имеют более ключевую роль, и вы хотите включить функции мониторинга, безопасности, высокой доступности и гибкости, то Kubernetes – вот ваш выбор.
Подведем итог
Благодаря этой статье мы узнали, что такое Docker Swarm и Kubernetes. Также мы узнали об их плюсах и минусах. Выбор между этими двумя технологиями достаточно субъективен и зависит от желаемых результатов.
Сталкивались ли вы задачей одновременной типовой настройки телефонный аппаратов? Например, настроить 50 штук IP – телефонов Yealink. Эта задача будет достаточно рутинной и затратной по времени. В FreePBX создан модуль End Point Manager, который позволяет создать шаблон настроек для определенных групп устройств и затем перенести его на телефонные аппараты. О нем и поговорим.
/p>
Пару слов про модуль End Point Manager
Как уже сказано выше, модуль EPM позволяет производить автоматическую настройку различных единиц оборудования, от конечных телефонных аппаратов до шлюзов. Условно говоря, настройка модуля делится на следующие сегменты:
Global Settings - глобальные настройки модуля, такие как IP – адрес Asterisk и прочие
Extension Mapping - раздел, в котором сопоставляется шаблон и MAC – адрес устройства
Brands - в разделе можно посмотреть марки оборудования, которые были сконфигурированы с помощью EPM
Модуль является платным и стоит 75$ на 25 лет. В бесплатной версии модуля, доступна только настройка телефонов марки Sangoma. Полный перечень приведен в таблице ниже.
Add Brand - добавьте необходимые брэнды оборудования, для которого вы бы хотели создать шаблон
Image Management - здесь можно загрузить картинку в формате GIF, JPEG, или PNG и размером не более 20 мегабайт, которая будет использоваться на оконечных телефонов, например в роли фонового изображения. Данный функционал работает только на устройствах с поддержкой фонового изображения
Basefile Edit - данный раздел позволяет менять различные значения, которые нельзя изменить через стандартные настройки телефона, например через его GUI. Представляет из себя XML – файл. Рекомендуем настраивать данный раздел только в том случае, если вы точно знаете что делаете.
Custom Extensions - раздел аналогичен настройке в модуле Custom Extension
Firmware Management - раздел служит для обновления прошивки телефонов.
Network Scan - сетевая утилита, которая позволяет сканировать указанную сеть на предмет наличия в ней поддерживаемых устройств и уточнения их MAC - адресов
Без приобретения лицензии на модуль вы сможете работать со следующими устройствами:
Производитель
Модель
Поддержка фонового изображения
Sangoma
s300
Нет
Sangoma
s500
Да
Sangoma
s700
Да
Sangoma
Vega 50-4FXS
-
Sangoma
Vega 50-8FXS
-
Sangoma
Vega 3000-24FXS
-
Sangoma
Vega 5000-24FXS
-
Sangoma
Vega 5000-50FXS
-
Поддерживаемые без лицензии устройства
В случае оплаты модуля, для работы будут доступны Aastra, Algo, Audio Codes, Cisco, Cortelco, CyberData, Digium, Grandstream, Mitel, Mocet, Obihai, Panasonic, Phoenix Audio, Polycom, Snom, Uniden, VTech, Xorcom и всеми любимый Yealink.
Настройка Global Settings
В настройках EPM переходим в раздел Global Settings:
Internal IP Address - укажите IP – адрес вашего Asterisk. В нашем случае это 192.168.0.77
External IP Address - если какие-то из ваших телефонов будут подключаться к АТС из внешней сети, то в данном поле укажите внешний IP – адрес или FQDN (Fully Qualified Domain Name)
Ports - в разделе будут указаны порты для WEB – доступа, порт для HTTP провижининга
(автоматической настройки телефонов) и RESTful приложений
Phone Admin Password - все управляемые телефоны имеют пароль для администратора. В данном поле вы можете указать его для всех устройств
Phone User Password - некоторые модели телефонов, например Cisco, имеют систему авторизации для администратора через обычного пользователя. Здесь нужно указать его пароль
ReSync Time - через указанное время телефоны будут обращаться к серверу на предмет изменения в их конфигурационных файлах. По умолчанию, время равно 86400 секунд, что есть 1440 минут, что в свою очередь ровняется 24 часа :)
XML-API (RestAPI) Default Login - включение/выключение данной опции позволяет телефону обращаться к различным приложениям через RestAPI
Extension Mapping IP Addresses - отображать ли IP – адрес устройства на этапе сопоставления телефона и внутреннего номера
Extension Mapping Phone Status - отображать ли время пинга до устройства. Оба параметра замедляют работу.
По окончанию настроек нажмите Save Global
Настройка шаблона настроек
Переходим к настройкам. Сделаем шаблон на примере производителя Sangoma. Для этого, в настройках модуля, в блоке Brands, выберем Sangoma. Для добавления нового шаблона нажимаем New Template. Производим настройки в первой вкладке, которая называется General:
Template Name - даем имя для нашего шаблона. Например, New_template
Default Template - будет ли данный шаблон шаблоном по умолчанию для телефонов. Выставляем Default
Destination Address - в данном поле необходимо указать IP – адрес или доменное имя для нашей IP – АТС Asterisk. При нажатии на кнопки Internal или External, при сохранении, в поле будет автоматически подставлено значение внутреннего или внешнего IP – адреса АТС соответственно. Это удобно в том случае, если мы делаем разные шаблона для внутренних телефонов и для внешних.
Provision Server Address - сервер, к которому телефон будет обращаться за конфигурацией. По умолчанию это наш Asterisk
Provision Server Protocol - протокол, который будет использовать IP – телефон чтобы получить файл конфигурации. Оставьте в данном поле TFTP
Переходим во вкладку Regional
Time Zone - временная зона. Поле прибавляет, или удаляет определенное количество часов к GMT (среднее время по Гринвичу). Например, в Москве GMT +03:00 и мы выбираем +03.00
Primary Time Server - главный сервер синхронизации времени по протоколу NTP. Вы можете посмотреть список серверов в интернете
Daylight Savings -опция подсказывает телефону, использовать ли настройки DST (Daylight Saving Time) – то есть сезонное время
Country Tones - опция настройки гудка. В разных странах они различаются, выберите подходящий
Web GUI Language - язык графического интерфейса администрирования IP - телефона
LCD Display Language - язык на дисплее телефона
Date Format - формат даты. Нам привычно ДД-ММ-ГГ
Time Format - формат времени. Мы выбрали 24 часовой формат
Двигаемся дальше и переходим во вкладку Options. Разберем здесь самые основные опции:
Background Image - выберите фоновое изображение, которое ранее, было залито с помощью пункта меню Image Management
Line Label - информация, которая будет отображаться о пользователе телефона на главном дисплее. Может быть следующих видов:
Name - имя пользователя. Например, «Иван Петров»
Extension - показывать только номер абонента. Например, «101»
Name-Extension - показывать и имя и номер. Например, «Иван Петров 101»
Multicast Enable - поддержка Multicast пейджинга
Функционал Multicast Paging появился в 13 версии FreePBX. Если коротко, то теперь телефон может отправлять на заранее сконфигурированный широковещательный адрес пейджинг запросы. Более подробно вы можете почитать в статье про новинки FreePBX 13
Multicast Address - мультикаст адрес, о котором мы рассказали выше
Dial Patterns - шаблон набора номеров для IP - телефона
Ring Tone - выбрать номер звукового сопровождения для звонка (рингтон)
Screen Saver - что показывать на дисплее телефона по таймауту бездействия Screen Saver Timeout
Call Waiting Signal - хотите ли вы услышать звуковой сигнал, при условии того, что вы уже разговариваете с одним из абонентов и вам поступает второй звонок
BLF Alert - тип индикатора BLF. Это может быть визуальное мигание, аудио сопровождение или оба сразу
По окончанию настроек не забываем нажимать Save Template
Соответствие телефона и шаблона
После того, как мы произвели настройку шаблона его необходимо проассоциировать с телефонным аппаратом. Мы будем делать это с помощью MAC – адреса устройства. Переходим в раздел Extension Mapping и нажимаем Add Extension
В столбце слева выбираем необходимый номер
По середине, выбираем производителя и вводим MAC – адрес телефона
В левом столбце выбираем шаблон и модель телефона
Теперь, чтобы доставить на телефоны адрес TFTP сервера (адреса нашего Asterisk в данном случае), в настройках DHCP сервера необходимо настроить параметр option 150 с IP – адресом TFTP. Телефон обратиться на сервер с просьбой предоставить файл конфигурации для устройства с его MAC – адресом, которое мы создали на этапе ранее.