Масштабирование платформы

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

Каждая функциональная роль может располагаться на отдельном сервере. А при избыточной нагрузке имеет методику разделения на группы по ответственности.

При этом архитектура коммуникационной платформы «Era» предполагает классификацию ролей по признаку тактики обеспечения доступности: active-active и active-passive (см. Шаг 6).

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

В пределе система выглядит как

• Множество сайтов (групп высокодоступных серверов), связанных между собой каналами с меньшими требованиями к стабильности и пропускной способности.
• Каждый сайт содержит множество серверов.
• Каждый сервер содержит одну или несколько ролей.
• Каждая роль расположена на нескольких серверах внутри каждого сайта.
• Каждая роль взаимодействует с другими ролями внутри сайта в части сервисов.
• Каждая роль взаимодействует со своим зеркалом на других сайтах в части согласования данных.

На одном сервере

Рассмотрение начинается с того, что система установлена на единственном сервере. Все роли активны. Пусть это будет 4-х ядерный сервер.

При этом система не зарезервирована от падения машины, при падении той или иной роли происходит ее перезапуск – имеющиеся активности теряются, данные сохраняются. Условно, один сервер в состоянии обработать с полной загрузкой следующие масштабы работ:

• либо 6000 SIP сообщений в секунду на SIP ролях;
• либо 20000 медиа пакетов в секунду (200 одновременных коммутаций * 2 транка * 50 пакетов в секунду) на MG
• либо 5000 операций поиска правил маршрутизации в секунду (~5 маршрутов, ~10 векторов на маршрут).
• либо 40000 операций регистрации в секунду на 1 ядро
• …

Один сервер может держать много доменов, много регистраций, много звонков, но все вместе ограниченно.

Расчеты нагрузки

Каждый абонент в среднем раз в 5 минут шлет регистрацию: UA - Gate - B2B. 12 SIP сообщений.

10000 абонентов - 400 SIP сообщений по операции регистрации в секунду - 8% от предела.

Каждый установленный диалог с обменом аудио - это ~0.5% от предела.

Каждый дополнительный CPS - это (30 + 15*(кол-во fork) + 24*(кол-во reinvite)) SIP сообщений + (5 + 3*(кол-во reinvite)) MEGACO сообщений. В простом случае - это 0.75% + 0.5% + 0.2% + одна операция маршрутизации от предела возможностей сервера.

Условно 10000 абонентов на одном сервере могут существовать при одновременном количестве разговоров до 150 и CPS до 50 (каждый макс) или условно 100/20 или 50/30.

Существенную нагрузку добавляют также подписки на состояния, групповые и многофорковые вызовы.

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

Поиск узких мест

1. При увеличении одновременных звонков – необходимо выделять на отдельные серверы роли MGC и MG. При увеличении одновременных звонков более 200 количество экземпляров роли MG можно и нужно размножать.
2. При увеличении одновременных звонков выше 2000 – необходимо размножать MGC и выделять медиа-группы. Медиа-группы можно размножать и в целях повышения доступности и устойчивости при сбоях.
3. При увеличении CPS – необходимо выделять на отдельные серверы и размножать B2B и SG.
4. При большом числе SG имеет смысл вводить роль REDIRECT.
5. При увеличении CPS дальше – в ряде случаев имеет смысл разделять STORE на группы.
6. При увеличении количества пользователей до 50000 или CPS до 1000 (маршрутизация, авторизация, регистрация, подписки) – необходимо пользователей делить на домены. Рекомендованное максимальное количество пользователей в домене – до 30 тысяч.
7. При массовом использовании подписок – необходимо разделять StateStore на группы с привязкой по доменам, а также размножать B2B и SG, выделяя их на отдельные серверы.
8. При увеличении нагрузки на нескольких доменах – необходимо разделять DC, REGISTRAR, StateStore на группы серверов с привязкой к доменам.
9. При увеличении количества серверов DC, Registrar, StateStore, Store, MGC, RPC до 40 – необходимо выделять сайты.

Направления масштабирования

Инфраструктура:

• добавление серверов;
• добавление сайтов.

Логика:

• добавление ролей типа active-active с выделением на новые серверы;
• разделение ролей типа active-passive на группы непересекающейся ответственности (по доменам, по хешрингу).

Данные:

• добавление новых доменов в дерево, перенос частей оргструктур в другие домены;
• вынесение баз данных на отдельные серверы под каждый домен;
• выделение под каждую роль своего сервера с репликой данных PostgreSQL/ClickHouse (dc, dms);
• выделение для каждого домена отдельного хранилища S3.