По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
Знаешь ли ты, что Asterisk Gateway Interface (AGI) делится на 3 различных вида: Enhanced AGI (EAGI), DeadAGI и fastAGI. Каждый из них имеет свои функциональные преимущества – он них и поговорим. Enhanced Asterisk Gateway Interface (EAGI) EAGI это более продвинутый AGI, который позволяет обрабатывать аудио – потоки с помощью файлового дескриптора (3). В действительности, с помощью EAGI вы можете создавать собственные приложения, предназначенные для анализа и выполнения различных задач со входящим аудио-потоком. Ниже приведен пример использования EAGI в диалплане: exten => helloworld,1,eagi(somescript.eagi) DeadAGI Указанное приложение выполняет AGI – совместимый скрипт на «мертвых» каналах (тех, на которых произошло событие hung-up). Основное отличие, что скрипт выполняется в экстеншене h. Дело в том, что скрипты, выполняемые через AGI – приложение не корректно отрабатывались на каналах, в которых случилось событие hang up. exten => h,1,DeadAGI(somescript.agi) FastAGI Обычное AGI – приложение задействует собственные (серверные) вычислительные мощности для каждого звонка. Безусловно, при высокой телефонной нагрузке, на сервере могут быть проблемы, связанные с нехваткой ресурсов. Помимо прочего, стандартный AGI имеет ограничения с точки зрения масштабирования. Поэтому, в рамках решения данные проблемы, было создано приложение FastAGI, которое позволяет выполнять скрипт на внешнем сервере, тем самым, «выносить» вычислительную нагрузку с сервера Asterisk на отдельный хост. IP – АТС Asterisk коммуницирует с сервером, на котором находится исполняемый скрипт с помощью TCP сокетов. Вызвать FastAGI можно следующим образом: exten => helloworld,1,AGI(agi://192.168.0.123:4567/somescript.agi) В рамках синтаксиса, мы обращаемся на хост 192.168.0.123 и порт 4567, вызываю скрип с именем somescript.agi. Здесь можно передать различные переменные, как и в обычном AGI.
img
В этой статье мы расскажем как настроить LACP (Link Aggregation Control Protocol) И PAgP (Port Aggregation Protocol), которые носят гордое название EtherChannels - агрегирование каналов. На самом деле EtherChannel это технология агрегации (объединения) каналов. Это означает, что мы можем объединить несколько линков в один логический, что позволит увеличить пропускную способность между коммутаторами. Пример использования Взглянем на схему ниже: В рамках данной схемы мы имеем серверную инфраструктуру, которая подключена в коммутатору распределения (distribution switch) через свой коммутатор. За коммутатором распределения сидят коммутаторы доступы, за которым расположились пользовательские рабочие станции: Если мы подключим два коммутатор линком в 1ГБ/сек, то потенциально, мы можем столкнуться с проблемой «бутылочного горлышка», то есть узкого места. Тогда пользователи испытают проблемы с доступом к серверной ферме. Используя технологию EtherChannel, мы можем объединить до 8 интерфейсов (физических) в один логический линк (агрегация портов, Port-Channel) и трафик будет распределяться между физическими портами равномерно (балансируя нагрузку). В нашем примере мы объединили 4 (четыре) гигабитных линка между рабочими станциями и серверами в один, с пропускной способностью 4ГБ/сек. Это увеличило общую пропускную способность и добавило отказоустойчивость линков! Не забывайте про STP (Spanning-tree protocol). В случае агрегации портов, мы исключаем STP петли. Режимы EtherChannel Каждый из протоколов LACP или PAgP имеет по 3 режима работы, которые определяют режим его активности (инициализировать ли построение агрегации со своей стороны, или ждать сигнал с удаленной стороны): LACP Modes: ON, ACTIVE, PASSIVE; PAgP Modes: ON, DESIRABLE, AUTO; Давайте посмотрим, в каком из случае будет установлено соединение EtherChannel при различных режимах настройки. Для LACP: Коммутатор №1 Коммутатор №2 Установится ли EtherChannel? ON ON Да ACTIVE ACTIVE/PASSIVE Да ON/ACTIVE/PASSIVE Not configured (off) Нет ON ACTIVE Нет PASSIVE/ON PASSIVE Нет Теперь разберемся с PAgP: Коммутатор №1 Коммутатор №2 Установится ли EtherChannel? ON ON Да DESIRABLE DESIRABLE/AUTO Да ON/DESIRABLE/AUTO Not configured (off) Нет ON DESIRABLE Нет AUTO / ON AUTO Нет Настройка Ок, предположим, что порты с Gi0/0 по Gi0/3 буду использованы для агрегации EtherChannel. Лучше всего настроить логический интерфейс (агрегированный) в качестве транка, чтобы пропускать VLAN между коммутаторами. Поднимаем LACP В нашем случае switch1 будет активном (Active) режиме, а switch2 будет в пассивном (Passive) режиме. switch1(config)# interface range Gi0/0 -3 // выбираем диапазон из 4х интерфейсов; switch1(config-if-range)# channel-protocol lacp // указываем протокол как LACP; switch1(config-if-range)# channel-group 1 mode active // указываем активный режим; switch1(config-if-range)# exit switch1(config)# interface port-channel 1 // конфигурируем логическую сущность как транк; switch1(config-if)#switchport trunk encapsulation dot1q switch1(config-if)#switchport mode trunk switch2(config)# interface range Gi0/0 – 3 // выбираем диапазон из 4х интерфейсов; switch2(config-if-range)# channel-protocol lacp // указываем протокол как LACP; switch2(config-if-range)# channel-group 1 mode passive // указываем пассивный режим; switch2(config-if-range)# exit switch2(config)# interface port-channel 1 // конфигурируем логическую сущность как транк; switch2(config-if)#switchport trunk encapsulation dot1q switch2(config-if)#switchport mode trunk Поднимаем PAgP В этом случае switch1 будет Desirable - режиме, а switch2 будет в автоматическом (Auto) режиме. switch1(config)# interface range Gi0/0 -3 // выбираем диапазон из 4х интерфейсов; switch1(config-if-range)# channel-group 1 mode desirable // указываем desirable режим; switch1(config-if-range)# exit switch1(config)# interface port-channel 1 // конфигурируем логическую сущность как транк; switch1(config-if)#switchport trunk encapsulation dot1q switch1(config-if)#switchport mode trunk switch2(config)# interface range Gi0/0 – 3 // выбираем диапазон из 4х интерфейсов; switch2(config-if-range)# channel-group 1 mode auto // указываем автоматический режим; switch2(config-if-range)# exit switch2(config)# interface port-channel 1 // конфигурируем логическую сущность как транк; switch2(config-if)#switchport trunk encapsulation dot1q switch2(config-if)#switchport mode trunk Полезные команды Вот некоторые команды, которые могут понадобиться вам в работе с EtherChannel: show etherchannel summary show etherchannel 1 port-channel show interfaces etherchannel
img
OpenVZ и LXD позволяют вам запустить полноценную операционную систему внутри контейнера, не сильно отличающиеся друг от друга. Но является ли одна системная платформа лучше другой? Вот сравнение OpenVZ и LXD. Обе платформы представляют собой “системные контейнеры”, предназначенные для размещения готовых клиентских операционных систем без необходимости эмуляции в стиле VMware. Системные контейнерные платформы отличаются от контейнеров Docker тем, что Docker предназначен в первую очередь для размещения отдельных приложений внутри контейнеров. Основным преимуществом OpenVZ и LXD является то, что они предоставляют более легкое решение для запуска клиентских операционных систем, чем VMware, KVM или других платформ виртуализации. С точки зрения качества, оба работают одинаково. OpenVZ против LXD Но есть некоторые важные характеристики, которые разделяют эти две платформы. Детали, характерные для OpenVZ, включают в себя: Она существует с середины 2000-х годов, и это уже устоявшаяся технология. Поддерживает все основные дистрибутивы Linux. Вам не нужно использовать определенный дистрибутив, чтобы использовать OpenVZ. Для его установки требуется специальное ядро. Это может быть проблемой, если Вам необходимы специальные функции в Вашем ядре, которые не встроены в пакеты ядра, предоставляемые OpenVZ. Коммерческая поддержка доступна от Virtuozzo, основной компании, занимающейся разработкой OpenVZ. Вы вряд ли найдете варианты коммерческой поддержки в другом месте. Доступ к физическому оборудованию из контейнера по умолчанию отключен при использовании OpenVZ. Это означает, если Вам необходимо, чтобы приложение внутри Вашей контейнерной клиентской операционной системы имело доступ к такому устройству, как видеокарта, Вам придется настроить доступ вручную (Это неудобство можно считать сильной стороной, поскольку ограничение доступа к оборудованию, возможно, является функцией безопасности.) А вот характерные особенности для LXD: Он основан на LXC, платформе контейнеризации Linux, которая существует с конца 2000-х годов. Однако сама LXD является новой технологией - её первый стабильный релиз состоялся весной 2016 года. В настоящее время он поддерживает только Ubuntu, дистрибутив Linux от Canonical. Он не требует специального ядра; Вы можете использовать стандартное ядро Ubuntu с LXD. Canonical заявляет, что предлагает коммерческую поддержку LXD, но для этого, во всей видимости, требуется оплатить план поддержки всей системы Ubuntu. Выбор между OpenVZ и LXD Какая из этих системных контейнерных платформ лучше всего подходит? Конечно, Вы можете начать с чего угодно. Но в целом LXD, вероятно, является лучшим решением, если Вы уже используете Ubuntu для размещения своих рабочих нагрузок или можете легко переключиться на него. В противном случае, поскольку LXD не работает на других дистрибутивах Linux, OpenVZ будет единственным вариантом, если Вы подключены к другой операционной системе. Я предполагаю, что, поскольку LXD пользуется сильной поддержкой со стороны Canonical, он будет продолжать развиваться и в конечном итоге поддерживать другие дистрибутивы. Когда это произойдет, это может быть лучшим выбором в целом, поскольку на него не распространяются некоторые ограничения OpenVZ, такие как требование установки специального ядра. Но до тех пор OpenVZ явно имеет большую ценность в качестве решения для запуска системных контейнеров на дистрибутивах, отличных от Ubuntu.
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59