По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Офисная IP – телефония является неотъемлемой частью современной структуры успешного бизнеса, которая работает параллельно с сотрудниками компании на общее благо. Даже когда заканчивается рабочий день, система продолжает свою работу, имея четки временные указания, как обрабатывать поступивший вызов в тот или иной момент времени. О том, как настроить временные группы и временные условия в IP – АТС Elastix 4 расскажем в статье
Терминология
Перед тем, как приступить к настройке, разберемся к это работает. В Elastix существуют временные условия (time conditions) и временные группы (time groups). Первые служат для выбора маршрута, если вызов попал в определенные временные рамки, а вторые, для определения этих временных рамок. Итак:
Time Condition - условия. Работают так: если время входящего вызова попало под условия, сформулированные в параметре Time Group, то вызов нужно отправить в направлении А, а если нет, то в направлении Б;
Time Groups - тайм – слоты. Например, с понедельника по пятницу, с 10 – 19, или в субботу с 14 – 15 и так далее;
Настройка Time Groups
Пусть задача у нас такова: наша организация работает с понедельника по пятницу, с 10 – 19 часов. Первым делом настроим Time Groups (временные группы). Для этого, переходим в раздел PBX → PBX Configuration → Time Groups:
Для сегментации вызовов, поступающих по будням, с 10 до 19 часов, производим следующие настройки:
Time to start: - 10:00
Time to finish: - 19:00
Week Day start: - Monday
Week Day finish: - Friday
Готово. Переходим к настройке временных условий.
Настройка Time Conditions
Продолжаем. Теперь настроим временные условия. Для этого, перейдите в раздел PBX → PBX Configuration → Time Conditions :
Выполняем следующие настройки:
Time Condition name - имя для временного условия. Например, work
Time Group - временная группа, которую мы создали ранее.
Destination if time matches - куда направлять вызов, если временное условие совпало (диапазон с понедельника по пятницу, с 10 – 19). В нашем примере, вызов отправится на голосовое приветствие, которое предназначено для звонящих в будние дни.
Destination if time does not match - куда направлять вызов, если временное условие не совпало. Мы отправляем на голосовое приветствие Holiday.
Готово. Нажимает Submit, а затем Apply Config.
Применение настроек в продуктивной среде
Чтобы наши настройки применялись ко всем входящим вызовам, повесим их в качестве назначения на входящем маршруте в поле Set Destination. Готово!
В больших корпоративных сетях могут использоваться несколько протоколов внутренней маршрутизации. Такая практика часто встречается при слиянии двух компаний. Чтобы компьютеры в одном домене маршрутизации (далее просто «домен») видели хосты в другом домене применятся так называемая редистрибуция. Эта функция позволяет маршрутизатору выбрать маршрут, выученный через один протокол маршрутизации, например, EIGRP и добавить в его в список анонсируемых сетей в другой, например, OSPF. Эта операция выполняется на маршрутизаторах, который смотрят в обе сети и называются точкой редистрибуции (Redistirbution Point). Маршрутизаторы, которые занимаются анонсированием сетей из одного домена в другой используют для этого таблицу маршрутизации. Другими словами, если маршрутизатор не найдет путь до какой-то сети в своей таблице, то он не будет анонсировать его в другой домен.
Схема сети
Для построения отказоустойчивой сети обычно применяются два или более маршрутизатора, которые занимаются перебросом маршрутной информации с одного домена в другой. В такой ситуации может образоваться так называемая петля маршрутизации. Поясним на рисунке:
В данном случае пакеты из маршрутизатор 2, чтобы добраться до сети Х, которая находится в том же домене делает круг через RD1 > R1 > RD2 > Subnet X. Это происходит потому, что маршрут, объявленный RD1 в Домен маршрутизации 2, имеет меньшее административное расстояние (Administrative Distance, AD), чем маршруты, объявленные роутерами из того же домена. Далее рассмотрим в каких случаях возможно такое.
Как избежать петель?
Один из самых лёгких методов для избегания петель маршрутизации это при добавлении маршрутов из одного домена в другой более высокой метрики.
В данном случае маршрутизаторы RD1 и RD2 при анонсировании маршрутов, выученных протоколом RIP в домен OSPF, назначают им метрику 500. И наоборот, из домена OSPF в домен RIP маршруты анонсируются с метрикой 5.
Второй способ – это административное расстояние. Любой маршрут, который добавляется в таблицу маршрутизации роутера, сопоставляется с административным расстоянием. Если роутер получил несколько маршрутов в одну и ту же сеть с одной и той же длиной префикса, то в таблицу попадают маршруты с меньшим AD. Маршрутизатор не учитывает метрику. Вместе с этим, AD – это локальное значение для каждого роутера и не объявляется соседним маршрутизаторам. В таблице ниже приведены административные расстояния для всех типов маршрутов на роутерах Cisco.
Тип маршрутаАдминистративное расстояниеConnected (подключённый)0Static (Статический)1EIGRP Summary route5eBGP (external BGP)20EIGRP (internal)90IGRP100OSPF110IS-IS115RIP120EIGRP (external)170iBGP (internal BGP)200
Настройки AD по умолчанию для протокола EIGRP при анонсировании маршрутов в OSPF и RIP предотвращают образование петель маршрутизации.
На рисунке выше подсеть 172.16.35.0/24 анонсируется через RD1 в домен OSPF. Маршрутизатор R2 в свою очередь анонсирует выученную через external OSPF сеть роутеру RD2. Но RD2 уже выучил маршрут до сети 35.0 через EIGRP, у которого административное расстояние равно 90, что меньше чем AD OSFP, которое равно 110. Таким образом RD2 не добавит маршрут, полученный у R2 с AD 110 в таблицу маршрутизации и соответственно не будет редистрибутировать обратно в EIGRP. Таким образом логику работы маршрутизатора RD2 можно сформулировать следующим образом:
RD2 считает маршрут, полученный по EIGRP лучшим, так как у него меньшее административное расстояние, и добавляет его в таблицу маршрутизации.
RD2 не будет анонсировать маршрут, полученный через OSPF, так как его нет в таблице маршрутизации.
В силу своей специфик, протокол EIGRP также предотвращает образование петель маршрутизации при редистрибуции из OSPF и RIP. Как было указано на таблице выше, внешние маршруты в EIGRP имеют административное расстояние равным 170.
В данном случае маршрутизатор RD2 выучил два маршрута в сеть 192.168.11.0/24. Один через R2 в домене OSPF с AD равным 110, второй через R1 в домене EIGRP с административным расстоянием равным 170-ти. Действуя по указанной выше логике, RD2 добавит в таблицу маршрутизации сеть 11.0 выученный у роутера R2 предотвращая таким образом образование петли.
Если в случае EIGRP-OSPF, EIGRP-RIP нам удалось без особых усилий предотвратить петлю маршрутизации, то в случае OSPF-RIP всё немного сложнее. Так как OSPF для всех типов маршрутов использует один показатель AD – 110, то при редистрибуции между RIP и OSPF избежать петель удается только изменение административного расстояния протоколов маршрутизации. Делается это командой distance. Для изменения показателя AD для внешних маршрутов, в интерфейсе настройки OSPF прописываем команду distance external ad-value. Значение, указанное параметром должно быть больше, чем у RIP (120).
Но не редки случаи, когда в сети работают более двух протоколов маршрутизации. В таких случаях значения AD по умолчанию не помогают. На рисунке ниже сеть 172.20.0.0/16 выучена протоколом EIGRP как внешний через RIP с АР (Административное Расстояние) равным 170. В свою очередь RD1 анонсирует данную сеть в домен OSPF с АР равным 110. RD2 же вместо маршрута с АР 170, полученного из домена EIGRP в таблицу добавляет маршрут с АР 110, полученный из домена OSPF. При таком раскладе маршрутизатор R4 получает два маршрута в одну и ту же сеть с одним и тем же АР. И в случае если метрика RD2 лучше, то R4 отправке пакетов в сеть 172.20 будет использовать более длинный путь. Нужно заметить, что это только в том случае, когда домены расположены именно в указанном порядке.
В таких случаях применяется настройка административного расстояния в зависимости от маршрута. Как было указано выше, для изменения АР используется команда distance. Эта команда принимает несколько параметров:
distance distance ip-adv-router wc-mask [ acl-number-or-name ]
В данной команде обязательным параметром является IP соседнего маршрутизатора. Если IP адрес анонсирующего маршрутизатора совпадёт с указанными в команде, то для маршрутов, полученных от этого соседа данный роутер назначит указанный в команде АР.
Рассмотрим указанный случай на практике. Детальная топология сети, показанная выше, указана на рисунке, а конфигурацию можете скачать по ссылке ниже:
Скачать файлы конфигрурации
Для начала просмотрим с каким АР RD1 выучил маршрут до сети 172.20:
Как видим, RD1 добавил в таблицу маршрутизации маршрут, выученный через OSPF, вместо EIGRP, так как АР у OSPF меньше. Теперь изменим поведение маршрутизатора и посмотрим, как это повлияет на таблицу маршрутизации.
ip access-list standard match-172-20
permit host 172.20.0.0
router ospf 2
distance 171 1.1.1.1 0.0.0.0 match-172-20
P.S. В GNS скорее всего придётся выключить, затем включить интерфейс, смотрящий в OSPF домен, чтобы изменения применились. В реальной сети всё работает правильно.
Поясним, что мы написали выше. Со стандартным списком доступа всё понятно. Команде distance параметром задали 171 – административное расстояние. Затем идет router id маршрутизатора, который анонсирует сеть 172.20. В нашем случае это маршрутизатор RD1. Таким образом, OSPF посмотрит полученный LSA и, если там увидит идентификатор маршрутизатора RD1, а также сеть, которая указана разрешённой в списке доступа, то применит этому маршруту расстояние 171.
Отметим, что указанную конфигурацию нужно сделать на всех роутерах, которые занимается распределением маршрутов и для всех сетей их третьего домена.
В этой статье вы узнаете о различных инструментах управления Kubernetes, которые можно использовать для управления кластерами Kubernetes.
В формирующейся облачной инфраструктуре Kubernetes повсюду, без сомнения, он стал стандартом для оркестрации контейнеров. Но обеспечение согласованной и безопасной работы нескольких кластеров Kubernetes, представляет собой новый набор проблем. Поэтому возникает потребность в инструментах управления Kubernetes.
Давайте рассмотрим некоторые популярные решения для эффективного управления Kubernetes.
Что такое DevOps, что нужно знать и сколько получают DevOps - специалисты?
1. K9s
k9s - панель мониторинга ресурсов на основе терминалов. Он имеет только интерфейс командной строки. Все что делали через веб-интерфейс панели мониторинга Kubernetes, вы можете сделать с помощью этой утилиты панели мониторинга терминала k9s.
Он постоянно следит за кластером Kubernetes и предлагает команды для работы с определенными ресурсами кластера.
Ниже приведены K9s функции:
Отслеживание состояния кластера в реальном времени
Настройка вида с помощью обложек K9s
Легкий переход между ресурсами Kubernetes
Параметры развертывания для проверки проблем с ресурсами кластера
Предоставляет расширенные подключаемые модули для создания собственных команд
2. Rancher
Rancher - платформа управления контейнерами с открытым исходным кодом, которая позволяет любому предприятию легко перенять Kubernetes. Вы можете развертывать и управлять облачными кластерами Kubernetes, работающими в GKE (GCP), EKS (AWS), AKS (Azure), или просто развертывать Kubernetes на виртуальных или физических машинах на ваш выбор.
Rancher упрощает все повседневные обязанности администратора, включая:
Мониторинг работоспособности кластеров
Настройка оповещений и уведомлений
Включение централизованного ведения журнала
Определение и применение глобальных политик безопасности
Установление аутентификации и применение наших политик обратной связи
Управление инфраструктурой и ее масштабирование
По мере ускорения внедрения Kubernetes в вашей компании, Кancher поощряет быстрое внедрение предоставления пользователям доступа непосредственно к Kubernetes API и CLI. Новый интеллектуальный интерфейс Rancher упрощает управление приложениями; команды могут легко развертывать рабочие нагрузки и управлять ими, определять объекты типа Секрет и управлять частными репозиториями, настраивать требования постоянных томов, настраивать балансировку нагрузки и обнаружение служб, управлять конвейерами CI.
3. Dashboard + Kubectl + Kubeadm
Панель управления Kubernetes представляет собой веб-интерфейс для развертывания контейнерных приложений. Он ищет и устраняет неисправности приложений и управляет кластером вместе с ресурсами.
С помощью панели мониторинга можно получить обзор приложений, запущенных в кластере, а также создать или изменить отдельные ресурсы Kubernetes, такие как задания развертывания, наборы реплик и многое другое.
Можно масштабировать развертывание или инициировать скользящее обновление, или даже перезапустить модуль или развернуть новые приложения с помощью мастера развертывания на панели мониторинга.
Kubectl - это средство командной строки для взаимодействия со службой API и отправки команд на главный узел. Его скрытые команды для вызовов API на сервер cluster API Kubernetes.
Kubeadm - это инструмент со встроенными командами для запуска минимального кластера Kubernetes. Он используется для начальной загрузки кластера, а не для подготовки компьютеров. С помощью kubeadm можно выполнить некоторые основные команды для загрузки кластера, создания маркера для присоединения к кластеру, возврата изменений, внесенных в кластер Kubernetes, и т.д.
4. Helm
Helm - менеджер пакетов для Kubernetes. Она позволяет разработчикам и операторам упаковывать, настраивать и развертывать приложения и службы в кластере Kubernetes. Он дает операторам больший контроль над кластерами Kubernetes, которые включают:
Упрощение, стандартизацию и многократное использование развертывания приложений
Простое описание сложных приложений с помощью диаграмм helm
Повышение производительности разработчиков
Снижение сложности развертывания
Повышает эксплуатационную готовность
Ускорение внедрения облачных приложений
Упрощает откат к предыдущей версии
Helm использует диаграммы, содержащие все определения ресурсов, для запуска приложений или служб в кластере Kubernetes. Здесь можно найти несколько helm диаграмм.
5. KubeSpray
KubeSpray - это диспетчер жизненного цикла кластера, который помогает развернуть готовый к эксплуатации кластер Kubernetes. Для автоматизации выделения ресурсов кластеров Kubernetes используется ansible-playbook.
Вот некоторые функции, которые включает в себя KubeSpray:
Основан на Ansible
Высокая доступность
Кроссплатформенность
Уровень производства
Возможность интеграции как с популярными поставщиками облачных инфраструктур, так и с железом
Различные опции конфигурации
Много платформенный CI/CD
Безопасность по умолчанию
По умолчанию Kubespray позволяет удаленно подключаться к кластеру Kubernetes через IP-адрес kube-master и порт 6443. Kubespray лучше всего подходит, если вам нужна гибкость в развертывании; он предоставляет множество пользовательских опций конфигурации.
Также, если вы знакомы с Ansible, то использование Kubespray вам покажется очень простым.
6. Kontena Lens
Kontena Lens - умная приборная панель для Kubernetes.
Это единственная система управления, которая вам понадобится, чтобы взять под контроль ваш Kubernetes. Он бесплатно доступен для операционных систем Mac OS, Windows и Linux. После запуска приложения Lens в интерфейсе появится список всех связанных кластеров.
Это самая мощная IDE для людей, которые действительно должны иметь дело с Kubernetes ежедневно. Вы можете обеспечить правильную настройку и настройку кластеров, а также более простую и быструю работу с кластерами и радикальное повышение производительности и скорости бизнеса.
Функции IDE Kontena Lens:
Возможность управления несколькими кластерами одновременно
Визуализация состояния кластера в реальном времени
Предоставляет встроенный терминал
Очень простая установка, поскольку это автономное приложение
Потрясающие возможности пользовательского интерфейса и пользователя
Поддерживается Kubernetes RBAC.
Протестировано для обработки почти 25K модулей в кластере
Kubernetes - это сложный инструмент, и Lens IDE помогает даже новичкам легко начать работу с Kubernetes. Это один из лучших инструментов для управления и визуализации кластеров Kubernetes.
7. WKSctl
WKSctl обозначает управление системой Weave Kubernetes. Является частью Wave Kubernetes Platform.
WKSctl - это инструмент, использующий GitOps для управления конфигурацией Kubernetes. GitOps - это не что иное, как набор практик, которые используют запросы git для управления приложениями и инфраструктурой традиционным способом.
С помощью WKSctl можно управлять кластерами Kubernetes через Git commits. Можно обновить кластер, добавлять или удалять узлы из кластера.
Этот инструмент можно запускать в 2 режимах: автономном и режиме GitOps. В автономном режиме создается статический кластер. В режиме GitOps он настраивает кластер в соответствии с данными cluster.yml и machines.yml, имеющимися в git.
Функции WKSctl:
Быстрый запуск кластера с git
Откат в случае сбоя развертывания
Регистрация изменения для рассмотрения и аудита
Для создания кластера требуются только IP-адрес и ключи ssh
Непрерывная проверка и корректировка состояние кластера
Заключение
Это был краткий обзор популярных инструментов управления Kubernetes кластерами. Выберите любой из вышеупомянутых инструментов и опробуйте его на своем кластере Kubernetes!