Replicação geográfica de Barramento de Serviço do Azure

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). Você pode habilitar Geo-Replication em namespaces novos e existentes.

O recurso Geo-Replication replica continuamente os metadados e os dados de um namespace de uma região primária para uma ou mais regiões secundárias. Ele replica:

  • Filas, tópicos, assinaturas e 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.

Esse recurso permite que você promova qualquer região secundária para primária, a qualquer momento. Promover uma região secundária renomeia o namespace para a região secundária selecionada e alterna as funções entre a região primária e a secundária.

Diagrama mostrando a replicação geográfica com uma região primária (Leste dos EUA) replicando para uma região secundária (Leste dos EUA 2), com clientes conectados à primária.

Observação

  • Esse recurso está disponível para o nível Premium do Barramento de Serviço do Azure.
  • Atualmente, há suporte apenas para uma única região secundária.

Importante

  • Você não pode usar esse recurso em combinação com o recurso Barramento de Serviço do Azure Geo-Disaster Recovery.
  • Os recursos a seguir ainda não estão disponíveis. A equipe do produto está continuamente trabalhando para trazer mais recursos e atualizará essa lista com o status mais recente.
    • Mensagens grandes ainda não têm suporte.
    • Geo-Replication em namespaces particionados ainda está em versão prévia pública.
  • Ao realizar um failover, o temporizador para entidades com exclusão automática em caso de inatividade ativada é reiniciado.
  • Ao habilitar a integração da Grade de Eventos em um namespace que usa a Replicação Geográfica, observe o seguinte:
    • A Grade de Eventos é replicada para o local emparelhado geograficamente, não para a região secundária configurada para replicação geográfica.
    • A promoção de uma região secundária para o Barramento de Serviço não inicia um failover da Grade de Eventos. Consequentemente, após a promoção, o Barramento de Serviço agora está em execução na nova região primária, mas a Grade de Eventos ainda está em execução na região primária inicial.
    • Se você remover a região primária inicial da configuração de Geo-Replication, essa ação interromperá a integração da Grade de Eventos.

Comparação com Geo-Disaster Recovery

O Barramento de Serviço do Azure oferece dois recursos para resiliência geográfica: Replicação Geográfica e Recuperação de Desastres Geográfico. A principal diferença é que Geo-Replication replica metadados e dados (mensagens, estados de mensagem, alterações de propriedade), enquanto Geo-Disaster Recovery replica apenas metadados. Para a maioria dos cenários de recuperação de desastre, Geo-Replication é a opção recomendada. Para obter uma comparação detalhada, consulte Confiabilidade no Barramento de Serviço do Azure – Resiliência a falhas em toda a região.

Cenários

Você pode usar o recurso Geo-Replication para implementar diferentes cenários, conforme descrito neste artigo. Para obter diretrizes sobre quando disparar uma promoção, consulte cenários recomendados para disparar a promoção.

Recuperação de desastre

As regiões primária e secundária sincronizam continuamente dados e metadados. Se sua região primária tiver uma degradação do serviço, você poderá promover uma região secundária como primária. Essa promoção mantém as cargas de trabalho em execução sem interrupção na região recém-promovida. Essa promoção pode ser necessária devido à degradação de 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 uma promoção planejada, o processo replica as mensagens de pré-lançamento antes da finalização da promoção. A promoção forçada executa imediatamente a promoção.

Migração de região

Talvez você queira migrar suas cargas de trabalho do Barramento de Serviço para serem executadas 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ê configura Geo-Replication no namespace existente com a nova região desejada como região secundária e aguarda a conclusão da sincronização. Quando a sincronização termina, você inicia uma promoção planejada, que replica todas as mensagens de pré-lançamento. Quando a promoção for concluída, você poderá remover opcionalmente a região antiga, que agora é a região secundária, e continuar executando suas cargas de trabalho na região desejada.

Manutenção planejada

Durante as atividades de manutenção planejadas na região primária, você pode promover a região secundária para manter a alta disponibilidade para aplicativos críticos. Essa abordagem permite que você execute a manutenção sem afetar suas cargas de trabalho.

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á uma única região primária que atende tanto produtores quanto consumidores. Regiões secundárias podem estar em um dos dois estados:

  • Secundário ativo: uma região secundária que faz parte da configuração de replicação e está sendo replicada ativamente. Secundários ativos fazem parte do quorum para replicação síncrona. Para obter mais informações, consulte o estado Pronto no Gerenciamento.
  • Secundária inativa: Uma região secundária que está sendo configurada ou sendo ressincronizada após uma promoção. Os secundários ociosos não fazem parte do quórum e não afetam as confirmações no modo síncrono. Para obter mais informações, consulte o estado do InBuild no Gerenciamento.

As regiões secundárias atuam como regiões de espera ativa, o que significa que você não pode interagir com elas. No entanto, eles são executados na mesma configuração que a região primária, o que permite uma promoção rápida. Suas cargas de trabalho podem continuar em execução imediatamente após a promoção.

Alguns dos principais aspectos do recurso Geo-Replication 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 de host de namespace único Após a configuração bem-sucedida de um namespace Geo-Replication habilitado, use o nome do host do namespace em seu aplicativo cliente. 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 você 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.
  • Nenhuma alteração é necessária nos SDKs do plano de dados ou nos aplicativos cliente para usar a Replicação Geográfica.
  • 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 de retardo de replicação estão disponíveis, que você pode usar para monitorar o status da replicação e automatizar a promoção.
  • Você pode adicionar ou remover regiões secundárias.
  • Quando o atraso de replicação atinge o máximo configurado, as solicitações do publicador são restringidas.

Modos de replicação

Há dois modos de replicação: síncrono e assíncrono. É importante entender as diferenças entre os dois modos.

Replicação assíncrona

Quando você usa a replicação assíncrona, o primário confirma todas as solicitações e envia uma confirmação ao cliente. A replicação para as regiões secundárias ocorre de maneira assíncrona. Você pode 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. O serviço replica continuamente os dados e metadados, garantindo que o atraso permaneça o menor possível. Se o atraso de um secundário ativo aumentar além do atraso máximo de replicação configurado pelo usuário, o primário iniciará a limitação das solicitações de entrada.

Replicação síncrona

Quando você usa a replicação síncrona, o sistema confirma todas as solicitações para os locais primário e secundário antes de enviar uma confirmação ao cliente. Por isso, o aplicativo é publicado na velocidade necessária para confirmar todas as regiões. Esse processo também significa que seu aplicativo depende da disponibilidade de ambas as regiões. Se houver retardo da região secundária ou ela estiver indisponível, a primária não reconhecerá nem confirmará mensagens e limitará 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 confirmação distribuídas.
  • A disponibilidade depende da 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ê usar a replicação síncrona, a operação de confirmação 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 é 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.

Assim, não há garantia absoluta de que todas as regiões tenham os dados antes da confirmação como a replicação síncrona, e a perda ou a duplicação de dados pode ocorrer quando se usa a promoção forçada. 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.

Recurso Replicação síncrona Replicação assíncrona
Latency Mais longo devido às operações de confirmação distribuídas Minimamente afetado
Disponibilidade Depende da disponibilidade de regiões secundárias A perda de uma região secundária não afeta imediatamente a disponibilidade
Consistê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 dentro do atraso configurado, possível perda de dados na promoção forçada

Você pode alterar o modo de replicação depois de configurar a Replicação Geográfica. Você pode alternar de síncrono para assíncrono ou de assíncrono para síncrono. Se você alternar de assíncrono para síncrono, seu secundário será configurado como síncrono depois que o atraso atingir zero. Se você estiver enfrentando 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 mudar para síncrono. Os motivos para habilitar a replicação síncrona 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

Se uma região secundária tiver atraso ou ficar indisponível, o aplicativo não poderá mais replicar para essa região e começará a aplicar restrições quando o atraso de replicação for atingido. Para continuar usando o namespace no local primário, remova a região secundária aflita. Se você remover todas as regiões secundárias, o namespace continuará sem Geo-Replication habilitado. Você pode adicionar regiões secundárias adicionais a qualquer momento. Entidades de nível superior, que são filas e tópicos, são replicadas de forma síncrona, independentemente do modo de replicação configurado. No entanto, as assinaturas de tópicos seguem o modo de replicação escolhido. Portanto, é crucial levá-los em conta ao decidir sobre o modo de replicação apropriado.

Seleção de região secundária

O recurso Geo-Replication depende da replicação de mensagens publicadas das regiões primárias para secundárias. Se a região secundária estiver em outro continente, essa opção afetará o atraso de replicação do primário para a região secundária. Se você usar Geo-Replication para disponibilidade, escolha regiões secundárias que estejam, pelo menos, no mesmo continente, sempre que possível. Para obter mais informações sobre a latência causada pela distância geográfica, consulte Azure estatísticas de latência de ida e volta da rede.

Gerenciamento de replicação geográfica

O recurso Geo-Replication permite configurar uma região secundária para replicar metadados e dados. Você pode executar as seguintes tarefas de gerenciamento:

  • Configurar a Replicação Geográfica. Você pode configurar regiões secundárias em qualquer namespace novo ou existente em uma região habilitando o recurso Geo-Replication.
  • Configure a consistência de replicação. Defina a replicação síncrona e assíncrona ao configurar a Replicação Geográfica. Você também pode alternar essa configuração mais tarde.
  • Promoção de gatilho. Todas as promoções são iniciadas pelo cliente.
  • Remova um elemento secundário. Você pode remover uma região secundária. Os dados na região secundária são excluídos.

Instalação

Usando o portal do Azure

A seção a seguir fornece uma visão geral para configurar o recurso Geo-Replication em um novo namespace por meio do portal do Azure.

  1. Crie um namespace de nível Premium.
  2. Marque a caixa de seleção Habilitar geo-replicação na seção Geo-Replication.
  3. Selecione Adicionar região secundária e escolha uma região.
  4. Marque a caixa de seleção de Replicação Síncrona ou especifique um valor para Replicação Assíncrona - Máximo atraso de replicação em minutos. Captura de tela mostrando a experiência Criar Namespace com a replicação geográfica habilitada.

Usar um modelo

Para criar um namespace com o recurso de Replicação Geográfica habilitado, adicione a seção de propriedades 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'
        }
      ]
    }
  }
}

Gerenciamento

Depois de criar um namespace com o recurso Geo-Replication habilitado, você pode gerenciar o recurso na folha Replicação Geográfica .

A região secundária pode estar em um dos seguintes estados:

Estado Description
InBuild A região secundária está sendo configurada e a sincronização inicial está em andamento ou a região está ressincronizando após uma promoção forçada. Regiões secundárias no estado InBuild não fazem parte do quorum.
Ready A região secundária faz parte da configuração de replicação e está sendo replicada ativamente.
Excluindo A região secundária está sendo removida da configuração de replicação.

Alternar o modo de replicação

Para alternar entre os modos de replicação ou atualizar o atraso máximo de replicação, selecione o link na consistência de Replicação. Marque a caixa de seleção para habilitar ou desabilitar a replicação síncrona ou atualize o valor na caixa de texto para alterar o atraso máximo de replicação assíncrono. Captura de tela mostrando como atualizar a configuração do recurso de replicação geográfica.

Excluir região secundária

Para remover uma região secundária, selecione Excluir e siga as instruções na folha pop-up. Enquanto a exclusão está em andamento, a região mostra o estado de exclusão . Captura de tela mostrando como excluir uma região secundária.

Fluxo de promoção

Um cliente dispara manualmente uma promoção (explicitamente por meio de um comando ou por meio da lógica de negócios de propriedade do cliente que dispara o comando). Azure nunca dispara uma promoção. Essa abordagem fornece ao cliente total propriedade e visibilidade da resolução de interrupções no backbone do Azure.

Existem dois tipos de promoção:

  • Promoção planejada: o serviço aguarda para acompanhar o atraso de replicação antes de iniciar a promoção. O namespace é colocado no modo somente leitura durante esse tempo, rejeitando novas mensagens e operações do consumidor até que a promoção seja concluída.
  • Promoção forçada: o serviço inicia a promoção imediatamente sem esperar que a replicação alcance.

Você pode fazer uma promoção forçada a qualquer momento após o início de uma promoção planejada, colocando você no controle para agilizar a promoção quando uma promoção planejada leva mais tempo do que o desejado. No entanto, mudar para a promoção forçada traz os mesmos riscos de perda de dados que iniciar uma promoção forçada diretamente.

Importante

Ao usar a promoção forçada, o serviço pode perder quaisquer dados ou metadados que não sejam replicados. Além disso, como as alterações de estado específicas ainda não são replicadas, essa ação também pode resultar no recebimento de mensagens duplicadas, como quando uma alteração de estado Concluída ou Adiada não foi replicada.

Após uma promoção forçada, a antiga primária (agora secundária) ainda contém dados não replicados. Esses dados são perdidos quando o primário antigo é ressincronizado como o novo secundário.

Aviso

Depois de realizar uma promoção forçada, a região primária anterior poderá conter dados não replicados e inconsistências de estado. Para garantir a integridade dos dados e evitar possíveis problemas com seu aplicativo, a melhor prática atual é excluir a região primária antiga e recriá-la em vez de permitir que ela seja ressincronizada como secundária.

Etapas recomendadas após a promoção forçada:

  1. Conclua a promoção obrigatória para estabelecer a nova região primária.
  2. Exclua a região primária antiga da configuração de Geo-Replication.
  3. Adicione uma nova região secundária para restaurar a redundância geográfica.

Seguir estas etapas ajuda a garantir que seu namespace opere com dados consistentes em todas as regiões.

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

  1. O nome de host é atualizado a fim de apontar para a região secundária, o que pode demorar vários 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.

  3. Se a promoção forçada foi usada, a nova região secundária entra no estado InBuild enquanto ela é ressincronizada e, em seguida, faz a transição para Pronto.

Captura de tela do portal mostrando o fluxo de promoção da região primária para a secundária.

Você pode automatizar a promoção 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, selecione o ícone Promover e siga as instruções no painel pop-up para excluir a região.

Captura de tela mostrando o fluxo para promover a região secundária.

Usando a CLI do Azure

Execute o comando CLI do Azure para iniciar a promoção.

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

Monitorando a replicação de dados

Você pode monitorar o progresso do trabalho de replicação verificando as métricas de retardo de replicação. Para obter uma lista completa das métricas disponíveis, consulte Métricas do Barramento de Serviço.

Duas métricas de atraso de replicação estão disponíveis, ambas apresentadas por entidade (na dimensão EntityName):

  • ReplicationLagDuration – o atraso de replicação em segundos, ou seja, o quão longe a região secundária está do primário. Essa métrica é a métrica recomendada para monitorar o RPO (objetivo de ponto de recuperação) e para configurar alertas. Quando o retardo atinge o máximo configurado, o primário limita solicitações de entrada.
  • ReplicationLagCount – o número de operações de replicação pendentes em que a região secundária está atrasada em relação à região primária. Use-o como um indicador relativo da lista de dependências da replicação: um aumento sustentado significa que a secundária está falhando. Esse valor reflete operações internas de log de replicação, não uma contagem de mensagens não duplicadas.

Exibir o atraso de replicação no portal do Azure

Para monitorar o atraso de replicação no portal do Azure:

  1. Vá para o namespace Barramento de Serviço no portal do Azure.
  2. Selecione Métricas na seção Monitoramento .
  3. Selecione a métrica ReplicationLagDuration na lista suspensa.
  4. O gráfico exibe o atraso de replicação entre regiões primárias e secundárias em segundos.

Você também pode configurar alertas nessa métrica para serem notificados quando o atraso exceder um limite.

Exibir o atraso de replicação no Log Analytics

Para usar o Log Analytics para consulta e análise histórica:

  1. Ative os logs de métricas no namespace do Barramento de Serviço, conforme descrito em Monitor Barramento de Serviço do Azure.
  2. Depois de habilitar os logs de métricas, você precisará produzir e consumir dados do namespace por alguns minutos antes de começar a consultar os logs.
  3. Para exibir logs de métricas, vá até a seção Monitoramento do Barramento de Serviço e selecione o painel 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"

Considerações

Tenha as seguintes considerações em mente ao usar este recurso:

  • Em seu planejamento de promoção, considere o fator de tempo. Por exemplo, se você perder a conectividade por mais de 15 a 20 minutos, você poderá decidir iniciar a promoção.
  • Você deve ensaiar a promoção de uma infraestrutura distribuída complexa 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 Geo-Replicação, cada réplica é executada no mesmo número de MUs configurado no servidor primário, e você é cobrado pelo total de MUs em todas as réplicas. Além disso, há uma cobrança com base nos dados replicados para as réplicas secundárias. A taxa de transferência de dados é determinada pela zona em que a região primária está localizada no momento da replicação. Para obter detalhes de preços atuais, incluindo taxas de transferência de dados, consulte a página de preços do Barramento de Serviço.

Você pode calcular o custo total da seguinte maneira:
(número de réplicas x MUs configurados no servidor primário x horas x taxa horária por MU) + (GBs replicados x taxa de transferência de dados por GB)

Por exemplo, se você tiver 2 MUs configuradas no namespace primário com 10 GB de dados replicados:
(2 réplicas x 2 MUs x horas x taxa horária) + (10 GB x taxa de transferência de dados)

Embora você possa disparar uma promoção a qualquer momento, aqui estão alguns cenários recomendados em que a promoção de um secundário para primário é aconselhável. Para obter mais detalhes sobre cada cenário, consulte Cenários.

  • Interrupção regional: se houver uma interrupção regional que afete a região primária, promova a região secundária para garantir a continuidade dos negócios e minimizar o tempo de inatividade.
  • Degradação de desempenho: se a região primária estiver enfrentando problemas de desempenho que afetam a disponibilidade ou a confiabilidade do namespace, promover a região secundária poderá ajudar a atenuar esses problemas.
  • Manutenção planejada: durante as atividades de manutenção agendadas na região primária, promover a região secundária ajuda a manter a alta disponibilidade.
  • Teste de recuperação de desastre: teste periodicamente seus mecanismos de failover para garantir que seu plano de continuidade de negócios seja eficaz e seus aplicativos possam alternar perfeitamente para a região secundária quando necessário.

Migração

Para migrar do Geo-Disaster Recovery para a Replicação Geográfica, primeiro interrompa o emparelhamento no namespace primário.

Captura de tela mostrando para clicar no botão Interromper emparelhamento na visão geral da Recuperação de Desastre Geográfica (Geo-DR).

Depois de interromper o emparelhamento, siga a configuração para habilitar a Replicação Geográfica.

Pontos de extremidade privados

Clientes que se conectam a um namespace Barramento de Serviço por meio de um endpoint privado conectam-se automaticamente à nova região primária após o failover. O namespace Barramento de Serviço direciona o tráfego para a região primária atual internamente, então os clientes não precisam saber qual região é primária e o endpoint privado continua funcionando sem nenhuma alteração. A promoção normalmente é concluída em menos de dois minutos, durante os quais os clientes podem perceber erros transitórios e se reconectar. Configure a política de repetição de acordo.

Endpoints privados são recursos regionais. Para alta disponibilidade, implante sua aplicação em múltiplas regiões e crie um endpoint privado na rede virtual de cada região.

Diagrama mostrando duas redes virtuais, cada uma com um endpoint privado para o mesmo namespace do Barramento de Serviço, e uma aplicação que abrange ambos.

DNS

Use uma privatelink.servicebus.windows.net zona DNS privada por região, vinculada apenas à rede virtual dessa região. O registro A para o endpoint privado local é adicionado automaticamente quando você anexa um grupo privado de zonas DNS. Cada região resolve o nome do namespace para seu ponto final local, independentemente de qual região seja a principal.

Se você compartilha uma única zona DNS privada entre ambas as redes virtuais, existe apenas um registro A e ele aponta para o endpoint que foi conectado por último. Nesse caso, adicione peering de rede virtual entre regiões para que todos os clientes possam acessar esse endpoint.

Para clientes locais, resolva o namespace para o ponto de extremidade privado da região mais próxima por meio de encaminhamento condicional ou um registro mantido manualmente. A promoção não exige uma mudança de DNS local.

Cenários de failover

  • Failover somente de aplicativo. A aplicação se move para a outra rede virtual. Ele alcança o namespace pelo endpoint privado local.
  • Failover somente de namespace. O papel principal do Barramento de Serviço muda. Os clientes mantêm a mesma cadeia de conexão e endpoint local; o tráfego é roteado automaticamente para o novo primário.
  • Interrupção regional. O ponto final privado na região afetada é inacessível. Clientes com um ponto de extremidade privado em uma região íntegra continuam na região sobrevivente.

Próximas etapas

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

  • Last updated on