Географическое аварийное восстановление в служебной шине Azure

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

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

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

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

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

Важные факторы, которые следует принять во внимание

• Эта функция обеспечивает мгновенную непрерывность операций с такой же конфигурацией, но не реплицирует сообщения, хранящиеся в очередях или подписках разделов или очередях недоставленных сообщений. Чтобы сохранить семантику очереди, такой реплика tion требует не только реплика обработки данных сообщения, но и каждого изменения состояния в брокере. Для большинства служебная шина пространств имен требуемый трафик реплика tion будет значительно превышать трафик приложения и с очередями высокой пропускной способности, большинство сообщений по-прежнему реплика te в дополнительный, пока они уже удаляются из основного, вызывая чрезмерно пустой трафик. Для маршрутов репликации с высокой задержкой, которые применяются ко многим комбинациям, которые можно выбрать для геоизбыточного аварийного восстановления, трафик репликации может быть недоступен для поддержания трафика приложения из-за эффектов регулирования, вызванных задержками.
• Назначения управления доступом на основе ролей (RBAC) Microsoft Entra для служебная шина сущностей в основном пространстве имен не реплика в дополнительное пространство имен. Создайте назначения ролей в дополнительном пространстве имен вручную, чтобы защитить доступ к этим сущностям.
• Следующие конфигурации не реплика.
  • Конфигурации виртуальной сети
  • Подключения частных конечных точек
  • Включенный доступ ко всем сетям
  • Включенный доступ к доверенной службе
  • Доступ из общедоступной сети
  • Действие сети по умолчанию
  • Удостоверения и параметры шифрования (шифрование ключей, управляемых клиентом, или создание собственных ключей (BYOK))
  • Включить автомасштабирование
  • Отключение локальной проверки подлинности
• Связывание секционированного пространства имен с несекционным пространством имен не поддерживается.
• Если AutoDeleteOnIdle для сущности включена, сущность может не присутствовать в дополнительном пространстве имен при отработке отказа. Когда вторичный становится основным состоянием последнего доступа, который не является частью метаданных, не будет доступен для новой первичной и сущности может быть удален в рамках AutoDeleteOnIdle очистки.

Совет

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

Сбои и аварийные ситуации

Важно отметить различия между "сбоями" и "авариями".

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

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

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

Основные понятия и термины

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

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

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

• Основное или дополнительное пространство имен. Пространство имен, соответствующее псевдониму. Основное пространство имен — "активно" и получает сообщения (это может быть существующее или новое пространство имен). Дополнительное пространство имен является "пассивным" и не получает сообщений. Метаданные между ними синхронизированы, поэтому они могут беспрепятственно принимать сообщения без каких-либо изменений кода или строки подключения приложения. Чтобы убедиться, что только активное пространство имен получает сообщения, необходимо использовать псевдоним.

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

• Отработка отказа: процесс активации дополнительного пространства имен.

Настройка

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

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

1. Создайте основное пространство имен уровня "Премиум".

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

3. На портале Microsoft Azure перейдите к основному пространству имен.

4. Выберите Геоизбыточное восстановление в меню слева, а затем Инициировать связывание на панели инструментов.

   

5. Выполните следующие действия на странице Инициировать связывание.

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

   2. В поле Псевдоним укажите псевдоним для сопряжения geo-dr.

   3. Затем выберите Создать.

      

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

   

7. На странице Псевдоним Geo-DR выберите Политики общего доступа в меню слева, чтобы получить доступ к основной строке подключения для псевдонима. Используйте эту строку соединения вместо строки подключения напрямую к основному или дополнительному пространству имен. Изначально псевдоним указывает на основное пространство имен.

8. Перейдите на страницу Обзор. Доступны следующие действия.

   1. Разорвать связь между основным и вспомогательным пространствами имен. Выберите Разорвать связь на панели инструментов.
   2. Выполните переход в дополнительное пространство имен вручную.

      1. Выберите Отработка отказа на панели инструментов.

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

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

         Примечание.

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

      4. Затем выберите Отработка отказа.

         

         Внимание

         Отработка отказа активирует дополнительное пространство имен и удаляет основное пространство имен из пары "Гео-аварийное восстановление". Создать другое пространство имен для создания новой пары геоизбыточного аварийного восстановления.

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

Служебная шина от стандартной до премиум

Если вы перенесли пространство имен Служебная шина Azure уровня "Стандартный" в Служебная шина Azure Premium, необходимо использовать предварительно существующий псевдоним (т. е. служебная шина стандартное пространство имен строка подключения), чтобы создать конфигурацию аварийного восстановления с помощью PS/CLI или REST API.

Это связано с тем, что во время миграции Служебная шина Azure стандартное пространство имен строка подключения/DNS-имя становится псевдонимом в Служебная шина Azure пространстве имен premium.

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

Если вы используете портал Azure для настройки конфигурации аварийного восстановления, портал абстрагирует эту оговорку от вас.

Поток отработки отказа

Отработка отказа активируется клиентом вручную (явно командой или посредством клиента с бизнес-логикой, которая выполняет команду), а не Azure. Это дает клиенту полный контроль и видимость для устранения сбоя на платформе Azure.

После активации отработки отказа происходит следующее.

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

2. Клиенты (отправители и получатели) автоматически подключаются к дополнительному пространству имен.

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

После инициирования отработки отказа происходит следующее.

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

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

Примечание.

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

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

Управление

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

Использование имеющихся пространств имен в качестве псевдонима

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

Примеры

В примере из GitHub показано, как настроить и инициировать отработку отказа. В этих примерах демонстрируются следующие понятия:

• Пример и параметры .NET, необходимые в идентификаторе Microsoft Entra для использования Azure Resource Manager с служебная шина, для настройки и включения геокадрового восстановления.
• шаги, необходимые для выполнения примера кода;
• Использование имеющегося пространства имен в качестве псевдонима.
• Инструкции по включению географически избыточного восстановления с помощью PowerShell или CLI.
• Отправка и получение из текущего основного и дополнительного пространства имен с помощью псевдонима.

Рекомендации

Обратите внимание на следующие моменты для этого выпуска:

• При планировании отработки отказа следует также учитывать фактор времени. Например, в случае потери подключения на более чем 15–20 минут можно запустить отработку отказа.
• Тот факт, что данные не реплицируются, означает, что в настоящее время активные сеансы не реплицируются. Кроме того, могут не работать повторяющиеся сообщения и сообщения, запланированные. Новые сеансы, новые запланированные сообщения и новые повторяющиеся работы.
• Отработку отказа сложной распределенной инфраструктуры необходимо протестировать по крайней мере один раз.
• Синхронизация сущностей может занять некоторое время (примерно 50–100 сущностей в минуту). Подписки и правила также учитываются как сущности.

зоны доступности;

Номер SKU служебная шина premium поддерживает зоны доступности, предоставляя изолированные от сбоя расположения в одном регионе Azure. служебная шина управляет тремя копиями хранилища сообщений (1 первичный и 2 вторичный). служебная шина сохраняет синхронизацию всех трех копий для операций управления и данных. Если первичная копия завершается сбоем, одна из вторичных копий повышается до первичной без наблюдаемого простоя. Если приложения видят временные отключения от служебная шина, логика повторных попыток в пакете SDK автоматически повторно подключается к служебная шина.

При использовании зон доступности метаданные и данные (сообщения) реплицируются в центрах обработки данных в зоне доступности.

Примечание.

Поддержка Зон доступности Служебной шины Azure ценовой категории "Премицм"доступна только в регионах Azure, в которых представлены зоны доступности.

При создании пространства имен уровня "Премиум" на портале поддержка зон доступности (если она доступна в выбранном регионе) автоматически включена для пространства имен. При создании пространства имен уровня "Премиум" с помощью других механизмов, таких как шаблоны ARM/ Bicep, CLI или PowerShell, свойство zoneRedundant должно быть явно задано, чтобы true включить зоны доступности (если они доступны в выбранном регионе). Дополнительные затраты на использование этой функции отсутствуют, и вы не можете отключить или включить эту функцию после создания пространства имен.

Частные конечные точки

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

Новые пары

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

Примечание.

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

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

Существующие пары

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

Примечание.

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

Рекомендуемая конфигурация

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

Предположим, что у вас есть две виртуальные сети: VNET-1, VNET-2 и эти первичные и вторичные пространства имен: ServiceBus-Namespace1-Primary, . ServiceBus-Namespace2-Secondary Сделайте следующее:

• Создайте ServiceBus-Namespace1-Primaryдве частные конечные точки, использующие подсети из виртуальной сети-1 и виртуальной сети-2.
• Создайте ServiceBus-Namespace2-Secondaryдве частные конечные точки, использующие одни и те же подсети из виртуальной сети-1 и виртуальной сети-2.

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

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

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

Примечание.

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

Управление доступом на основе ролей

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

Следующие шаги

• Ознакомьтесь со справочными материалами по REST API для географического аварийного восстановления.
• Запустите пример географического аварийного восстановления на GitHub.
• Ознакомьтесь с примером географического аварийного восстановления, отправляющим сообщения псевдониму.

Дополнительную информацию об обмене сообщениями через служебную шину см. в следующих статьях:

• Очереди, разделы и подписки служебной шины
• Начало работы с очередями служебной шины
• Начало работы с разделами служебной шины
• REST API