Как на базе Asterisk поставить SAAS решение. Архитектура и технические подробности

Речь пойдёт о практическом опыте построения SaaS-платформы виртуальной АТС — без попыток описать идеальную архитектуру и без отрыва от реальной эксплуатации. Это история про систему, которая росла, сталкивалась с ограничениями по ресурсам, требовала постоянных компромиссов и в итоге стала устойчивым продуктом, работающим в продакшене.
В центре внимания — архитектурные решения, которые принимались не «по учебнику», а исходя из задач масштабирования, стоимости сопровождения и доступности специалистов. Отдельно рассматриваются проблемы, которые начали проявляться только на больших масштабах, и способы, которыми они были решены.

Общая архитектура платформы

В основе платформы лежит кластер физических серверов, на каждом из которых развёрнуто большое количество виртуальных машин. В качестве гипервизора используется Xen, а внутри каждой виртуальной машины работает отдельный экземпляр Asterisk.
Один физический сервер может обслуживать от сотни до нескольких сотен виртуальных АТС. Такой подход позволяет изолировать клиентов друг от друга и масштабировать систему горизонтально — добавлением новых серверов, а не усложнением конфигурации существующих.
На уровне физического сервера также размещаются сервисы, выполняющие роль session border controller: OpenSIPS и RTP Proxy. Они принимают SIP-регистрации и вызовы, определяют, в какой виртуальной машине находится нужный клиент, и маршрутизируют трафик к соответствующему Asterisk. После этого вся логика обработки вызова остаётся внутри виртуальной машины.
Дополнительно используются кэширующий DNS-сервер, веб-сервер для клиентского интерфейса, сервер баз данных и NFS-хранилище с общими конфигурациями.

Почему виртуальные машины и маленькие Asterisk

На этапе проектирования рассматривались и другие варианты, в том числе использование небольшого числа «больших» Asterisk-серверов с балансировкой нагрузки. На практике от этой идеи отказались.
Основная причина — эксплуатация. Чем сложнее и крупнее инстанс, тем выше требования к квалификации специалистов и тем дороже ошибки. В случае с большим количеством небольших виртуальных АТС система масштабируется проще: проблема, решённая для одной виртуальной машины, автоматически решена для всех остальных.
Отдельную роль сыграл выбор технологии виртуализации. Для голосовых сервисов критична точность таймингов процессора, и полная виртуализация на больших нагрузках начала давать сбои по качеству звука. Xen с поддержкой паравиртуализации оказался наиболее стабильным вариантом, который позволил контролировать ресурсы и сохранить качество аудио.

Внутренние сервисы и интеграции

Внутри каждой виртуальной машины, помимо Asterisk, работает отдельный Node.js-процесс. Он отвечает за интеграции с внешними сервисами: CRM, мессенджерами, обработку событий звонков и различную бизнес-логику.
Централизация этой логики на уровне физического сервера выглядела заманчиво, но быстро показала свои минусы. При большом количестве виртуальных машин это потребовало бы сложной системы очередей и синхронизации. Локальный Node.js внутри каждой виртуалки оказался гораздо проще в сопровождении: если не хватает ресурсов, достаточно увеличить лимиты конкретной машины.
Использование Node.js также позволило снизить потребление памяти по сравнению с PHP и упростить работу с Asterisk Manager Interface.

Хранение данных и изоляция клиентов

Для каждого клиента используется отдельная база данных. Это осознанный выбор, продиктованный опытом эксплуатации. Одна большая база со временем становится узким местом, требующим постоянной оптимизации и внимания специалистов.
Разделение данных по клиентам упрощает обслуживание, резервное копирование и изоляцию. При необходимости восстановить или перенести одного клиента это можно сделать без влияния на остальных. При этом используется выделенный сервер баз данных и резервный сервер, способный быстро взять на себя нагрузку.

Маршрутизация вызовов

Каждому клиенту внутри платформы выделяется собственный домен. При поступлении SIP-запроса OpenSIPS анализирует доменное имя, сопоставляет его с внутренним IP-адресом виртуальной машины и направляет вызов в нужный Asterisk.
Такой подход позволил обойтись без сложных таблиц маршрутизации и сделать логику прозрачной: по домену всегда понятно, куда должен попасть вызов.

Что начало ломаться при росте

По мере роста количества виртуальных машин стали проявляться проблемы, которые на малых масштабах были незаметны. Одна из ключевых — обновление конфигураций и схем баз данных.
Когда у тебя сотни отдельных баз, любое изменение структуры превращается в потенциально опасную операцию. В итоге была выстроена строгая процедура управления изменениями: разделение окружений на dev, test и stable, автоматизация обновлений и использование инструментов сравнения схем. Ручные правки в таких условиях просто перестали быть вариантом.

Управление конфигурациями Asterisk

Все экземпляры Asterisk используют одинаковые конфигурации, хранящиеся на NFS. При этом значительная часть логики и диалпланов формируется на основе данных из базы и подгружается в память Asterisk при reload.
Конфигурации генерируются автоматически на основании данных, которые клиент вводит через веб-интерфейс. Вместо генерации множества файлов используется загрузка параметров напрямую в память, что упрощает управление и ускоряет применение изменений.

Развёртывание виртуальных машин

Новые виртуальные машины создаются на основе заранее подготовленного образа с уже собранным Asterisk и всеми необходимыми компонентами. Процесс развёртывания автоматизирован: копирование образа, настройка hostname, веб-сервера и DNS-записей.
Из-за нагрузки на дисковую подсистему такие операции выполняются вне пиковых часов, а пул виртуальных машин формируется заранее.

Аналитика и фоновые задачи

Некоторые клиенты используют расширенную аналитику по звонкам. Чтобы такие вычисления не влияли на основную работу системы, они выполняются фоновыми задачами внутри виртуальных машин.
Запуск задач происходит в случайные моменты времени, что позволяет избежать ситуации, когда десятки виртуалок одновременно начинают тяжёлые расчёты.

Мониторинг и устойчивость

Все ключевые процессы — Asterisk и Node.js — находятся под постоянным контролем. При падении процесс автоматически перезапускается, а команда получает уведомление. При этом реализованы ограничения, предотвращающие бесконечные циклы рестарта при проблемах с внешними сервисами, такими как база данных.
Дополнительно реализованы автоматические сценарии восстановления для типовых проблем Asterisk, включая повторную регистрацию и reload при сбоях.

Выбор версий и экономия ресурсов

Для снижения потребления ресурсов используется Asterisk 1.8 и CentOS 6. Более новые версии требуют значительно больше памяти, что напрямую снижает плотность размещения виртуальных машин на сервере.
В среднем одна виртуальная АТС укладывается в 100–200 МБ оперативной памяти и способна обслуживать десятки SIP-устройств. Это критично для экономической эффективности SaaS-платформы.

Отказы дата-центров и резервирование

Архитектура учитывает возможность отказа целого дата-центра. Критичные данные регулярно резервируются и реплицируются в соседние площадки. При аварии достаточно поднять виртуальные машины на резервном сервере и загрузить актуальные данные — без изменения логики работы системы.

Облачная и коробочная версии

Изначально архитектура проектировалась так, чтобы одинаково работать как в облаке, так и в коробочной версии. В локальной установке клиент получает тот же функционал и интерфейс, но без необходимости использовать OpenSIPS и виртуализацию.
Это позволило развивать продукт в двух форматах, не поддерживая отдельные кодовые базы.