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

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

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

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

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

Платформа Azure Well-Architected Framework предоставляет рекомендации по надежности, безопасности, затратам, операциям и производительности. Сведения о том, как эти области влияют друг на друга и способствуют надежному решению службы "Сетка событий Azure", см. в руководстве по Azure Well-Architected Framework для службы "Сетка событий Azure".

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

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

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

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

Служба "Сетка событий" поддерживает несколько типов ресурсов и моделей развертывания:

• Разделы — это основные сущности, которые получают и хранят события.

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

  Топики могут поддерживать push и pull-доставку.

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

• Пространства имен используются со стандартным уровнем и предоставляют контейнер для нескольких ресурсов сетки событий. Дополнительные сведения см. в концепциях пространства имен сетки событий Azure.

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

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

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

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

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

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

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

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

  Мы рекомендуем использовать пакеты SDK для плоскости данных сетки событий, которые автоматически обеспечивают временную обработку ошибок.

• Потребители событий: Event Grid направляет события в настроенные пункты назначения. Для этих исходящих подключений вы настраиваете политики повторных попыток в подписках на события. Эти политики определяют, как часто и сколько времени Event Grid будет пытаться повторно доставить сообщение в случае сбоя, включая временные ошибки. Дополнительные сведения см. в разделе отправки сообщений и повторных попыток с разделами пространства имен

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

  Вы несете ответственность за проектирование архитектуры обработки событий и приложения для обеспечения идемпотентности. Общие сведения см. в разделе "Идемпотентность".

• Обработка недоставленных сообщений: Event Grid поддерживает обработку недоставленных событий, что помогает сохранять данные при длительных сбоях у потребителей событий. Дополнительные сведения см. в статье о недоставке подписок на события в разделах пространства имен в Службе событий Azure.

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

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

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

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

Требования

Поддержка региона: Избыточность зон доступна во всех регионах Azure, поддерживающих зоны доступности.

Cost

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ресурс "Сетка событий"	Поддерживает восстановление после геокатастроф	Поддерживает пользовательское решение
Пользовательские темы	Поддерживается	Поддерживается
Системные темы	Включен автоматически	Не поддерживается
Домены	Поддерживается	Поддерживается
Пространства имен	Не поддерживается	Поддерживается
Пространства имен партнеров	Не поддерживается	Поддерживается

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

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

Гео-аварийное восстановление разработано в качестве оптимальной резервной копии, управляемой Корпорацией Майкрософт, для серьезных региональных сбоев и не предназначено для обеспечения быстрого или прогнозируемого времени восстановления. Корпорация Майкрософт инициирует переключение на резервный в редких ситуациях, чтобы осуществить переключение ресурсов Event Grid (Сетка событий) из затронутого региона в соответствующий парный регион. Корпорация Майкрософт оставляет за собой право определить, когда этот параметр будет использоваться. Этот механизм не включает согласие клиента до переключения трафика при сбое.

Это важно

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

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

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

Эта функция недоступна в регионах без парного региона.

Требования

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

• Типы ресурсов: Пользовательские темы и домены поддерживают восстановление после географических катастроф. Системные темы включены для автоматического восстановления после гео-катастроф. Другие типы ресурсов, такие как пространства имен и пространства имен партнеров, не поддерживаются.

Cost

Нет дополнительных затрат на геоотказоустойчивое восстановление.

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

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

• Чтобы включить геоизбыточное восстановление: Обновите конфигурацию раздела или домена и выберите "Межрегионально" (по умолчанию).

• Чтобы отключить восстановление после региональной катастрофы: Обновите конфигурацию темы или домена и выберите «Региональный».

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

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

• Операция между регионами: Весь трафик направляется в основной регион.

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

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

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

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

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

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

• Ожидаемая потеря данных:

  • Metadata: Event Grid сохраняет метаданные во время резервирования. Так как все изменения метаданных реплицируются синхронно, потеря метаданных не ожидается.

  • Данные события: Данные о событиях в основном регионе недоступны и могут быть потеряны, если регион недоступен.

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

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

    Замечание

    Event Grid не может гарантировать сохранение данных во время сбоя в регионе. Если требуется гарантированное хранение, необходимо разработать приложение для хранения событий в другом хранилище данных.

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

  После запуска переключения на резервный сервер в течение пяти минут Event Grid начинает принимать запросы для разделов и подписок, включая операции создания, обновления и удаления.

• Перераспределение: После завершения сбоя трафик автоматически направляется во вторичный регион.

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

Корпорация Майкрософт управляет восстановлением региона и процесс восстановления зависит от конкретного сценария сбоя. Переключение на резервный канал обычно рассматривается как односторонняя операция.

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

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

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

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

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

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

При разработке решения с несколькими регионами следует учитывать следующие факторы:

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

• Подходы к отказоустойчивости: Можно выбрать, следует ли создать активно-активное или активно-пассивное решение.

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

• Мониторинг работоспособности: Встроенные API работоспособности, предоставляемые сеткой событий, можно использовать для мониторинга работоспособности разделов.

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

  Кроме того, вы можете реализовать службу поддержки , которая направляет клиентов к основным или вторичным конечным точкам для своих тем или пространств имен, выполняя проверки работоспособности этих конечных точек. Служба поддержки может быть веб-приложением, которое географически реплицируется и поддерживается с помощью методов перенаправления DNS или таких служб, как Azure Traffic Manager.

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

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

Сетка событий в основном является службой маршрутизации событий и не имеет собственных функций резервного копирования или восстановления.

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

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

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

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

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

Соглашение об уровне обслуживания доступности сетки событий охватывает публикацию событий.

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

• Надежность в Azure
• Руководство по Azure Well-Architected Framework для Azure Event Grid
• Документация по Azure Event Grid