Надежность в Центры событий Azure

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

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

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

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

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

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

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

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

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

В пространстве имен можно упорядочить события в концентратор событий. Экосистема Apache® Kafka называет этот тип сущности топиком. Концентратор событий или тема — это распределенный журнал событий, в который можно только добавлять.

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

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

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

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

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

Для обеспечения избыточности каждый кластер имеет несколько реплик, которые обрабатывают запросы на чтение и запись. Для оптимизации высокой доступности и производительности все данные хранятся в трех репликах хранилища. Чтобы масштабировать вычислительные ресурсы пространства имен, разверните единицы пропускной способности (TUS), единицы обработки (PUS) или единицы емкости (CUS) в зависимости от уровня. Дополнительные сведения см. в статье Масштабирование с помощью Центров событий.

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

Временные сбои

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

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

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

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

• Используйте встроенные политики повторных попыток. Центры событий и пакеты SDK Apache Kafka автоматически повторяют операции при ошибках, для которых возможно повторное выполнение операций, таких как сетевая задержка, ограничение частоты ответов или занятость сервера. Чтобы избежать ненужной перегрузки службы, они реализуют экспоненциальную задержку по умолчанию.

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

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

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

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

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

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

Центры событий поддерживают развертывания с зональной избыточностью на всех уровнях сервиса. При создании пространства имен Центров событий в поддерживаемом регионе избыточность зон автоматически включается без дополнительных затрат. Но в выделенном уровне зоны доступности поддерживаются только если имеется как минимум три вычислительных блока. Модель развертывания с резервированием по зонам применяется ко всем возможностям Event Hubs, включая Capture, Schema Registry и поддержку протокола Kafka.

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

Поддержка регионов

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

Требования

• Уровни "Стандартный" и "Премиум" поддерживают зоны доступности без дополнительной настройки.

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

Себестоимость

Избыточность зоны в Центрах событий не добавляет дополнительных затрат.

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

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

Нормальная работа

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

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

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

Опыт понижения зоны

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

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

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

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

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

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

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

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

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

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

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

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

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

Поддержка нескольких регионов

Центры событий поддерживают два типа поддержки нескольких регионов:

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

• Геоизбыточное восстановление метаданных (уровень "Стандартный" и выше) обеспечивает активно-пассивную репликацию конфигурации и метаданных между основным и вторичным регионом, но не реплицирует событийные данные. Используйте гео-аварийное восстановление для приложений, которые могут допустить некоторую потерю данных о событиях во время сценария аварии и которым необходимо быстро возобновить операции в другом регионе.

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

Geo-replication

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

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

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

В любое время вы можете продвигать дополнительный регион в основной регион. Когда вы повышаете вторичный регион, службы Event Hubs перенаправляют полное доменное имя пространства имён (FQDN) на выбранный вторичный регион, а предыдущий основной регион понижается до вторичного региона. Вы решаете, следует ли выполнять плановое повышение, что означает ожидание завершения репликации данных, или принудительное повышение, что может привести к потере данных.

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

Поддержка регионов

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

Требования

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

Соображения

При включении георепликации учитывайте следующие факторы:

• Формат контрольной точки: Формат контрольных точек изменяется. Дополнительные сведения см. в разделе "Георепликация: использование данных".

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

Себестоимость

Сведения о том, как работает цена на георепликацию, см. в разделе "Цены".

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

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

• Измените подход репликации. Чтобы изменить режим синхронизации и асинхронной репликации, см. раздел "Переключить режим репликации".

• Отключите георепликацию. Чтобы отключить георепликацию в дополнительный регион, см. раздел "Удалить дополнительный регион".

Нормальная работа

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

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

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

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

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

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

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

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

    При настройке асинхронной репликации необходимо настроить максимально допустимое время задержки для репликации. В любое время можно проверить текущую задержку репликации с помощью метрик Azure Monitor.

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

    Дополнительные сведения см. в режимах репликации.

Опыт региональной недоступности

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

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

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

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

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

  Настройте оповещения для получения уведомлений о проблемах на уровне региона. Дополнительные сведения см. в статье "Создание оповещений о работоспособности службы" на портале Azure.

• Активные запросы: Поведение зависит от того, происходит ли сбой региона в основном регионе или дополнительном регионе:

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

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

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

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

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

• Ожидаемая потеря данных: Объем потери данных зависит от типа продвижения (запланированного или принудительного) и режима репликации (синхронного или асинхронного):

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

  • Принудительное повышение, синхронная репликация: Не ожидается потеря данных.

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

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

• Ожидаемое время простоя: Количество ожидаемого простоя зависит от того, выполняете ли вы плановую или вынужденную рекламу:

  • Плановая промоция: Первый шаг в плановой промоции реплицирует данные в вторичный регион. В большинстве случаев этот процесс выполняется быстро, но в некоторых ситуациях это может занять столько времени, сколько длится задержка репликации. После завершения репликации процесс продвижения обычно занимает около 5–10 минут. Иногда может потребоваться больше времени для серверов системы доменных имен (DNS) для обновления записей и полной репликации записей на клиенты.

    Основной регион не принимает операции записи во время всего процесса продвижения.

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

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

    Основной регион не принимает операции записи в течение всего процесса повышения.

• Перенаправка трафика: После завершения продвижения полное доменное имя пространства имен указывает на новый основной регион. Но это перенаправление зависит от того, насколько быстро обновляются записи DNS клиентов, включая DNS-серверы для соблюдения времени жизни (TTL) записей DNS пространства имен.

  В некоторых ситуациях необходимо настроить потребительские приложения для согласованного поведения после продвижения региона. Дополнительные сведения см. в разделе "Георепликация: использование данных".

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

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

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

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

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

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

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

Гео-катастрофическое восстановление метаданных

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

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

При настройке геокатастасного восстановления метаданных создается псевдоним , к которому подключаются клиентские приложения. Псевдоним — это полностью квалифицированное доменное имя (FQDN), которое по умолчанию перенаправляет весь трафик на основное пространство имен.

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

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

Поддержка регионов

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

Требования

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

• Дополнительный уровень пространства имен: Гео-катастрофоустойчивое восстановление метаданных поддерживает определенные комбинации уровней для основных и вторичных пространств имен. Дополнительные сведения см. в разделе "Поддерживаемые пары пространств имен".

Соображения

• Назначения ролей: Назначения управления доступом на основе ролей (RBAC) Microsoft Entra для сущностей в основном пространстве имен не реплицируются в дополнительное пространство имен. Создайте назначения ролей в дополнительном пространстве имен вручную, чтобы защитить доступ к этим сущностям.

• Реестр схем: Метаданные реестра схем реплицируются при использовании гео-аварийного восстановления метаданных, но схемы, зарегистрированные в реестре схем, не реплицируются.

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

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

Себестоимость

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

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

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

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

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

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

Нормальная работа

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

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

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

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

  Все данные событий остаются только в основном пространстве имен и не реплицируются в дополнительное пространство имен.

Опыт региональной недоступности

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

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

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

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

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

  Настройте оповещения для получения уведомлений о проблемах на уровне региона. Дополнительные сведения см. в статье "Создание оповещений о работоспособности службы" на портале Azure.

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

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

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

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

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

• Ожидаемое время простоя: Переключение на резервную систему обычно происходит в течение 5–10 минут. На полную репликацию и обновление записей DNS у клиентов может уйти больше времени.

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

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

После восстановления исходного основного региона необходимо вручную заново установить связь и при необходимости осуществить возврат. Создайте новую пару гео-катастрофического восстановления с восстановленным регионом в качестве второстепенного, а затем выполните ещё одно переключение на резервную копию, если вы хотите вернуться в исходный регион. Этот процесс включает в себя потенциальную потерю данных событий, отправленных во временный первичный объект.

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

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

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

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

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

Альтернативные подходы с несколькими регионами

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

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

Backups

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

Если необходимо сохранить копии ваших событий, можно использовать Event Hubs Capture, который сохраняет эти копии в учетную запись Azure BLOB Storage.

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

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

Доступность SLA для вашего пространства имен выше, если используются уровни "Премиум" или "Выделенный".

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

• Документация по Центрам событий
• Обзор надежности Azure