Azure Service Bus Geo-Replication (Preview)

The Service Bus Geo-Replication feature is one of the options to insulate Azure Service Bus applications against outages and disasters, providing replication of both metadata (entities, configuration, properties) and data (message data and message property / state changes).

The Geo-Replication feature ensures that the metadata and data of a namespace are continuously replicated from a primary region to one or more secondary regions.

• Queues, topics, subscriptions, filters.
• Data, which resides in the entities.
• Все изменения состояния и свойств выполняются в отношении сообщений в пределах пространства имен.
• Конфигурация пространства имён.

This feature allows promoting any secondary region to primary, at any time. Promoting a secondary repoints the name for the namespace to the selected secondary region, and switches the roles between the primary and secondary region. The promotion is nearly instantaneous once initiated.

Сценарии

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

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

Data and metadata are continuously synchronized between the primary and secondary regions. Если регион отстает или недоступен, можно назначить вторичный регион в качестве основного. Данная акция позволяет обеспечить бесперебойную работу нагрузок в недавно повышенном регионе. Такая промоция может быть вызвана деградацией Service Bus или других сервисов в вашем рабочем процессе, особенно если вы планируете запускать различные компоненты вместе. В зависимости от серьезности и затронутых услуг, продвижение может быть либо планируемым, либо вынужденным. В случае планируемого повышения, сообщения в реальном времени копируются до завершения повышения, тогда как при принудительном повышении это выполняется немедленно.

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

Иногда возникает необходимость перенести рабочие нагрузки Service Bus для запуска в другом регионе. Например, когда Azure добавляет новый регион, который находится географически ближе к вашему местоположению, пользователям или другим услугам. В качестве альтернативы, вы можете захотеть перенести данные, когда изменится регион, в котором выполняется большинство ваших задач. Функция георепликации также предлагает хорошее решение в этих случаях. In this case, you would set up Geo-Replication on your existing namespace with the desired new region as secondary region and wait for the synchronization to complete. На этом этапе вы бы начали запланированную акцию, что позволит дублировать любые активные сообщения. Once the promotion is completed you can now optionally remove the old region, which is now the secondary region, and continue running your workloads in the desired region.

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

The Geo-Replication feature implements metadata and data replication in a primary-secondary replication model. В определенный момент есть один главный регион, который обслуживает как производителей, так и потребителей. Вторичные регионы действуют как горячий резерв, то есть с этими вторичными регионами невозможно взаимодействовать. Однако они работают в той же конфигурации, что и основная область, что позволяет быстро продвигаться и означает, что ваши рабочие нагрузки могут сразу продолжить работу после завершения продвижения. Функция георепликации доступна на премиум уровне.

Некоторые из ключевых аспектов функции георепликации:

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

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

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

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

При использовании асинхронной репликации все запросы фиксируются на основном сервере, после чего клиенту отправляется подтверждение. Replication to the secondary regions happens asynchronously. Пользователи могут настроить максимально допустимое время задержки. Время задержки — это смещение на стороне сервиса между последним действием в основном и вторичном регионах. Если задержка для активного вторичного узла превышает настройки пользователя, первичный узел начинает ограничивать входящие запросы.

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

При использовании синхронной репликации все запросы реплицируются на вторичный сервер, который должен завершить и подтвердить операцию перед фиксацией на основном сервере. As such, your application publishes at the rate it takes to publish, replicate, acknowledge, and commit. Moreover, it also means that your application is tied to the availability of both regions. Если вторичный регион отстает или недоступен, сообщения не будут подтверждены и зафиксированы, а основной регион будет замедлять входящие запросы.

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

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

• Latency is longer due to the distributed commit operations.
• Availability is tied to the availability of two regions.

On the other hand, synchronous replication provides the greatest assurance that your data is safe. Если у вас есть синхронная репликация, то при фиксации данные фиксируются во всех регионах, которые вы настроили для георепликации, обеспечивая наилучшую надежность данных.

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

• Задержка минимально влияет.
• The loss of a secondary region doesn't immediately impact availability. Однако доступность становится проблематичной, как только достигается настроенная максимальная задержка репликации.

As such, it doesn’t have the absolute guarantee that all regions have the data before we commit it like synchronous replication does, and data loss or duplication may occur. Однако, так как вы больше не испытываете непосредственного влияния, когда один из регионов отстает или недоступен, доступность приложения улучшается, что способствует также снижению задержки.

Режим репликации можно изменить после настройки георепликации. Вы можете перейти от синхронного к асинхронному или от асинхронного к синхронному. Если вы переходите с асинхронного режима на синхронный, ваш вторичный узел будет настроен как синхронный после того, как задержка достигнет нуля. Если у вас постоянно возникают задержки по какой-либо причине, возможно, вам нужно приостановить публикации, чтобы задержка дошла до нуля, и ваш режим смог переключиться на синхронный. The reasons to have synchronous replication enabled, instead of asynchronous replication, are tied to the importance of the data, specific business needs, or compliance reasons, rather than availability of your application.

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

Для включения функции георепликации необходимо использовать основные и вторичные регионы, в которых эта функция активирована. The Geo-Replication feature depends on being able to replicate published messages from the primary to the secondary regions. Если вторичный регион находится на другом континенте, это сильно влияет на задержку репликации от первичного региона ко вторичному. Если вы используете гео-репликацию по причинам доступности, то лучше всего, чтобы вторичные регионы находились хотя бы на одном континенте, если это возможно. Чтобы лучше понять задержку, вызванную географическим расстоянием, вы можете узнать больше из статистики задержки в сетях Azure.

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

The Geo-Replication feature enables customers to configure a secondary region towards which to replicate metadata and data. Таким образом, клиенты могут выполнять следующие управленческие задачи:

• Настройте гео-репликацию; вторичные регионы могут быть настроены в любом новом или существующем пространстве имен в регионе с включенной функцией гео-репликации.

  Заметка

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

• Настройте согласованность репликации; Синхронная и асинхронная репликация устанавливаются при настройке георепликации, но их также можно переключить позже.
• Trigger promotion; All promotions are customer initiated.
• Remove a secondary; If at any time you want to remove a secondary region, you can do so after which the data in the secondary region is deleted.

Setup

Using Azure portal

Следующий раздел представляет собой обзор настройки функции георепликации в новом пространстве имен через портал Azure.

1. Создайте новое пространство имен премиум-класса.
2. Установите флажок Включить георепликацию в разделе Репликация (предварительная версия).
3. Нажмите кнопку Добавить вторичный регион и выберите регион.
4. Либо установите флажок Синхронная репликация, либо укажите значение для Асинхронная репликация - Максимальное отставание репликации в секундах.

Using Bicep template

To create a namespace with the Geo-Replication feature enabled, add the geoDataReplication properties section.

param serviceBusName string
param primaryLocation string
param secondaryLocation string
param maxReplicationLagInSeconds int

resource sb 'Microsoft.ServiceBus/namespaces@2023-01-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'
        }
      ]
    }
  }
}

Управление

Как только вы создадите пространство имен с включенной функцией гео-репликации, вы сможете управлять этой функцией на панели Репликация (предварительная версия).

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

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

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

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

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

Акция запускается вручную клиентом (либо явно через команду, либо через бизнес-логику клиента, которая запускает команду) и никогда не Azure. Это предоставляет клиенту полное обладание и видимость для разрешения перебоев на магистральной сети Azure. При выборе Planned повышения, сервис ожидает устранения задержки репликации перед началом продвижения. On the other hand, when choosing Forced promotion, the service immediately initiates the promotion. Пространство имен будет переведено в режим только для чтения с момента запроса повышения до завершения процесса повышения. Можно выполнить принудительное продвижение в любое время после начала запланированного продвижения. Это дает пользователю возможность ускорить продвижение, если запланированное переключение занимает больше времени, чем ожидалось.

After the promotion is initiated:

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

   Note

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

2. Clients automatically reconnect to the secondary region.

Вы можете автоматизировать продвижение с помощью мониторинговых систем или собственных разработанных решений для мониторинга. However, such automation takes extra planning and work, which is out of the scope of this article.

Using Azure portal

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

Using Azure CLI

Выполните команду Azure CLI для начала продвижения. Свойство Force является необязательным и по умолчанию принимает значение false.

az rest --method post --url https://management.azure.com/subscriptions/<subscriptionId>/resourceGroups/<resourceGroup>/providers/Microsoft.ServiceBus/namespaces/<namespaceName>/failover?api-version=2023-01-01-preview --body "{'properties': {'PrimaryLocation': '<newPrimaryLocation>', 'api-version':'2023-01-01-preview', 'Force':'false'}}"

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

Users can monitor the progress of the replication job by monitoring the replication lag metric in Log Analytics.

• Включите журналы метрик в пространстве имен службы Service Bus, как описано в Monitor Azure Service Bus.
• Как только логирование метрик включено, вам нужно производить и потреблять данные из пространства имен в течение нескольких минут, прежде чем вы начнёте видеть логи.
• Чтобы просмотреть журналы метрик, перейдите в раздел мониторинга Service Bus и нажмите на вкладку Журналы. Вы можете использовать следующий запрос, чтобы найти задержку репликации (в секундах) между основным и второстепенным регионами.

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

Публикация данных

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

• After requesting promotion of a secondary region, the existing primary region rejects any new messages that are published to Service Bus until promotion has completed.
• Когда задержка репликации между основными и вторичными регионами достигает максимальной продолжительности задержки, входная рабочая нагрузка издателя может быть ограничена.

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

Потребление данных

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

Соображения

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

• При планировании продвижения вам следует также учитывать фактор времени. For example, if you lose connectivity for longer than 15 to 20 minutes, you might decide to initiate the promotion.
• Promoting a complex distributed infrastructure should be rehearsed at least once.

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

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

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

• См. справочник REST API по георепликации здесь.
• Запустите пример Geo-Replication на GitHub.
• См. пример георепликации , который отправляет сообщения на псевдоним.

To learn more about Service Bus messaging, see the following articles:

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