Гео-репликация служебной шины Azure

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

Функция Geo-Replication непрерывно реплицирует метаданные и данные пространства имен из основного региона в один или несколько дополнительных регионов. Он реплицирует:

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

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

Сравнение с восстановлением после гео-бедствий

Служебная шина Azure предоставляет две функции для географической устойчивости: Geo-Replication и Geo-Disaster Recovery. Ключевое различие заключается в том, что Geo-Replication реплицирует метаданные и данные (сообщения, состояния сообщений, изменения свойств), а Geo-Disaster Recovery реплицирует только метаданные. Для большинства сценариев аварийного восстановления рекомендуется использовать георепликацию. Подробное сравнение см. в разделе "Надежность" в служебной шине Azure. Устойчивость к сбоям на уровне региона.

Сценарии

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

Восстановление после катастрофы

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

Миграция региона

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

Плановое техническое обслуживание

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

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

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

• Активный дополнительный регион: дополнительный регион, входящий в конфигурацию репликации и являющийся целевым регионом активной репликации. Активные вторичные узлы являются частью кворума при синхронной репликации. Дополнительные сведения см. в состоянии "Готово" в разделе Управление.
• Неактивный вторичный регион: вторичный регион, который настраивается или повторно синхронизируется после повышения роли. Неактивные вторичные узлы не являются частью кворума и не влияют на подтверждения в синхронном режиме. Дополнительные сведения см. в разделе "Состояние InBuild" в разделе "Управление".

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

Ниже приведены некоторые ключевые аспекты функции Geo-Replication:

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

Режимы репликации

Существует два режима репликации: синхронная и асинхронная. Важно понимать различия между двумя режимами.

Асинхронная репликация

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

Синхронная репликация

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

Сравнение режимов репликации

С синхронной репликацией:

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

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

С асинхронной репликацией:

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

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

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

Выбор вторичного региона

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

Управление гео-репликацией

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

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

Настройка

Использование портала Azure

В следующем разделе представлен обзор настройки функции Geo-Replication в новом пространстве имен на портале Azure.

1. Создайте новое пространство имен премиум-класса.
2. Установите флажок "Включить георепликацию" в разделе "Георепликация ".
3. Выберите "Добавить дополнительный регион" и выберите регион.
4. Установите флажок "Синхронная репликация" или укажите значение для асинхронной репликации — максимальное значение задержки репликации в минутах.

Использование шаблона

Чтобы создать пространство имен с включенным компонентом Geo-Replication, добавьте раздел свойств geoDataReplication .

@description('Name of the Service Bus namespace')
param serviceBusName string

@description('Primary location for the namespace')
param primaryLocation string

@description('Secondary location for geo-replication')
param secondaryLocation string

@description('Maximum replication lag in seconds for async replication')
param maxReplicationLagInSeconds int

resource serviceBusNamespace 'Microsoft.ServiceBus/namespaces@2025-05-01-preview' = {
  name: serviceBusName
  location: primaryLocation
  sku: {
    name: 'Premium'
    tier: 'Premium'
    capacity: 1
  }
  properties: {
    geoDataReplication: {
      maxReplicationLagDurationInSeconds: maxReplicationLagInSeconds
      locations: [
        {
          locationName: primaryLocation
          roleType: 'Primary'
        }
        {
          locationName: secondaryLocation
          roleType: 'Secondary'
        }
      ]
    }
  }
}

{
    "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
    "parameters": {
        "serviceBusName": {
            "type": "string",
            "metadata": {
                "description": "Name of the Service Bus namespace"
            }
        },
        "primaryLocation": {
            "type": "string",
            "metadata": {
                "description": "Primary location for the namespace"
            }
        },
        "secondaryLocation": {
            "type": "string",
            "metadata": {
                "description": "Secondary location for geo-replication"
            }
        },
        "maxReplicationLagInSeconds": {
            "type": "int",
            "metadata": {
                "description": "Maximum replication lag in seconds for async replication"
            }
        }
    },
    "resources": [
        {
            "type": "Microsoft.ServiceBus/namespaces",
            "apiVersion": "2025-05-01-preview",
            "name": "[parameters('serviceBusName')]",
            "location": "[parameters('primaryLocation')]",
            "sku": {
                "name": "Premium",
                "tier": "Premium",
                "capacity": 1
            },
            "properties": {
                "geoDataReplication": {
                    "maxReplicationLagDurationInSeconds": "[parameters('maxReplicationLagInSeconds')]",
                    "locations": [
                        {
                            "locationName": "[parameters('primaryLocation')]",
                            "roleType": "Primary"
                        },
                        {
                            "locationName": "[parameters('secondaryLocation')]",
                            "roleType": "Secondary"
                        }
                    ]
                }
            }
        }
    ]
}

Управление

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

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

Переключить режим репликации

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

Удалить вторичный регион

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

Процесс продвижения

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

Существуют два типа продвижения:

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

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

После начала продвижения:

1. Имя хоста обновится и начнёт указывать на вторичный регион, что может занять несколько минут.

   Примечание

   Вы можете проверить текущий основной регион, выполнив команду ping: ping полное имя вашего пространства имен

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

3. Если принудительное повышение было использовано, новый дополнительный регион входит в состояние InBuild во время повторной синхронизации, а затем переходит в Ready.

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

Использование портала Azure

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

Использование Azure CLI

Выполните команду Azure CLI, чтобы начать повышение.

az servicebus namespace failover --namespace-name <your-namespace-name> --resource-group <your-resource-group> --primary-location <new-primary-location>

Мониторинг репликации данных

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

Доступны две метрики задержки репликации; обе приводятся для каждой сущности (измерение EntityName):

• ReplicationLagDuration — задержка репликации в секундах, то есть насколько вторичный регион отстаёт от первичного. Эта метрика — это рекомендуемая метрика для мониторинга целевой точки восстановления (RPO) и настройки оповещений. Когда задержка достигает настроенного максимального значения, основной узел ограничивает входящие запросы.
• ReplicationLagCount — количество ожидающих операций репликации, на которое вторичный регион отстаёт от основного. Используйте это как относительный индикатор отставания репликации: устойчивое увеличение означает, что вторичный узел отстает. Это значение отражает внутренние операции журнала репликации, а не количество незарегистраированных сообщений.

Просмотр задержки репликации на портале Azure

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

1. Перейдите к пространству имен служебная шина на портале Azure.
2. Выберите метрики в разделе "Мониторинг ".
3. Выберите метрику ReplicationLagDuration из раскрывающегося списка.
4. На диаграмме отображается задержка репликации между основными и вторичными регионами в секундах.

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

Просмотр задержки репликации в Log Analytics

Чтобы использовать Log Analytics для запроса и исторического анализа, выполните приведенные ниже действия.

1. Включите журналы метрик в пространстве имен служебная шина, как описано в разделе "Мониторинг Служебная шина Azure".
2. После включения журналов метрик необходимо создать и использовать данные из пространства имен в течение нескольких минут, прежде чем приступить к просмотру журналов.
3. Чтобы просмотреть журналы Metrics, перейдите в раздел "Мониторинг" службы служебная шина и выберите вкладку Журналы. Вы можете использовать следующий запрос, чтобы найти задержку репликации (в секундах) между основным и второстепенным регионами.

AzureMetrics
| where TimeGenerated > ago(1h)
| where MetricName == "ReplicationLagDuration"

Соображения

При использовании этой функции следует учитывать следующие рекомендации.

• В планировании продвижения учитывайте фактор времени. Например, если вы потеряете подключение до 15–20 минут, вы можете принять решение инициировать повышение.
• Следует репетировать продвижение сложной распределенной инфраструктуры по крайней мере один раз.

Ценообразование

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

Вы можете вычислить общую стоимость следующим образом:
(количество реплик x MUs, настроенных на основной x часы x часовая ставка за MU) + (ГБ, реплицированные x ставка передачи данных на ГБ)

Например, если в основном пространстве имен настроено 2 МУ с репликацией 10 ГБ данных:
(2 реплики x 2 МЮ x часы x почасовая ставка) + (10 ГБ x скорость передачи данных)

Рекомендуемые сценарии для активации повышения уровня

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

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

Миграция

Для миграции из Geo-Disaster Recovery на Гео-Репликацию сначала отключите связку в основном пространстве имен.

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

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

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

Частные конечные точки — это региональные ресурсы. Для высокой доступности разверните приложение в нескольких регионах и создайте приватную конечную точку в виртуальной сети каждого региона.

DNS

Используйте одну privatelink.servicebus.windows.net приватную DNS-зону для каждого региона, подключённую только к виртуальной сети этого региона. Запись A для локальной приватной конечной точки добавляется автоматически, когда вы прикрепляете группу приватной DNS-зоны. Каждый регион сопоставляет имя пространства имён со своей локальной конечной точкой независимо от того, какой регион является основным.

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

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

Сценарии отказа

• Переключение на резерв только на уровне приложения. Приложение перемещается в другую виртуальную сеть. Он подключается к пространству имен через локальную частную конечную точку.
• Аварийное переключение только для пространства имён. Основная роль служебная шина меняется. Клиенты сохраняют одну и ту же строка подключения и локальную конечную точку; трафик автоматически направляется к новому основному.
• Региональный сбой. Частная конечная точка в затронутом регионе недоступна. Клиенты, использующие частную конечную точку в работоспособном регионе, продолжают работать в оставшемся доступном регионе.

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

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

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