Доступность сайта и целостность данных

Оглавление

Обзор
Размещение сайта в двух датацентрах

Обзор

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

Невозможность распадания сайта на несколько несвязанных групп серверов обусловлена необходимостью обеспечения целостности данных. Для гарантированного обеспечения этого требования применяется модель кворума - микросервисы по работе с данными (резервируются в режиме active-passive) активны только на тех серверах, которые входят в связную группу из более чем половины активных серверов сайта. Включение режима обеспечения кворума производится в конфигурационных параметрах каждого сайта параметром check_quorum (по умолчанию выключено). Случай кворума для половины серверов может быть решен с помощью элементарного арбитра - внешнего IP-адреса путем простейшего пинга. Это верно для случая, когда связь между серверами и связь с внешним миром для каждого из серверов обеспечивается одним и тем же каналом связи так, что падение сервера или отключение его от сети выглядит одинаково как для других серверов системы, так и для устройств внешнего мира.

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

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

Размещение сайта в двух датацентрах

Требуется настроить сайт таким образом, чтобы:

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

Для этого серверы сайта разделены пополам таким образом, что каждая из групп содержит полный набор микросервисов:

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

В зависимости от того, каким образом обеспечена связь между датацентрами - общим внешним каналом (1) или отдельным прямым каналом (2) - настройка может производиться разными способами.

1. Случай использования внешнего канала для связи между датацентрами.

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

Для обеспечения работоспособности оставшейся части системы Б необходимо и достаточно, чтобы она посчитала себя находящейся в кворуме.

Вариант 1. Разделить серверы строго пополам, включить режим обеспечения кворума, зарегистрировать в качестве арбитра любой внешний постоянно доступный адрес.

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

Вариант 2. Не использовать режим обеспечения кворума, положившись на гарантированную недоступность группы А при обоих видах проблем: падение связи и падение вычислительных ресурсов.

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

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

2. Случай раздельных внешнего канала и прямого канала между датацентрами.

В корпоративных сетях дата-центры как правило изначально аппаратно настроены на обеспечение резервирования работы распределенных сервисов:

один из дата-центров назначен лидером (А), а другой фолловером (Б);
кросс-канал связи между дата-центрами на порядок шире их внешних каналов;
поддерживается VPN кросс-канал между дата-центрами через внешние интерфейсы;
маршрутизаторы осуществляют взаимную рассылку heartbeat-сообщений одновременно через кросс-канал и через VPN over WAN;
маршрутизаторы при падении внешнего канала связи обеспечивают автоматическое изменение маршрута для исходящих запросов на внешние адреса, активируя перенаправление исходящего трафика на маршрутизатор другого дата-центра через кросс-канал;
маршрутизатор в датацентре Б настроен на
- при отсутствии хартбита из кросс-канала и одновременном наличии хартбита из VPN over WAN — автоматическое отключение маршрутизации трафика;
- при отсутствии хартбита из обоих направлений — автоматическое включение маршрутизации трафика;
- при наличии хартбита из обоих направлений — автоматическое включение маршрутизации трафика;
- при наличии хартбита из кросс-канала и одновременном отсутствии хартбита из VPN over WAN — автоматическое включение маршрутизации трафика и обеспечение дополнительно маршрутизации для исходящих запросов, поступающих через кросс-канал;

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

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

Дальнейшее рассмотрение касается дата-центров, не имеющих вышеупомянутых аппаратных настроек и являющихся симметричными.

2.1. Кейс падения вычислительных ресурсов дата-центра.

Этот кейс эквивалентен случаю 1 и иных сложностей не представляет.

2.2. Кейс падения внешнего канала связи у одного из дата-центров (А).

Угрозы кворуму нет, арбитр не опрашивается ни одним из серверов.

Все микросервисы внутреннего контура продолжают быть активными в группах на обоих датацентрах и доступными для других микросервисов системы.

2.2.1. Микросервисы внешнего контура в группе А остаются без связи с внешним миром.

ws (webserver). Работает в режиме active-active. Существующие websocket подключения порвутся, новые установятся клиентами к доступному вебсерверу группы Б. По умолчанию ws не совершает исходящих запросов, если иное не настроено в сценариях.
sg (sip gate). Работает в режиме active-active. Новые регистрации и продления регистраций будут произведены к доступному экземпляру группы Б. Существующие звонки, проходящие через sg группы А, потеряют возможность управления. При использовании для обслуживания трафика медиагейта группы А, звук пропадет, разговор будет вынужденно завершен абонентами.
mg (media gate). Работает в режиме active-active. Резервируется для обслуживания звонка другими микросервисами системы, таким образом при отсутствии специальных настроек в среднем половина звонков будет попадать на медиагейты группы А и не давать возможности абонентам обмениваться трафиком. Проблема MG рассмотрена отдельно: 3.2. Проблема медиагейта.
esg (external sip gate). Работает в режиме active-active, однако каждую учетную запись провайдера обслуживает один и только один экземпляр esg. Настройки приоритетов выбора esg для обслуживания каждой учетной записи провайдера задаются непосредственно в свойствах описывающей ее сущности (provider). Выбор иного esg производится на основании недоступности. В рассматриваемом случае отсутствия внешнего канала связи датацентра А, учетные записи, привязанные в приоритете к экземплярам esg группы А, продолжат обслуживаться там же без возможности обмена данными с провайдером. Решение вопроса обеспечения связи с ТФОП для абонентов рассмотрено отдельно: 3.1. Проблема провайдера.
bgmg (border media gate). активен на серверах рядом esg, и не используется без активности соответствующих esg.

2.2.2. Микросервисы внутреннего контура с процессами доступа к внешним системам, находящимся за пределами внешнего канала связи, продолжают работать, получая неудовлетворительные ответы (3.3. Проблема доступа к внешним системам).

script (все виды сценариев). Работают в режиме active-active. Каждый сценарий обслуживается на одном экземпляре, а выбор экземпляра производится другими микросервисами системы. Компоненты доступа к веб-ресурсам, к почтовым серверам, к внешним БД в сценариях, исполняемых экземплярами группы А, будут завершаться с ошибкой. В частности ASR и TTS при использовании Yandex SpeechKit. Проблема хешринга рассмотрена отдельно: 3.4. Проблема выбора экземпляра микросервиса.
im (instant-messaging). Обеспечивает обмен текстовыми сообщениями с серверами мессенджеров. Сервис работает в режиме active-passive. Экземпляр группы А будет получать ошибку связи при попытке обмена данными. Обмен сообщениями с мессенджерами приостановится. Проблема распределенных сервисов с лидером рассмотрена отдельно: 3.5. Проблема распределенных приложений и сервисов с лидером.
email. Обеспечивает обмен письмами с почтовыми серверами. Сервис работает в режиме active-passive. Экземпляр группы А будет получать ошибку связи при попытке обмена данными. Обмен письмами с почтовыми серверами приостановится. Проблема распределенных сервисов с лидером рассмотрена отдельно: 3.5. Проблема распределенных приложений и сервисов с лидером.
mware (middleware). Сервис генерации сертификатов letsencrypt, доступа к telegram для нужд администрирования. Экземпляр группы А будет получать ошибку связи при попытке обмена данными. Проблема распределенных сервисов с лидером рассмотрена отдельно: 3.5. Проблема распределенных приложений и сервисов с лидером.

2.3. Кейс падения канала связи между дата-центрами.

В этом случае внешние каналы связи в обоих дата-центрах активны.

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

По результатам опроса арбитра обе группы готовы продолжать независимую работу.

Для обеспечения целостности данных необходимо вывести из эксплуатации одну и только одну из групп - либо А, либо Б. Тогда кейс сведется к случаям 1 и 2.1 (падения вычислительных ресурсов одного из дата-центров или его доступности для всех).

Определение происходит согласованно - обе группы принимают одинаковое решение.

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

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

Взаимный опрос группами производится по http/https путем отправки HTTP запроса на публичный URL (со статическим ключом) к веб-серверам текущего сайта, находящимся в недоступной зоне.

2.4. Падение нескольких сущностей.

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

2.4.1. Каналы и вычислительные ресурсы одного из датацентров

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

2.4.2. Несколько серверов в разных группах

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

2.4.3. Один из дата-центров и сервер в другом дата-центре

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

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

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

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

микросервисы active-active должны иметь 4 и более экземпляров - минимум по 2 в каждой из групп.
микросервисы active-passive должны иметь не два, а четыре экземпляра - минимум по 2 в каждой из групп.
инстансы СУБД должны располагаться не на серверах сайта, а в высокодоступных виртуальных средах, либо должны управляться внешним образом для обеспечения слежения за 4 репликами.

2.4.4. Весовые модели при расчете кворума

(TODO) При расчете кворума потенциально могут применяться расширенные весовые модели, допуская работу групп с количеством серверов менее половины от общего количества серверов на сайте. Эта возможность обеспечивается концепцией арбиртражных серверов и предопределенной границей между группами, проходящей между дата-центрами. В этом случае:

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

3. Рассмотрение выявленных проблем.

3.1. Проблема провайдера

3.1.1. Исходящие звонки

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

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

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

3.1.2. Входящие звонки.

Варианты:

При недоступности одного из серверов для провайдера, INVITE запрос не получает подтверждения 100 Trying. На этом основании оборудование провайдера спешно отправляет запрос по другой учетной записи (внутренняя переадресация). Провайдер должен поддерживать переадресацию вызова по неответу в короткий интервал, значительно меньший чем время жизни транзакции (32 секунды).
Оборудование провайдера направляет поступающие извне вызовы на внешний номер сразу на две учетных записи (групповой номер с параллельным вызовом, либо варианты с небольшой задержкой). При ответе одного из них, в другую отправляется CANCEL. В системе может быть настроен прием звонков в сценарии с моментальным ответом (и моментальным отклонением дублирующего вызова) и дальнейшим переводом через таблицу маршрутизации, с целью устранения дублей в статистике.
Запросы отправляются на оба сервера одновременно (forking), при ответе одного из них, другой получает CANCEL. Аналогично предыдущему, может быть настроен прием звонков в сценарии с моментальным ответом.
(TODO) Два экземпляра esg одновременно регистрируются под одной и той же учетной записью (forking). Провайдер должен поддерживать такой режим. Поступающие извне вызовы отправляются одновременно на два устройства, зарегистрированные под одной учетной записью. Задача системы а) позволить настроить одновременную регистрацию под одной учетной записью, б) отклонить дублирующий вызов на входе при обнаружении его смежника на другом экземпляре на основании настроенного критерия, применяя транзакцию.

3.2. Проблема медиагейта

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

3.2.1. Настройка постоянного использования пограничного медиагейта bgmg, всегда располагающегося непосредственно на том же сервере, где и пограничный sip-сервер (esg, sg), вызывающий соответствующее плечо звонка. Тогда недоступность внешнего канала для основного используемого при обслуживании звонка медиагейта не является значимой. Однако в этом случае выход из строя пограничного сервера приводит к невозможности продолжения обмена трафиком существующих вызовов.

3.2.2. При выборе медиагейта контроллером автоматически производится учет доступности ему арбитра. Фильтр применяется только для медиа контекстов, управляемых микросервисом b2b. Фильтр не применяется для медиа контекстов, управляемых микросервисами ivr и conf (поскольку исключена возможность их контакта с внешними абонентами, они всегда связаны с медиагейтами b2b, и внутренний канал не нарушен. Проблема выбора экземпляра микросервиса рассмотрена отдельно: 3.4. Проблема выбора экземпляра микросервиса.

3.2.3. (TODO) Разнесение медиа-групп по разным сайтам вместе с их медиагейтами. При организации случайного списка приоритетное использование той медиа-группы, которая находится в одном датацентре с сервером-инициатором вызова (sg, esg, ivr, conf).

3.3. Проблема доступа к внешним системам

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

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

Среди микросервисов, имеющих проблему, есть и работающие в режиме active-active (например, script), и active-passive (например, email). Для них применяются разные схемы.

3.3.1. Active-active.

При выборе ноды для выполнения сценария применяется офлайн-фильтр на основании информации о доступности арбитра для серверов с микросервисами script и ivrscript. Используется кэш с интервалом обновления 20 секунд.

Аналогичное поведение при выборе медиагейтов (3.2. Проблема медиагейта).

3.3.2. Active-passive

При остутствии связи с арбитром микросервис в группе А переходит в режим ожидания его появления, не участвуя в процессе конкуренции за лидерство. Таким образом экземпляр микросервиса в группе Б активируется вне зависимости от настроенного приоритета лидерства в конфигурации. Восстановление производится также на основе информации о появлении связи с арбитром. Интервал проверки - 10 секунд. Данные в кэше не используются, но обновляются.

3.4. Проблема выбора экземпляра микросервиса

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

Регулярная (интервал 20 секунд) инициация проверки доступности арбитра с сервера, где располагается экземпляр микросервиса, и кэширование сведений для дальнейшего использования при выборе (в частности, для mediagate - на управляющем медиа-контроллере). Арбитр в этом случае применяется далеко не только при определении кворума для связной половины серверов, а регулярно с каждого сервера (где работают микросервисы, требующие фильтра по наличию внешней связи).

С целью исключения риска зависимости функционирования от работоспособности самого арбитра, в конфигурации для сайта регистрируется несколько высокодоступных внешних серверов. Конфигурационная опция для сайта odd_referee в виде строки "IP1, IP2, IP3".

3.5. Проблема распределенных приложений и сервисов с лидером

Выбор лидера для распределенных приложений осуществляется на основании приоритетов, установленных в конфигурации для роли на сайте. При выходе из строя новым лидером становится следующий по приоритету экземпляр микросервиса на сайте (failover). При восстановлении более приоритетного экземпляра он принудительно забирает на себя лидерство (takeover).

Выбор лидера для динамических распределенных сервисов осуществляется путем транзакции захвата и носит случайный характер. Операция failover сопровождается следующей итерацей случайного захвата лидерства одним из оставшихся экземпляров. Операция takeover не применяется.

Из конкуренции за лидерство выводятся экземпляры, действующие на серверах с отсутствующим доступом к внешнему арбитру. При загрузке не активируются, в ходе работы - 3 неудачных попытки через 2 секунды подряд перед принятием решения. Опция сайта check_offline.

3.6. Проблема PostgreSQL

Все инстансы PostgreSQL имеют потоковые реплики и подключены к контроллеру репликаций (микросервис mware, работающий в режиме active-passive). Контроллер репликаций активен лишь в группе, находящейся в кворуме и оставшейся в лидерах после взаимного опроса через WAN. В случае, если инстанс БД, находящийся в активной группе, является репликой, это обнаруживается активным контроллером репликаций. По истечении 30 секунд после обнаружения недоступности мастера контроллер преобразует реплику в мастер. Операция преобразования точечная и завершается за миллисекунды. С этих пор микросервисы, взаимодействующие с БД (mdc, dms, возможно script), получат возможность подключиться к БД.

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

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