Глава 5. Методики управления атрибутами качества

Масштабирование

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

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

При этом архитектура коммуникационной платформы «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.

Повышение доступности

Система построена на базе функциональных ролей, образующих active-active hash-ring и active-passive резервирующие группы. Роли предоставляют друг другу и внешним пользователям сервисы.

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

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

При активности узла активность роли гарантируется конфигурационным супервизором, активность которого обеспечивается демонами/службами ОС.

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

  • Горячее резервирование (active-passive).

  • Параллельная доступность (active-active).

  • Микс, при котором active-passive группы разделяются по ответственности (reg,dc,store) или по загрузке (mgc,mg) на несколько одновременно действующих групп.

  • Быстрое применение изменений конфигурации.

  • Внешний сетевой контур кластера содержит только роли WS, ESG, SG, REDIRECT, и возможно RPCO, каждая из которых имеет механизмы защиты от проникновения, подбора паролей учетных записей, потери производительности от (D)DoS-атак путем использования встроенных пограничных фильтров.

Повышение доступности системы в связи с использованием хранилищ (внешние по отношению к платформе) – S3, PostgreSQL, ClickHouse, напрямую обеспечивается доступностью самих хранилищ и обеспечения повышения их доступности для системы. Так, в конфигурации системы каждое подключение к хранилищу может быть задублировано произвольным количеством альтернатив. В этом случае при недоступности подключения по первой строке подключения система осуществляет перебор остальных вариантов и останавливается на следующем доступном. Внутридоменные настройки подключения к S3 и ClickHouse также могут быть задублированы произвольным количеством.

Основным кейсом является обеспечение коммуникационного процессинга, и при недоступности хранилищ для статистики и записей разговоров основная работа системы не прекращается.

Повышение доступности ролей

Роли ACTIVE-ACTIVE (B2B, MG, WS, …​)

  • добавление в конфигурацию серверов, использующих соответствующие роли (кол-во 1,3,15,…​).

Роли ACTIVE-PASSIVE (REGISTRAR, MDC, SDC, MGC, STATESTORE, …​)

  • Добавление в конфигурацию серверов, использующих соответствующие роли в резервном режиме (кол-во 1,2,3).

  • Для ролей, разделяемых по доменам. Разделение резервирующей группы на несколько резервирующих групп по ответственности за домены, с частичным или полным вынесением на отдельные серверы и образованием непересекающихся групп active-passive (registrar, mdc, sdc, statestore, …​).

  • Для роли системного объектного хранилища (store). Разделение на несколько групп с вынесением на отдельные серверы – запросы распределяются автоматически через hashring по ключам.

  • Для роли медийного контроллера (mgc). Разделение на несколько групп с вынесением на отдельные серверы – запросы распределяются автоматически через случайный выбор группы при создании медиа-контекста. Каждая группа обязана получить привязанные к ней MG, причем рационально использовать одинаковое количество MG во всех группах MGC на сайте.

Повышение доступности сервисов

Медийный процессинг

  • добавление в конфигурацию новых серверов, на которых разворачиваются новые группы MGC-MG с новыми номерами.

Внешние подключения к провайдерам

  • дублирование подключений на разных серверах роли ESG, с одновременной настройкой в маршрутах последовательных или конкурирующих по приоритетам.

SIP-сигнализация

  • размножение SG, внесение в SIP-устройства дублированных адресов Outbound proxy-сервер.

  • размножение SG, DNS-маршрутизация на резервный сервер по одному и тому же адресу.

  • использование REDIRECT.

Повышение доступности при физических сбоях

Отсутствие связи между городами

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

  • привязка доменов к сайтам, обеспечивающая кеширование и хранение доменной информации на сайте.

(D)DoS атаки на сервер

  • размножение SG, ESG и WS с разными внешними адресами.

  • применение белых/черных списков на SG и ESG.

  • SG и ESG имеют встроенный сетевой фильтр по адресам отправителей неудавшихся аутентификаций.

Падение сайта

  • привязка домена к нескольким сайтам (резервным или параллельным), данные автоматически реплицируются.

  • настройка телефонов на перебор Outbound proxy, где участвует другой сайт.

  • Персонализация
  • Увеличить шрифт
  • Уменьшить шрифт