Replicação geográfica do Barramento de Serviço do Azure (versão prévia)

O recurso de replicação geográfica do Barramento de Serviço é uma das opções para isolar aplicativos do Barramento de Serviço do Azure contra interrupções e desastres, fornecendo a replicação tanto de metadados (entidades, configuração, propriedades) quanto de dados (dados de mensagem e propriedades de mensagem/alterações de estado).

Observação

Esse recurso está disponível para o nível Premium do Barramento de Serviço do Azure.

O recurso de replicação geográfica garante que os metadados e os dados de um namespace sejam replicados continuamente de uma região primária para uma ou mais regiões secundárias.

• Filas, tópicos, assinaturas, filtros.
• Dados, que residem nas entidades.
• Todas as alterações de estado e alterações de propriedade executadas em relação às mensagens em um namespace.
• Configuração do namespace.

Observação

Atualmente, há suporte para apenas uma origem.

Esse recurso permite promover qualquer região secundária a primária, em qualquer momento. Promover uma secundária redireciona o nome do namespace para a região secundária selecionada e alterna as funções entre a região primária e secundária. Depois de iniciada, a promoção é quase instantânea.

Importante

• Esse recurso está atualmente em versão preliminar pública e não deve ser usado em cenários de produção.
• Atualmente, há suporte para as regiões abaixo na versão preliminar pública.

América do Norte	Europa	APAC
EUA Central EUAP	Norte da Itália	Austrália Central
Canadá Central	Espanha Central	Leste da Austrália
Leste do Canadá	Leste da Noruega

• Esse recurso está disponível atualmente em novos namespaces. Se um namespace tiver esse recurso habilitado antes, ele poderá ser desabilitado (removendo as regiões secundárias) e habilitado novamente.
• Atualmente, não há suporte para os recursos a seguir. Estamos continuamente trabalhando para trazer mais recursos para a versão preliminar pública e atualizaremos essa lista com o status mais recente.
  • Suporte a mensagens grandes.
  • Recursos de VNet/rede avançados/ (pontos de extremidade privados, ACLs de IP, NSP, pontos de extremidade de serviço).
  • Identidades (MSI, desabilitar autenticação local) e configurações de criptografia (criptografia CMK (chave gerenciada pelo cliente) ou criptografia BYOK (traga sua própria chave)).
  • Dimensionamento automático.
  • Namespaces particionados.
  • Enviar eventos para a Grade de Eventos.
• Esse recurso não pode ser usado em combinação com o recurso de Recuperação de desastre geográfico do Barramento de Serviço do Azure.

Cenários

O recurso de replicação geográfica pode ser usado para implementar diferentes cenários, conforme descrito aqui.

Recuperação de desastre

Dados e metadados são sincronizados continuamente entre as regiões primária e secundária. Se uma região estiver com retardo ou indisponível, será possível promover uma região secundária para primária. Essa promoção permite a operação ininterrupta de cargas de trabalho na região recém-promovida. Essa promoção pode ser necessária pela degradação do Barramento de Serviço ou outros serviços em sua carga de trabalho, especialmente se você pretende executar os vários componentes juntos. Dependendo da gravidade e dos serviços afetados, a promoção pode ser planejada ou forçada. No caso de promoção planejada, mensagens são replicadas durante o andamento da operação e antes da promoção ser finalizada, enquanto com a promoção forçada isso é executado imediatamente.

Migração de região

Há momentos em que você deseja migrar suas cargas de trabalho do Barramento de Serviço para execução em uma região diferente. Por exemplo, quando o Azure adiciona uma nova região que está geograficamente mais próxima de sua localização, usuários ou outros serviços. Como alternativa, talvez você queira migrar quando as regiões em que a maioria das cargas de trabalho são executadas forem deslocadas. O recurso de replicação geográfica também fornece uma boa solução nesses casos. Nesse caso, você configuraria a replicação geográfica em seu namespace existente com a nova região desejada como região secundária e aguardaria a conclusão da sincronização. Neste ponto, você iniciaria uma promoção planejada, permitindo que todas as mensagens em pré-lançamento fossem replicadas. Depois que a promoção for concluída, você poderá remover opcionalmente a região antiga, que será então a região secundária, e continuar executando suas cargas de trabalho na região desejada.

Conceitos básicos

O recurso de replicação geográfica implementa metadados e replicação de dados em um modelo de replicação primária-secundária. Em um determinado momento há apenas uma região primária, que está atendendo produtores e consumidores. As secundárias atuam como regiões de espera de acesso frequente, o que significa que não é possível interagir com essas regiões secundárias. No entanto, elas são executadas na mesma configuração que a região primária, permitindo uma promoção rápida e o que significa que suas cargas de trabalho podem continuar em execução imediatamente após a conclusão da promoção. O recurso de replicação geográfica está disponível para o nível Premium.

Alguns dos principais aspectos do recurso de replicação geográfica são:

• Os serviços do Barramento de Serviço executam a replicação totalmente gerenciada de metadados, dados de mensagem e alterações de estado e propriedade da mensagem entre regiões que aderem à consistência de replicação configurada no namespace.
• Nome do host de namespace único; Após a configuração bem-sucedida de um namespace habilitado para replicação geográfica, os usuários podem usar o nome do host do namespace no aplicativo cliente deles. O nome do host se comporta de maneira independente das regiões primárias e secundárias configuradas e sempre aponta para a região primária.
• Quando um cliente inicia uma promoção, o nome do host aponta para a região selecionada para ser a nova região primária. A antiga região primária se torna uma região secundária.
• Não é possível ler ou gravar nas regiões secundárias.
• Modos de replicação síncronos e assíncronos, descritos aqui.
• Promoção gerenciada pelo cliente da região primária para a secundária, fornecendo total propriedade e visibilidade para a resolução de interrupções. As métricas estão disponíveis, o que pode ajudar a automatizar a promoção do lado do cliente.
• Regiões secundárias podem ser adicionadas ou removidas a critério do cliente.

Modos de replicação

Há dois modos de replicação, síncrona e assíncrona. É importante saber as diferenças entre os dois modos.

Replicação assíncrona

Usando a replicação assíncrona, todas as solicitações são confirmadas no primário, após o qual uma confirmação é enviada ao cliente. A replicação para as regiões secundárias ocorre de maneira assíncrona. Os usuários podem configurar a quantidade máxima aceitável de tempo de retardo. O tempo de retardo é o deslocamento do lado do serviço entre a ação mais recente nas regiões primária e secundária. Se o retardo de uma região secundária ativa aumentar além da configuração do usuário, a primária começará a limitar as solicitações de entrada.

Replicação síncrona

Usando a replicação síncrona, todas as solicitações são replicadas para a região secundária, que precisa fazer commit e confirmar a operação antes de se fazer commit na região primária. Dessa maneira, seu aplicativo publica na velocidade necessária para publicar, replicar, confirmar e fazer commit. Além disso, isso também significa que seu aplicativo está vinculado à disponibilidade de ambas as regiões. Se a região secundária ficar defasada ou não estiver disponível, as mensagens não serão reconhecidas e confirmadas e a região primária limitará as solicitações de entrada.

Comparação entre modos de replicação

Com a replicação síncrona:

• A latência é maior devido às operações de commit distribuídas.
• A disponibilidade está vinculada à disponibilidade de duas regiões.

Por outro lado, a replicação síncrona fornece a maior garantia de que seus dados estão seguros. Se você tiver replicação síncrona, quando fizermos commit, ela será confirmada em todas as regiões configuradas para replicação geográfica, fornecendo a melhor garantia de dados.

Com a replicação assíncrona:

• A latência é afetada minimamente.
• A perda de uma região secundária não afeta imediatamente a disponibilidade. No entanto, a disponibilidade é afetada quando o atraso máximo de replicação configurado é atingido.

Dessa forma, ela não fornece a garantia absoluta de que todas as regiões tenham os dados antes de fazer commit deles como ocorre na replicação síncrona, e podem ocorrer duplicação ou perda de dados. No entanto, como você não é mais afetado imediatamente quando apenas uma região fica indisponível ou não está disponível, a disponibilidade do aplicativo melhora, além de ter uma latência menor.

Funcionalidade	Replicação síncrona	Replicação assíncrona
Latência	Mais tempo devido a operações de confirmação distribuídas	Minimamente afetado
Disponibilidade	Vinculado à disponibilidade de regiões secundárias	A perda de uma região secundária não afeta imediatamente a disponibilidade
Coerência de dados	O commit dos dados é sempre feito em ambas as regiões antes da confirmação	O commit dos dados é feito somente na região primária antes da confirmação
RPO (Objetivo de Ponto de Recuperação)	RPO 0, sem perda de dados na promoção	RPO > 0, possível perda de dados na promoção

O modo de replicação pode ser alterado após a configuração da replicação geográfica. Você pode ir da replicação síncrona para assíncrona ou da replicação assíncrona para síncrona. Se você for da replicação assíncrona para síncrona, sua região secundária será configurada como síncrona depois que o retardo atingir zero. Se a execução estiver com um retardo contínuo por qualquer motivo, talvez seja necessário pausar seus publicadores para que o retardo chegue a zero e seu modo possa ser alternado para replicação síncrona. Os motivos para ter a replicação síncrona habilitada, em vez de replicação assíncrona, estão vinculados à importância dos dados, às necessidades comerciais específicas ou às razões de conformidade, em vez da disponibilidade do aplicativo.

Observação

Caso uma região secundária apresente retardo ou fique indisponível, o aplicativo não poderá mais replicar para essa região e iniciará a limitação quando o retardo de replicação for atingido. Para continuar usando o namespace no local primário, a região secundária aflita pode ser removida. Se não houver mais regiões secundárias configuradas, o namespace continuará sem a replicação geográfica habilitada. É possível adicionar regiões secundárias adicionais a qualquer momento.

Seleção de região secundária

Para habilitar o recurso de replicação geográfica, você precisa usar uma região primária e secundária em que o recurso esteja habilitado. O recurso de replicação geográfica depende da capacidade de replicar mensagens publicadas da região primária para a secundária. Se a região secundária estiver em outro continente, isso terá um grande impacto no retardo da replicação da região primária para a secundária. Se você estiver usando a replicação geográfica por motivos de disponibilidade, é melhor que as regiões secundárias estejam pelo menos no mesmo continente, sempre que possível. Para entender melhor a latência induzida pela distância geográfica, saiba mais em Estatísticas de latência de ida e volta da rede do Azure.

Gerenciamento de replicação geográfica

O recurso de replicação geográfica permite que os clientes configurem uma região secundária para a qual replicar dados e metadados. Dessa forma, os clientes podem executar as seguintes tarefas de gerenciamento:

• Configurar a replicação geográfica: regiões secundárias podem ser configuradas em qualquer namespace existente em uma região com o recurso de replicação geográfica habilitado.

  Observação

  Atualmente, na versão preliminar pública, há suporte apenas para novos namespaces.

• Configurar a consistência de replicação: a replicação síncrona e assíncrona é definida quando a replicação geográfica é configurada, mas também pode ser alternada posteriormente.
• Disparar promoção: todas as promoções são iniciadas pelo cliente.
• Remover uma região secundária: se a qualquer momento você quiser remover uma região secundária, poderá fazê-lo depois que os dados na região secundária forem excluídos.

Instalação

Usando o Portal do Azure

A seção a seguir é uma visão geral para configurar o recurso de replicação geográfica em um novo namespace por meio do portal do Azure.

Observação

Essa experiência pode mudar durante a versão preliminar pública. Atualizaremos este documento de acordo.

1. Crie um namespace de nível Premium.
2. Marque a caixa de seleção Habilitar replicação geográfica na seção Replicação (versão prévia).
3. Clique no botão Adicionar região secundária e escolha uma região.
4. Verifique a caixa de seleção Replicação síncrona ou especifique um valor para o valor de Replicação Assíncrona – Retardo máximo de replicação em segundos.

Usando o modelo do Bicep

Para criar um namespace com o recurso de Replicação Geográfica habilitado, adicione a seção de propriedades geoDataReplication.

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'
        }
      ]
    }
  }
}

Gerenciamento

Depois de criar um namespace com o recurso de replicação geográfica habilitado, você poderá gerenciar o recurso na folha Replicação (versão prévia).

Alternar o modo de replicação

Para alternar entre os modos de replicação ou atualizar o retardo máximo de replicação, clique no link sob Consistência de replicação e clique na caixa de seleção para habilitar/desabilitar a replicação síncrona ou atualize o valor na caixa de texto para alterar o retardo máximo de replicação assíncrona.

Excluir região secundária

Para remover uma região secundária, clique nas reticências (...) ao lado da região e clique em Excluir. Para excluir a região, siga as instruções na folha pop-up.

Fluxo de promoção

Uma promoção é disparada manualmente pelo cliente (seja explicitamente por meio de um comando ou por meio da lógica de negócios de propriedade do cliente que aciona o comando) e nunca pelo Azure. Ele dá ao cliente visibilidade e propriedade completa para resolução de interrupção no backbone do Azure. Ao escolher a promoção Planejada, o serviço aguarda para acompanhar o retardo de replicação antes de iniciar a promoção. Por outro lado, ao escolher a promoção Forçada, o serviço inicia imediatamente a promoção. O namespace será colocado no modo somente leitura a partir do momento em que uma promoção for solicitada, até o momento em que a promoção for concluída. É possível fazer uma promoção forçada a qualquer momento após o início de uma promoção planejada. Isso coloca o usuário no controle para agilizar a promoção, quando uma recuperação planejada leva mais tempo do que o desejado.

Importante

Ao usar a promoção Forçada, todos os dados que não foram replicados podem ser perdidos.

Depois que a promoção for iniciada:

1. O nome do host é atualizado para apontar para a região secundária, o que pode levar alguns minutos.

   Observação

   Você pode verificar a região primária atual iniciando um comando ping: ping nome-do-seu-namespace-totalmente-qualificado

2. Os clientes se reconectam automaticamente à região secundária.

Você pode automatizar a promoção tanto com sistemas de monitoramento ou com soluções de monitoramento personalizadas. No entanto, essa automação precisa de planejamento e trabalho adicionais, o que está fora do escopo deste artigo.

Usando o Portal do Azure

No portal, clique no ícone Promover e siga as instruções na folha pop-up para excluir a região.

Usando a CLI do Azure

Execute o comando da CLI do Azure para iniciar a promoção. A propriedade Impor é opcional e usa como padrão falso.

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': '<newPrimaryocation>', 'api-version':'2023-01-01-preview', 'Force':'false'}}"

Monitorando a replicação de dados

Os usuários podem monitorar o progresso do trabalho de replicação monitorando a métrica de retardo de replicação no Log Analytics.

• Habilite os logs de métricas no namespace do Barramento de Serviço, conforme descrito no Barramento de Serviço do Azure Monitor.
• Depois que os logs de métricas do aplicativo estiverem habilitados, você precisará produzir e consumir dados do namespace por alguns minutos antes de começar a ver os logs.
• Para exibir os logs de métricas, navegue até a seção Monitoramento do Barramento de Serviço e clique na folha Logs. Você pode usar a consulta a seguir para localizar o retardo de replicação (em segundos) entre as regiões primária e secundária.

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

Publicando dados

Os aplicativos de publicação podem publicar dados em namespaces replicados geograficamente por meio do nome do host do namespace habilitado para replicação geográfica. A abordagem de publicação é a mesma que o caso de replicação não geográfica e nenhuma alteração em SDKs do plano de dados ou aplicativos cliente é necessária. A publicação pode não estar disponível durante as seguintes circunstâncias:

• Depois de solicitar a promoção de uma região secundária, a região primária existente rejeitará as novas mensagens publicadas no Barramento de Serviço até que a promoção seja concluída.
• Quando o retardo de replicação entre as regiões primária e secundária atinge a duração máxima de retardo de replicação, a carga de trabalho de entrada do publicador pode ser limitada.

Os aplicativos do publicador não podem acessar diretamente namespaces nas regiões secundárias.

Consumindo dados

O consumo de aplicativos pode consumir dados usando o nome do host do namespace de um namespace com o recurso de replicação geográfica habilitado. As operações do consumidor não têm suporte desde o momento em que a promoção é iniciada até que a promoção seja concluída.

Considerações

Observe as seguintes considerações a serem lembradas quanto a esta versão:

• Em seu planejamento de promoção, você também deve considerar o fator tempo. Por exemplo, se você perder a conectividade por mais de 15 a 20 minutos, você poderá decidir iniciar a promoção.
• A promoção de uma infraestrutura complexa distribuída deve ser testado pelo menos uma vez.

Preços

A camada Premium do Barramento de Serviço é precificada por unidade do sistema de mensagens. Com o recurso de Replicação Geográfica, as regiões secundárias são executadas no mesmo número de unidades do sistema de mensagens que a região primária e o preço é calculado sobre o número total de unidades do sistema de mensagens. Além disso, há uma cobrança pela replicação geográfica com base na largura de banda publicada vezes o número de regiões secundárias. Durante a versão preliminar pública antecipada, essa cobrança é dispensada.

Próximas etapas

• Veja a referência da API REST de Replicação Geográfica aqui.
• Execute o exemplo de replicação geográfica no GitHub.
• Consulte o exemplo de replicação geográfica que envia mensagens para um alias.

Para saber mais sobre as mensagens do Barramento de Serviço, confira os artigos a seguir:

• Filas, tópicos e assinaturas do Barramento de Serviço
• Introdução às filas do Barramento de Serviço
• Como usar tópicos e assinaturas do Barramento de Serviço
• REST API