Надежность в сервисной шине Azure

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

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

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

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

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

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

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

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

Пространство имен служит контейнером управления для служебной шины и может быть настроено для использования уровня "Базовый", "Стандартный" или "Премиум". Вы настраиваете службу на уровне пространства имен путем выделения емкости, настройки сетевой безопасности и включения Geo-Replication и Geo-Disaster Recovery.

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

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

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

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

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

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

Для пространств имен уровня "Премиум" служебная шина предоставляет выделенные единицы обмена сообщениями (MUS), которые имеют выделенные ресурсы ЦП и памяти. Пространства имен уровня "Премиум" могут автоматически масштабироваться на основе требований рабочей нагрузки. Дополнительные сведения см. в статье Автоматическое обновление MUS пространства имен служебной шины.

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

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

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

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

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

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

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

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

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

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

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

Требования

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

• Уровни: Все уровни служебной шины (Базовый, Стандартный и Премиум) поддерживают зоны доступности без дополнительных требований.

Соображения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В следующей таблице приведены основные различия между двумя функциями:

Для большинства сценариев аварийного восстановления Geo-Replication рекомендуется, так как он обеспечивает полную защиту данных. Рассмотрите использование Geo-Disaster Recovery только в случаях, если необходима репликация только метаданных.

** Geo-Replication и Geo-Disaster Recovery требуют ручного переключения на резервный режим или повышения статуса вторичного региона, чтобы он стал новым основным регионом. Корпорация Майкрософт не запускает переключение при отказе или повышение до ведущего, даже в случае отключения основного региона.

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

Geo-Replication

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

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

Пространство имен по сути охватывает регионы. Один регион выступает в качестве основного, а другие — вторичными. Ваша подписка Azure отображает одно пространство имён.

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

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

Требования

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

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

• Аварийное восстановление метаданных Geo: Нельзя настроить пространство имен для использования Geo-Replication и аварийного восстановления Geo.

Соображения

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

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

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

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

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

• Включите Geo-Replication в новом пространстве имен. Чтобы включить георепликацию в пространстве имен во время создания, см. статью Настройка георепликации.

• Перейти от использования метаданных Geo-Disaster Recovery к Geo-Replication.Переключиться с использования метаданных Geo-Disaster Recovery на Geo-Replication.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Восстановление метаданных в случае геокатастрофы

Тариф "Премиум" поддерживает метаданные восстановления при геокатастрофах. Эта функция улучшает восстановление от сценариев аварии, включая катастрофическую потерю региона. Geo-Disaster Recovery реплицирует только конфигурацию и метаданные пространства имен, но не реплицирует данные сообщений. Для поддержки аварийного восстановления эта функция гарантирует, что пространство имен в другом регионе предварительно настроено и готово немедленно принимать сообщения от клиентов. Geo-Disaster Recovery служит односторонним решением для восстановления и не поддерживает откат в предыдущий основной регион.

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

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

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

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

Требования

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

• Ярус: Чтобы включить восстановление метаданных Geo-Disaster, оба пространства имен должны использовать уровень "Премиум".

• Секционирование: Невозможно связать секционированное пространство имен с неклассифицированным пространством имен.

• Аварийное восстановление метаданных Geo: Нельзя настроить пространство имен для использования Geo-Replication и аварийного восстановления Geo.

Соображения

• Ограничения функций: При включении функции Geo-Disaster Recovery применяются некоторые ограничения. Дополнительные сведения см. в разделе "Важные моменты" и"Рекомендации".

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

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

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

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

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

При включении метаданных Geo-Disaster восстановления вы оплачиваете как первичные, так и вторичные пространства имен.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Geo-Replication и Geo-Disaster Recovery метаданных обеспечивают устойчивость к сбоям регионов и другим проблемам и подходят для большинства рабочих задач. Эти возможности могут не соответствовать вашим потребностям в следующих ситуациях:

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

• Вы используете уровень служебной шины, который не поддерживает эти функции.

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

• Изоляция приложений служебной шины от сбоев и аварий
• Репликация сообщений и федерация между регионами

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

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

Дополнительные сведения см. в разделе «События обслуживания Azure для служебная шина».

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

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

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

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

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

служебная шина предоставляет SLA для всех пространств имен. Гарантия доступности выше, если ваше пространство имен соответствует следующим критериям:

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

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

• Введение в служебная шина
• Восстановление служебной шины Geo-Disaster
• Георепликация служебной шины