Partilhar via

Confiabilidade no Azure Service Bus

O Azure Service Bus é um serviço de corretora de mensagens empresariais totalmente gerido que fornece capacidades fiáveis de mensagens assíncronas para desacoplar aplicações e serviços. O Service Bus suporta filas para comunicação ponto a ponto e tópicos com assinaturas para padrões de mensagens pub/sub. O serviço oferece funcionalidades de fiabilidade incorporadas, incluindo durabilidade das mensagens, garantias de entrega pelo menos uma vez e filas de cartas mortas para lidar com falhas no processamento de mensagens.

Quando você usa o Azure, a confiabilidade é uma responsabilidade compartilhada. A Microsoft fornece uma variedade de recursos para oferecer 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 potenciais interrupções e problemas, incluindo falhas transitórias, interrupções em zonas de disponibilidade e interrupções regionais. Destaca também algumas informações-chave sobre o acordo de nível de serviço (SLA) dos Autocarros de Serviço.

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 compreender como estas áreas se influenciam mutuamente e contribuem para uma solução fiável de App Service, consulte as melhores práticas de arquitetura para Azure Service Bus no Azure Well-Architected Framework.

Visão geral da arquitetura de confiabilidade

Esta secção descreve alguns dos aspetos importantes do funcionamento do serviço que são mais relevantes do ponto de vista da fiabilidade. A secção apresenta a arquitetura lógica, que inclui alguns dos recursos e funcionalidades que implementa e utiliza. Também discute a arquitetura física, detalhando como o serviço funciona nos bastidores.

Arquitetura lógica

Um namespace serve como contentor de gestão para o Service Bus e pode ser configurado para usar a camada Basic, Standard ou Premium. Configura o serviço ao nível do namespace, alocando capacidade, configurando a segurança da rede e ativando Geo-Replication e Geo-Disaster Recovery.

Dentro de um namespace, implementas filas e tópicos, que são entidades de mensagens com semântica diferente. Para obter mais informações, consulte Filas, tópicos e assinaturas do Service Bus.

Pode, opcionalmente, configurar partições no seu namespace, que espalha filas e tópicos por vários brokers de mensagens e lojas de mensagens. Um namespace pode usar múltiplas partições para realizar processamento paralelo e escalabilidade horizontal. O Service Bus só garante a ordem dentro de uma única partição. O particionamento desempenha um papel fundamental no design de confiabilidade do seu aplicativo. Ao projetar seu aplicativo, faça um compromisso entre maximizar a disponibilidade e a consistência. Para o nível Premium, ativas a partição no namespace. Para namespaces de níveis Basic e Standard, configuras partições na entidade e , opcionalmente, quando envias mensagens.

Pode usar o Service Bus e as suas abordagens de design assíncrono para aumentar a disponibilidade das suas aplicações. Para mais informações, consulte Padrões de mensagens assíncronas e alta disponibilidade.

Arquitetura física

O Service Bus fornece os recursos de computação e armazenamento subjacentes. Para cada namespace, múltiplos brokers de mensagens processam as mensagens e vários repositórios de mensagens armazenam as mensagens. Existem três cópias da loja de mensagens: uma principal e duas secundárias. O Service Bus mantém as três cópias sincronizadas para dados e operações de gerenciamento. Se a cópia principal falhar, uma das cópias secundárias será promovida para principal sem tempo de inatividade percebido.

Para namespaces que utilizam o nível Basic ou Standard, o Service Bus fornece redundância através de uma infraestrutura multitenant partilhada que replica automaticamente mensagens entre zonas de disponibilidade quando disponíveis. O serviço mantém múltiplos armazenamentos de mensagens e mantém todas as cópias sincronizadas tanto para dados como para operações de gestão.

Para namespaces de nível Premium, o Service Bus fornece unidades de mensagens dedicadas, cada uma com recursos dedicados de CPU e memória. Os namespaces de níveis premium podem escalar automaticamente com base nas exigências de carga de trabalho. Para mais informações, veja Atualizar automaticamente as unidades de mensagens de um namespace Azure Service Bus.

A infraestrutura do Service Bus abrange várias máquinas e racks físicos espalhados por domínios de falha, o que reduz o risco de falhas catastróficas que afetem o seu namespace. Nas regiões que têm zonas de disponibilidade, a infraestrutura estende-se por centros de dados físicos separados. O serviço implementa mecanismos transparentes de deteção de falhas e failover, de modo que continue a operar dentro dos níveis de serviço assegurados e normalmente sem interrupções notórias quando tais falhas ocorrem.

Resiliência a falhas transitórias

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

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

O SDK do Azure Service Bus inclui lógica automática de retentativa com recuo exponencial para operações que falham devido a condições transitórias, como timeouts de rede ou indisponibilidade temporária de serviços. Quando as aplicações sofrem desconexões transitórias do Service Bus, o SDK tenta automaticamente reconectar usando a política de reintento configurada.

Para otimizar o tratamento de falhas transitórias nas suas aplicações, utilize o mais recente Service Bus SDK, que inclui as funcionalidades mais recentes de lógica de retentativas e gestão de ligações. Para mais informações, consulte a biblioteca cliente Azure Service Bus para .NET.

Resiliência a falhas na zona de disponibilidade

As zonas de disponibilidade são grupos fisicamente separados de centros de dados dentro de uma região Azure. Quando uma zona falha, os serviços podem ser transferidos para uma das zonas restantes.

O Barramento de Serviço suporta implementações redundantes por zonas em todos os níveis de serviço. Quando cria um namespace de Service Bus numa região suportada, a redundância de zona é automaticamente ativada sem custos adicionais. O modelo de implementação redundante por zonas aplica-se a todas as funcionalidades do Service Bus, incluindo particionamento e sessões.

O Service Bus replica de forma transparente a sua configuração, metadados e dados de mensagens em várias zonas de disponibilidade na região. A redundância de zona fornece failover automático sem necessitar de qualquer intervenção da sua parte. Todos os componentes do Service Bus, 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 total de uma zona. Mesmo que toda uma zona de disponibilidade fique indisponível, o Service Bus continua a operar sem perda de dados ou interrupção das aplicações de mensagens.

Diagrama que mostra um namespace de Barramento de Serviço redundante por zona.

Requerimentos

  • Apoio regional: Namespaces de Service Bus redundantes de zona podem ser implementados em regiões do Azure com suporte a zonas de disponibilidade. O Service Bus ativa automaticamente o suporte a zonas de disponibilidade quando cria um namespace numa região suportada, sem necessidade de configuração adicional.

  • Níveis: Todos os níveis do Service Bus (Básico, Standard e Premium) suportam zonas de disponibilidade sem requisitos adicionais.

Considerações

Os espaços de nomes do Service Bus incluem uma zoneRedundant propriedade. Anteriormente, esta propriedade era obrigatória para ativar zonas de disponibilidade, mas este comportamento mudou e a zoneRedundant propriedade está a ser obsoleta. Esta propriedade pode continuar a aparecer false mesmo quando a redundância de zona está ativada. Todos os namespaces em regiões com zonas de disponibilidade são redundantes por zona.

Custo

A redundância de zonas no Service Bus não acrescenta custo extra.

Configurar o suporte à zona de disponibilidade

Os namespaces do Service Bus suportam automaticamente redundância de zonas quando implementados em regiões suportadas. Não é necessário efetuar mais configurações.

Comportamento quando todas as zonas estão íntegras

Esta secção descreve o que esperar quando os namespaces do Service Bus são configurados para redundância de zonas e todas as zonas de disponibilidade estão operacionais.

  • Roteamento de tráfego entre zonas. O Service Bus utiliza um modelo ativo-ativo onde as mensagens são distribuídas por múltiplas zonas de disponibilidade. As ligações dos clientes são automaticamente balanceadas de carga entre zonas, e o serviço encaminha as operações para a infraestrutura de mensagens disponível independentemente da zona.

  • Replicação de dados entre zonas. O Service Bus utiliza replicação síncrona entre zonas de disponibilidade, incluindo para metadados e dados de mensagens. Múltiplas cópias do armazenamento de mensagens devem confirmar operações de escrita antes de serem consideradas concluídas, garantindo a consistência dos dados entre zonas durante as operações normais.

Comportamento durante uma falha de zona

Esta secção descreve o que esperar quando os namespaces do Service Bus são configurados para redundância de zona e há uma falha na zona de disponibilidade.

  • Deteção e resposta: A Microsoft deteta automaticamente falhas de zona e inicia failover para zonas saudáveis. Não é necessária qualquer ação por parte do cliente para o failover a nível de zona.

  • Pedidos ativos: Durante uma falha de zona, o "Service Bus" pode descartar os pedidos ativos. 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: Não ocorre perda de dados durante uma falha de zona porque o Service Bus replica de forma síncrona mensagens entre zonas antes do reconhecimento.

  • Tempo de inatividade esperado: uma falha de 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: O Service Bus deteta a perda da zona e redireciona automaticamente novos pedidos para outra réplica numa das zonas de disponibilidade saudáveis.

    O SDK do Service Bus normalmente gere a gestão de conexões e a lógica de reintento de maneira transparente.

Recuperação de zona

Quando uma zona de disponibilidade recupera, o Service Bus reintegra automaticamente a zona na topologia de serviço ativo. A zona recuperada começa a aceitar novas ligações e a processar mensagens juntamente 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.

Teste de falhas de zona

Service Bus gere o encaminhamento do tráfego, o failover e a recuperação de falhas de zona, por isso não precisa de validar os processos de falhas de zonas de disponibilidade nem de fornecer mais informações adicionais.

Resiliência a falhas em toda a região

O Service Bus oferece dois tipos de suporte multirregião, ambos exigindo namespaces de nível Premium.

  • A Geo-Replicação fornece replicação ativa-passiva tanto dos metadados como dos dados das mensagens entre uma região primária e uma região secundária. Use Geo-Replication para a maioria das aplicações que precisam de se manter resilientes a falhas regionais e têm baixa tolerância à perda de dados de mensagens.

  • O 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 os dados das mensagens. Considere usar Geo-Disaster Recovery para aplicações que gerem a sua própria replicação de dados, ou que não necessitem de replicação de dados.

Tanto a Geo-Replication como a recuperação de metadados Geo-Disaster exigem que inicie manualmente o failover ou promoção de uma região secundária para se tornar a nova região primária. A Microsoft não executa automaticamente failover ou promoção, mesmo que sua região principal esteja inativa.

Os namespaces nos níveis Basic e Standard não incluem funcionalidades nativas multi-regionais, mas podes implementar padrões de replicação ao nível da aplicação usando múltiplos namespaces entre regiões. Para mais informações, consulte a secção Soluções multi-região personalizadas para resiliência abaixo.

Geo-Replication

O nível Premium suporta a Geo-Replicação. Esta funcionalidade replica tanto metadados (como entidades, configuração e propriedades) como dados (como mensagens nas suas filas e tópicos, e propriedades e estado das mensagens) para o namespace. Configura a abordagem de replicação para a configuração e dados do seu namespace. Esta funcionalidade garante que as suas mensagens permanecem disponíveis noutra região e permite-lhe mudar para a região secundária quando necessário.

Use Geo-Replication para cenários que exigem resiliência a falhas regionais e que tenham baixa tolerância à perda de dados de mensagens.

O namespace se estende essencialmente entre regiões. Uma região serve como principal e as outras regiões como secundárias. A tua subscrição do Azure mostra um único namespace.

Diagrama que mostra um namespace de Service Bus configurado para Geo-Replicação.

A qualquer momento, pode promover a região secundária a região primária. Quando promove a região secundária, o Service Bus redireciona o nome de domínio totalmente qualificado (FQDN) do espaço de nomes 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, que pode resultar em perda de dados.

Observação

Service Bus Geo-Replication usa o termo promoção porque representa melhor o processo de promoção de uma região secundária para uma região primária (e mais tarde de despromoção de uma região primária para uma região secundária). Você também pode ver o termo failover usado para descrever o processo geral.

Esta secção resume aspetos importantes da Geo-Replicação. Consulte a documentação completa para entender exatamente como funciona. Para mais informações, consulte Geo-Replicação do Barramento de Serviço.

Requerimentos

  • Apoio regional: Podes escolher qualquer região Azure que suporte Service Bus como tua região principal ou 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.

  • Tier: Para ativar a Geo-Replicação, o seu espaço de nomes deve usar o nível Premium.

  • Metadados de Recuperação de Desastres Geo: Não é possível configurar um namespace para usar tanto Geo-Replicação como Recuperação de Desastres Geo.

Considerações

  • Limitações das funcionalidades: Quando ativas a Geo-Replicação, existem algumas restrições. Para mais informações, consulte Geo-Replicação do Barramento de Serviço.

  • Pontos finais privados: Se o utilizador usar pontos de extremidade privados para ligar-se ao seu namespace, também precisará configurar a rede de comunicações nas suas regiões principal e secundária. Para mais informações, consulte endpoints privados na documentação do Azure Event Hubs.

Custo

Para compreender como funciona a fixação de preços para a Geo-Replicação, consulte Preços.

Configurar suporte a várias regiões

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

Esta secção descreve o que esperar quando um namespace de Barramento de Serviço é configurado para Geo-Replicação e a região principal 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.

    Apenas a região primária processa ativamente mensagens dos clientes durante as operações normais. A região secundária recebe mensagens replicadas, mas permanece passiva em 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 configurar o seu emparelhamento de replicação para usar replicação síncrona ou assíncrona.

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

      Este modo oferece a maior garantia de que os seus dados de mensagem estão seguros, uma vez que devem ser confirmados tanto na região primária como na secundária. No entanto, a replicação síncrona aumenta substancialmente a latência de escrita para mensagens recebidas. Também requer que a região secundária esteja disponível para aceitar a operação de escrita, de modo que uma falha na região secundária faça com que a operação de escrita falhe.

      • Assíncrono: As mensagens são escritas na região primária e depois a operação de escrita é concluída. Pouco tempo depois, 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 as operações de gravação. Além disso, o modo de replicação assíncrona pode tolerar a perda da região secundária, permitindo ainda assim operações de escrita na região primária. No entanto, se a região primária tiver uma interrupção, os dados que ainda não foram replicados para a região secundária poderão não estar disponíveis ou perdidos.

      Ao configurar a replicação assíncrona, você configura o tempo de atraso máximo 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 da replicação assíncrona aumentar além do máximo especificado, a região primária começará a limitar as solicitações de entrada para que a replicação possa se atualizar. Para evitar essa situação, é importante selecionar regiões secundárias que não estejam demasiado distantes geograficamente e assegurar que a sua capacidade seja suficiente para a largura de banda.

      Alguns tipos de metadados são replicados de forma síncrona mesmo que selecione o modo de replicação assíncrona.

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

Comportamento durante uma interrupção regional

Esta secção descreve o que esperar quando um namespace de Service Bus é configurado para Geo-Replication e há uma falha na região primária ou secundária.

  • Deteção e resposta: És responsável por decidir quando promover a região secundária do teu 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 se houver uma interrupção de região. Para os critérios sugeridos a ter em conta ao decidir se deve efetuar a cessão, veja os Cenários recomendados para desencadear a promoção.

    Para mais informações sobre como promover uma região secundária para a nova primária, consulte 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 espera que a região secundária recupere antes de aceitar novo tráfego. Essa abordagem elimina a perda de dados, mas introduz tempo de inatividade.

    Durante uma falha na região principal, geralmente é necessário realizar uma promoção compulsória. Se a região principal estiver disponível e tu acionares uma promoção por outro motivo, poderás escolher uma promoção planificada.

  • Notificação: A Microsoft não o notifica automaticamente quando uma região está fora do ar. No entanto, pode usar o Azure Service Health para compreender a saúde geral do serviço, incluindo quaisquer falhas de região, e pode configurar alertas de Saúde do Serviço para o informar sobre problemas.

  • Pedidos ativos: O comportamento depende se a interrupção da região ocorre na região primária ou na 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 da 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 alguma região secundária não estiver disponível.

      • Se usares o modo de replicação assíncrona, o teu namespace limita e não aceita novas mensagens depois de o atraso de replicação atingir o máximo que configuras.

      Para continuar a usar o namespace na região primária, remova o namespace secundário da sua configuração 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íncrona ou assíncrona):

    • Promoção prevista: Nenhuma perda de dados é esperada. No entanto, durante uma interrupção da 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: Pode experienciar alguma perda de dados por mensagens recentes que não são replicadas para a região secundária, e por alterações de estado que ainda não foram replicadas. A quantidade depende do atraso na replicação. Para verificar o atraso de replicação atual, use as métricas do Azure Monitor.

    Caso efetue uma promoção forçada, não pode recuperar dados perdidos, mesmo após a região principal estar disponível.

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

    • Promoção prevista: A primeira etapa de 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 entradas e replicarem totalmente seus registros para os clientes.

      A região principal 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 requer 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 que a replicação dos dados seja concluída 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 os clientes.

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

  • Reencaminhamento do 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 tempo de vida (TTL) dos registros DNS do namespace.

Recuperação da região

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

Se realizou uma promoção forçada durante a falha da região, não conseguirá recuperar os dados perdidos, mesmo depois que a região principal se tornar disponível.

Teste para falhas regionais

Para testar a Geo-Replicação, promova temporariamente a região secundária a primária e valide que as suas aplicações clientes podem alternar entre regiões com perturbações mínimas.

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

Compreenda o potencial tempo de inatividade e perda de dados que você pode enfrentar durante e após o processo de promoção. Teste Geo-Replication num ambiente não produtivo que espelha a configuração do seu namespace de produção.

Recuperação de Metadados de Desastres Geográficos

O nível Premium suporta metadados para Recuperação de Desastres Geo. Esse recurso melhora a recuperação de cenários de desastre, incluindo a perda catastrófica de uma região. Geo-Disaster Recuperação apenas replica a configuração e os metadados do seu namespace. No entanto, não replica os dados das mensagens. Para suportar a recuperação de desastres, esta funcionalidade garante que um namespace noutra região está pré-configurado e pronto para aceitar imediatamente mensagens dos clientes. Geo-Disaster Recovery serve como uma solução de recuperação unidirecional e não suporta reversão de volta à região primária anterior.

A Recuperação de Metadados em Geo-Desastre funciona melhor para aplicações que não precisam estritamente manter todas as mensagens e que podem tolerar alguma perda de dados durante um cenário de desastre. Metadata Geo-Disaster Recuperação pode também ser adequada para aplicações que replicam dados por si próprias, ou que não necessitam de replicação de dados. Por exemplo, se as suas mensagens representam imagens grandes que depois converte em miniaturas, pode decidir que pode perder algumas mensagens de uma região falhada se conseguir rapidamente retomar o processamento de novas mensagens noutra região, e depois reconstruir as mensagens para recuperar o atraso.

Importante

A Geo-Disaster Recovery permite a continuidade das operações que têm a mesma configuração mas não replicam os dados das mensagens. Se precisares de replicar dados de mensagens, considera usar a Geo-Replicação.

Quando configura metadados Geo-Disaster Recovery, cria um alias ao qual as aplicações clientes se ligam. O alias é um FQDN que direciona todo o tráfego para o namespace principal por padrão.

Diagrama que mostra dois namespaces do Service Bus configurados para metadados Geo-Disaster Recuperação.

Se a região primária falhar ou ocorrer outro tipo de desastre, você poderá iniciar manualmente uma mudança de failover unidirecional única da região primária para a região secundária a qualquer momento. Pode optar por realizar um failover seguro, que espera que as replicações sejam concluídas antes de mudar para o secundário, embora esta opção possa não estar disponível durante uma interrupção regional. Assim que um failover começa, este conclui-se quase instantaneamente. Durante o processo de failover, o alias de Recuperação de Desastres Geograficamente Distribuída reponta para o namespace secundário e o emparelhamento é removido.

Esta secção resume aspetos importantes da Recuperação de Geo-Desastres. Consulte a documentação completa para entender exatamente como funciona. Para mais informações, consulte Service Bus Geo-Disaster Recovery.

Requerimentos

  • Apoio regional: Pode selecionar qualquer região Azure que suporte Service Bus como seu namespace principal 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.

  • Tier: Para permitir a Recuperação Geo-Desastre dos metadados, ambos os namespaces devem usar o nível Premium.

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

  • Metadados de Recuperação de Desastres Geo: Não é possível configurar um namespace para usar tanto Geo-Replicação como Recuperação de Desastres Geo.

Considerações

  • Limitações das funcionalidades: Quando ativas Geo-Disaster Recuperação, existem algumas restrições. Para mais informações, consulte Pontos importantes a considerar e Considerações.

  • Atribuições de funções: 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 de aplicações: Geo-Disaster Recuperação requer considerações específicas ao desenhar as suas aplicações para clientes. Para obter mais informações, consulte Considerações.

  • Private endpoints: Se utilizar endpoints privados para se conectar ao seu namespace, configure a rede tanto na região primária como na secundária. Para obter mais informações, consulte Endereços privados.

  • Os namespaces migraram do standard para o premium: Se o teu namespace esteve anteriormente no nível Standard e o migraste para o tier Premium, tens de gerir o alias de forma diferente. Para mais informações, consulte Service Bus Standard to Premium.

Custo

Quando ativas metadados Geo-Disaster Recovery, pagas tanto pelos namespaces primários como secundários.

Configurar suporte a várias regiões

Planejamento e gerenciamento de capacidade

Ao planejar implantações em várias regiões, certifique-se de que ambas as regiões tenham capacidade suficiente para lidar com a carga total 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 secção descreve o que esperar quando um namespace do Service Bus está configurado para Recuperação Geo-Desastre e a região principal está operacional.

  • Encaminhamento do tráfego entre regiões: As aplicações cliente conectam-se através do alias de Geo-Disaster Recovery para o seu namespace, e o seu tráfego é encaminhado para o namespace principal na região principal.

    Apenas o espaço de nomes primário processa ativamente mensagens dos clientes durante as operações normais. O namespace secundário permanece passivo no modo de espera e todas as solicitações de acesso a 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 das mensagens permanecem apenas no namespace primário e não se replicam para o namespace secundário.

Comportamento durante uma interrupção regional

Esta secção descreve o que esperar quando um namespace de Service Bus é configurado para Geo-Disaster Recovery e há uma falha na região principal.

  • Deteção e resposta: Você é responsável por monitorar a integridade da região e iniciar o failover manualmente. A Microsoft não executa failover ou promove uma região secundária automaticamente, mesmo que a região principal esteja inativa.

    Para mais informações sobre como iniciar o failover, veja Fluxo de failover.

    Quando iniciar um failover, escolha se deve realizar um failover seguro ou um failover padrão (forçado ou manual). Um failover seguro espera que a replicação seja concluída na região secundária antes de o failover começar. Esta abordagem reduz a perda de metadados, mas introduz tempos de inatividade. O failover seguro exige que os namespaces estejam na mesma subscrição do Azure.

    Durante uma interrupção na região principal, normalmente é necessário realizar um failover forçado. Se a região principal estiver disponível e desencadear um failover por outro motivo, pode optar por um failover planeado.

    O failover é uma operação unidirecional, por isso precisa de restabelecer o emparelhamento Geo-Disaster Recovery mais tarde. Para obter mais informações, consulte Recuperação de região.

  • Notificação: A Microsoft não o notifica automaticamente quando uma região está fora do ar. No entanto, pode usar o Azure Service Health para compreender a saúde geral do serviço, incluindo quaisquer falhas de região, e pode configurar alertas de Saúde do Serviço para o informar sobre problemas.

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

  • Perda de dados esperada:

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

    • Dados da mensagem: Os dados das mensagens não se replicam entre regiões. Se a região primária cair, as mensagens no seu namespace principal tornam-se indisponíveis.

      As mensagens não se perdem permanentemente, a menos que um desastre catastrófico cause a perda total da região principal. Se a região recuperar, podes 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 que os clientes repliquem e atualizem totalmente as entradas DNS.

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

Recuperação da 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 par de Recuperação de Desastres Geográficos com a região recuperada como secundária e, se pretender regressar à região original, realize outro failover. Este processo envolve a perda potencial de dados das mensagens enviadas para o temporário principal.

Se o desastre causar a perda de todas as zonas na região primária, seus dados podem ser irrecuperáveis. Noutros cenários, os dados da sua mensagem que permanecem no namespace primário desde antes do failover são recuperáveis. Pode obter mensagens históricas do antigo espaço de nomes primário depois de restaurar o acesso. És responsável por configurar as tuas aplicações para receberem e processarem essas mensagens. A Microsoft não os restaura automaticamente na sua região secundária.

Teste para falhas regionais

Para testar seus processos de resposta e recuperação de desastres, execute um failover planejado durante uma janela de manutenção. Inicie o failover do seu namespace primário para o seu namespace secundário e verifique se as suas aplicações conseguem ligar-se e processar mensagens do novo namespace primário.

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

Compreenda o tempo de inatividade potencial e a perda de dados que você pode enfrentar durante e após o processo de failover. Metadados de teste de Recuperação de Desastres Geográficos num ambiente não produtivo que reflete a configuração do namespace de produção.

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

Geo-Replication e metadados Geo-Disaster Recuperação proporcionam resiliência a falhas de região e outros problemas, sendo adequados para a maioria das cargas de trabalho. No entanto, podem não se adequar às suas necessidades nas seguintes situações:

  • Tens requisitos para replicação personalizada ou para manter múltiplas regiões ativas em simultâneo.
  • Usas um nível de Service Bus que não suporta estas funcionalidades.

Existe uma variedade de padrões de design para alcançar diferentes tipos de suporte multi-região no Service Bus. Muitos dos padrões exigem a implementação de múltiplos namespaces e a configuração da aplicação para usar esses namespaces de forma adequada. Para saber mais, consulte os seguintes artigos:

Resiliência à manutenção de serviços

O Service Bus realiza manutenção regular. Durante a manutenção planeada, os namespaces são movidos para um nó redundante que contém as atualizações mais recentes. Quando esta mudança ocorre, o SDK dos clientes desliga-se e reconecta-se automaticamente no namespace. Normalmente, as melhorias acontecem em 30 segundos. É importante que as suas aplicações estejam preparadas para quaisquer desconexões transitórias da rede que ocorram durante os períodos de manutenção.

Para mais informações, consulte Orientação sobre eventos de manutenção Azure para Azure Service Bus.

Backup e restauração

O Service Bus não foi concebido como um local de armazenamento a longo prazo para os seus dados. Normalmente, os dados são armazenados num tópico ou fila durante um curto período de tempo, e depois são processados ou mantidos para outro sistema de armazenamento de dados, altura em que são eliminados. Devido a este design, o Service Bus mantém automaticamente réplicas dos dados das mensagens, mas não fornece capacidades de backup e restauro dos dados das mensagens.

Para cenários que requerem retenção de mensagens a longo prazo, considere implementar o arquivamento ao nível da aplicação no Azure Storage ou noutros serviços de armazenamento duráveis.

Contrato de nível de serviço

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

O Service Bus fornece um SLA para todos os namespaces. O SLA de disponibilidade é maior quando o seu namespace cumpre todos os seguintes critérios:

  • Usa o nível premium.
  • Está localizada numa região com zonas de disponibilidade.
  • Utiliza particionamento.

Conteúdo relacionado

  • Last updated on