Надежность в службе Azure Web PubSub

Azure Web PubSub Service — это полностью управляемая служба обмена сообщениями в режиме реального времени, которая обеспечивает двунаправленное взаимодействие между серверами и клиентами с помощью протокола WebSocket. Один ресурс Web PubSub может масштабироваться до одного миллиона одновременных подключений WebSocket. Служба поддерживает несколько шаблонов обмена сообщениями, включая трансляцию от сервера к клиенту, обмен сообщениями в именованные группы, клиент-к-клиенту pub/sub и потоковую передачу токенов ИИ.

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

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

Рекомендации по развертыванию в рабочей среде для обеспечения надежности

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

  • Используйте уровень "Премиум". Уровень "Премиум" устойчив к сбоям зоны доступности в поддерживаемых регионах и позволяет настроить георепликацию.
  • Используйте Azure Web PubSub Client SDK при создании клиентских приложений или следуйте рекомендациям по безопасному повторному подключению для обработки временных сбоев. Переключение на резервное копирование между зонами и регионами, а также временные ошибки приводят к сбросу активных соединений.
  • Включите георепликацию для защиты от сбоев на уровне региона. Настройте каждую реплику таким образом, чтобы количество единиц было достаточным для обработки полного ожидаемого трафика в случае отказа.

Обзор архитектуры надежности

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

Логическая архитектура

Создаваемый ресурс — это ресурс Web PubSub. Вы настраиваете ресурс с несколькими единицами, которые представляют емкость ресурса, включая максимальное количество одновременных подключений. Дополнительные сведения см. в руководстве Performance для службы Azure Web PubSub.

Ресурс Web PubSub имеет глобально уникальную конечную точку, аналогичную contoso.webpubsub.azure.com. Клиенты устанавливают подключения WebSocket к этой конечной точке. Серверы приложений подключаются к той же конечной точке для отправки сообщений и получения событий от клиентов.

Дополнительные сведения см. в разделе Azure Web PubSub внутренних служб.

Физическая архитектура

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

Устойчивость к временным сбоям

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

Все облачные приложения должны следовать рекомендациям по обработке временных ошибок Azure при обмене данными с любыми размещенными в облаке API, базами данных и другими компонентами. Дополнительные сведения см. в Рекомендациях по обработке временных сбоев.

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

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

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

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

Устойчивость к сбоям зоны доступности

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

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

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

Требования

  • Поддержка региона: Избыточность зоны поддерживается в большинстве регионов, где применяются оба этих условия:

    • доступна служба Azure Web PubSub. Список регионов, где доступна служба, см. в разделе "Доступность продукта по регионам".
    • Регион поддерживает зоны доступности. Список регионов с зонами доступности см. в списке регионов Azure.

    Япония Запад в настоящее время не поддерживает зональную избыточность для Azure Web PubSub.

  • Уровень: Избыточность зоны доступна на уровне "Премиум".

Cost

Отказоустойчивость зоны не увеличивает расходы, и вы оплачиваете стандартный тариф уровня Премиум. Дополнительные сведения см. в разделе цен на услугу Azure Web PubSub.

Настройка поддержки зоны доступности

Избыточность зоны не требует настройки, кроме выбора уровня "Премиум". Он автоматически включен в обоих из этих случаев:

  • Создайте новый ресурс Web PubSub с отказоустойчивостью по зонам. При создании ресурса выберите номер SKU уровня "Премиум". Дополнительные сведения см. в разделе Создание ресурса Azure Web PubSub.

  • Обновите существующий ресурс до уровня "Премиум". Зональная избыточность автоматически включается при обновлении существующего ресурса до SKU уровня Premium. Обновление с уровня "Стандартный" до "Премиум" не приводит к простою службы. Дополнительные сведения см. в разделе Scale an Azure Web PubSub Service instance.

Поведение, когда все зоны работоспособны

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

  • Cross-zone operation: Azure Web PubSub Service автоматически управляет распределением подключений и операций между зонами доступности. Инфраструктура в нескольких зонах обрабатывает трафик в модели "активный-активный". Вам не нужно ничего настраивать, чтобы воспользоваться этим поведением. Служба автоматически направляет сообщения между экземплярами, находящимися в разных зонах, поэтому сообщение, которое отправляет клиент в одной зоне, передаётся клиентам, подключённым к любой другой зоне.

  • Cross-zone data replication: Azure Web PubSub Service не сохраняет данные клиента. Служба поддерживает метаданные сеанса, такие как сведения о состоянии подключения и последовательности сообщений для активных подключений. Эти метаданные синхронно реплицируются в зонах доступности.

Поведение во время сбоя зоны

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

  • Обнаружение и реагирование: Платформа службы Azure Web PubSub отвечает за обнаружение сбоя в зоне доступности. Вам не нужно предпринимать никаких действий для запуска переключения зоны при отказе.

  • Активные запросы: Во время сбоя зоны активные подключения WebSocket к инфраструктуре в затронутой зоне удаляются. Если клиенты обрабатывают временные ошибки соответствующим образом, например путем повторного подключения через короткий период времени, они обычно избегают значительного влияния.

  • Ожидаемая потеря данных: Служба Azure Web PubSub не сохраняет сообщения, поэтому отказ зоны обычно не приводит к потере данных в службе Azure Web PubSub. Однако все активные подключения прерываются во время события выхода из строя зоны, что приводит к потере всех данных, которые активно передаются.

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

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

  • Redistribution: Azure Web PubSub Служба обнаруживает потерю зоны и автоматически распределяет трафик по здоровым зонам. Вам не нужно предпринимать никаких действий.

Восстановление зоны

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

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

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

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

Устойчивость к сбоям на уровне региона

служба Azure Web PubSub — это служба с одним регионом. Если регион становится недоступным, ресурс Web PubSub также недоступен.

Чтобы защитить приложение от сбоя на уровне региона, можно использовать георепликацию, которая доступна на уровне "Премиум". Кроме того, можно создать пользовательское решение с несколькими регионами, развернув несколько ресурсов Web PubSub в разных регионах.

Geo-replication

Георепликация позволяет добавлять реплики ресурса Web PubSub в других регионах Azure. Все реплики совместно используют одну конечную точку (contoso.webpubsub.azure.com). За этой конечной точкой Диспетчер трафика Azure используется маршрутизация на основе DNS для направления каждого клиента в ближайшую здоровую региональную реплику. Если в регионе происходит сбой, диспетчер трафика обнаруживает его с помощью проверок работоспособности и прекращает перенаправление клиентов к этой реплике. Новые клиентские подключения автоматически направляются к ближайшей работоспособной реплике.

Диаграмма, показывающая конфигурацию Azure Web PubSub для георепликации между двумя регионами.

Регион, в который вы создали ресурс Web PubSub, называется основным регионом, и ее реплика является основной репликой. Уровень управления основного ресурса управляет конфигурацией ресурса Web PubSub.

Требования

  • Region support: Вы можете добавлять реплики в любом регионе, где доступна служба Azure Web PubSub.
  • Уровня: Чтобы включить георепликацию, необходимо использовать уровень "Премиум".
  • Ограничение реплики: Каждый основной ресурс Web PubSub поддерживает до восьми реплик.

Соображения

  • Наследование конфигурации: Реплики наследуют большинство параметров конфигурации от основного ресурса. Для каждой реплики необходимо настроить определенные параметры отдельно. Полный список параметров, которые не наследуются, см. в разделе Geo-replication in Azure Web PubSub.

  • Изменения конфигурации: Основная плоскость управления в основном регионе обрабатывает любые изменения конфигурации ресурса Web PubSub. Если основной уровень управления недоступен, вы не сможете обновить конфигурацию ресурсов, хотя существующие реплики будут продолжать обрабатывать трафик данных без прерывания.

Cost

Каждая реплика тарифицируется отдельно на основе собственного количества единиц и объема исходящих сообщений. Если сообщение передается между репликами, а затем передается клиенту или серверу в другом регионе, он оплачивается как исходящее сообщение. Дополнительные сведения см. в разделе Цены на услуги сервиса Azure Web PubSub.

Настройка георепликации

Сведения о добавлении или удалении реплики в ресурс Web PubSub см. в статье Geo-replication in Azure Web PubSub.

Планирование ресурсов и управление ими

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

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

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

Поведение, когда все регионы работоспособны

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

  • операция межрегиональная: Диспетчер трафика Azure направляет каждого клиента к ближайшей доступной региональной копии. Клиенты в разных географических областях могут подключаться к разным репликам. Служба Web PubSub синхронизирует сообщения между репликами, чтобы клиенты, подключенные к любой реплике, могли взаимодействовать друг с другом.

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

    служба Azure Web PubSub не сохраняет сообщения; только активная доставка синхронизируется между репликами.

Поведение во время сбоя региона

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

  • Обнаружение и ответ: Служба Web PubSub отвечает за обнаружение сбоя в регионе и автоматическое перенаправление входящего трафика в реплику в одном из других регионов, настроенных вами.

  • Активные запросы: Активные подключения WebSocket к реплике в регионе с ошибкой удаляются. Клиенты должны повторно подключиться после отработки отказа реплики.

  • Expected data loss: Azure Web PubSub Service не сохраняет сообщения. Сообщения, передаваемые клиентам в неисправном регионе во время сбоя, могут быть потеряны. Не ожидается постоянная потеря данных, так как служба не хранит данные клиента.

  • Ожидаемое время простоя: Диспетчер трафика Azure выполняет проверки работоспособности для каждой реплики. Если сбой региона приводит к сбою проверки работоспособности реплики, диспетчер трафика удаляет конечную точку этой реплики из результатов разрешения DNS. После удаления конечной точки срок жизни DNS в 90 секунд должен пройти до того, как клиенты увидят обновленные записи DNS. В общей сложности переход обычно занимает несколько минут. Хорошо разработанные клиенты, реализующие логику повторного подключения, могут возобновить нормальную работу после повторного подключения к работоспособной реплике.

    Если основная плоскость управления недоступна, вы не можете вносить изменения в конфигурацию ресурса Web PubSub или ее реплик. Однако подключения WebSocket продолжают работать в работоспособных репликах.

  • Redistribution: Диспетчер трафика Azure направляет входящие запросы на работоспособные реплики. Однако, если клиент пытается повторно подключиться до того, как Диспетчер трафика Azure обнаружит сбой реплики и обновлённые DNS-записи дойдут до клиента, то попытка повторного подключения клиента может по-прежнему быть направлена на недоступный регион и завершиться неудачей.

    После распространения обновления DNS клиенты, повторно подключающиеся, автоматически направляются к ближайшей исправной реплике.

Восстановление региона

Когда вышедший из строя регион восстанавливается, мониторинг работоспособности диспетчера трафика обнаруживает восстановленную реплику и снова включает её конечную точку в разрешение DNS. Клиенты, подключенные к другим репликам, не затрагиваются и остаются подключенными, пока они не будут отключены. Новые подключения снова перенаправляются на реплику восстановленного региона, когда она является ближайшей работоспособной репликой.

Проверка сбоев в регионе

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

Кастомные многорегиональные решения для повышения отказоустойчивости

Если вам нужна устойчивость в нескольких регионах, но вы не используете георепликацию, вы можете развертывать и управлять отдельными ресурсами Web PubSub в нескольких регионах и реализовывать собственную логику отказоустойчивости на сервере приложений. Этот подход более сложный, чем георепликация, и не поддерживает отказоустойчивость без простоя для клиент-клиент подключения. Для получения подробной информации об архитектуре, паттернах отказоустойчивости и руководстве по тестированию, см. раздел Устойчивость и аварийное восстановление в службе Azure Web PubSub.

Резервное копирование и восстановление

Служба Azure Web PubSub — это бессостоячная служба обмена сообщениями. Он не сохраняет сообщения клиентов и не имеет возможности резервного копирования или восстановления.

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

Устойчивость к обслуживанию служб

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

Соглашение об уровне обслуживания

Соглашение об уровне обслуживания (SLA) для служб Azure описывает ожидаемую доступность каждой службы и условия, которые должно соответствовать вашему решению для достижения этого ожидания доступности. Дополнительные сведения см. в разделе SLA для онлайн-услуг.

Связанный контент

  • Last updated on