Надежность в Центрах уведомлений Azure

Azure Notification Hubs помогает управлять push-уведомлениями в нескольких системах уведомлений платформы (PNS), таких как служба push-уведомлений Apple (APNs), Firebase Cloud Messaging (FCM) и Windows службы push-уведомлений (WNS).

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

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

Рекомендации по развертыванию в производственной среде

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

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

Azure Notification Hubs организованы вокруг пространств имен и центров уведомлений. Пространство имен — это граница управления, содержащая один или несколько центров. Центры представляют конечные точки для приложения. Устройства регистрируются с этими конечными точками с помощью регистраций или установок, которые позволяют службе отправлять push-уведомления на устройства. Дополнительные сведения см. в разделе "Управление регистрацией".

Центры уведомлений отправляют push-уведомления в системы уведомлений платформы (PNS), такие как служба push-уведомлений Apple (APNs) и Firebase Cloud Messaging (FCM). Сквозная доставка уведомлений зависит от доступности центров уведомлений и поведения подчиненных поставщиков PNS.

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

• Метаданные: Конфигурация пространства имён и центра, включая сведения о подключении и конфигурацию аварийного восстановления.
• Регистрационные данные: Регистрации устройств и установки, которые сопоставляют пользователей и устройства с тегами и шаблонами.

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

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

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

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

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

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

• Отправка уведомлений и операции управления: Используйте SDK, предоставляемый Microsoft, для отправки push-уведомлений и выполнения операций управления. Эти пакеты SDK автоматически повторяют попытку при возникновении временных сбоев.

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

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

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

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

Requirements

• Поддержка региона:

  Notification Hubs автоматически включает зональную избыточность для всех пространств имен в следующих регионах. Вы не можете отключить зональную избыточность в следующих регионах:

  Европа	Ближний Восток	Africa	Asia Pacific
  France Central	Qatar Central	Север Южной Африки	Северный Китай 3
  Italy North			Центральная Корея
  Norway East
  Центральная Польша
  Sweden Central
  Switzerland North

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

• Поддержка уровня: Зоны доступности можно использовать со всеми уровнями Центров уведомлений.

Cost

За зональную избыточность взимается дополнительная плата сверх стоимости ценового уровня. Дополнительные сведения см. в разделе цен на Центры уведомлений.

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

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

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

    Important

    В этих регионах служба Notification Hubs всегда создает пространства имен с включенной зональной избыточностью, даже если при развертывании с помощью кода, например, с использованием файла Bicep или шаблона Azure Resource Manager, указано, что зональная избыточность отключена.

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

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

• Сделайте существующее пространство имен избыточным: Центры уведомлений не поддерживают миграцию существующего пространства имен в поддержку зоны доступности. Необходимо развернуть новое пространство имен и переместить регистрации в это пространство имен. Следуйте указаниям из статьи Перемещение ресурсов между регионами Azure; это также применимо, если вы развертываете новое пространство имен в том же регионе.

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

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

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

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

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

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

• Обнаружение и реагирование: Microsoft обнаруживает сбои в зоне и управляет переключением при отказе в пределах региона. Вам не нужно инициировать переключение при отказе.

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

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

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

  Эта репликация не является резервной копией. В рамках модели общей ответственности вы несете ответственность за резервное копирование данных регистрации и установки. Дополнительные сведения см. в разделе "Резервное копирование и восстановление".

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

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

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

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

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

Вы не можете напрямую инициировать переключение на резервную зону в Notification Hubs. Чтобы проверить поведение рабочей нагрузки, выполните тесты устойчивости для повторных попыток, идемпотентности и сбоев зависимостей в непроизводственных средах. Вы также можете использовать Azure Chaos Studio для тестирования компонентов приложения.

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

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

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

аварийное геовосстановление метаданных под управлением Microsoft

Центры уведомлений поддерживают аварийное восстановление метаданных, управляемых Microsoft, в дополнительный регион Azure. Если в основном регионе есть парный регион, можно выбрать этот парный регион. Независимо от состояния связывания основного региона, вы также можете выбрать дополнительный регион из списка гибких регионов восстановления. Затем Центры уведомлений реплицируют метаданные пространства имен, такие как имя пространства имен, строки подключения и другие критически важные сведения.

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

Requirements

• Поддерживаемые регионы: В парных регионах Azure ваше пространство имен может использовать парный регион Azure в качестве вторичного региона.

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

  Америки	Европа	Africa	Asia Pacific
  Бразилия (Юг)	North Europe	Север Южной Африки	Australia East
  Западная часть США 2			Юго-Восточная Азия

• Поддержка уровня: Параметры аварийного восстановления метаданных доступны на всех уровнях Центров уведомлений.

Cost

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

Настройка поддержки нескольких регионов

• Включите геоаварийное восстановление метаданных для нового пространства имен: Выполните процедуру, описанную в разделе «Создание концентратора уведомлений Azure на портале Azure». При создании пространства имен выберите конфигурацию аварийного восстановления.

• Включите или отключите геоаварийное восстановление метаданных для существующего пространства имён: Следуйте инструкциям из раздела Включение аварийного восстановления для существующего пространства имён Azure Notification Hubs.

• Создайте резервную копию данных регистрации устройства: См. статью Экспорт и импорт регистраций Azure Notification Hubs в массовом режиме.

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

В этом разделе описано, чего ожидать при настройке пространства имён Notification Hubs для географического аварийного восстановления метаданных, если основной и дополнительный регионы работоспособны.

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

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

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

В этом разделе описывается, чего ожидать, если вы настроили пространство имен Notification Hubs для геовосстановления метаданных после аварии и в первичном регионе произошёл сбой.

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

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

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

• Ожидаемая потеря данных: Метаданные сохраняются. Данные регистрации не автоматически резервируются, но вы можете создать резервную копию самостоятельно. Дополнительные сведения см. в статье "Массовый экспорт и импорт регистраций в Azure Notification Hubs". Если вы этого не сделали, данные регистрации недоступны до тех пор, пока основной регион не восстановится.

• Ожидаемое время простоя: Microsoft требуется некоторое время, чтобы инициировать аварийное переключение метаданных, а затем — чтобы это переключение завершилось. Хотя время может отличаться, обычно это занимает несколько часов.

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

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

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

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

После восстановления основного региона необходимо выполнить следующие действия.

• Проверьте состояние пространства имен и его данных.
• Определите, следует ли синхронизировать последние изменения данных регистрации из дополнительного региона обратно в основной регион.

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

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

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

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

Если ваши целевые показатели восстановления предусматривают сокращение времени простоя или объема ручного вмешательства, вы можете внедрить специализированное мультирегиональное решение по схеме «активный — активный». Заранее разверните второе пространство имен Центров уведомлений в другом регионе Azure.

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

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

  • Для установок: Используйте серверную часть приложения, которая одновременно создает и обновляет установки в обоих центрах уведомлений. Установки позволяют указать собственный уникальный идентификатор устройства, который поддерживает этот сценарий репликации. Дополнительные сведения см. в примере RedundantHub.

  • Для регистрации: Используйте серверную часть приложения, которая регулярно экспортирует регистрации из основного концентратора уведомлений в качестве резервной копии и массовый импортирует их в дополнительный центр уведомлений. Дополнительные сведения см. в статье "Массовый экспорт и импорт регистраций Azure Notification Hubs".

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

• Истекшие регистрации и установки: Во вторичном концентраторе уведомлений могут быть регистрации и установки с истекшим сроком действия. Когда push-уведомление отправляется в дескриптор, срок действия которого истек, Центры уведомлений автоматически удаляют связанную запись о регистрации или установке в концентраторе уведомлений на основе ответа, полученного от сервера PNS. Вы можете очистить истекшие записи из выбранного решения резервного копирования, добавив пользовательскую логику, которая обрабатывает обратную связь от каждой отправки и удаляет просроченные регистрации и установки.

• Незакрытые приложения: Существует период времени, в течение которого устройства с незакрытыми приложениями не получают уведомлений.

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

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

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

• Используйте инфраструктуру в виде кода (IaC), например Bicep, чтобы определить пространство имён, хаб и конфигурацию политик. Сохраните эти определения в системе контроля версий, чтобы при необходимости вы могли повторно развернуть ресурсы.
• Создайте резервную копию данных о регистрации устройства, путем массового экспорта регистраций Azure Notification Hubs.

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

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

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

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

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

Связанные материалы

• Надежность в Azure