Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Географически распределенное аварийное восстановление — это функция аварийного восстановления в Центры событий Azure, постоянно реплицирующая конфигурацию пространства имен (концентраторы событий, группы потребителей и параметры) из основного пространства имен в резервное. Эта функция позволяет инициировать переключение отказа из первичного в вторичное пространство имен во время региональных сбоев.
Примечание.
В этой статье описывается функция восстановления после гео-катастроф, которая реплицирует только метаданные. Сведения о функции георепликации, которая реплицирует как данные, так и метаданные, см. в разделе "Георепликация".
Модель полностью активного кластера Центры событий Azure с поддержкой зоны доступности обеспечивает устойчивость к сбоям оборудования и отключениям в центрах обработки данных. Однако, если происходит авария, при которой весь регион и все зоны недоступны, можно использовать геоаварийное восстановление для восстановления рабочей нагрузки и конфигурации приложения.
Основные понятия и рабочий процесс, описанные в этой статье, применяются к сценариям стихийных бедствий, а не временным сбоям. Подробное обсуждение аварийного восстановления в Microsoft Azure см. в разделе Disaster recovery для приложений Azure. С помощью гео-восстановления после бедствий можно инициировать однократную смену с основного на вторичный в любое время. Переключение на резервную систему указывает выбранное имя псевдонима для пространства имен на резервное пространство имен. После перемещения соединение удаляется. После запуска переключение на резерв происходит почти мгновенно.
Внимание
- Эта функция обеспечивает мгновенную непрерывность операций с одной и той же конфигурацией, однако не реплицирует данные событий. Если авария не вызвала потерю всех зон, данные событий, сохраненные в основном концентраторе событий после отработки отказа, могут быть восстановлены, а доступ к историческим событиям можно будет получить после восстановления доступа. Для репликации данных событий и соответствующих пространств имен в активно-активных конфигурациях для решения сбоев и аварий не следует полагаться на этот набор функций гео-восстановления после сбоев, а следуйте инструкциям по репликации.
- Назначения управления доступом на основе ролей (RBAC) Microsoft Entra для сущностей в основном пространстве имен не реплицируются в вторичное пространство имен. Создайте назначения ролей в дополнительном пространстве имен вручную, чтобы обеспечить безопасность доступа.
Сведения о настройке пары для геокатастрофического восстановления и запуске переключения на резерв см. в разделе "Настройка геокатастрофического восстановления".
Основные понятия и термины
Функция аварийного восстановления реализует аварийное восстановление метаданных и зависит от основных и вторичных пространств имен аварийного восстановления. Функция гео-аварийного восстановления доступна только для стандартного, премиум и выделенного уровней. Вам не нужно изменять какие-либо строки подключения, так как подключение выполняется через псевдоним.
В этом руководстве используются термины, представленные ниже.
- Псевдоним. Имя настроенной конфигурации аварийного восстановления. Псевдоним предоставляет единую стабильную строку подключения полного доменного имени (FQDN). Приложения используют ее для подключения к пространству имен.
- Основное или дополнительное пространство имен. Пространство имен, соответствующее псевдониму. Основное пространство имен активно и получает сообщения (может быть существующим или новым пространством имен). Дополнительное пространство имен является пассивным и не получает сообщения. Метаданные между ними синхронизированы, поэтому они могут беспрепятственно принимать сообщения без каких-либо изменений кода или строки подключения приложения. Чтобы убедиться, что только активное пространство имен получает сообщения, необходимо использовать псевдоним.
- Метаданные: такие сущности, как центры событий и группы потребителей, и их свойства в рамках службы, связанной с пространством имен. Только сущности и их параметры реплицируются автоматически. Сообщения и события не реплицируются.
- Переключение при отказе: процесс активации вторичного пространства имен.
Поддерживаемые пары пространств имен
Поддерживаются следующие сочетания первичных и вторичных пространств имен.
| Уровень основного пространства имен | Уровень допустимого вторичного пространства имен |
|---|---|
| Стандарт | Стандартный, Выделенный |
| Премиум | Премиум |
| Специально выделенные | Специально выделенные |
Внимание
Невозможно связать пространства имен, размещенные в одном выделенном кластере. Можно связать пространства имен, размещенные в разных кластерах.
Соображения по резервированию
При планировании переключения на резерв рассмотрите следующие аспекты:
По замыслу, гео-катастрофическое восстановление Центров событий не отвечает за репликацию данных. Поэтому вы не можете повторно использовать старое значение смещения основного концентратора событий в дополнительном концентраторе событий. Перезапустите приемник событий с помощью одного из следующих методов:
- EventPosition.FromStart() — если вы хотите считывать все данные в дополнительном концентраторе событий.
- EventPosition.FromEnd() — если вы хотите считывать все новые данные с момента подключения к дополнительному концентратору событий.
- EventPosition.FromEnqueuedTime(dateTime) — если вы хотите считывать все данные, полученные в дополнительном концентраторе событий, начиная с заданной даты и времени.
Учитывайте фактор времени в планировании переключения на резерв. Если потеряно подключение более чем на 15–20 минут, можно предпринять переключение на резервный ресурс.
Так как данные не реплицируются, текущие активные сеансы не реплицируются. Кроме того, обнаружение дубликатов или запланированные сообщения могут не работать. Новые сеансы, запланированные сообщения и новые повторяющиеся работы.
Вы должны отрепетировать имитацию отказа как минимум один раз в распределённой сложной инфраструктуре.
Синхронизация сущностей может занять некоторое время (примерно 50–100 сущностей в минуту).
Некоторые аспекты контрольной плоскости для вторичного пространства имен становятся доступными только для чтения, когда активирована пара геовосстановления.
Плоскость данных вторичного пространства имен доступна только для чтения, пока взаимосвязь для геовосстановления активна. Плоскость передачи данных дополнительного пространства имен принимает GET-запросы для проверки подключения клиента и контроля доступа.
Частные конечные точки
В этом разделе представлены требования к использованию гео-восстановления после катастрофы в пространствах имен, использующих частные конечные точки. Чтобы узнать больше об использовании частных конечных точек с Центрами событий, ознакомьтесь с разделом Настройка частных конечных точек.
Новые пары
Если вы пытаетесь создать связывание между основным пространством имен с частной конечной точкой и вторичным пространством имен без частной конечной точки, связывание завершается ошибкой. Связывание выполняется только в том случае, если первичные и вторичные пространства имен имеют частные конечные точки. Используйте те же конфигурации в основных и вторичных пространствах имен и в виртуальных сетях, где создаются частные конечные точки.
Примечание.
При попытке связать основное пространство имен с частной конечной точкой и вторичным пространством имен процесс проверки проверяет, существует ли частная конечная точка в дополнительном пространстве имен. Не проверяется, работает ли конечная точка сейчас и будет ли она работать после переключения. Вы несете ответственность за то, чтобы вторичное пространство имен с приватной конечной точкой работало должным образом после фейловера.
Чтобы проверить, что конфигурации частных конечных точек совпадают с основными и вторичными пространствами имен, отправьте запрос на чтение (например, Get Event Hub) в дополнительное пространство имен извне виртуальной сети и убедитесь, что вы получаете сообщение об ошибке от службы.
Существующие пары
Если связь между основным и вторичным пространством имен уже существует, создание частной конечной точки в основном пространстве имен завершается сбоем. Чтобы устранить эту ошибку, сначала создайте частную конечную точку в дополнительном пространстве имен, а затем создайте ее для основного пространства имен.
Примечание.
Хотя вы можете получить доступ ко вторичному пространству имен только для чтения, вы можете обновить конфигурации частной конечной точки.
Рекомендуемая конфигурация
При создании конфигурации аварийного восстановления для приложений и пространств имен Центров событий создайте частные конечные точки для основных и вторичных пространств имен Центров событий. Эти частные конечные точки подключаются к виртуальным сетям, в которых размещаются как первичные, так и вторичные экземпляры приложения.
Предположим, у вас есть две виртуальные сети, VNET-1 и VNET-2, и эти первичные и вторичные пространства имен: EventHubs-Namespace1-Primary и EventHubs-Namespace2-Secondary. Выполните следующие действия.
- Создайте
EventHubs-Namespace1-Primaryдве частные конечные точки, использующие подсети изVNET-1иVNET-2 - На
EventHubs-Namespace2-Secondaryсоздайте две частные конечные точки, использующие одни и те же подсети изVNET-1иVNET-2
Преимуществом этого подхода является то, что резервное переключение может произойти на уровне приложения независимо от пространства имен Event Hubs. Рассмотрим следующие сценарии.
Отказоустойчивость только для приложения: В этом сценарии приложение отсутствует в VNET-1, но перемещается в VNET-2. Так как частные конечные точки настроены как для VNET-1 первичных, так и для VNET-2 вторичных пространств имен, приложение работает без проблем.
Отказоустойчивость только по пространствам имен Event Hubs: В этом сценарии частные конечные точки настроены на обеих виртуальных сетях как для основных, так и для вторичных пространств имен, и приложение работает.
Примечание.
Рекомендации по географически распределенному аварийному восстановлению виртуальной сети см. в статье Виртуальная сеть — непрерывность бизнес-процессов.
Ролевое управление доступом (RBAC)
Назначения управления доступом на основе ролей (RBAC) Microsoft Entra для сущностей в основном пространстве имен не реплицируются в вторичное пространство имен. Создайте назначения ролей в дополнительном пространстве имен вручную, чтобы обеспечить безопасность доступа.