По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
Привет! В этой статье мы рассмотрим Partitions и Calling Search Space (CSS) в Cisco Unified Communications Manager (CUCM) , которые являются частью механизма Class of Control и применяются при разграничении доступов. /p> Partitions можно рассматривать как набор маршрутов, паттернов, номеров DN, каждый из которых может принадлежать к определенным разделам. CSS же представляет собой упорядоченный список Partitions. Чтобы совершить вызов Partition вызываемой стороны должен принадлежать CSS вызывающей стороны. При попытке выполнить вызов CUCM просматривает CSS вызывающей стороны и проверяет, принадлежит ли вызываемая сторона Partition’у в CSS. Если это так, вызов направляется в Translation Pattern. Если нет, то вызов отклоняется или Translation Pattern игнорируется. Подробнее про маршрутизацию и Translation Pattern’ы можно прочить в наших статьях. Можно назначить разные CSS IP-телефонам, номерам DN, переадресации всех вызовов (Call Forwarding All – CFA), переадресации без ответа (Call Forwarding No Answer - CFNA), переадресации вызовов в случае занятости (Call Forwarding Busy - CFB), шлюзов и паттернам Translation Pattern. Разделы и CSS облегчают маршрутизацию вызовов, поскольку они делят план маршрутизации на логические подмножества на основе организации, местоположения и/или типа вызова. Чтобы лучше понять, как все это работает, рассмотрим пример. Пример использования Partitions и CSS Этот пример иллюстрирует, как можно разграничить маршрутизацию звонка между пользователями в пределах организации. Допустим, у нас имеется три группы пользователей: Стажеры (могут звонить только на внутренние номера) Работники (могут звонить на внутренние номера и совершать междугородние звонки) Руководство (могут звонить на внутренние номера, совершать междугородние и международные звонки) Для каждого направления необходимо иметь Partition: Внутренние номера –Partition_1 Междугородние звонки – Partition_2 Международные звонки – Partition_3 Эти разделы отражают все возможные направления звонков. Все телефоны (номера DN) мы поместим в раздел Partition_1 (внутренние номера). На шлюзе сконфигурировано два паттерна Route Patterns: Все звонки кроме международных (поместим в раздел Partition_2) Международные звонки (поместим в раздел Partition_3) На основании этих ограничений создаем три CSS: CSS1 содержит разделы: Partition_1 CSS2 содержит разделы: Partition_1, Partition_2 CSS3 содержит разделы: Partition_1, Partition_2, Partition_3 Настраиваем телефоны: На телефонах стажеров указываем CSS1 На телефонах работников указываем CSS2 На телефонах руководства указываем CSS3 Теперь совершим тестовые звонки с заданными настройками. Тест 1: Звонок с телефона стажера Набран внутренний номер: Вызываемый абонент: Partition_1 Разделы CSS вызывающего абонента: Partition_1 Результат: Вызов выполнится (раздел Partition_1 включен в CSS) Набран междугородний номер: Вызываемый абонент: Partition_2 Разделы CSS вызывающего абонента: Partition_1 Результат: Вызов не выполнится (раздел Partition_2 не включен в CSS) Набран международный номер: Вызываемый абонент: Partition_3 Разделы CSS вызывающего абонента: Partition_1 Результат: Вызов не выполнится (раздел Partition_3 не включен в CSS) Тест 2: Звонок с телефона работника Набран внутренний номер: Вызываемый абонент: Partition_1 Разделы CSS вызывающего абонента: Partition_1, Partition_2 Результат: Вызов выполнится (раздел Partition_1 включен в CSS) Набран междугородний номер: Вызываемый абонент: Partition_2 Разделы CSS вызывающего абонента: Partition_1, Partition_2 Результат: Вызов выполнится (раздел Partition_2 включен в CSS) Набран международный номер: Вызываемый абонент: Partition_3 Разделы CSS вызывающего абонента: Partition_1, Partition_2 Результат: Вызов не выполнится (раздел Partition_3 не включен в CSS) Тест 3: Звонок с телефона руководства Набран внутренний номер: Вызываемый абонент: Partition_1 Разделы CSS вызывающего абонента: Partition_1, Partition_2, Partition_3 Результат: Вызов выполнится (раздел Partition_1 включен в CSS) Набран междугородний номер: Вызываемый абонент: Partition_2 Разделы CSS вызывающего абонента: Partition_1, Partition_2, Partition_3 Результат: Вызов выполнится (раздел Partition_2 включен в CSS) Набран международный номер: Вызываемый абонент: Partition_3 Разделы CSS вызывающего абонента: Partition_1, Partition_2, Partition_3 Результат: Вызов выполнится (раздел Partition_3 включен в CSS) Таким образом, получается, что вызовы совершать можно, только если раздел Partition вызываемого абонента находится в CSS вызывающего. Настройка Начнем с настройки Partitions. В Cisco Call Manager Administration переходим во вкладку Call Routing → Class of Control → Partition и нажимаем Add New. Здесь в поле Name указываем название для раздела и нажимаем Save. Теперь перейдем к созданию CSS. Для этого выберем вкладку Call Routing → Class of Control → Calling Search Space. Тут указываем имя в поле Name, из поля Available Partitions перенесем в поле Selected Partitions разделы, которые должен содержать CSS. Перенос осуществляется при помощи стрелочек. После чего нажимаем кнопку Save для сохранения. После того как мы создали CSS и Partitions на наших серверах, применим их к устройствам. Рассмотрим это на примере настройки телефона. Для этого выбираем телефон, который мы хотим настроить во вкладке Device → Phone. В его настройках выбираем желаемую линию и нажимаем на нее, например Line [1] . В открывшемся окне в строке Route Partition в выпадающем списке выбираем раздел для этой линии. После этого нажимаем Save и возвращаемся назад. Теперь нам осталось применить к телефону CSS. Здесь, в настройках телефона в поле Device Information находим строчку Calling Search Space и в выпадающем меню выбираем созданный ранее CSS. Затем сохраняем и применяем настройки. Аналогично мы можем настраивать Partitions и CSS на других устройствах, паттернах и номерах.
img
Третья статья будет посвящена поиску и устранению неисправностей EtherChannels. Большинство проблем с EtherChannels происходит из-за неправильной конфигурации. Предыдущие статьи этого цикла: Устранение неполадок коммутации Cisco Траблшутинг STP (Spanning tree protocol) Case #1 В этом сценарии есть только два коммутатора и два интерфейса. Идея состоит в том, чтобы сформировать etherchannel путем объединения интерфейсов FastEthernet 0/13 и 0/14, но это не работает Сначала мы проверим, все ли интерфейсы работают. Да они все работают. Мы можем проверить, что port-channel interface был создан, но он не работает. Вот хорошая команда для проверки EtherChannel. Используйте суммарную информацию от команды show etherchannel summary, чтобы увидеть ваши port-channels. Мы видим, что коммутатор A настроен для LACP и коммутатор B для PAgP, а это никогда не будет работать. Лучшая команда для использования это show etherchannel detail. Это дает вам много информации, но нам особенно интересно узнать, настроен ли LACP для пассивного или активного режима. Интерфейсы в активном режиме будут "активно" пытаться сформировать EtherChannel. Интерфейсы в пассивном режиме будут отвечать только на запросы LACP. Вот вывод команды show etherchannel detail на коммутаторе B. Мы видим, что он был настроен для PAgP, и интерфейсы настроены для desirable режима. Если бы они были настроены на автоматический режим, мы бы увидели флаг А. SwitchB(config)#no interface po1 SwitchB(config)#interface fa0/13 SwitchB(config-if)#channel-group 1 mode passive SwitchB(config-if)#exit SwitchB(config)#interface fa0/14 SwitchB(config-if)#channel-group 1 mode passive Давайте сначала избавимся от port-channel interface. Если мы этого не сделаем, вы увидите ошибку при попытке изменить channel-group mode на интерфейсах. После изменения конфигурации мы видим, что port-channel1 поднялся. Задача решена! Извлеченный урок: убедитесь, что вы используете один и тот же режим EtherChannel с обеих сторон. Case #2 Ну что же давайте рассмотрим другую ошибку! Та же топология и EtherChannel, который не функционирует: Мы проверяем, что port-channel interface существует, но он не работает с обеих сторон. Мы также видим, что интерфейс FastEthernet 0/13 и 0/14 были добавлены к port-channel interface. Интерфейсы FastEthernet рабочие, поэтому мы знаем, что проблема не в этом. Давайте углубимся в конфигурацию EtherChannel. Мы видим, что FastEthernet 0/13 и 0/14 на коммутаторе A оба настроены на автоматический режим PAgP (из-за флага "A"). FastEthernet 0/13 и 0/14 на коммутаторе B также настроены на автоматический режим PAgP. Это никогда не сбудет работать, потому что оба коммутатора теперь пассивно ждут сообщений PAgP. SwitchB(config)#interface fa0/13 SwitchB(config-if)#channel-group 1 mode desirable SwitchB(config-if)#interface fa0/14 SwitchB(config-if)#channel-group 1 mode desirable Давайте изменим один из коммутаторов, чтобы он активно отправлял сообщения PAgP. EtherChannel сейчас работает. Проблема решена! Извлеченный урок: при использовании PAgP убедитесь, что хотя бы один из коммутаторов использует требуемый режим, или в случае LACP убедитесь, что один коммутатор находится в активном режиме. Case #3 Еще одна ситуация: EtherChannel настроен между коммутатором A и коммутатором B, но клиент жалуется, что соединение медленное ... что может быть не так? Быстрая проверка говорит нам, что port-channel interface работает. Команда show etherchannel detail дает нам много выходных данных, но она так же нам говорит, что происходит. Вы видите, что интерфейс FastEthernet 0/13 и 0/14 были настроены для port-channel, но коммутатор не смог связать их, потому что FastEthernet 0/14 настроен на 10 Мбит. Возможно, что это основная причина медленной скорости передачи данных. Мы будем использовать один из операторов для команды show. Нас интересует только то, чтобы увидеть вероятную причину, которую команда "show etherchannel detail" покажет. SwitchA(config)#interface fa0/14 SwitchA(config-if)#speed auto SwitchB(config)#interface fa0/14 SwitchB(config-if)#speed auto Давайте изменим скорость на авто. Мы должны убедиться, что FastEthernet 0/13 и 0/14 имеют одинаковую конфигурацию. Вероятно, вы увидите пару сообщений о том, что ваши интерфейсы переходят в состояние up и down. Теперь мы видим, что оба интерфейса были добавлены в port-channel... проблема решена! Извлеченный урок: убедитесь, что все интерфейсы, которые будут добавлены в port-channel, имеют одинаковую конфигурацию!
img
В производственной среде даже минимальное время простоя недопустимо. Это может привести к потере доходов и, что хуже всего, репутации. Чтобы отладить возможные сценарии, которые приводят к простою, развертываются разные системы регистрации событий и мониторинга. Это помогает экономить средства и своевременно выявлять проблемы, которые могут возникнуть в будущем. В настоящее время большинство организаций, вне зависимости от размера, так или иначе использует принципы и инструменты DevOps. Наиболее популярны контейнеры и Kubernetes. И мониторинг такой системы проводится очень эффективно с помощью Prometheus. Но там, где Prometheus отстает – узкая часть. Она не обеспечивает централизованную систему логирования, и именно здесь на сцену выходит Loki. Что такое Grafana Loki? Grafana Loki - система агрегации логов с нескольких источников, запущенная компанией Grafana в 2018 году и выпущенная под лицензией Apache 2.0. Разработки системы были вдохновлены Prometheus. Он широко используется с поставщиками облачных технологий и такими инструментами, как Prometheus и Grafana. Loki аналогичен стеку ELK/EFK, но его проще настроить и использовать, и предлагает лучшие функциональными возможностями. Loki не индексирует содержимое журнала, а индексирует метки времени и набор меток для потока журнала. Это делает индекс меньше, что упрощает операции и в конечном итоге снижает стоимость. Преимущества Loki Ниже приведены преимущества использования Loki в стеке: Благодаря индексации только метаданных, Loki очень экономичен. Выполнение индексов для полнотекстовой обработки требует большей оперативной памяти, которая стоит дорогой. Хранение журналов на объектах хранения, как S3, также уменьшает себестоимость. Он поддерживает использование нескольких источников с использованием tenantID, поэтому данные из каждого ресурса хранятся отдельно. Loki можно запускать локально для небольших операций или легко масштабировать по горизонтали для крупномасштабных операций. Он использует динамический стиль для обеспечения согласованности кворума для операций чтения и записи. По умолчанию он настроен на создание 3 реплик журналов для защиты от сбоев процессов и внезапных выходов с места потери журналов. Да, это повлечет за собой дополнительные расходы, но не такие высокие – целостность данных более критична. Легко интегрируется с такими популярными инструментам, как Kubernetes, Prometheus и визуализация в Grafana. Архитектура Loki Архитектура Loki состоит из трех компонентов - Promtail, Loki и Grafana. Promtail - это агент, который должен быть установлен на каждом узле, на котором выполняются приложения или службы. Основной обязанностью Promtail является обнаружение цели, прикрепление меток к потокам подов, и сохранение этих логов в экземпляры Loki. Агент promtail передает журналы из локальной файловой системы на центральный сервер Loki. После этого можно выполнить обратный запрос журналов с помощью Grafana. Сценарии использования Loki Ниже приведены популярные сценарии использования системы ведения журнала, подобных Loki. Бизнес-аналитика: Это, пожалуй, самый распространённый пример использования, создание действенного понимания на основе данных журнала всегда может быть очень полезным. Loki может помочь в понимании данных журнала и даст возможность создавать новые стратегии для роста бизнеса. Например, с помощью данных журнала организации можно узнать коэффициенты эффективности рекламного канала. Мониторинг: Prometheus часто используется для мониторинга в разных отраслях. Но вы можете многое идентифицировать, отслеживая свои журналы с помощью таких инструментов, как Loki. Она, просматривая журналы и отправляя предупреждения после превышения порога, поможет вам отслеживать частоту ошибок на вашем веб-сайте. Отладка и устранение неполадок: Loki может помочь команде DevOps быстро находить ответ на такие вопросы, как когда произошел сбой приложения, причина его сбоя, его последний статус перед сбоем и т.д. Кибербезопасность: За последние несколько лет число кибератак на порталы электронной коммерции увеличивается в геометрической прогрессии. С помощью Loki можно выполнить проверку журналов, чтобы выявить любые угрозы, проблемы или вредоносные действия, происходящие в системе вашей организации. Если взлом был успешным, Loki мог бы быть полезным для криминалистов, чтобы детально понять, что происходило в системе. Это поможет им отследить хакеров. Соблюдение норм: Для соблюдения отраслевых норм организации должны вести журналы аудита до 7 лет. Местные власти могут проверять журналы в любое время. Loki может безопасно хранить ваши журналы аудита. Установка Loki и Promtail Далее покажем, как установить и визуализировать журналы на Grafana. В этой демонстрации мы используем общую конфигурацию, которая будет собирать журналы из /var/log/* log. Перейдите на страницу релизов Loki на Github, прокрутите вниз до Assets. Здесь вы найдете несколько пакетов Loki и Promtail. Загрузите пакет Loki в соответствии с используемой системой. Не устанавливайте пакеты cli или canary Loki. Я загружаю loki-linux-amd64.zip и promtail-linux-amd64.zip для моей системы Ubuntu. После завершения загрузки разархивируйте файлы Loki и Promtail и поместите их в единый каталог. Теперь загрузите общий файл конфигурации Loki и Promtail. Чтобы запустить Loki, выполните приведенную ниже команду с файлом конфигурации Loki. Это приведет к запуску Loki и отображению журналов Loki в терминале. loki-linux-amd64 loki-local-config.yaml promtail-linux-amd64 promtail-local-config.yaml Чтобы запустить Promtail, выполните приведенную ниже команду с файлом конфигурации Promtail. Promtail должен получить журналы в Loki. ./loki-linux-amd64 -config.file=loki-local-config.yaml Визуализация логов с помощью Loki и Grafana Grafana обеспечивает встроенную поддержку Loki. Loki уже присутствует в источниках данных Графаны. Шаг 1. Перейдите к разделу Конфигурации Grafana и нажмите кнопку Data Sources (Источники данных). Шаг 2. В окне источников данных можно выполнить поиск источника по имени или типу. Шаг 3. Введите в строку поиска слово Loki. Этот источник данных уже присутствует в Grafana. Нажмите кнопку Select (Выбрать). Шаг 4. Введите имя, которое вы хотите дать источнику данных, и поместите http://localhost:3100 (измените его на IP-адрес сервера, если Loki работает на сервере, отличном от Grafana) в строку URL. Порт прописываем потому, что мы запустили Loki на порту 3100. Нажмите кнопку Save and Test внизу. Если настройка Loki выполнена правильно, появится следующее сообщение в зеленом поле. Шаг 5.Нажмите на вкладку Explore (Обзор) на левой части панели. Выберите Loki в раскрывающемся списке выбора источника данных. Теперь неплохо было бы визуализировать активность журналов Grafana. Для этого необходимо добавить запрос {filename = "/var/log/grafana/grafana.log "} в строку обозревателя журналов. Зеленые полосы ниже представляют собой записи событий в файле журнала. Можно выбрать временной диапазон, для которого визуализация должна отображаться на панели мониторинга, а также задать интервал обновления запроса. Чтобы просмотреть более подробную информацию о событии, прокрутите вниз и щелкните по одной из записей журнала, она выведет всю имеющуюся информацию, связанные с данным событием. Заключение Распределенная система состоит из множества приложений или микросервисов, каждый из которых генерирует тысячи событий. Нужен экономичный способ сбора журналов, их хранения и последующего использования. Loki - идеальное решение для таких случаев. Фактически, за счет интеграции Loki в производственную среду, затраты на ведение журналов и мониторинг можно сократить до 75%.
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59