[recovery mode] Отказоустойчивый VoIP кластер 3CX
Отказоустойчивый кластер 3CX представляет собой два реплицируемых сервера АТС. Когда основной сервер выходит из строя, в работу включается сервер-реплика, минимизируя время отказа телефонии. В этой статье мы рассмотрим, как правильно конфигурировать отказоустойчивость АТС 3CX.
Лицензирование
Для использования отказоустойчивости вам потребуется одна лицензия Enterprise (ENT) или Professional (PRO). В лицензии ENT установлено время жизни (TTL) А-записи FQDN сервера 3CX в 5 минут. В лицензии PRO TTL А-записи установлено в 6 часов. Это значит, что в редакции PRO время аварийного переподключения IP-телефонов, клиентов 3CX, 3CX SBC и веб-клиента будет значительно выше.
Реализация отказоустойчивости
В 3CX используется принцип активного-пассивного кластера с репликацией конфигурации раз в минимум 24 часа. Основной (активный) узел выполняет обработку VoIP вызовов, а резервный (пассивный) узел мониторит активный хост. При выходе из строя активного хоста (независимо от причины), пассивный хост включается в работу примерно с того же состояния. Механизм определения выхода из строя активного хоста зависит от настроек на пассивном хосте и рассматривается ниже.
Поддерживаемые топологии сети
Отказоустойчивый кластер 3CX рассчитан на работу в следующих топологиях:
- Локальный сервер (NAT)
- Облако (публичный сервер)
Отказоустойчивость между локальным и облачным узлом официально не поддерживается. Также предполагается, что FQDN сервера 3CX предоставлено и поддерживается компанией 3CX. Разумеется, вы можете использовать более сложную топологию и собственное FQDN имя, но в этом случае управление DNS записями и переконфигурированием устройств является зоной ответственности системного администратора.
Предварительные требования
Перед запуском отказоустойчивого кластера на 2 серверах должен быть установлен сервер 3CX следующим образом:
- Одна 3CX в облаке (первый публичный IP) и другая АТС в облаке (второй публичный IP) с FQDN именем от компании 3CX
- Оба сервера устанавливаются с идентичными настройками — одинаковые FQDN, SSL сертификат и порты SIP, туннеля и веб-сервера.
- Во вкладке автонастройки IP-телефонов необходимо указывать интерфейс как FQDN, а не как IP-адрес (см. ниже).
В других топологиях, например, одном узле в частной сети, а другом — в облаке, необходимо использовать скрипты для обновления DNS А-записей. Скрипты должны выполняться в момент аварийного переключения. Ниже мы поговорим об этом подробнее.
Настройка основного узла
Предположим, что на основном (активном) сервере уже установлена и настроена 3CX v15.5.
Для всех добавочных номеров укажите вариант автонастройки IP-телефонов через FQDN (вкладка Автонастройка телефона, опция Выберите интерфейс).
В разделе Резервирование нажмите кнопку Расположение и выберите Google Drive. Вы можете выбрать другое расположение, доступное с обоих серверов. В нашем примере кластер хранит конфигурацию в папке SIP3CXCOMBackups на Google Drive.
Нажмите кнопку План резервного копирования и выберите данные, которые необходимо синхронизировать в кластере, а также время синхронизации. Рекомендуется настроить ежедневную ночную синхронизацию, как показано выше. Имя файла резервной копии 3CXScheduledBackup.zip разерезвировано в 3CX для последней выгруженной конфигурации и используется обоими узлами кластера.
В этом же разделе нажмите кнопку Отказоустойчивость, включите опцию Включить резервное копирование и выберите Режим резервного переключения — Основной.
На этом настройка активного узла кластера завершена.
Настройка резервного узла
На резервном сервере установите 3CX, учитывая предварительные требования, перечисленные выше. Обратите внимание — если у вас основной и резервный сервер используют разные публичные IP-адреса, после установки резервного сервера общее FQDN имя кластера будет резолвится на резервный узел (а вначале, после установки основного сервера, оно резолвится на его IP). Для того, чтобы снова связать FQDN с IP-адресом основного сервера, на основном сервере в разделе Главная кликните на ссылке Лицензия, а затем нажмите Изменить и OK. Теперь FQDN снова начнет указывать на IP основного сервера.
Перейдите в раздел Резервирование и нажмите кнопку План восстановления. Включите восстановление и укажите время восстановления (разумеется, оно должно быть немного позже времени резервного копирования). Затем установите опцию Не запускать сервисы после восстановления.
В этом же разделе нажмите кнопку Отказоустойчивость, включите опцию Включить резервное копирование и выберите Режим резервного переключения — Резервный. Укажите IP адрес основного сервера (в нашем примере 1.1.1.1) и сервисы, которые следует мониторить: SIP Server, Web Server или Tunnel Server. Установите интервал проверки и логику срабатывания переключения — при «падении» только одного сервиса или всех сервисов.
Если резервный сервер обнаруживает отказ основного, он включается в работу, используя данные последней восстановленной резервной копии. Кроме того, он уведомляет DNS 3CX (который расположен в инфраструктуре Google) об изменении A-записи FQDN на IP-адрес резервного узла.
Важно, чтобы «упавший» основной сервер был полностью выключен, поскольку если на нем остались работающие сервисы 3CX, возможен конфликт с аналогичными сервисами на резервном узле.
Стоит отметить, что 3CX официально не поддерживает работу FXO или FXS шлюзов в отказоустойчивом кластере, поскольку взаимодействие шлюзов и сервера в такой топологии зависит от особенностей вендора, конкретной модели и версии прошивки.
Скрипты в сложной топологии
Если у вас используется собственное FQDN в топологии LAN-LAN или топология LAN-Cloud, необходимо использовать специальные скрипты (в Windows это Powershell скрипты отказоустойчивости для Active Directory), запускаемые с определенными привилегиями.
По умолчанию, скрипты, которые могут выполняться в процессе резервного переключения, выполняются с привилегиями сервиса 3CX Event Notification Manager (по умолчанию Local System). Как правило, для выполнения скрипта нужны привилегии управления DNS сервером (dnscmd или psexec).
Кликните по сервису в соответствующей оснастке Windows и на вкладке Log On измените учетную запись с Local System на ту, которая имеет соответствующие привилегии для конфигурирования DNS, и перезапустите сервис. Рекомендуется создать отдельного пользователя с данной привилегией и задать ему неизменяемый пароль.
