Одна голова хорошо, а две лучше, или как жить в двух ДЦ сразу

Введение

     В докладе рассматривается проект по развёртыванию отказоустойчивой VoIP-инфраструктуры на базе Asterisk в собственном дата-центре заказчика. Задача заключалась в переносе сервисов в новый ДЦ при отсутствии выделенных серверов, при этом обеспечить круглосуточную работу колл-центра без потери вызовов.

Архитектура кластеров

     Для реализации решения были развернуты два Asterisk-кластера в разных дата-центрах, находящихся даже в разных странах. Между ними организован защищённый SIP-транк для репликации и синхронизации данных. Внешний доступ к ядрам скрыт за двумя отдельными фронтенд-прокси, которые выполняют функции балансировщиков и точек входа для подключения к SIP-провайдерам.

Репликация данных

     На каждом из основных серверов установлены Asterisk и MySQL. Для синхронизации базы данных используется мастер-мастер репликация MySQL, что позволяет сохранять актуальность данных в обоих ДЦ и обеспечивает резервирование на уровне СУБД. Все каналы связи между дата-центрами шифруются для защиты пользовательской информации.

Фронтенд-прокси и многотранспортность

     Два прокси-сервера (B2BUA) скрывают ядро от прямого выхода в интернет и управляют подключениями к SIP-провайдерам. На них используется поддержка многотранспортности (“multi-transport”), благодаря чему каждому провайдеру назначается собственный транспорт (IP-адрес и порт). Это повышает гибкость маршрутизации и защищает от сканирования стандартных SIP-портов.

Локальные АТС в колл-центрах

     Для обеспечения резервирования и снижения задержек в разных регионах установлены локальные АТС в колл-центрах. Эти серверы не участвуют в полном кластере, но подключаются по TLS-транку к основным ядрам. При отказе локальной АТС возможен автоматический переход на другой регион.

Синхронизация состояний операторов

     Состояние каждого оператора (занят/свободен, пауза) хранится в общей базе MySQL. Для передачи обновлений между кластерами применяется механизм Outbound Publish в Asterisk, который шлёт изменения статуса из одного хастера на другой. Это обеспечивает актуальность данных очередей и статусов операторов в реальном времени.

Хранение CDR и мультимедиа

     Полные CDR записываются в базу на каждом локальном Asterisk-сервере и дополнительно дублируются в отдельной аналитической базе для построения отчётов и графиков. Звуковые файлы (IVR-промты, голосовые записи разговоров) хранятся на файловом хранилище, также синхронизируемом между дата-центрами.

Основные проблемы и подходы к их решению

1. Качество каналов между ДЦ. Из-за нестабильности интернет-соединения возможны задержки и потеря пакетов. Для переключения трафика между ядрами применяется балансировщик на основе механизма Outbound Publish, который динамически перенаправляет вызовы на доступный узел.
2. Мониторинг очередей. Сбор метрик по API Manager Interface (AMI) осуществляется одновременно с обоих ядер. Один из серверов назначается «мастером» для приёма основной нагрузки, второй — резервным, однако в период плохого соединения оба могут обрабатывать вызовы параллельно.
3. Масштабирование кластера. Мастер-мастер репликация двух баз отлично работает для текущей конфигурации, но добавление третьего узла вызывает значительные сложности и требует поиска нового решения.
4. Балансировка нагрузки. Корректная параллельная обработка звонков на двух серверах остаётся сложной задачей; временным решением стало использование одного узла как основного и второго как резервного.

Вывод

     Реализованная архитектура на базе Asterisk и MySQL с мастер-мастер репликацией, обязательным шифрованием SIP-транков и разграничением фронтенд-прокси продемонстрировала высокую отказоустойчивость и гибкость маршрутизации. Основные сложности связаны с нестабильностью каналов связи и масштабированием beyond two nodes, что требует дальнейшей доработки.