Confiabilidade no Azure Service Bus

O Azure Service Bus é um serviço de broker de mensagens empresarial totalmente gerenciado que fornece funcionalidades confiáveis de mensagens assíncronas para desacoplar aplicativos e serviços. O Barramento de Serviço oferece suporte a filas para comunicação ponto a ponto e tópicos com assinaturas para padrões de mensagens de publicação-assinatura. O serviço oferece recursos de confiabilidade integrados, incluindo durabilidade de mensagens, garantias de entrega pelo menos uma vez e filas de mensagens não entregues para lidar com o processamento de mensagens com falha.

Quando você usa o Azure, a confiabilidade é uma responsabilidade compartilhada. A Microsoft fornece uma variedade de recursos para dar suporte à resiliência e recuperação. Você é responsável por entender como esses recursos funcionam em todos os serviços que você usa e selecionar os recursos necessários para atender aos seus objetivos de negócios e metas de tempo de atividade.

Este artigo descreve como tornar o Service Bus resiliente a uma variedade de possíveis interrupções e problemas, incluindo falhas transitórias, interrupções de zona de disponibilidade e interrupções de região. Ele também destaca algumas informações importantes sobre o contrato de nível de serviço (SLA) do Service Bus.

Recomendações de implantação de produção

O Azure Well-Architected Framework fornece recomendações sobre confiabilidade, desempenho, segurança, custo e operações. Para entender como essas áreas influenciam umas às outras e contribuem para uma solução confiável do Serviço de Aplicativo, consulte as práticas recomendadas de arquitetura para o Barramento de Serviço do Azure no Azure Well-Architected Framework.

Visão geral da arquitetura de confiabilidade

Esta seção descreve alguns dos aspectos importantes de como o serviço funciona que são mais relevantes do ponto de vista da confiabilidade. A seção apresenta a arquitetura lógica, que inclui alguns dos recursos e recursos que você implanta e usa. Também discute a arquitetura física, que fornece detalhes sobre como o serviço funciona nos bastidores.

Arquitetura lógica

Um namespace serve como contêiner de gerenciamento para o Barramento de Serviço e pode ser configurado para usar o nível Básico, Padrão ou Premium. Configure o serviço no nível do namespace alocando capacidade, configurando a segurança de rede e habilitando Geo-Replication e Geo-Disaster Recovery.

Em um namespace, você implanta filas e tópicos, que são entidades de mensagens com semânticas distintas. Para obter mais informações, consulte filas do Barramento de Serviço, tópicos e assinaturas.

Você pode configurar opcionalmente partições no seu namespace, que distribui filas e tópicos por vários agentes de mensagens e armazenamentos de mensagens. Um namespace pode usar várias partições para executar o processamento paralelo e o dimensionamento horizontal. O Service Bus só garante a ordenação dentro de uma única partição. O particionamento desempenha um papel fundamental no design de confiabilidade do aplicativo. Ao projetar seu aplicativo, faça uma compensação entre maximizar a disponibilidade e a consistência. Para a camada Premium, você habilita o particionamento no namespace. Para namespaces de camada Básico e Standard, você configura partições na entidade e opcionalmente ao enviar mensagens.

Você pode usar o Barramento de Serviço e suas abordagens de design assíncrono para aumentar a disponibilidade de seus aplicativos. Para obter mais informações, consulte padrões de mensagens assíncronas e alta disponibilidade.

Arquitetura física

O barramento de serviço fornece recursos subjacentes de computação e armazenamento. Para cada namespace, vários agentes de mensagens processam as mensagens e vários repositórios de mensagens armazenam as mensagens. Há três cópias do repositório de mensagens: uma primária e duas secundárias. O Barramento de Serviço mantém todas as três cópias em sincronia para operações de gerenciamento e dados. Se a cópia primária falhar, uma das cópias secundárias será promovida para primária sem nenhum tempo de inatividade percebido.

Para namespaces que utilizam o nível Básico ou Padrão, o Barramento de Serviço oferece redundância por meio de uma infraestrutura multitenant compartilhada que replica automaticamente as mensagens entre as zonas de disponibilidade, quando disponíveis. O serviço mantém vários repositórios de mensagens e mantém todas as cópias sincronizadas para operações de gerenciamento e dados.

Para namespaces de camada Premium, o Barramento de Serviço fornece unidades de mensagens dedicadas, cada uma com recursos dedicados de CPU e memória. Os namespaces de camada Premium podem ser dimensionados automaticamente com base nas demandas de carga de trabalho. Para obter mais informações, consulte Atualizar automaticamente as unidades de mensagens de um namespace do Barramento de Serviço do Azure.

A infraestrutura do Barramento de Serviço abrange várias máquinas físicas e racks distribuídos por domínios de falha, o que reduz o risco de falhas catastróficas que afetam seu namespace. Em regiões que têm zonas de disponibilidade, a infraestrutura se estende entre datacenters físicos separados. O serviço implementa mecanismos transparentes de detecção de falhas e failover, de modo que ele continua a operar dentro dos níveis de serviço garantidos e, normalmente, sem interrupções perceptíveis quando essas falhas ocorrem.

Resiliência a falhas transitórias

Falhas transitórias são falhas curtas e intermitentes nos componentes. Elas ocorrem com frequência em um ambiente distribuído, como a nuvem, e são uma parte normal das operações. Falhas transitórias se corrigem após um curto período de tempo. É importante que seus aplicativos possam lidar com falhas transitórias, geralmente repetindo solicitações afetadas.

Todos os aplicativos hospedados na nuvem devem seguir as diretrizes transitórias de tratamento de falhas do Azure quando eles se comunicam com qualquer APIs, bancos de dados e outros componentes hospedados na nuvem. Para obter mais informações, confira Recomendações para tratamento de falhas transitórias.

O SDK do Barramento de Serviço do Azure inclui lógica de repetição automática com retirada exponencial para operações que falham devido a condições transitórias, como tempos limite de rede ou indisponibilidade temporária do serviço. Quando os aplicativos sofrem desconexões transitórias do Barramento de Serviço, o SDK tenta automaticamente se reconectar usando a política de repetição configurada.

Para otimizar o tratamento de falhas transitórias em seus aplicativos, use o SDK mais recente do Service Bus, que inclui a lógica de repetição mais atual e os recursos de gerenciamento de conexão. Para obter mais informações, consulte a biblioteca de cliente do Azure Service Bus para .NET.

Resiliência a falhas de zona de disponibilidade

As zonas de disponibilidade são grupos fisicamente separados de datacenters em uma região do Azure. Quando uma zona falha, os serviços podem fazer o failover de uma das zonas restantes.

O Barramento de Serviço oferece suporte a implantações com redundância de zona em todas as camadas de serviço. Quando você cria um namespace do Barramento de Serviço em uma região com suporte, a redundância de zona é habilitada automaticamente sem custo adicional. O modelo de implantação com redundância de zona se aplica a todos os recursos do Barramento de Serviço, incluindo particionamento e sessões.

Service Bus replica de forma transparente sua configuração, metadados e dados de mensagem por meio de várias zonas de disponibilidade na região. A redundância de zona fornece failover automático sem nenhuma intervenção necessária por parte do usuário. Todos os componentes do Barramento de Serviço, incluindo computação, rede e armazenamento, são replicados entre zonas. O Service Bus tem reservas de capacidade suficientes para lidar instantaneamente com a perda completa de uma zona. Mesmo que uma zona de disponibilidade inteira fique indisponível, o Service Bus continuará operando sem perda de dados ou interrupção nos aplicativos de mensagens.

Requirements

• Suporte à região: Namespaces do Barramento de Serviço com redundância de zona podem ser implantados em regiões do Azure com suporte para zonas de disponibilidade. O Service Bus habilita automaticamente o suporte à zona de disponibilidade quando você cria um namespace em uma região compatível, sem necessidade de configuração adicional.

• Camadas: todas as camadas do Barramento de Serviço (Básico, Padrão e Premium) suportam zonas de disponibilidade sem requisitos adicionais.

Considerações

Os namespaces do Service Bus incluem a zoneRedundant propriedade. Anteriormente, essa propriedade era necessária para habilitar zonas de disponibilidade, mas esse comportamento foi alterado e a zoneRedundant propriedade está sendo preterida. Essa propriedade ainda pode ser mostrada como false mesmo quando a redundância de zona está habilitada. Todos os namespaces em regiões com zonas de disponibilidade possuem redundância de zona.

Custo

A redundância de zona no Barramento de Serviço não adiciona custo extra.

Configurar o suporte à zona de disponibilidade

Os namespaces do Service Bus oferecem suporte automaticamente à redundância de zona quando implantados em regiões com suporte. Nenhuma configuração adicional é necessária.

Comportamento quando todas as zonas estão saudáveis

Esta seção descreve o que esperar quando os namespaces do Barramento de Serviço são configurados para redundância de zona e todas as zonas de disponibilidade estão operacionais.

• Roteamento de tráfego entre zonas. O Barramento de Serviço usa um modelo ativo-ativo, no qual as mensagens são distribuídas por várias zonas de disponibilidade. As conexões de cliente são automaticamente balanceadas por carga entre zonas e o serviço roteia as operações para a infraestrutura de mensagens disponível, independentemente da zona.

• Replicação de dados entre zonas. O Barramento de Serviço usa replicação síncrona entre zonas de disponibilidade, incluindo metadados e dados de mensagens. Várias cópias do repositório de mensagens devem reconhecer as operações de gravação antes de serem consideradas concluídas, garantindo a consistência de dados entre zonas durante operações normais.

Comportamento durante uma falha de zona

Esta seção descreve o que se deve esperar quando os namespaces do Service Bus são configurados para redundância de zona e ocorre uma interrupção em uma zona de disponibilidade.

• Detecção e resposta: a Microsoft detecta automaticamente falhas de zona e inicia o failover para zonas íntegras. Nenhuma ação do cliente é necessária para o failover no nível de zona.

• Notificação: a Microsoft não notifica você automaticamente quando uma zona está inativa. No entanto, você pode usar a Integridade do Serviço do Azure para entender a integridade geral do serviço, incluindo quaisquer falhas de zona, e pode configurar alertas de Integridade do Serviço para notificá-lo de problemas.

• Solicitações ativas: Durante uma falha de zona, o Service Bus pode descartar solicitações ativas. Se seus clientes lidarem adequadamente com falhas transitórias tentando novamente após um curto período de tempo, eles normalmente evitam um impacto significativo.

• Perda de dados esperada: nenhuma perda de dados ocorre durante uma falha de zona porque o Barramento de Serviço replica sincronicamente mensagens entre zonas antes do reconhecimento.

• Tempo de inatividade esperado: uma falha na zona pode causar alguns segundos de tempo de inatividade. Se seus clientes lidarem adequadamente com falhas transitórias tentando novamente após um curto período de tempo, eles normalmente evitam um impacto significativo.

• Redirecionamento de tráfego: barramento de Serviço detecta a perda da zona e redireciona automaticamente novas solicitações para outra réplica em uma das zonas de disponibilidade saudáveis.

  O SDK do Service Bus normalmente manipula o gerenciamento de conexões e a lógica de repetição de maneira transparente.

Recuperação de zona

Quando uma zona de disponibilidade é recuperada, o Barramento de Serviço reintegra automaticamente a zona na topologia de serviço ativa. A zona recuperada começa a aceitar novas conexões e processar mensagens junto com as outras zonas. Os dados que foram replicados para zonas sobreviventes durante a interrupção permanecem intactos e a replicação síncrona normal é retomada em todas as zonas. Você não precisa tomar medidas para recuperação e reintegração de zona.

Testar falhas em zonas

O Barramento de Serviço gerencia o roteamento de tráfego, o failover e a recuperação de zonas em caso de falhas, para que você não precise validar os processos de falha da zona de disponibilidade nem fornecer mais informações.

Resiliência a falhas em toda a região

Service Bus fornece dois tipos de suporte multi-região, ambos exigem namespaces de camada Premium.

• A Replicação Geográfica fornece replicação ativa-passiva de dados de metadados e mensagens entre uma região primária e uma região secundária. Use Geo-Replication para a maioria dos aplicativos que precisam permanecer resilientes a interrupções regionais e apresentam baixa tolerância a perdas de dados de mensagens.

• Metadata Geo-Disaster Recovery fornece replicação ativa-passiva de configuração e metadados entre uma região primária e secundária, mas não replica dados das mensagens. Considere usar Geo-Disaster Recovery para aplicativos que lidam com sua própria replicação de dados ou que não precisam de replicação de dados.

Tanto a replicação geográfica quanto a recuperação de desastre geográfico de metadados exigem que você inicie manualmente o failover ou a promoção de uma região secundária para se tornar a nova região primária. A Microsoft não realiza failover ou promoção automaticamente, mesmo que a região primária esteja inoperante.

Os namespaces nas camadas Básico e Standard não incluem recursos nativos de várias regiões, mas você pode implementar padrões de replicação no nível do aplicativo usando vários namespaces entre regiões. Para obter mais informações, consulte a seção Soluções personalizadas de várias regiões para resiliência abaixo.

Geo-Replication

A camada Premium dá suporte à Replicação Geográfica. Esse recurso replica metadados (como entidades, configuração e propriedades) e dados (como mensagens em suas filas e tópicos e propriedades e estado da mensagem) para o namespace. Você configura a abordagem de replicação para a configuração e os dados do namespace. Esse recurso garante que suas mensagens permaneçam disponíveis em outra região e permite que você alterne para a região secundária quando necessário.

Use Geo-Replication para cenários que exigem resiliência a interrupções de região e têm uma tolerância baixa para perda de dados de mensagens.

O namespace se estende essencialmente entre regiões. Uma região serve como primária e as outras regiões servem como secundárias. Sua assinatura do Azure mostra um único namespace.

A qualquer momento, você pode promover a região secundária para uma região primária. Quando você promove a região secundária, o Barramento de Serviço redireciona o nome de domínio totalmente qualificado (FQDN) do namespace para a região secundária selecionada e rebaixa a região primária anterior para uma região secundária. Você decide se deseja executar uma promoção planejada, o que significa que você aguarda a conclusão da replicação de dados ou uma promoção forçada, o que pode resultar em perda de dados.

Esta seção resume aspectos importantes da Replicação Geográfica. Examine a documentação completa para entender exatamente como ela funciona. Para obter mais informações, consulte Replicação Geográfica do Service Bus.

Requirements

• Suporte à região: você pode escolher qualquer região do Azure que suporte Barramento de Serviço como sua região primária ou região secundária. Você não precisa usar regiões emparelhadas do Azure, portanto, pode escolher regiões secundárias com base em seus requisitos de latência, conformidade ou residência de dados.

• Camada: Para habilitar a Replicação Geográfica, seu namespace deve usar a camada Premium.

• Metadata Geo-Disaster Recovery: Não é possível configurar um namespace para usar Geo-Replication e Geo-Disaster Recovery.

Considerações

• Limitações de recursos: Quando você habilita a Replicação Geográfica, há algumas restrições. Para obter mais informações, consulte Replicação Geográfica do Service Bus.

• Pontos de extremidade privados: Se você usar pontos de extremidade privados para se conectar ao namespace, também precisará configurar a rede em suas regiões primárias e secundárias. Para obter mais informações, consulte Pontos de extremidade privados na documentação dos Hubs de Eventos do Azure.

Custo

Para entender como os preços funcionam para a Replicação Geográfica, consulte Preços.

Configurar o suporte a várias regiões

• Habilite Geo-Replication em um novo namespace. Para habilitar a Replicação Geográfica em um namespace durante a criação, consulte Alternar modo de replicação.

• Migrar de Recuperação de desastre geográfico para Replicação geográfica.Você pode alternar do uso de Recuperação de desastre geográfico de metadados para Replicação geográfica..

• Altere a abordagem de replicação. Para alterar entre os modos de replicação síncrona e assíncrona, consulte Alternar modo de replicação.

• Desabilite a Replicação Geográfica. Para desabilitar Geo-Replication a uma região secundária, consulte Excluir região secundária.

Comportamento quando todas as regiões estão saudáveis

Esta seção descreve o que esperar quando um namespace do Service Bus é configurado para Replicação Geográfica e a região primária está operacional.

• Roteamento de tráfego entre regiões: Os aplicativos cliente se conectam por meio do FQDN para seu namespace e suas rotas de tráfego para a região primária.

  Somente a região primária processa ativamente mensagens de clientes durante operações normais. A região secundária recebe mensagens replicadas, mas, caso contrário, permanece passiva no modo de espera.

• Replicação de dados entre regiões: O comportamento de replicação de dados entre a região primária e secundária depende de você configurar o emparelhamento de replicação para usar a replicação síncrona ou assíncrona.

  • Síncrono: As mensagens são replicadas para a região secundária antes da conclusão da operação de gravação.

    Esse modo fornece a maior garantia de que seus dados de mensagem são seguros porque devem ser confirmados na região primária e secundária. No entanto, a replicação síncrona aumenta substancialmente a latência de gravação para mensagens de entrada. Também requer que a região secundária esteja disponível para aceitar a operação de gravação, portanto, uma interrupção na região secundária faz com que a operação de gravação falhe.

    • Assíncrono: As mensagens são gravadas na região primária e, em seguida, a operação de gravação é concluída. Pouco tempo depois, ele replica as mensagens para a região secundária.

    Esse modo fornece uma taxa de transferência de gravação maior do que a replicação síncrona porque não há latência de replicação entre regiões durante operações de gravação. Além disso, o modo de replicação assíncrona pode tolerar a perda da região secundária enquanto ainda permite operações de gravação na região primária. No entanto, se a região primária tiver uma interrupção, todos os dados que ainda não foram replicados para a região secundária poderão estar indisponíveis ou perdidos.

    Ao configurar a replicação assíncrona, você configura o tempo máximo de retardo aceitável para a replicação. A qualquer momento, você pode verificar o atraso de replicação atual usando as métricas do Azure Monitor.

    Se o atraso de replicação assíncrona aumentar além do máximo que você especificar, a região primária começará a limitar as solicitações de entrada para que a replicação possa ser atualizada. Para evitar essa situação, é importante selecionar regiões secundárias que não estejam muito distantes geograficamente e garantir que a sua capacidade seja suficiente para a taxa de transferência.

    Alguns tipos de metadados são replicados de forma síncrona, mesmo se você selecionar o modo de replicação assíncrono.

    Para obter mais informações, consulte os modos de replicação.

Comportamento durante uma interrupção de região

Esta seção descreve o que esperar quando um namespace do Barramento de Serviço é configurado para replicação geográfica e há uma interrupção na região primária ou secundária.

• Detecção e resposta: Você é responsável por decidir quando promover a região secundária do namespace para se tornar a nova região primária. A Microsoft não toma essa decisão nem inicia o processo para você, mesmo que haja uma interrupção na região. Para ver critérios sugeridos a serem considerados ao decidir realizar failover, consulte Cenários recomendados para disparar a promoção.

  Para obter mais informações sobre como promover uma região secundária para o novo primário, consulte o fluxo de Promoção.

  Ao promover uma região secundária, escolha se deseja realizar uma promoção planejada ou uma promoção forçada. Uma promoção planejada aguarda que a região secundária se atualize antes de aceitar o novo tráfego. Essa abordagem elimina a perda de dados, mas introduz o tempo de inatividade.

  Interrupções na região primária normalmente tornam necessário realizar uma promoção forçada. Se a região primária estiver disponível e você iniciar uma promoção por uma razão diferente, poderá optar por uma promoção planejada.

• Notificação: a Microsoft não notifica você automaticamente quando uma região está inoperante. No entanto, você pode usar a Integridade do Serviço do Azure para entender a integridade geral do serviço, incluindo quaisquer falhas na região, e pode configurar alertas de Integridade do Serviço para notificá-lo de problemas.

• Solicitações ativas: O comportamento depende se a interrupção da região ocorre na região primária ou na região secundária:

  • Interrupção da região primária: Se a região primária não estiver disponível, todas as solicitações ativas serão encerradas. Os aplicativos cliente devem repetir as operações após a conclusão da promoção.

  • Interrupção de região secundária: Uma interrupção na região secundária pode causar problemas para solicitações ativas nas seguintes situações:

    • Se você usar o modo de replicação síncrona, a região primária não poderá concluir as operações de gravação se qualquer região secundária não estiver disponível.

    • Se você usar o modo de replicação assíncrono, o namespace limitará e não aceitará novas mensagens depois que o atraso de replicação atingir o máximo configurado.

    Para continuar usando o namespace na região primária, remova o namespace secundário da configuração de Geo-Replication.

• Perda de dados esperada: A quantidade de perda de dados depende do tipo de promoção que você executa (planejada ou forçada) e do modo de replicação (síncrono ou assíncrono):

  • Promoção planejada: Nenhuma perda de dados é esperada. No entanto, durante uma interrupção de região, uma promoção planejada pode não ser possível porque exige que todas as regiões primárias e secundárias estejam disponíveis.

  • Promoção forçada, replicação síncrona: Nenhuma perda de dados é esperada.

  • Promoção forçada, replicação assíncrona: Você pode ter alguma perda de dados para mensagens recentes que não são replicadas para a região secundária e para alterações de estado que ainda não foram replicadas. O valor depende do atraso de replicação. Para verificar o atraso de replicação atual, use as métricas do Azure Monitor.

  Se você executar uma promoção forçada, não poderá recuperar os dados perdidos, mesmo depois que a região primária estiver disponível.

• Tempo de inatividade esperado: A quantidade de tempo de inatividade esperada depende de você executar uma promoção planejada ou forçada:

  • Promoção planejada: A primeira etapa em uma promoção planejada replica dados para a região secundária. Esse processo geralmente é concluído rapidamente, mas em algumas situações, pode levar até o comprimento do atraso de replicação. Após a conclusão da replicação, o processo de promoção normalmente leva cerca de 5 a 10 minutos. Às vezes, pode levar mais tempo para os servidores DNS (Sistema de Nomes de Domínio) atualizarem as entradas e replicarem totalmente seus registros para os clientes.

    A região primária não aceita operações de gravação durante todo o processo de promoção.

    Essa opção pode não ser possível durante uma interrupção de região porque exige que todas as regiões primárias e secundárias estejam disponíveis.

  • Promoção forçada: Durante uma promoção forçada, o Service Bus não espera a conclusão da replicação de dados e inicia a promoção imediatamente. O processo de promoção normalmente leva cerca de 5 a 10 minutos. Às vezes, pode levar mais tempo para que as entradas DNS sejam totalmente replicadas e atualizadas entre clientes.

    A região primária não aceita operações de gravação durante todo o processo de promoção.

• Redirecionamento de tráfego: Após a conclusão da promoção, o FQDN do namespace aponta para a nova região primária. Mas esse redirecionamento depende da rapidez com que os registros DNS dos clientes são atualizados, inclusive para que seus servidores DNS honrem o TTL (tempo de vida útil) dos registros DNS do namespace.

Recuperação de região

Depois que a região primária original for recuperada, se você quiser retornar o namespace para sua região primária original, siga o mesmo processo de promoção de região.

Se você realizou uma promoção forçada durante a interrupção da região, não poderá recuperar dados perdidos, mesmo após a região primária ficar disponível.

Teste de falhas na região

Para testar a Replicação Geográfica, promova temporariamente a região secundária para primária e valide se os aplicativos cliente podem alternar entre regiões com interrupção mínima.

Monitore a duração da promoção e valide se os seus runbooks e automação funcionam corretamente. Após o teste, você pode fazer failback para a configuração original.

Entenda o tempo de inatividade potencial e a perda de dados que você pode experimentar durante e após o processo de promoção. Teste a Geo-Replicação em um ambiente não-produtivo que reflita a configuração do seu namespace de produção.

Recuperação de Desastre Geográfico de Metadados

A camada Premium dá suporte a metadados Geo-Disaster Recovery. Esse recurso melhora a recuperação de cenários de desastre, incluindo a perda catastrófica de uma região. Geo-Disaster Recovery replica apenas a configuração e os metadados do namespace. No entanto, ele não replica os dados da mensagem. Para dar suporte à recuperação de desastre, esse recurso garante que um namespace em outra região esteja pré-configurado e pronto para aceitar imediatamente as mensagens dos clientes. A Recuperação de Desastre Geográfico serve como uma solução de recuperação unidirecional e não dá suporte ao retorno para a região primária anterior.

Os metadados Geo-Disaster Recovery funcionam melhor para aplicativos que não precisam estritamente manter todas as mensagens e podem tolerar alguma perda de dados durante um cenário de desastre. A recuperação de desastre geográfico de metadados também pode ser adequada para aplicativos que replicam os próprios dados ou que não precisam de replicação de dados. Por exemplo, se suas mensagens representarem imagens grandes convertidas posteriormente em miniaturas, você poderá decidir que pode perder algumas mensagens de uma região com falha se puder retomar rapidamente o processamento de novas mensagens em outra região e poderá reconstruir as mensagens mais tarde para atualizar.

Ao configurar metadados Geo-Disaster Recovery, você cria um alias ao qual os aplicativos cliente se conectam. O alias é um FQDN que direciona todo o tráfego para o namespace primário por padrão.

Se a região primária falhar ou houver outro tipo de desastre, você poderá iniciar manualmente uma movimentação de failover unidirecional de tempo único da região primária para a secundária a qualquer momento. Você pode optar por executar um failover seguro, que aguarda a conclusão das réplicas antes de mudar para o secundário, embora essa opção possa não estar disponível durante uma interrupção na região. Quando um failover é iniciado, ele é concluído quase instantaneamente. Durante o processo de failover, o alias de Recuperação de Desastre Geográfico é redirecionado para o namespace secundário e o pareamento é desfeito.

Esta seção resume aspectos importantes do Geo-Disaster Recovery. Examine a documentação completa para entender exatamente como ela funciona. Para mais informações consulte Recuperação de Desastre Geográfico do Barramento de Serviço.

Requirements

• Suporte à região: Você pode selecionar qualquer região do Azure que ofereça suporte ao Service Bus como sendo seu namespace primário ou secundário. Você não precisa usar regiões emparelhadas do Azure, portanto, pode escolher regiões secundárias com base em seus requisitos de latência, conformidade ou residência de dados.

• Camada: Para habilitar metadados Geo-Disaster Recovery, ambos os namespaces devem usar a camada Premium.

• Particionamento: Não é possível emparelhar um namespace particionado com um namespace não particionado.

• Metadata Geo-Disaster Recovery: Não é possível configurar um namespace para usar Geo-Replication e Geo-Disaster Recovery.

Considerações

• Limitações de recursos: Quando você habilita Geo-Disaster Recuperação, há algumas restrições. Para obter mais informações, consulte Pontos importantes a serem considerados e considerações.

• Atribuições de função: As atribuições de RBAC (controle de acesso baseado em função) do Microsoft Entra para entidades no namespace primário não são replicadas para o namespace secundário. Crie atribuições de função manualmente no namespace secundário para proteger o acesso a elas.

• Design do aplicativo: Geo-Disaster Recovery requer considerações específicas ao projetar seus aplicativos cliente. Para obter mais informações, confira as Considerações.

• Pontos de extremidade privados: Se você usar pontos de extremidade privados para se conectar ao namespace, configure a rede na região primária e secundária. Para obter mais informações, confira Pontos de extremidade privados.

• Namespaces migrados do padrão para o premium: Se o namespace estava anteriormente na camada Standard e você o migrou para a camada Premium, será necessário manipular o alias de forma diferente. Para obter mais informações, consulte Barramento de Serviço Standard para Premium.

Custo

Ao habilitar metadados Geo-Disaster Recovery, você paga pelos namespaces primário e secundário.

Configurar o suporte a várias regiões

• Crie metadados para pareamento de Recuperação de Desastre Geográfico. Para configurar a recuperação de desastre entre namespaces primários e secundários, consulte Fluxo de instalação e failover.

• Desabilite a Recuperação de Desastre Geográfico de metadados. Para interromper o emparelhamento entre namespaces, consulte Configuração e processo de failover.

Planejamento e gerenciamento de capacidade

Quando você planeja implantações de várias regiões, verifique se ambas as regiões têm capacidade suficiente para lidar com a carga completa se uma região falhar. A região secundária permanece passiva durante as operações normais, mas deve lidar imediatamente com o tráfego após o failover. Planeje como dimensionar a capacidade do namespace secundário para que ele possa receber tráfego de produção sem demora. Se você puder tolerar tempo de inatividade extra durante o processo de failover, poderá optar por dimensionar a capacidade do namespace secundário durante ou após o failover. Para reduzir o tempo de inatividade, provisione a capacidade no namespace secundário com antecedência para que ele permaneça pronto para receber a carga de produção.

Comportamento quando todas as regiões estão saudáveis

Esta seção descreve o que esperar quando um namespace do Barramento de Serviço é configurado para Recuperação de Desastre Geográfico e a região principal está operacional.

• Roteamento de tráfego entre regiões: Os aplicativos cliente se conectam por meio do alias de recuperação de desastres geográficos para seu namespace, e o tráfego deles é direcionado para o namespace primário na região primária.

  Somente o namespace primário processa ativamente mensagens de clientes durante operações normais. O namespace secundário permanece passivo no modo de espera e todas as solicitações para acessar dados falham.

• Replicação de dados entre regiões: Somente os metadados de configuração são replicados entre os namespaces. A replicação da configuração ocorre de forma contínua e assíncrona.

  Todos os dados de mensagem permanecem apenas no namespace primário e não são replicados para o namespace secundário.

Comportamento durante uma interrupção de região

Esta seção descreve o que esperar quando um namespace do Barramento de Serviço é configurado para Recuperação de Desastre Geográfico e há uma interrupção na região primária.

• Detecção e resposta: você é responsável por monitorar a integridade da região e iniciar o failover manualmente. A Microsoft não executa failover nem promove uma região secundária automaticamente, mesmo que sua região primária esteja inoperante.

  Para obter mais informações sobre como iniciar o failover, consulte Failover flow.

  Ao iniciar um failover, escolha se deseja executar um failover seguro ou um failover padrão (forçado ou manual). Um failover seguro aguarda a conclusão da replicação na região secundária antes que o failover seja iniciado. Essa abordagem reduz a perda de metadados, mas introduz o tempo de inatividade. O failover seguro requer que os namespaces estejam na mesma assinatura do Azure.

  Durante uma interrupção na região principal, normalmente é necessário realizar um failover forçado. Se a região primária estiver disponível e você disparar um failover por outro motivo, você poderá escolher um failover planejado.

  O failover é uma operação unidirecional, então é necessário reestabelecer o pareamento de Recuperação de Desastre Geográfico posteriormente. Para obter mais informações, consulte Recuperação de Região.

• Notificação: a Microsoft não notifica você automaticamente quando uma região está inoperante. No entanto, você pode usar a Integridade do Serviço do Azure para entender a integridade geral do serviço, incluindo quaisquer falhas na região, e pode configurar alertas de Integridade do Serviço para notificá-lo de problemas.

• Solicitações ativas: As solicitações ativas em andamento terminam quando o failover é iniciado. Os aplicativos cliente devem repetir as operações após a conclusão do failover.

• Perda de dados esperada:

  • Metadados: Normalmente, a configuração e os metadados são replicados para o namespace secundário. Mas a replicação de metadados ocorre de forma assíncrona, portanto, alterações recentes podem não ser replicadas, especialmente alterações complexas. Verifique a configuração do namespace secundário antes que os clientes o acessem.

  • Dados da mensagem: Os dados da mensagem não são replicados entre regiões. Se a região primária falhar, as mensagens no namespace primário ficarão indisponíveis.

    As mensagens não são perdidas permanentemente, a menos que um desastre catastrófico cause perda total da região primária. Se a região for recuperada, você poderá recuperar mensagens do namespace primário mais tarde.

• Tempo de inatividade esperado: O failover normalmente ocorre dentro de 5 a 10 minutos. Pode levar mais tempo para os clientes replicarem e atualizarem totalmente as entradas DNS.

• Redirecionamento de tráfego: Clientes que usam o alias Geo-Disaster Recovery para se conectar ao namespace redirecionam automaticamente para o namespace secundário após o failover. Mas esse redirecionamento depende de servidores DNS que respeitam a TTL dos registros DNS do namespace e clientes que recebem esses registros DNS atualizados.

Recuperação de região

Depois que a região primária original for recuperada, você deverá restabelecer manualmente o emparelhamento e, opcionalmente, fazer failback. Crie um novo pareamento de Recuperação de Desastre Geográfico com a região recuperada como secundária e execute outro failover se desejar retornar à região original. Esse processo envolve a perda potencial de dados das mensagens enviadas para o primário temporário.

Se o desastre causar a perda de todas as zonas na região primária, seus dados poderão ser irrecuperáveis. Em outros cenários, os dados da mensagem permanecem no namespace primário antes do failover e são recuperáveis. Você pode obter mensagens históricas do namespace primário antigo depois de restaurar o acesso. Você é responsável por configurar seus aplicativos para receber e processar essas mensagens. A Microsoft não os restaura automaticamente em sua região secundária.

Teste de falhas na região

Para testar seus processos de resposta e recuperação de desastre, execute um failover planejado durante uma janela de manutenção. Inicie o failover do namespace primário para o namespace secundário e verifique se seus aplicativos podem se conectar e processar mensagens do novo namespace primário.

Monitore a duração do failover e valide se os runbooks e automação funcionam corretamente. Após o teste, você pode fazer failback para a configuração original.

Entenda o tempo de inatividade potencial e a perda de dados que você pode experimentar durante e após o processo de failover. Teste a Recuperação de Desastre Geográfico de metadados em um ambiente que não seja de produção e que reflita a configuração do seu namespace de produção.

Soluções personalizadas de várias regiões para resiliência

A Replicação Geográfica e a Recuperação de Desastre Geográfico de metadados fornecem resiliência a interrupções de região e outros problemas e são adequadas para a maioria das cargas de trabalho. No entanto, eles podem não atender às suas necessidades nas seguintes situações:

• Você tem requisitos para replicação personalizada ou para manter várias regiões ativas simultaneamente.
• Você está usando uma camada do Barramento de Serviço que não oferece suporte a esses recursos.

Existem vários padrões de design para obter diferentes tipos de suporte multirregional em Barramento de Serviço. Muitos dos padrões exigem a implantação de vários namespaces e a configuração do aplicativo para usar os namespaces adequadamente. Para saber mais, veja estes artigos:

• Usar vários namespaces para isolar aplicativos contra interrupções e desastres do Barramento de Serviço
• Replicação de mensagem e federação entre regiões.

Resiliência à manutenção do serviço

O Barramento de Serviço realiza manutenção regular. Durante a manutenção planejada, os namespaces são movidos para um nó redundante que contém as atualizações mais recentes. Conforme esse movimento acontece, o SDK de clientes se desconecta e se reconecta automaticamente no namespace. Normalmente, as atualizações ocorrem dentro de 30 segundos. É importante que seus aplicativos estejam preparados para quaisquer desconexões transitórias de rede que ocorram durante os períodos de manutenção.

Para obter mais informações, consulte Diretrizes sobre eventos de manutenção do Azure para o Barramento de Serviço do Azure.

Backup e restauração

O Service Bus não foi concebido como um local de armazenamento a longo prazo para seus dados. Normalmente, os dados são armazenados em um tópico ou fila por um curto período de tempo e, em seguida, são processados ou persistidos em outro sistema de armazenamento de dados, momento em que são excluídos. Devido a esse design, o Service Bus mantém automaticamente a replicação dos dados de mensagens, mas não fornece recursos de backup e restauração para esses dados.

Para cenários que exigem retenção de mensagens de longo prazo, considere implementar o arquivamento no nível do aplicativo no Armazenamento do Azure ou em outros serviços de armazenamento duráveis.

Contrato de nível de serviço

O acordo de nível de serviço (SLA) dos serviços do Azure descreve a disponibilidade esperada de cada serviço e as condições que sua solução deve atender para alcançar essa expectativa de disponibilidade. Para obter mais informações, consulte SLAs para serviços online.

O Barramento de Serviço fornece um SLA para todos os namespaces. O SLA de disponibilidade é maior quando o namespace atende a todos os seguintes critérios:

• Ele usa a camada premium.
• Ele está localizado em uma região com zonas de disponibilidade.
• Usa particionamento.

Conteúdo relacionado

• Documentação do Barramento de Serviço
• Recuperação de desastre geográfico do Barramento de Serviço do Azure
• Replicação geográfica do Barramento de Serviço do Azure