Recuperação de desastres geográficos do Barramento de Serviço do Azure

A resiliência contra interrupções desastrosas de recursos de processamento de dados é um requisito para muitas empresas e, em alguns casos, até mesmo exigido pelas regulamentações do setor.

O Barramento de Serviço do Azure já espalha o risco de falhas catastróficas de máquinas individuais ou até mesmo racks completos entre clusters que abrangem vários domínios de falha em um datacenter e implementa mecanismos transparentes de deteção de falhas e failover, de modo que o serviço continue a operar dentro dos níveis de serviço garantidos e, normalmente, sem interrupções percetíveis quando tais falhas ocorrem. Um namespace premium pode ter duas ou mais unidades de mensagens e essas unidades de mensagens estão espalhadas por vários domínios de falha em um datacenter, suportando um modelo de cluster do Service Bus totalmente ativo.

Para um namespace de nível premium, o risco de interrupção é ainda mais espalhado por três instalações fisicamente separadas (zonas de disponibilidade), e o serviço tem reservas de capacidade suficientes para lidar instantaneamente com a perda completa e catastrófica de um datacenter. O modelo de cluster do Barramento de Serviço do Azure totalmente ativo dentro de um domínio de falha, juntamente com o suporte à zona de disponibilidade, é superior a qualquer produto de agente de mensagens local em termos de resiliência contra falhas graves de hardware e até mesmo perda catastrófica de instalações inteiras do datacenter. Ainda assim, pode haver situações graves com destruição física generalizada contra as quais mesmo essas medidas não conseguem se defender suficientemente.

O recurso de recuperação de desastres geográficos do Service Bus foi projetado para facilitar a recuperação de um desastre dessa magnitude e abandonar definitivamente uma região do Azure com falha e sem precisar alterar as configurações do aplicativo. Abandonar uma região do Azure normalmente envolve vários serviços e esse recurso visa principalmente ajudar a preservar a integridade da configuração do aplicativo composto. O recurso está disponível globalmente para o Service Bus Premium SKU.

O recurso de recuperação de desastres geográficos garante que toda a configuração de um namespace (filas, tópicos, assinaturas, filtros) seja replicada continuamente de um namespace primário para um namespace secundário quando emparelhado e permite que você inicie uma mudança de failover única do primário para o secundário a qualquer momento. A movimentação de failover reaponta o nome do alias escolhido para o namespace para o namespace secundário e, em seguida, interrompe o emparelhamento. O failover é quase instantâneo uma vez iniciado.

Pontos importantes a considerar

• O recurso permite a continuidade instantânea de operações com a mesma configuração, mas não replica as mensagens mantidas em filas ou assinaturas de tópicos ou filas de mensagens mortas. Para preservar a semântica da fila, essa replicação requer não apenas a replicação de dados de mensagens, mas de todas as alterações de estado no broker. Para a maioria dos namespaces do Service Bus, o tráfego de replicação necessário excederia em muito o tráfego do aplicativo e, com filas de alta taxa de transferência, a maioria das mensagens ainda seria replicada para o secundário enquanto já estivessem sendo excluídas do principal, causando tráfego excessivamente desperdiçado. Para rotas de replicação de alta latência, que se aplicam a muitos emparelhamentos que você escolheria para recuperação de desastres geográficos, também pode ser impossível para o tráfego de replicação acompanhar de forma sustentável o tráfego do aplicativo devido aos efeitos de limitação induzidos pela latência.
• As atribuições RBAC (controle de acesso baseado em função) do Microsoft Entra para entidades do Service Bus 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.
• As configurações a seguir não são replicadas.
  • Configurações de rede virtual
  • Ligações de ponto final privado
  • Todos os acessos a redes ativados
  • Acesso a serviços confiáveis habilitado
  • Acesso à rede pública
  • Ação de rede padrão
  • Identidades e configurações de criptografia (criptografia de chave gerenciada pelo cliente ou criptografia de traga sua própria chave (BYOK))
  • Ativar dimensionamento automático
  • Desativar autenticação local
• Não há suporte para emparelhamento de um namespace particionado com um namespace não particionado.
• Se AutoDeleteOnIdle estiver habilitada para uma entidade, a entidade pode não estar presente no namespace secundário quando o failover ocorrer. Quando o secundário se torna primário, o último status de acesso, que não faz parte dos metadados, não estará disponível para o novo primário e a entidade poderá ser excluída como parte da AutoDeleteOnIdle limpeza.

Gorjeta

Para replicar o conteúdo de filas e assinaturas de tópicos e operar namespaces correspondentes em configurações ativas/ativas para lidar com interrupções e desastres, não se apoie neste conjunto de recursos de recuperação de desastres geográficos, mas siga as diretrizes de replicação.

Interrupções e desastres

É importante notar a distinção entre "interrupções" e "desastres".

Uma interrupção é a indisponibilidade temporária do Barramento de Serviço do Azure e pode afetar alguns componentes do serviço, como um armazenamento de mensagens ou até mesmo todo o datacenter. No entanto, depois que o problema é corrigido, o Service Bus fica disponível novamente. Normalmente, uma interrupção não causa a perda de mensagens ou outros dados. Um exemplo dessa interrupção pode ser uma falha de energia no datacenter. Algumas interrupções são apenas perdas de conexão curtas devido a problemas transitórios ou de rede.

Um desastre é definido como a perda permanente ou de longo prazo de um cluster do Service Bus, região do Azure ou datacenter. A região ou o datacenter pode ou não ficar disponível novamente ou pode ficar inativo por horas ou dias. Exemplos de tais desastres são incêndios, inundações ou terremotos. Um desastre que se torna permanente pode causar a perda de algumas mensagens, eventos ou outros dados. No entanto, na maioria dos casos, não deve haver perda de dados e as mensagens podem ser recuperadas assim que o data center voltar a funcionar.

O recurso de recuperação de desastres geográficos do Barramento de Serviço do Azure é uma solução de recuperação de desastres. Os conceitos e o fluxo de trabalho descritos neste artigo aplicam-se a cenários de desastre e não a interrupções transitórias ou temporárias. Para obter uma discussão detalhada sobre recuperação de desastres no Microsoft Azure, consulte este artigo.

Conceitos e termos básicos

O recurso de recuperação de desastres implementa a recuperação de desastres de metadados e depende de namespaces de recuperação de desastres primários e secundários. O recurso de recuperação de desastres geográficos está disponível apenas para o SKU Premium. Não é necessário fazer alterações na cadeia de conexão, pois a conexão é feita por meio de um alias.

Os seguintes termos são usados neste artigo:

• Alias: o nome de uma configuração de recuperação de desastres que você configurou. O alias fornece uma única cadeia de conexão estável FQDN (Fully Qualified Domain Name). Os aplicativos usam essa cadeia de conexão de alias para se conectar a um namespace. O uso de um alias garante que a cadeia de conexão permaneça inalterada quando o failover for acionado.

• Namespace primário/secundário: os namespaces que correspondem ao alias. O namespace principal é "ativo" e recebe mensagens (pode ser um namespace existente ou novo). O namespace secundário é "passivo" e não recebe mensagens. Os metadados entre ambos estão sincronizados, para que ambos possam aceitar mensagens sem qualquer código de aplicativo ou alterações na cadeia de conexão. Para garantir que apenas o namespace ativo receba mensagens, você deve usar o alias.

• Metadados: entidades como filas, tópicos e assinaturas e suas propriedades do serviço associadas ao namespace. Somente entidades e suas configurações são replicadas automaticamente. As mensagens não são replicadas.

• Failover: O processo de ativação do namespace secundário.

Configurar

A seção a seguir é uma visão geral para configurar o emparelhamento entre os namespaces.

Primeiro, você cria ou usa um namespace primário existente e um novo namespace secundário e, em seguida, emparelha os dois. Esse emparelhamento fornece um alias que você pode usar para se conectar. Como você usa um alias, não é necessário alterar cadeias de conexão. Somente novos namespaces podem ser adicionados ao seu emparelhamento de failover.

1. Crie o namespace primário de camada premium.

2. Crie o namespace secundário de camada premium em uma região diferente. Este passo é opcional. Você pode criar o namespace secundário enquanto cria o emparelhamento na próxima etapa.

3. No portal do Azure, navegue até seu namespace principal.

4. Selecione Geo-recuperação no menu à esquerda e selecione Iniciar emparelhamento na barra de ferramentas.

   

5. Na página Iniciar emparelhamento, siga estes passos:

   1. Selecione um namespace secundário existente ou crie um em uma região diferente. Neste exemplo, um namespace existente é usado como o namespace secundário.

   2. Para Alias, insira um alias para o emparelhamento geo-dr.

   3. Em seguida, selecione Criar.

      

6. Você deve ver a página Alias Geo-DR do Service Bus, conforme mostrado na imagem a seguir. Você também pode navegar até a página Alias Geo-DR na página de namespace principal selecionando a Recuperação geográfica no menu à esquerda.

   

7. Na página Alias Geo-DR, selecione Políticas de acesso compartilhado no menu à esquerda para acessar a cadeia de conexão primária para o alias. Use essa cadeia de conexão em vez de usar a cadeia de conexão diretamente para o namespace primário/secundário. Inicialmente, o alias aponta para o namespace principal.

8. Alterne para a página Visão geral . Você pode executar as seguintes ações:

   1. Quebre o emparelhamento entre namespaces primários e secundários. Selecione Quebrar emparelhamento na barra de ferramentas.
   2. Faça failover manualmente para o namespace secundário.

      1. Selecione Failover na barra de ferramentas.

      2. Confirme que deseja fazer failover para o namespace secundário digitando seu alias.

      3. Ative a opção Failover seguro para fazer failover com segurança para o namespace secundário.

         Nota

         • O failover seguro garante que as replicações Geo-DR pendentes sejam concluídas antes de mudar para o secundário. Enquanto o failover forçado ou manual não espera que as replicações pendentes sejam concluídas antes de mudar para o secundário.
         • Atualmente, o failover seguro falhará se os namespaces primário e secundário não estiverem na mesma assinatura do Azure.

      4. Em seguida, selecione Failover.

         

         Importante

         O failover ativa o namespace secundário e remove o namespace primário do emparelhamento Geo-Disaster Recovery. Crie outro namespace para ter um novo par de recuperação de desastres geográficos.

9. Finalmente, você deve adicionar algum monitoramento para detetar se um failover é necessário. Na maioria dos casos, o serviço é uma parte de um grande ecossistema, portanto, failovers automáticos raramente são possíveis, pois muitas vezes os failovers devem ser executados em sincronia com o subsistema ou infraestrutura restante.

Barramento de serviço padrão para premium

Se você migrou seu namespace do Azure Service Bus Standard para o Azure Service Bus Premium, deverá usar o alias pré-existente (ou seja, sua cadeia de conexão de namespace do Service Bus Standard) para criar a configuração de recuperação de desastres por meio da API PS/CLI ou REST.

Isso ocorre porque, durante a migração, a própria cadeia de conexão de namespace padrão do Barramento de Serviço do Azure/nome DNS se torna um alias para seu namespace premium do Barramento de Serviço do Azure.

Seus aplicativos cliente devem utilizar esse alias (ou seja, a cadeia de conexão de namespace padrão do Barramento de Serviço do Azure) para se conectar ao namespace premium onde o emparelhamento de recuperação de desastres foi configurado.

Se você usar o portal do Azure para configurar a configuração de recuperação de desastres, o portal abstrai essa advertência de você.

Fluxo de failover

Um failover é acionado manualmente pelo cliente (explicitamente por meio de um comando ou por meio da lógica de negócios de propriedade do cliente que aciona o comando) e nunca pelo Azure. Ele dá ao cliente total propriedade e visibilidade para a resolução de interrupções no backbone do Azure.

Depois que o failover for acionado -

1. A cadeia de conexão de alias é atualizada para apontar para o namespace Premium Secundário.

2. Os clientes (remetentes e recetores) se conectam automaticamente ao namespace secundário.

3. O emparelhamento existente entre o namespace premium Primário e Secundário foi quebrado.

Uma vez iniciado o failover -

1. Se ocorrer outra interrupção, você deseja poder falhar novamente. Portanto, configure outro namespace passivo e atualize o emparelhamento.

2. Extraia mensagens do namespace principal anterior quando ele estiver disponível novamente. Depois disso, use esse namespace para mensagens regulares fora da configuração de recuperação geográfica ou exclua o namespace primário antigo.

Nota

Apenas a semântica de avanço de falha é suportada. Nesse cenário, você faz failover e, em seguida, emparelhar novamente com um novo namespace. Não há suporte para failback; por exemplo, em um cluster SQL.

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

Gestão

Se você cometeu um erro, por exemplo, emparelhou as regiões erradas durante a configuração inicial, poderá interromper o emparelhamento dos dois namespaces a qualquer momento. Se você quiser usar os namespaces emparelhados como namespaces regulares, exclua o alias.

Usar namespace existente como alias

Se você tiver um cenário no qual não pode alterar as conexões de produtores e consumidores, poderá reutilizar o nome do namespace como o nome do alias. Veja o código de exemplo no GitHub aqui.

Exemplos

Os exemplos no GitHub mostram como configurar e iniciar um failover. Estes exemplos demonstram os seguintes conceitos:

• Um exemplo .NET e configurações que são necessárias na ID do Microsoft Entra para usar o Azure Resource Manager com Service Bus, para configurar e habilitar a recuperação de desastres geográficos.
• Etapas necessárias para executar o código de exemplo.
• Como usar um namespace existente como um alias.
• Etapas para habilitar alternativamente a recuperação de desastres geográficos via PowerShell ou CLI.
• Envie e receba do namespace primário ou secundário atual usando o alias.

Considerações

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

• No planejamento de failover, você também deve considerar o fator tempo. Por exemplo, se você perder a conectividade por mais de 15 a 20 minutos, poderá decidir iniciar o failover.
• O fato de nenhum dado ser replicado significa que as sessões ativas atualmente não são replicadas. Além disso, a deteção de duplicados e mensagens agendadas podem não funcionar. Novas sessões, novas mensagens agendadas e novas duplicatas funcionam.
• O failover de uma infraestrutura distribuída complexa deve ser ensaiado pelo menos uma vez.
• A sincronização de entidades pode levar algum tempo, aproximadamente 50-100 entidades por minuto. Subscrições e regras também contam como entidades.

Zonas de Disponibilidade

A SKU Premium do Service Bus dá suporte a zonas de disponibilidade, fornecendo locais isolados por falhas dentro da mesma região do Azure. O Service Bus gerencia três cópias do armazenamento de mensagens (1 primária e 2 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. Se os aplicativos virem desconexões transitórias do Service Bus, a lógica de repetição no SDK se reconectará automaticamente ao Service Bus.

Quando você usa zonas de disponibilidade, metadados e dados (mensagens) são replicados entre data centers na zona de disponibilidade.

Nota

O suporte de Zonas de Disponibilidade para o Azure Service Bus Premium só está disponível em regiões do Azure onde as zonas de disponibilidade estão presentes.

Quando você cria um namespace de camada premium por meio do portal, o suporte para zonas de disponibilidade (se disponível na região selecionada) é automaticamente habilitado para o namespace. Ao criar um namespace de camada premium por meio de outros mecanismos, como modelos ARM / Bicep, CLI ou PowerShell, a propriedade zoneRedundant precisa ser explicitamente definida para true habilitar zonas de disponibilidade (se disponíveis na região selecionada). Não há custo adicional para usar esse recurso e você não pode desabilitar ou habilitar esse recurso após a criação do namespace.

Pontos finais privados

Esta seção fornece mais considerações ao usar a recuperação de desastres geográficos com namespaces que usam pontos de extremidade privados. Para saber mais sobre como usar pontos de extremidade privados com o Service Bus em geral, consulte Integrar o Barramento de Serviço do Azure com o Azure Private Link.

Novos emparelhamentos

Se você tentar criar um emparelhamento entre um namespace primário com um ponto de extremidade privado e um namespace secundário sem um ponto de extremidade privado, o emparelhamento falhará. O emparelhamento será bem-sucedido somente se os namespaces primário e secundário tiverem pontos de extremidade privados. Recomendamos que você use as mesmas configurações nos namespaces primário e secundário e em redes virtuais nas quais pontos de extremidade privados são criados.

Nota

Quando você tenta emparelhar o namespace primário com um ponto de extremidade privado e o namespace secundário, o processo de validação verifica apenas se existe um ponto de extremidade privado no namespace secundário. Ele não verifica se o ponto de extremidade funciona ou funciona após o failover. É sua responsabilidade garantir que o namespace secundário com ponto de extremidade privado funcione conforme o esperado após o failover.

Para testar se as configurações de ponto de extremidade privado são as mesmas, envie uma solicitação Get queues para o namespace secundário de fora da rede virtual e verifique se você recebeu uma mensagem de erro do serviço.

Emparelhamentos existentes

Se o emparelhamento entre namespace primário e secundário já existir, a criação de ponto de extremidade privado no namespace primário falhará. Para resolver, crie primeiro um ponto de extremidade privado no namespace secundário e, em seguida, crie um para o namespace primário.

Nota

Embora permitamos acesso somente leitura ao namespace secundário, atualizações para as configurações de ponto de extremidade privado são permitidas.

Configuração recomendada

Ao criar uma configuração de recuperação de desastres para seu aplicativo e Service Bus, você deve criar pontos de extremidade privados para namespaces primários e secundários do Service Bus em redes virtuais que hospedam instâncias primárias e secundárias do seu aplicativo.

Digamos que você tenha duas redes virtuais: VNET-1, VNET-2 e esses namespaces primários e secundários: ServiceBus-Namespace1-Primary, ServiceBus-Namespace2-Secondary. Você precisa fazer as seguintes etapas:

• No ServiceBus-Namespace1-Primary, crie dois pontos de extremidade privados que usam sub-redes de VNET-1 e VNET-2
• No ServiceBus-Namespace2-Secondary, crie dois pontos de extremidade privados que usam as mesmas sub-redes de VNET-1 e VNET-2

A vantagem dessa abordagem é que o failover pode ocorrer na camada de aplicativo independentemente do namespace do Service Bus. Considere os seguintes cenários:

Failover somente de aplicativo: aqui, o aplicativo não existe em VNET-1, mas é movido para VNET-2. Como ambos os pontos de extremidade privados são configurados em VNET-1 e VNET-2 para namespaces primários e secundários, o aplicativo simplesmente funciona.

Failover somente de namespace do Service Bus: aqui novamente, como ambos os pontos de extremidade privados são configurados em ambas as redes virtuais para namespaces primários e secundários, o aplicativo simplesmente funciona.

Nota

Para obter orientação sobre a recuperação de desastres geográficos de uma rede virtual, consulte Rede virtual - Continuidade de negócios.

Controlo de acesso baseado em funções

As atribuições RBAC (controle de acesso baseado em função) do Microsoft Entra para entidades do Service Bus 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.

Próximos passos

• Consulte a referência da API REST de recuperação de desastres geográficos aqui.
• Execute o exemplo de recuperação de desastres geográficos no GitHub.
• Consulte o Exemplo de recuperação de desastres geográficos que envia mensagens para um alias.

Para saber mais sobre as mensagens do Service Bus, consulte os seguintes artigos:

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