Двухсерверная конфигурация Эра: плюсы, минусы и реальная отказоустойчивость

Когда система работает на одном сервере, мы не задумываемся о внутренних процессах. Нас не волнуют зацепленные связи между компонентами, потоки данных или нагрузка на каналы. Внутри одного узла нет явных сетевых задержек, нет проблем синхронизации времени, нет резервных точек подключения. Понятие «точка целостности» даже не возникает, пока мы находимся в границах единичного. Нам не нужно заботиться о проблемах сплит-брейна, кворума или механизмах восстановления данных.

Это большое благо односерверной архитектуры. Но это благо исчезает сразу, как только система выходит за пределы одного узла.

В статье мы рассмотрим особенности двухсерверной конфигурации. Это первый шаг за пределы одиночного сервера. Но уже на этом шаге нас ждет весь спектр последствий выбора пути в многосерверную конфигурацию.

Очевидно, что дополнительные серверы позволяют распределять нагрузку. Однако аспект масштабирования мы оставим за скобками — он менее интересен в контексте рисков. Нас интересует резервирование. В этом аспекте скрыт огромный пласт деталей, невидимых при поверхностном взгляде, но напрямую влияющих на результат.

В основном мы посвятим внимание конфигурации Active-Active — два сервера в рамках одного экземпляра системы.

Двухсерверную конфигурацию выбирают, как правило, ради отказоустойчивости. А зачем? Запрос на отказоустойчивость — это результат отработки рисков проекта. Очевидный риск — выход одного сервера из строя.

Однако отказоустойчивость — это не обязательно несколько серверов. Если сервер категории High Availability (аппаратно надежный), риск его физического выхода из строя часто закрыт на более низком уровне. В таких случаях выгода от двухсерверной конфигурации может не перевешивать объем усилий и усложнений, которые она влечет.

Прежде чем переходить к сложностям, давайте честно ответим на вопрос: когда одного сервера достаточно? Платформа «Эра» позволяет построить отказоустойчивую схему, но она не является «волшебной таблеткой». Если инфраструктура вокруг не готова, второй сервер лишь усложнит жизнь.

Односерверная конфигурация оправдана, если:

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

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

Итак, второй сервер добавлен. Для полноценной работы состав ролей на серверах должен быть идентичным и полнофункциональным. Микросервисы распределились, появились пары и группы, определены лидеры в парах с точками целостности. Массовые процессы (обслуживание вызовов) статистически распределяются по обоим узлам. Часть активных микросервисов на первом сервере, часть активных на втором сервере. При должной настройке оба узла нагружаются равномерно.

Вдруг срабатывает риск — теряется один сервер.

Группы микросервисов, отвечающие за точку целостности, имеют по одному активному экземпляру (грубо, поскольку есть механизмы тонкой настройки разделения точки целостности по доменам, классам и другим критериям). Потеря доступа к ним приводит к пропаданию доступности. Платформа «Эра» детектирует это почти сразу (2 секунды). Доступность — атрибут качества второго приоритета, главнейший драйвер архитектуры наряду с масштабируемостью.

Происходит скорая failover-активация резервных экземпляров. Двухсерверное распределение активных микросервисов переходит в односерверное. Через короткое время (5-10 секунд) новый поступивший запрос будет обработан. Администратору не придется участвовать в срочном восстановлении сервиса вручную.

Но давайте зададим важный вопрос, который волнует руководителя:

Здесь нам придется снять розовые очки. Чудес не бывает: частичное зацепление сессий при отказе узла неизбежно. Сценарии развития событий будут разными:

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

Однако для другой половины ситуация сложнее. Чтобы разговор выжил полностью, необходимо, чтобы все микросервисы, обслуживающие конкретный вызов (фасады, логика, медиа), одновременно оказались на оставшемся узле. Вероятность такого совпадения в динамической среде невелика - всего около 12%. Поэтому 44% разговоров окажутся без медиа и с разрывом в цепочке сигнализации. Можно считать, что они на этом этапе потерялись.

Существует ли решение? Да. В платформе «Эра» есть специальный Сервис восстановления разговоров.

Как он работает? При потере сервера система адаптирует failover-конфигурацию, подхватывает или дожидается необходимых регистраций и инициирует восстановление плеч зацепленных потерей вызовов.

На всю эту цепочку выделяется до 20 секунд. Сервис способен восстановить все разговоры почти наверное (термин теории вероятностей), вернув абонентам и голос, и управление. Почти — потому что некоторые отдельные разговоры могут всё же порваться, если в интервале попытаются воспользоваться удержанием или осуществить перевод. Кстати, только такой механизм способен восстановить вызов в IVR-сценарий, если микросервис IVR остался на недоступном сервере.

И здесь мы видим яркое проявление архитектурного предела двухсерверной схемы. Если мы сравним её с конфигурацией из 4-х и более серверов, где роли жестко разделены (отдельные узлы только под медиа, отдельные — под сигнализацию), картина меняется радикально. В такой архитектуре даже без сложного сервиса восстановления разговоров потеря одного сервера не приводит к обрыву голоса. В худшем сценарии (теряется именно один из серверов сигнализации, вероятность этого не более 50%) лишь половина вызовов останется с голосом без возможности управления, остальные случаи и разговоры — с сохранением управления.

Но бывает, что теряется не сервер, а пропадает сеть до него или между ними. TCP-подключения могут «зависать» до 60 секунд, если удаленный узел перестал отвечать, но не разорвал соединение. Failover не произойдет, пока подключение не разорвется.

Для оперативной активации система рассылает внутри heartbeats (сигналы жизни). Отсутствие heartbeat влечет принудительный разрыв TCP-соединений. Здесь мы входим в зону принятия решения. Серверу непонятно: сеть восстановится через секунду или потеряна навсегда?

Существуют ошибки двух родов:

Выбор стратегии должен опираться на статистику сбоев сети:

Это управляется конфигурационной опцией интервала ожидания (pang_to_disconnect_sec). По умолчанию — 10 секунд. Идеальный вариант избежать обоих родов ошибок — исключить подмирающие сети на уровне инфраструктуры (например, подключив серверы к одному отказоустойчивому коммутатору). Тогда можно разрывать подключения сразу, установив опцию в 0. Если нет — нужно делать обоснованный выбор и принимать последствия.

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

«Эра» имеет инструменты плавного вывода сервера из эксплуатации. Администратор мастер-домена переключает подготовленные пресеты активности серверов. Если сервер деактивирован в пресете, он не отключается моментально, а в течение пары часов перестает принимать новую работу. Микросервисы перестают участвовать в выборах, но дообслуживают текущие контексты. Активные экземпляры постепенно один за другим передают нагрузку на оставшийся сервер. Фасадные микросервисы отказывают или перенаправляют входящие подключения.

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

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

Если устройство подключено к живому серверу — потеря второго узла для него незаметна. Если устройство было подключено через упавший сервер — ему нужно переподключиться. Простое добавление второго сервера само по себе этого не обеспечивает.

Варианты решения:

Рассматриваем два кейса:

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

Какие есть варианты:

Если клиентское приложение раз подключилось, то при должной настройке его переподключение к живому серверу при потере связи с текущим сервером происходит автоматически. (Сейчас с опорой на virtual ip или multi dns с полной перезагрузкой клиентского приложения.)

Потеря сервера не должна приводить к потере связи с ТФОП (PSTN). Без этого очевидно невозможно обеспечить полнофункциональную доступность. Варианты организации резервной схемы:

В версиях двухлетней давности потеря сервера с IVR или медиашлюзом, обслуживающим его медиа-сеанс, влекла потерю вызова.

Система хранит доменное дерево и учетные записи в PostgreSQL. Архивы могут быть здесь же (в том числе и в другом инстансе PostgreSQL) или вынесены в ClickHouse. Сервер БД также должен быть зарезервирован, иначе это профанация отказоустойчивости.

При настройке «Эры» задаются строки подключения. «Эра» выбирает подключение к мастеру. Если мастера нет в моменте, но есть read-only рекавери, загрузка может пройти и с рекавери-инстанса с целью снижения времени недоступности.

Одна строка подключения, если фасадный балансировщик HA. Или несколько строк подключения, если как-то иначе. Вплоть до того, что для разных серверов можно задать разные наборы строк подключения.

Часто встречается дефолтная установка: БД рядом с платформой, на этой же паре серверов (потоковая репликация). Если нет внешних инструментов, используется встроенный контроллер репликации (микросервис middleware).

Встроенный контроллер не заменяет профессиональные инструменты (Patroni и т.д.). Он закрывает кейсы минимально достаточным образом. Управлять его поведением можно только условным тумблером Вкл-Выкл.

Для гарантированного сохранения архивных данных может использоваться брокер. Это относится к случаю, когда архивы также хранятся в БД PostgreSql. С версии 1.10 появилась возможность переключать коллекции исторического типа с хранилищем в PostgreSQL в режим работы через брокера (используются Mnesia или KAFKA).

Если же система настроена на работу с ClickHouse, то брокер KAFKA используется априори. Однако стоит помнить, что несмотря на распределенную архитектуру и ClickHouse и KAFKA, двухсерверный вариант не является полноценным, поскольку не обеспечивает кворума при потере сервера, а значит подвержен split-brain. Таким образом, двухсерверная конфигурация платформы не должна сопровождаться развертыванием KAFKA и CLICKHOUSE на этих же двух серверах.

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

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

Разделы хранения:

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

В настоящее время подключение внешнего файлового хранилища выглядит так:

Таким образом все классы автоматически привязываются к соответствующим файловым хранилищам для вложений. Изменить привязку к другому файловому хранилищу можно и вручную.

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

Вопрос интеграций — открытое проектное поле. Обобщение по аналогии с предыдущими пунктами:

Если связь между серверами теряется, но оба сервера активны, возникает т.н. split-brain. Система адаптируется, активируя резервные экземпляры и, возможно, резервный инстанс БД. Возникают две параллельно работающие системы.

Если это возможно, то конфигурация должна быть настроена на кворум.

Острова без кворума выводятся из обслуживания (микросервисы тухнут, фасадные порты закрываются, сценарии и обращения к внешним сервисам прекращаются). Они переходят в режим ожидания появления кворума.

В двухсерверной системе возможно состояние «два острова по половине серверов». Применение обычного кворума выключит сервис на обоих островах. Необходимо оставить ровно один остров в работе.

«Эра» предоставляет два механизма:

При восстановлении связи происходит объединение, адаптация конфигурации. Это повышает утилизацию CPU на время синхронизации. Возможно перезапуск репликации БД, если резервный инстанс в момент потери связи оказался на выбранном острове и был превращен в мастер. А в ином случае лога транзакций PostgreSQL может хватить для возобновления потоковой репликации после объединения островов.

Сравниваем двухсерверную конфигурацию с односерверной.

Давайте соберём всё в единую картину. Перед вами архитектура, к которой стоит стремиться при построении отказоустойчивого решения на платформе «Эра» в двухсерверной конфигурации.

Обратите внимание: платформа — это только часть системы. Внешний кластер баз данных обеспечивает кворум и надежную администрируемую репликацию. S3-хранилище гарантирует доступность файлов независимо от состояния серверов. Арбитр предотвращает сплит-брейн.

Балансировщик здесь показан опционально. Если ваши клиенты и провайдеры умеют работать с несколькими адресами напрямую — балансировщик не нужен. Это избавляет от ещё одного компонента, который нужно резервировать и администрировать. Балансировщик имеет смысл, когда нужно скрыть внутреннюю структуру, обеспечить заданное распределение подключений по узлам или клиенты не поддерживают multi-homing при том, что не используется ни Virtual IP, ни Multi DNS.

Кстати говоря, два сервера могут решать задачу резервирования совершенно иным способом — не как равноправные узлы Active-Active, а в режиме Primary-Secondary.