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

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

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

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

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

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

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

Ниже приведена схема, которая иллюстрирует такую топологию:

Последовательность переключения на резервную систему и рекомендации по лучшим методам

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

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

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

Рис.1 до сбоя

Рис.2 после отказоустойчивости

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

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

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

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

Основные способы реализации архитектуры с высокой отказоустойчивостью и доступностью между регионами:

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

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

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

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

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

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

Как протестировать фейловер

Следуйте шагам, чтобы активировать аварийное переключение:

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

Дальнейшие действия

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

Используйте эти ресурсы для начала создания собственного приложения: