Надежность в Служба Azure SignalR

Служба Azure SignalR — это полностью управляемая служба, которая обеспечивает двунаправленное взаимодействие в веб-приложениях и мобильных приложениях в режиме реального времени. Он абстрагирует базовый механизм транспорта. Когда доступны WebSockets, служба использует их. Если они не работают, он переключается на серверные события или длинное опросирование. Эта абстракция означает, что код клиента и сервера может взаимодействовать в режиме реального времени без привязки к определенному транспортному протоколу.

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

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

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

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

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

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

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

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

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

Служба Azure SignalR поддерживает два режима службы. В режиме по умолчанию серверы приложений подключаются к ресурсу Служба Azure SignalR и содержат логику концентратора. В бессерверном режиме служба интегрируется с Функции Azure, а функции выполняют роль обработчиков сообщений на основе событий, чтобы не управлять серверами приложений напрямую. Для получения дополнительной информации см. Service mode в службе Azure SignalR.

Ресурс Служба SignalR имеет глобально уникальную конечную точку, аналогичную contoso.service.signalr.net. Клиенты устанавливают подключения к этой конечной точке. Серверы приложений подключаются к той же конечной точке для отправки сообщений и получения событий от клиентов.

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

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

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

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

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

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

Пакеты SDK Служба Azure SignalR включают встроенную обработку повторного подключения для подключений сервера к службе. Повторное подключение на стороне клиента зависит от используемой клиентской библиотеки. ASP.NET Core клиенты SignalR поддерживают повторное подключение с отслеживанием состояния, что позволяет клиенту возобновить предыдущее подключение, не теряя состояние, если он повторно подключается быстро с помощью того же идентификатора подключения. Если повторное подключение приводит к новому идентификатору соединения, например, после длительного сбоя, служба обрабатывает клиента как новое соединение. В этом случае клиенту необходимо повторно присоединиться к любым группам, в которые он был ранее, и восстановить любое состояние сеанса.

Для получения подробных инструкций по проектированию приложения для обработки отключений клиентов и повторных подключений, см. раздел Понимание отключений клиентов и повторных подключений в Служба Azure SignalR.

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

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

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

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

Требования

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

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

    Однако Запад Японии в настоящее время не поддерживает отказоустойчивость на уровне зон для Служба Azure SignalR.

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

Cost

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

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

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

  • Создайте ресурс зонально избыточного Служба SignalR. При создании ресурса выберите номер SKU уровня "Премиум". Дополнительные сведения см. в кратких руководствах, таких как Быстрый старт: создание чатовой комнаты с помощью службы SignalR.

  • Обновите существующий ресурс до уровня "Премиум". Зональная избыточность автоматически включается при обновлении существующего ресурса до SKU уровня Premium. Обновление с уровня "Стандартный" до "Премиум" не приводит к простою службы. Для получения дополнительной информации см. раздел Изменение уровня службы Azure SignalR.

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

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

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

  • Cross-zone data replication: Служба Azure SignalR не сохраняет данные клиента, поэтому нет данных для репликации между зонами. Состояние подключения является временным и связано с каждым активным подключением.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Geo-replication

Георепликация позволяет добавлять реплики вашего ресурса Служба SignalR в других регионах Azure. Диспетчер трафика Azure использует маршрутизацию на основе DNS для направления каждого клиента в ближайшую здоровую региональную реплику. Если в регионе происходит сбой, диспетчер трафика обнаруживает его с помощью проверок работоспособности и прекращает перенаправление клиентов к этой реплике. Новые клиентские подключения автоматически направляются к ближайшей работоспособной реплике.

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

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

Требования

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

Рекомендации

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

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

Cost

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

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

Сведения о добавлении или удалении реплики к ресурсу Служба Azure SignalR см. в разделе Geo-replication in Служба Azure SignalR.

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

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

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

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

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

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

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

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

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

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

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

  • Обнаружение и реакция: Служба SignalR отвечает за обнаружение сбоя в регионе и автоматическое перенаправление входящего трафика на реплику в одном из других регионов, которые вы настроили.
  • Уведомление: Microsoft не уведомляет вас автоматически об отключении региона. Однако вы можете использовать Работоспособность служб Azure, чтобы понять общее состояние службы, включая сбои в любом регионе, и настроить оповещения Service Health для уведомления о проблемах.
  • Активные запросы: Активные подключения к реплике в неудачном регионе удаляются. Клиенты должны повторно подключиться после отработки отказа реплики.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Во время планового обслуживания Служба Azure SignalR использует правильную стратегию завершения работы, чтобы снизить влияние на подключенные клиенты. Подключения постепенно отключаются по истечении заданного периода времени, что позволяет клиентам повторно подключаться постепенно, а не одновременно. Дополнительные сведения см. в разделе Отключения во время технического обслуживания службы.

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

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

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