Геоизбыточное аварийное восстановление в службе "Центры событий Azure"
Устойчивость к катастрофическим сбоям ресурсов обработки данных является обязательным требованием для многих предприятий, а в некоторых случаях даже входит в состав отраслевых нормативных положений.
Центры событий Azure уже распространяет риск катастрофических сбоев отдельных компьютеров или даже полных стоек в кластерах, охватывающих несколько доменов сбоев в центре обработки данных. Он реализует прозрачные механизмы обнаружения сбоев и отработки отказа, таким образом, что служба будет продолжать работать в пределах гарантированного уровня обслуживания и, как правило, без заметных прерываний в случае таких сбоев. Если вы создаете пространство имен Центров событий с включенными зонами доступности, уменьшите риск сбоя и включите высокий уровень доступности. При наличии зон доступности риск сбоя дополнительно распространяется на три физически разделенных объекта, и служба имеет достаточно резервов емкости, чтобы мгновенно справиться с полным, катастрофическим потерей всего объекта.
Активная модель кластера концентраторов событий Azure с поддержкой зон доступности обеспечивает устойчивость к серьезным сбоям оборудования и даже катастрофической потере всех объектов центра обработки данных. Тем не менее могут возникнуть серьезные ситуации с широкомасштабными разрушениями, обеспечить защиту от которых не в силах даже эти меры.
Функция геоизбыточного аварийного восстановления Центров событий призвана упростить восстановление после аварии подобного масштаба и окончательное прекращение использования региона Azure, в котором произошел сбой, без необходимости изменять конфигурации приложений. Прекращение использования региона Azure, как правило, затрагивает несколько служб. Эта функция в основном нацелена на сохранение целостности конфигурации составного приложения.
Функция геоизбыточного аварийного восстановления гарантирует непрерывную репликацию всей конфигурации пространства имен (Центры событий, группы потребителей и параметры) из основного пространства имен в дополнительное пространство имен, если они используются в паре, и позволяет в любой момент инициировать единовременное перемещение из основного пространства имен в дополнительное с целью отработки отказа. При перемещении для отработки отказа выбранное имя псевдонима для пространства имен будет повторно назначено дополнительному пространству имен, после чего сопряжение будет разорвано. После инициации отработка отказа происходит почти мгновенно.
Важно!
- Эта функция обеспечивает мгновенную непрерывность операций с одной и той же конфигурацией, однако не реплицирует данные событий. Если сбой не привел к потере всех зон, данные о событии, сохраняемые в основном концентраторе событий после отработки отказа, будут восстановлены, а события за прошедший период можно будет оттуда получить после восстановления доступа. В случае сбоев и аварий при репликации данных о событиях и работе с соответствующими пространствами имен в конфигурациях "активный — активный" не используйте этот набор функций геоизбыточного аварийного восстановления, а следуйте руководству по репликации.
- Назначения управления доступом на основе ролей (RBAC) Microsoft Entra для сущностей в основном пространстве имен не реплика в дополнительное пространство имен. Создайте назначения ролей в дополнительном пространстве имен вручную, чтобы защитить доступ к этим сущностям.
Сбои и аварийные ситуации
Важно отметить различия между "сбоями" и "авариями". Сбой — это временная недоступность Центров событий Azure. Он может повлиять на некоторые компоненты службы, такие как хранилище сообщений, или даже весь центр обработки данных. Однако после устранения проблемы Центры событий снова становятся доступны. Как правило, простой не приводит к утрате сообщений или других данных. Примером такого сбоя может быть сбой питания в центре обработки данных. Некоторые сбои являются всего лишь кратковременными потерями подключения из-за временных или сетевых проблем.
Авария определяется как полная или долговременная потеря кластера Центров событий, региона Azure или центра обработки данных. Регион или центр обработки данных может снова стать доступным, но может и не стать или быть отключенным в течение нескольких часов или дней. Примеры аварий — пожар, наводнение или землетрясение. Длительное аварийное состояние может привести к потере некоторых сообщений, событий или других данных. Но в большинстве случаев потеря данных не происходит и сообщения можно восстановить сразу же после резервного копирования в центре обработки данных.
Функция географического аварийного восстановления Центров событий Azure — это решение для аварийного восстановления. Основные понятия и рабочий процесс, описанные в этой статье, относятся к сценариям восстановления после аварий, но не временных сбоев. Дополнительные сведения об аварийном восстановлении в Microsoft Azure см. в статье Аварийное восстановление для приложений на платформе Azure.
Основные понятия и термины
Функция аварийного восстановления реализует аварийное восстановление метаданных и основывается на первичном и вторичном пространстве имен для аварийного восстановления.
Функция геоизбыточного аварийного восстановления доступна только для номеров SKU ценовых категорий "Стандартный", "Премиум" и "Выделенный". Вам не нужно изменять какие-либо строки подключения, так как подключение выполняется через псевдоним.
В этом руководстве используются термины, представленные ниже.
Псевдоним. Имя настроенной конфигурации аварийного восстановления. Псевдоним предоставляет единую стабильную строку подключения полного доменного имени (FQDN). Приложения используют ее для подключения к пространству имен.
Основное или дополнительное пространство имен. Пространство имен, соответствующее псевдониму. Основное пространство имен является "активным" и получает сообщения (это может быть существующее или новое пространство имен). Дополнительное пространство имен является "пассивным" и не получает сообщений. Метаданные между ними синхронизированы, поэтому они могут беспрепятственно принимать сообщения без каких-либо изменений кода или строки подключения приложения. Чтобы убедиться, что только активное пространство имен получает сообщения, необходимо использовать псевдоним.
Метаданные. Сущности, такие как концентраторы событий и группы потребителей, и их свойства службы, связанные с пространством имен. Только сущности и их параметры реплицируются автоматически. Сообщения и события не реплицируются.
Отработка отказа: процесс активации дополнительного пространства имен.
Поддерживаемые пары пространств имен
Ниже приведены поддерживаемые сочетания основного и дополнительного пространств имен.
| Уровень основного пространства имен | Уровень разрешенного дополнительного пространства имен |
|---|---|
| Standard | Стандартный, Выделенный |
| Premium | Premium |
| Выделенные | Выделенные |
Примечание.
Невозможно связать пространства имен, размещенные в одном выделенном кластере. Можно связать пространства имен, размещенные в разных кластерах.
Настройка и поток отработки отказа
Здесь приведен обзор процесса отработки отказа и объясняется, как настроить начальную отработку отказа.
Настройка
Сначала создается или используется существующее основное пространство имен и новое дополнительное пространство имен, а затем они связываются. Это связывание предоставит псевдоним, который можно использовать для подключения. Так как используется псевдоним, нет необходимости изменять строки подключения. Только новые пространства имен могут быть добавлены к вашему связыванию.
Создание основного пространства имен.
Создание дополнительного пространства имен в другом регионе. Этот шаг необязательный. Вы можете создать дополнительное пространство имен при сопряжении на следующем шаге.
На портале Microsoft Azure перейдите к основному пространству имен.
Выберите Геоизбыточное восстановление в меню слева, а затем Инициировать связывание на панели инструментов.
Выполните следующие действия на странице Инициировать связывание.
- Выберите существующее дополнительное пространство имен или создайте его в другом регионе. В этом примере выбрано существующее пространство имен.
- В поле Псевдоним укажите псевдоним для сопряжения geo-dr.
- Затем выберите Создать.
Должна появиться страница Псевдоним Geo-DR. Кроме того, на эту страницу можно перейти из основного пространства имен, выбрав Геоизбыточное восстановление в меню слева.
На странице Псевдоним Geo-DR выберите Политики общего доступа в меню слева, чтобы получить доступ к основной строке подключения для псевдонима. Используйте эту строку соединения вместо строки подключения напрямую к основному или дополнительному пространству имен.
На этой странице Обзор можно выполнить следующие действия.
Разорвать связь между основным и вспомогательным пространствами имен. Выберите Разорвать связь на панели инструментов.
Выполните переход в дополнительное пространство имен вручную. Выберите Отработка отказа на панели инструментов.
Предупреждение
При отработке отказа будет активировано дополнительное пространство имен, а основное пространство имен будет удалено из связывания геоизбыточного аварийного восстановления. Создать другое пространство имен для создания новой пары геоизбыточного аварийного восстановления.
Наконец, следует добавить некоторые функции мониторинга, чтобы определить, необходимо ли выполнять отработку отказа. В большинстве случаев служба — это одна из частей большой экосистемы, поэтому автоматический переход на другой ресурс не всегда возможен, так как отработки отказа следует выполнять синхронно с оставшимися подсистемами или инфраструктурой.
Пример
Рассмотрим пример сценария с решением точки розничной продажи (POS), которое создает сообщения и события. Центры событий передают эти события решению сопоставления или переформатирования, которое затем переадресовывает сопоставленные данные в другую систему для дальнейшей обработки. В этот момент все эти системы могут размещаться в одном регионе Azure. Решение о том, когда и для каких частей выполнять отработку отказа, зависит от потока данных в инфраструктуре.
Отработку отказа можно автоматизировать с помощью систем мониторинга или пользовательских решений для мониторинга. Однако такая автоматизация требует дополнительного планирования и работы, что выходит за рамки данной статьи.
Поток отработки отказа
Если вы инициируете отработку отказа, необходимо выполнить два шага:
В случае другого сбоя необходимо иметь возможность повторной отработки отказа. Поэтому настройте другое пассивное пространство имен и обновите связывание.
Извлеките сообщения из прежнего основного пространства имен, как только оно станет доступным. После этого используйте это пространство имен для регулярного обмена сообщениями вне настройки географического восстановления или удалите старое основное пространство имен.
Примечание.
Поддерживается только семантика переадресации сбоя. В этом сценарии выполняется отработка отказа, а затем повторное связывание с новым пространством имен. Восстановление размещения не поддерживается, к примеру, в кластере SQL.
Переход на другой ресурс вручную
В этом разделе показано, как вручную выполнить отработку отказа с помощью портала Azure, CLI, PowerShell, C# и т. д.
На портале Microsoft Azure перейдите к основному пространству имен.
В меню слева выберите Geo-recovery (Геоизбыточное восстановление).
Выполните переход в дополнительное пространство имен вручную. Выберите Отработка отказа на панели инструментов.
Предупреждение
При отработке отказа будет активировано дополнительное пространство имен, а основное пространство имен будет удалено из связывания геоизбыточного аварийного восстановления. Создать другое пространство имен для создания новой пары геоизбыточного аварийного восстановления.
Управление
Если допущена ошибка, например, во время первоначальной настройки связаны неправильные регионы, связь двух пространств имен можно разорвать в любое время. Если вы хотите использовать сопряженные пространства имен в качестве обычных пространств имен, удалите псевдоним.
Рекомендации
Обратите внимание на следующие моменты.
Геоизбыточное аварийное восстановление Центров событий не реплицирует данные, поэтому вы не можете повторно использовать старое значение смещения основного концентратора событий в дополнительном концентраторе событий. Рекомендуется перезапустить приемник событий одним из следующих способов.
- EventPosition.FromStart() — если вы хотите читать все данные в дополнительном концентраторе событий.
- EventPosition.FromEnd() — если вы хотите читать все новые данные с момента подключения к дополнительному концентратору событий.
- EventPosition.FromEnqueuedTime(dateTime) — если вы хотите читать все данные, полученные в дополнительном концентраторе событий, начиная с заданной даты и времени.
При планировании отработки отказа следует также учитывать фактор времени. Например, в случае потери подключения на более чем 15–20 минут можно запустить отработку отказа.
Тот факт, что данные не реплицируются, означает, что в настоящее время активные сеансы не реплицируются. Кроме того, обнаружение дубликатов и запланированные сообщения могут не работать. Новые сеансы, запланированные сообщения и новые дубликаты будут работать.
Отработку отказа сложной распределенной инфраструктуры необходимо протестировать по крайней мере один раз.
Синхронизация сущностей может занять некоторое время (примерно 50–100 сущностей в минуту).
Некоторые аспекты плоскости управления для дополнительного пространства имен становятся доступны только для чтения, а пара геовосстановления активна.
Плоскость данных дополнительного пространства имен будет доступна только для чтения, а пара геовосстановления активна. Плоскость данных дополнительного пространства имен принимает запросы GET для включения проверки подключения клиента и управления доступом.
зоны доступности;
Центры событий поддерживают функцию Зоны доступности, предоставляя изолированные от сбоев расположения в регионе Azure. Поддержка Зоны доступности доступна только в регионах Azure с зонами доступности. Метаданные и данные (события) реплицируются в центрах обработки данных в зоне доступности.
Когда вы создаете пространство имен, при выборе региона, в котором находятся зоны доступности, отображается следующее выделенное сообщение.
Примечание.
При использовании портала Azure избыточность между зонами автоматически реализуется через поддержку зон доступности. Ее нельзя отключить на портале. Вы можете создать пространство имен без избыточности между зонами с помощью команды Azure CLI az eventhubs namespace с параметром --zone-redundant=false или с помощью команды PowerShell New-AzEventHubNamespace с параметром -ZoneRedundant=false.
Частные конечные точки
В этом разделе приводятся дополнительные рекомендации по применению геоизбыточного аварийного восстановления для пространств имен, в которых используются частные конечные точки. Чтобы узнать больше об использовании частных конечных точек с Центрами событий, ознакомьтесь с разделом Настройка частных конечных точек.
Новые пары
При попытке создать пару между основным пространством имен с частной конечной точкой и дополнительным пространством имен без частной конечной точки связывание завершится ошибкой. Связывание выполнится успешно, только если у основного и дополнительного пространств имен есть частные конечные точки. Рекомендуется использовать одинаковые конфигурации в основном и дополнительном пространствах имен и в виртуальных сетях, в которых создаются частные конечные точки.
Примечание.
При попытке связать основное пространство имен с частной конечной точкой и дополнительное пространство имен проверяется только, существует ли частная конечная точка в дополнительном пространстве имен. Не проверяется, работает ли конечная точка и будет ли она работать после отработки отказа. Вы должны убедиться, что дополнительное пространство имен с частной конечной точкой будет корректно работать после отработки отказа.
Чтобы проверить, совпадают ли конфигурации частных конечных точек в основном и дополнительной пространствах имен, отправьте запрос на чтение (например, Получение концентратора событий) к дополнительному пространству имен из-за пределов виртуальной сети и убедитесь, что служба выдает сообщение об ошибке.
Существующие пары
Если связывание между основным и дополнительным пространством имен уже существует, создание частной конечной точки в основном пространстве имен завершится ошибкой. Чтобы устранить эту проблему, сначала создайте частную конечную точку в дополнительном пространстве имен, а затем — в основном.
Примечание.
Хотя мы допускаем доступ только для чтения к дополнительному пространству имен, обновление конфигураций частных конечных точек разрешено.
Рекомендуемая конфигурация
При создании конфигурации аварийного восстановления для приложения и пространств имен Центров событий необходимо создать частные конечные точки для основного и дополнительного пространств имен Центров событий для виртуальных сетей, в которых размещаются как первичные, так и вторичные экземпляры приложения.
Предположим, что у вас есть две виртуальные сети, VNET-1 и VNET-2, а также основное и дополнительное пространства имен, EventHubs-Namespace1-Primary и EventHubs-Namespace2-Secondary. Сделайте следующее:
- В EventHubs-Namespace1-Primary создайте две частные конечные точки, которые используют подсети VNET-1 и VNET-2
- В EventHubs-Namespace2-Secondary создайте две частные конечные точки, которые используют подсети VNET-1 и VNET-2
Преимуществом этого подхода является то, что отработка отказа может происходить на уровне приложения независимо от пространства имен Центров событий. Рассмотрим следующие сценарии.
Отработка отказа только на уровне приложения. Приложение не будет существовать в VNET-1, но будет перемещено в VNET-2. Так как обе частные конечные точки настроены в VNET-1 и VNET-2 как для основного, так и для дополнительного пространства имен, приложение будет работать.
Отработка отказа только в пространстве имен Центров событий. И снова, так как обе частные конечные точки настроены в обеих виртуальных сетях как для основного, так и для дополнительного пространства имен, приложение будет работать.
Примечание.
Рекомендации по геоизбыточному аварийному восстановлению виртуальной сети см. в статье Виртуальная сеть — непрерывность бизнес-процессов.
Управление доступом на основе ролей
Назначения управления доступом на основе ролей (RBAC) Microsoft Entra для сущностей в основном пространстве имен не реплика в дополнительное пространство имен. Создайте назначения ролей в дополнительном пространстве имен вручную, чтобы защитить доступ к этим сущностям.
Следующие шаги
Изучите следующие примеры и справочную документацию.