Поделиться через

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Требования

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

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

Соображения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Geo-Replication

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

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

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

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

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

Замечание

Служебная шина Geo-Replication использует термин продвижение, так как лучше всего представляет процесс продвижения вторичного региона в основной регион (а затем понижение уровня основного региона во вторичный регион). Кроме того, может использоваться термин фейловер для описания общего процесса.

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

Требования

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

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

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

Соображения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Это важно

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

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

Схема, показывающая два пространства имен Service Bus, настроенных для геоаварийного восстановления метаданных.

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

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

Требования

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

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

  • Разбиение: Невозможно сочетать разделённое пространство имен с неразделённым пространством имен.

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

Соображения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Service Bus выполняет регулярное техническое обслуживание. Во время планового обслуживания пространства имен перемещаются на избыточный узел, содержащий последние обновления. Как только происходит это перемещение, клиентский SDK отключается и повторно подключается к пространству имен. Как правило, обновления происходят в течение 30 секунд. Важно, чтобы приложения были подготовлены для любых временных сетевых отключений , которые происходят в периоды обслуживания.

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

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

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

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

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

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

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

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

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

  • Last updated on