Replicação Geográfica do Barramento de Serviço do Azure (Visualização)

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

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 de propriedade executadas nas mensagens dentro de um namespace.
• Configuração de namespace.

Este recurso permite promover qualquer região secundária para primária, a qualquer momento. A promoção de um secundário reaponta 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. A promoção é quase instantânea uma vez iniciada.

Cenários

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

Recuperação após desastre

Os dados e metadados são continuamente sincronizados entre as regiões primária e secundária. Se uma região estiver atrasada ou indisponível, é possível promover uma região secundária como primária. Esta promoção permite o funcionamento ininterrupto de cargas de trabalho na região recém-promovida. Tal promoção pode ser necessária pela degradação do Service Bus ou de outros serviços dentro da 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 da promoção planejada, as mensagens a bordo são replicadas antes de finalizar a promoção, enquanto com a promoção forçada isso é imediatamente executado.

Migração de região

Há momentos em que você deseja migrar suas cargas de trabalho do Service Bus para serem executadas em uma região diferente. Por exemplo, quando o Azure adiciona uma nova região que está geograficamente mais próxima da sua localização, utilizadores ou outros serviços. Como alternativa, convém migrar quando as regiões onde 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ê começaria uma promoção planejada, permitindo que todas as mensagens a bordo fossem replicadas. Quando a promoção estiver concluída, você pode, opcionalmente, remover a região antiga, que agora é 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ário-secundário. Em um determinado momento, há uma única região primária, que está servindo tanto produtores quanto consumidores. As secundárias atuam como regiões quentes em stand-by, o que significa que não é possível interagir com essas regiões secundárias. No entanto, eles são executados na mesma configuração da região principal, permitindo uma promoção rápida e o que significa que suas cargas de trabalho podem continuar sendo executadas imediatamente após a conclusão da promoção. O recurso de replicação geográfica está disponível para a camada Premium.

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

• Os serviços do Service Bus executam replicação totalmente gerenciada de metadados, dados de mensagens e alterações de estado e propriedade da mensagem entre regiões aderentes à consistência de replicação configurada no namespace.
• Nome de 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 de host do namespace em seu aplicativo cliente. O nome do host se comporta de forma agnóstica 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 principal. A antiga primária torna-se uma região secundária.
• Não é possível ler ou escrever nas regiões secundárias.
• Modos de replicação síncrona e assíncrona, descritos mais detalhadamente aqui.
• Promoção gerenciada pelo cliente da região primária para a secundária, fornecendo total propriedade e visibilidade para resolução de interrupções. Estão disponíveis métricas, que podem ajudar a automatizar a promoção do lado do cliente.
• As 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íncrono e assíncrono. É importante conhecer 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 que uma confirmação é enviada ao cliente. A replicação para as regiões secundárias acontece de forma assíncrona. Os usuários podem configurar a quantidade máxima aceitável de tempo de atraso. O tempo de atraso é o deslocamento do lado do serviço entre a ação mais recente nas regiões primária e secundária. Se o atraso de um secundário ativo crescer além da configuração do usuário, o primário 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 o secundário, que deve confirmar e confirmar a operação antes de confirmar no primário. Como tal, a sua aplicação publica ao ritmo necessário para publicar, replicar, reconhecer e confirmar. Além disso, isso também significa que seu aplicativo está vinculado à disponibilidade de ambas as regiões. Se a região secundária estiver atrasada ou indisponível, as mensagens não serão reconhecidas e confirmadas, e a principal limitará as solicitações recebidas.

Comparação do modo de replicação

Com replicação síncrona :

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

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

Com replicação assíncrona :

• A latência é minimamente afetada.
• 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.

Como tal, ele não tem a garantia absoluta de que todas as regiões têm os dados antes de confirmá-los, como a replicação síncrona, e a perda ou duplicação de dados pode ocorrer. No entanto, como você não é mais afetado imediatamente quando uma única região fica atrasada ou indisponível, a disponibilidade do aplicativo melhora, além de ter uma latência menor.

O modo de replicação pode ser alterado após a configuração da Replicação Geográfica. Você pode ir de síncrono para assíncrono ou de assíncrono para síncrono. Se você passar de assíncrono para síncrono, seu secundário será configurado como síncrono depois que o atraso atingir zero. Se você estiver executando com um atraso contínuo por qualquer motivo, talvez seja necessário pausar seus editores para que o atraso chegue a zero e seu modo possa alternar para síncrono. Os motivos para habilitar a replicação síncrona, em vez da replicação assíncrona, estão ligados à importância dos dados, às necessidades específicas dos negócios ou aos motivos de conformidade, e não à disponibilidade do seu aplicativo.

Seleção de região secundária

Para habilitar o recurso de replicação geográfica, você precisa usar regiões primárias e secundárias onde o recurso está habilitado. O recurso de replicação geográfica depende da capacidade de replicar mensagens publicadas das regiões primária para a secundária. Se a região secundária estiver em outro continente, isso terá um grande impacto no atraso de replicação da região primária para a secundária. Se 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, você pode aprender mais com as 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 metadados e dados. Como tal, os clientes podem executar as seguintes tarefas de gestão:

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

  Nota

  Atualmente, na visualização pública, apenas novos namespaces são suportados.

• Configurar a consistência da replicação; A replicação síncrona e assíncrona é definida quando a replicação geográfica é configurada, mas também pode ser comutada posteriormente.
• Promoção de gatilho; Todas as promoções são iniciadas pelo cliente.
• Remover um secundário; Se, a qualquer momento, você quiser remover uma região secundária, poderá fazê-lo após o que os dados na região secundária serão excluídos.

Configurar

Através do 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.

1. Crie um novo namespace de camada premium.
2. Marque a caixa de seleção Habilitar replicação geográfica na seção Replicação (visualização ).
3. Clique no botão Adicionar região secundária e escolha uma região.
4. Marque a caixa de seleção Replicação síncrona ou especifique um valor para o valor de atraso Replicação assíncrona - Replicação máxima em segundos.

Usando o modelo Bicep

Para criar um namespace com o recurso Geo-Replication 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'
        }
      ]
    }
  }
}

Gestão

Depois de criar um namespace com o recurso de Replicação Geográfica habilitado, você pode gerenciar o recurso na folha Replicação (visualização).

Modo de replicação do switch

Para alternar entre os modos de replicação ou atualizar o atraso máximo de replicação, clique no link em 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 atraso máximo de replicação assíncrona.

Excluir região secundária

Para remover uma região secundária, clique no botão ...-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 é acionada manualmente pelo cliente (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 total propriedade e visibilidade para a resolução de interrupções no backbone do Azure. Ao escolher a promoção planejada , o serviço aguarda para recuperar o atraso 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 planeada. Isso coloca o usuário no controle para agilizar a promoção, quando um failover planejado leva mais tempo do que o desejado.

Após o início da promoção:

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

   Nota

   Você pode verificar a região primária atual iniciando um comando ping: ping your-namespace-fully-qualified-name

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

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

Através do portal do Azure

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

Utilizar a CLI do Azure

Execute o comando CLI do Azure para iniciar a promoção. A propriedade Force é opcional e assume como padrão 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': '<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 atraso de replicação no Log Analytics.

• Habilite os logs de métricas em seu namespace do Service Bus, conforme descrito em Monitor Azure Service Bus.
• Depois que os logs de métricas 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 Service Bus e clique na folha Logs . Você pode usar a consulta a seguir para localizar o atraso de replicação (em segundos) entre as regiões primária e secundária.

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

Publicação de dados

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

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

Os aplicativos do Publisher não podem acessar diretamente nenhum namespace nas regiões secundárias.

Consumindo dados

Os aplicativos que consomem podem consumir dados usando o nome de host do namespace de um namespace com o recurso de replicação geográfica habilitado. As operações do consumidor não são suportadas a partir do momento em que a promoção é iniciada até que a promoção seja concluída.

Considerações

Observe as seguintes considerações a ter em mente com esta versão:

• No 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, poderá decidir iniciar a promoção.
• A promoção de uma infraestrutura distribuída complexa deve ser ensaiada pelo menos uma vez.

Preços

A camada Premium do Service Bus tem um preço por unidade de mensagens. Com o recurso de replicação geográfica, as regiões secundárias são executadas no mesmo número de MUs que a região primária, e o preço é calculado sobre o número total de MUs. Além disso, há uma cobrança com base na largura de banda publicada vezes o número de regiões secundárias. Durante a pré-visualização pública, esta taxa é dispensada.

Próximos passos

• Consulte 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 Service Bus, consulte os seguintes artigos:

• Filas, tópicos e subscrições do Service Bus
• Introdução às filas do Service Bus
• Como utilizar os tópicos e as subscrições do Service Bus
• API REST