Устойчивость и аварийное восстановление в службе Azure Web PubSub

Статья
10/26/2023

Устойчивость и аварийное восстановление — это одно из основных требований практически ко всем веб-системам. Служба Azure Web PubSub уже гарантирует доступность 99,9 %, но она по-прежнему является региональной службой. При возникновении сбоя на уровне региона важно, чтобы служба продолжала обрабатывать сообщения в режиме реального времени в другом регионе.

Для регионального аварийного восстановления рекомендуется использовать следующие два подхода:

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

Высокодоступная архитектура для службы Web PubSub

Существует два типичных шаблона с помощью службы Web PubSub:

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

В следующих разделах описаны различные способы выполнения аварийного восстановления в этих двух шаблонах.

Высокодоступная архитектура для шаблона клиентского сервера

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

Одна из типичных настроек для сценария между регионами заключается в наличии двух (или более) пар экземпляров службы Web PubSub и серверов приложений.

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

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

Сервер приложений может использовать API работоспособности службы проверка для обнаружения работоспособности или нет его основной и вторичной служб. Например, для вызываемой службы demoWeb PubSub конечная точка https://demo.webpubsub.azure.com/api/health возвращает 200, когда служба работоспособна. Сервер приложений может периодически вызывать конечные точки или вызывать конечные точки по запросу, чтобы проверка, если конечные точки работоспособны. Клиенты WebSocket обычно согласовывают с сервером приложений сначала, чтобы получить URL-адрес, подключающийся к службе Web PubSub, и приложение использует этот шаг согласования для отработки отказа клиентов на другие здоровые вторичные службы. Подробные действия, описанные ниже:

При согласовании клиента с сервером приложений сервер приложений ДОЛЖЕН возвращать только основные конечные точки службы Web PubSub, поэтому в обычном случае клиенты подключаются только к основным конечным точкам.
Если основной экземпляр отключен, согласование ДОЛЖНО возвращать здоровую вторичную конечную точку, чтобы клиент по-прежнему может выполнять подключения, и клиент подключается к вторичной конечной точке.
При запуске первичного экземпляра согласование ДОЛЖНО возвращать здоровую первичную конечную точку, чтобы клиенты могли подключаться к основной конечной точке.
При трансляции сообщений сервера приложений он ДОЛЖЕН транслировать сообщения во все здоровые конечные точки, включая как первичные, так и вторичные.
Сервер приложений может закрыть подключения, подключенные к вторичным конечным точкам, чтобы клиенты повторно подключались к работоспособной первичной конечной точке.

Благодаря этой топологии сообщение с одного сервера по-прежнему можно доставлять всем клиентам, так как все серверы приложений и экземпляры службы Web PubSub связаны между собой.

Мы еще не интегрировали стратегию в пакет SDK, поэтому для этого приложения необходимо реализовать эту стратегию самостоятельно.

В итоге, что необходимо реализовать стороне приложения:

Работоспособности проверка. Приложение может проверка, если служба работает с помощью API работоспособности службы проверка периодически в фоновом режиме или по требованию для каждого вызова переговоров.
Согласование логики. Приложение возвращает здоровую первичную конечную точку по умолчанию. Когда основная конечная точка отключена, приложение возвращает здоровую вторичную конечную точку.
Логика трансляции. Когда сообщения отправляются нескольким клиентам, приложение должно убедиться, что оно передает сообщения всем здоровым конечным точкам.

На схеме ниже показан пример такой топологии сети:

Diagram shows two regions each with an app server and a Web PubSub service, where each server is associated with the Web PubSub service in its region as primary and with the service in the other region as secondary.

Последовательность отработки отказа и рекомендации по ней

Теперь топология вашей системы настроена правильно. Каждый раз, когда один экземпляр службы Web PubSub отключен, трафик через Интернет будет перенаправлен в другие экземпляры. Вот что происходит, когда первичный экземпляр не работает (и восстанавливает работу через некоторое время):

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

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

Рис.1 перед отработой отказа Before Failover

Рис.2 после отработки отказа After Failover

Рис.3 Короткое время после первичного восстановления Short time after primary recovers

В обычном случае только основной сервер приложений и служба Web PubSub имеют интернет-трафик (в синем цвете).

После отработки отказа сервер приложений-получатель и служба Web PubSub также становятся активными. После возврата основной службы Web PubSub новые клиенты будут подключаться к основному веб-pubSub. При этом клиенты продолжают подключаться к вторичному экземпляру, поэтому оба экземпляра принимают трафик.

После отключения всех подключенных клиентов ваша система перейдет в обычное состояние (рис. 1).

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

Первый — иметь пару серверов приложений и экземпляр службы Web PubSub, принимающие весь интернет-трафик, и иметь другую пару как резервную копию (называемую активной и пассивной, иллюстрированной в рис.1).
Другой — иметь две (или более) пары серверов приложений и экземпляров службы Web PubSub, каждый из которых принимает участие в сетевом трафике и служит резервным копированием для других пар (называется активным и активным, похожим на Рис.3).

Служба Web PubSub может поддерживать оба шаблона, главное отличие заключается в том, как вы реализуете серверы приложений. Если серверы приложений активны и пассивны, служба Web PubSub также будет активной или пассивной (так как сервер основного приложения возвращает только его основной экземпляр службы Web PubSub). Если серверы приложений активны и активны, служба Web PubSub также будет активной и активной (так как все серверы приложений возвращают собственные основные экземпляры Web PubSub, поэтому все они могут получить трафик).

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

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

Высокодоступная архитектура для шаблона клиента-клиента

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

Тестирование отработки отказа

Выполните действия, чтобы активировать отработку отказа:

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