Запрос ЦеныЗапрос Цены
Онлайн ЧатОнлайн Чат
Зона КлиентовЗона Клиентов
КонтактыКонтакты
Скрыть
Live Support
Sales department
Technical Support
Преодоление отказа VoIP PBX сервера

1. Введение

Главной целью этого проекта является обеспечение непрерывной работы такой абонентской службы с поддержкой тонального сигнала приоритетности как VoIP, с минимальным временем простоя в случае чрезвычайной ситуации, перегрузки сети или аппаратного сбоя. Также эта схема преодоления отказа может использоваться для серверов в разных географических расположениях и при разных Интернет-провайдерах или в среде виртуального офиса. Такая схема обеспечивает минимум в ситуациях, когда по некоторым причинам сеть недоступна в течение короткого периода времени до 5 минут из-за перегрузки или отключения сетевого кабеля из розетки. Система основана на bash скриптах, и мы используем только базовые системные инструменты, поэтому её не трудно использовать, и она требует небольшого количества ресурсов.

2. Описание

Система основана на активном (PBX01 - Master)/пассивном (PBX02 - Slave) кластерном подходе с полуавтоматическим восстановлением после отказа. Это означает, что если у нас появляются какие-либо проблемы с Master АТС, переход на резервный АТС сервер будет автоматическим, однако восстановление будет выполняться вручную.
Главный скрипт будет работать на PBX02 (Slave АТС). Если PBX01 будет не доступен, то мы начнем обслуживание АТС на Slave сервере и изменим CNAME sip.domain.com чтобы указать на АТС, таким образом, все входящие и исходящие соединения будут обрабатываться этим сервером. Это даст нам гарантию того, что домен всегда будет направлен на текущий активный сервер.

3. Реализация

Для реализации этой возможности всё, о чём мы упоминали выше, было разработано в скрипте, который контролирует доступность PBX01 из PBX02 с помощью nrpe на трёх контрольных точках. Скрипт запускается через cron каждую минуту на Slave АТС.
*/1 * * * * /root/bin/check_voip.sh

Скрипт преодоления отказа работает по следующему алгоритму:
1. Получите данные со всех контрольных пунктов. Если всё в порядке, то сбросьте счётчик и начните всё с начала *.
2. Если мы получили отчёт об отказе со всех точек, тогда мы увеличиваем счётчик на единицу и переходим к следующему пункту.
3.Если сбой счетчика равен 5 (это означает, что PBX01 не доступен в течение 5 минут со всех контрольных пунктов), то мы включаем PBX услугу на Slave АТС, и меняем запись DNS для sip.domain.net, чтобы она указывала на PBX02 (slave pbx).
4. Если услуга АТС запускается на PBX02,тогда мы проверяем услугу АТС на PBX01. Если она включена, мы останавливаем услугу АТС PBX02(slave)
5.В случае отказа услуги АТС, по электронной почте будет отправлено уведомление.* Счётчик отказа используется для подсчета 5 минут недоступности и для начала процедуры восстановления после отказа.

Обратите внимание на то, что:
- ТТL для sip.domain.net должен быть установлен на 30 секунд.
- / root/ bin / event - в этом файле мы храним всю информацию относительно работы скрипта (событие запуска, событие остановки, счётчик и т.д.).

На PBX02(slave) помещается полная рабочая копия PBX01(master) без панели управления или другого скрипта управления.
*/2 * * * * /root/bin/rsync.sh

Такая частая синхронизация обусловлена тем, что все файлы и данные базы данных должны быть синхронизированы. Это даст нам следующие преимущества:
- Конфигурация очереди вызовов - это позволит агентам, которые были зарегистрированы в очереди на первичном сервере не регистрироваться снова на Slave сервере и начать принимать звонки без дополнительных действий с их стороны.
- Конфигурация параметров пользователей АТС - это означает, что все пользователи мгновенно получат любой входящий вызов и смогут сделать исходящий. На серверах мы получили Мaster-Slave репликацию MySQL, с первичным сервером MySQL на PBX01. На VSP (провайдере VoIP-услуги), таком как DIDww, мы устанавливаем правило - первый вызов будет отправлен на PBX01 и если первый сервер не доступен, тогда вызов будет переадресован на PBX02, таким образом, вызов будет отправлен на правильный сервер. Другие провайдеры, которые работают по регистрации, получат новую регистрацию, и все звонки будут направлены на активный сервер АТС.

Для преодоления отказа PBX01:
на первом сервере мы должны запустить /root/bin/recoverymysql.sh – это может привести к простою продолжительностью до 2-3 минут из-за синхронизации базы данных. Основной целью этого скрипта является синхронизация всех данных, которые были добавлены на PBX02 (Slave) в то время, когда этот сервер был активен. Это также переключит обратно CNAME на sip.domain.com, чтобы он указывал на PBX01.

4. Заключение

В заключение, мы хотели бы отметить, что этот подход поможет вам наладить работу при минимальном допустимом простое таких абонентских служб с поддержкой тонального сигнала приоритетности как VoIP, который является чрезвычайно важным для многих компаний. Мы можем применить эту схему в среде виртуального офиса, где офисы и АТС услуги дислоцированы географически отдельно друг от друга . Простои также могут быть сведены к минимуму благодаря настройке восстановления после отказа параметров системы.

Запросить цену
Заполните форму и мы свяжемся с Вами в ближайшее время
Вход для клиентов
Система запросов и другие полезные сервисы для наших клиентов
Свяжитесь с нами
Мы с удовольствием ответим на все ваши вопросы