Recuperação de desastre em área geográfica 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 exigida por regulamentos do setor.

O Barramento de Serviço do Azure já espalha o risco de falhas catastróficas de computadores individuais ou até mesmo racks completos em clusters que abrangem vários domínios de falha dentro de um datacenter e implementa mecanismos transparentes de detecção e failover de falha, de modo que o serviço continue operando dentro dos níveis de serviço garantidos, normalmente sem interrupções perceptíveis quando essas falhas ocorrem. Um namespace premium pode ter duas ou mais unidades do sistema de mensagens e essas unidades são distribuídas entre vários domínios de falha em um datacenter, dando suporte a um modelo de cluster do Barramento de Serviço totalmente ativo.

Para um namespace da camada premium, o risco de interrupção é distribuído em três instalações fisicamente separadas (zonas de disponibilidade) e o serviço terá reservas de capacidade suficientes para lidar instantaneamente com a perda total 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 do agente de mensagens local em termos de resiliência contra falhas graves de hardware e até mesmo perda catastrófica de instalações de datacenter inteiras. Ainda assim, pode haver grave situações com destruição física generalizada em que até mesmo essas medidas poderão não ser suficientes para garantir a proteção.

O recurso de recuperação de desastre geográfico do barramento de serviço foi projetado para facilitar a recuperação de um desastre dessa magnitude e abandonar uma região do Azure com falha para sempre e sem precisar alterar as configurações do aplicativo. Abandonar uma região do Azure normalmente envolve vários serviços e esse recurso destina-se principalmente a ajudar a preservar a integridade da configuração do aplicativo composto. O recurso de recuperação de desastres em área geográfica fica globalmente disponível para a SKU Premium do Barramento de Serviço.

O recurso de recuperação de desastre geográfico 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, além de permitir que você inicie uma movimentação de failover apenas uma vez, do primário para o secundário, a qualquer momento. O movimento de failover aponta novamente o nome do alias escolhido para o namespace para o namespace secundário e, em seguida, interrompe o emparelhamento. O failover é quase instantâneo depois de iniciado.

Pontos importantes a serem considerados

• 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ópico 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 mensagem, mas de cada alteração de estado no agente. Para a maioria dos namespaces do Barramento de Serviço, o tráfego de replicação necessário excederia 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 embora já estivesse sendo excluída do primário, causando um tráfego excessivo e desnecessário. Para rotas de replicação de alta latência, que se aplicam a vários emparelhamentos que você escolheria para a recuperação de desastre geográfico, também pode ser impossível para o tráfego de replicação acompanhar o tráfego do aplicativo devido a efeitos de limitação induzida por latência.
• As atribuições de RBAC (controle de acesso baseado em função) do Microsoft Entra às entidades de Barramento de Serviço no namespace primário não são replicadas no 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
  • Conexões de ponto de extremidade privado
  • Acesso a todas as redes habilitado
  • Acesso ao serviço confiável 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 BYOK, Bring Your Own Key)
  • Habilitar a escala automática
  • Desabilitar autenticação local
• Não há suporte para emparelhamento de um namespace particionado com um namespace não particionado.
• Se AutoDeleteOnIdle estiver habilitado para uma entidade, a entidade poderá não estar presente no namespace secundário quando ocorrer o failover. Quando o secundário se tornar 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.

Dica

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

Interrupções e desastres

É importante observar a diferença entre "interrupção" e "desastres".

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

Um desastre é definido como a perda permanente ou de longo prazo de um cluster do Barramento de Serviço, uma região do Azure ou um datacenter. A região ou o datacenter pode ou não ficar disponível novamente ou pode ficar inativa por horas ou dias. Outros exemplos desses desastres são incêndios, enchentes ou terremoto. Um desastre que se torne permanente pode causar a perda de algumas mensagens, alguns eventos ou outros dados. No entanto, na maioria dos casos, não deve haver perda de dados e as mensagens podem ser recuperadas depois que o data center se torna disponível novamente.

O recurso de recuperação de desastre em área geográfica do Barramento de Serviço do Azure é uma solução de recuperação de desastre. Os conceitos e o fluxo de trabalho descrito neste artigo se aplicam a cenários de desastre e não a falhas transitórias ou temporárias. Para uma discussão detalhada sobre a recuperação de desastre no Microsoft Azure, consulte este artigo.

Termos e conceitos básicos

O recurso de recuperação de desastre implementa a recuperação de desastre dos metadados e se baseia em namespaces de recuperação de desastre primário e secundário. O recurso de recuperação de desastre geográfico está disponível somente para a SKU Premium. Você não precisa fazer nenhuma alteração de cadeia de conexão, já que a conexão é feita por meio de um alias.

Os seguintes termos são usados neste artigo:

• Alias: o nome para uma configuração de recuperação de desastre que você configurou. O alias fornece uma única cadeia de conexão estável do FQDN (Nome de Domínio Totalmente Qualificado). Aplicativos usam essa cadeia de conexão de alias para conectarem-se a um namespace. Usar um alias garante que a cadeia de caracteres de conexão fique inalterada quando o failover for disparado.

• Namespace primário/secundário: os namespaces que correspondem ao alias. O namespace primário é "ativo" e recebe mensagens (pode ser um namespace existente ou novo). O namespace secundário "passivo" e não recebe mensagens. Os metadados entre os dois estão sincronizados, para que ambos possam aceitar mensagens continuamente sem quaisquer alterações no código do aplicativo ou 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 que são associadas ao namespace. Somente entidades e suas configurações são replicadas automaticamente. Mensagens não são replicadas.

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

Instalação

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

Primeiro crie ou use um namespace primário existente e um novo namespace secundário, depois emparelhe os dois. Esse emparelhamento fornece um alias que você pode usar para se conectar. Como você usa um alias, não precisa alterar cadeias de conexão. Somente novos namespaces podem ser adicionados ao emparelhamento de failover.

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

2. Crie o namespace secundário da camada premium em uma região diferente. Esta etapa é opcional. Você pode criar o namespace secundário ao criar o emparelhamento na próxima etapa.

3. No portal do Azure, navegue até o namespace primário.

4. Selecione Recuperação geográfica no menu esquerdo e selecione Iniciar emparelhamento na barra de ferramentas.

   

5. Na página Iniciar emparelhamento, siga estas etapas:

   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 de geo-dr.

   3. Em seguida, selecione Criar.

      

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

   

7. Na página Alias de Geo-DR, selecione Políticas de acesso compartilhado no menu esquerdo 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 para o namespace primário/secundário diretamente. Inicialmente, o alias aponta para o namespace primário.

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

   1. Quebre o emparelhamento entre os namespaces primário e secundário. 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 você 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.

         Observação

         • O failover seguro garante que as replicações de DR geográfica pendentes sejam concluídas antes de alternar para a secundária. Já o failover forçado ou manual não aguarda a conclusão das replicações pendentes antes de alternar para a secundária.
         • 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 recuperação de desastre geográfico. Crie outro namespace para ter um novo par de recuperação de desastre geográfico.

9. Por fim, você deve adicionar um monitoramento para detectar se um failover é necessário. Na maioria dos casos, o serviço é uma parte de um grande ecossistema, assim, failovers automáticos raramente são possíveis, uma vez que failovers devem ser executados em sincronia com o subsistema ou a infraestrutura restante.

Barramento de Serviço Standard para Premium

Se você tiver migrado o namespace do Barramento de Serviço do Azure Standard para o Barramento de Serviço do Azure Premium, use o alias preexistente (ou seja, a cadeia de conexão de namespace do Barramento de Serviço Standard) para criar a configuração de recuperação de desastre por meio de PS/CLI ou da API REST.

Isso ocorre porque, durante a migração, sua cadeia de conexão de namespace standard/nome DNS do Barramento de Serviço do Azure em si se torna um alias para o namespace premium do Barramento de Serviço do Azure.

Os aplicativos cliente devem utilizar esse alias (ou seja, a cadeia de conexão de namespace standard do Barramento de Serviço do Azure) para se conectar ao namespace premium em que o emparelhamento de recuperação de desastre foi configurado.

Se você usar o portal do Azure para configurar a recuperação de desastre, o portal abstrairá essa limitação de você.

Fluxo do failover

Um failover é disparado manualmente pelo cliente (seja 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 visibilidade e propriedade completa para resolução de interrupção no backbone do Azure.

Após o failover ser disparado:

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

2. Os clientes (remetentes e receptores) conectam-se automaticamente no namespace secundário.

3. O emparelhamento existente entre os namespaces premium primário e secundário é interrompido.

Depois que o failover é iniciado:

1. Caso ocorra outra interrupção, você deve ser capaz de fazer o failover novamente. Portanto, configure outro namespace passivo e atualize o emparelhamento.

2. Faça pull das mensagens do namespace primário anterior assim que estiver disponível novamente. Depois disso, use esse namespace para mensagens regulares fora de sua configuração de recuperação geográfica ou exclua o namespace primário antigo.

Observação

Há suporte apenas para semânticas encaminhadas com falha. Nesse cenário, você faz o failover e emparelha novamente com um novo namespace. Não há suporte para failback, em um cluster do SQL por exemplo.

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

Gerenciamento

Se você cometeu um erro, por exemplo, emparelhou as regiões erradas durante a configuração inicial, é possível 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 é possível alterar as conexões de produtores e consumidores, poderá reutilizar o nome do namespace como o nome do alias. Consulte o exemplo de código no GitHub aqui.

Exemplos

Os exemplos no GitHub mostram como configurar e iniciar um failover. Esses exemplos demonstram os conceitos a seguir:

• Um exemplo de .NET e configurações necessárias no Microsoft Entra ID para usar o Azure Resource Manager com o Barramento de Serviço para configurar e habilitar a recuperação de desastre geográfico.
• Etapas necessárias para executar o exemplo de código.
• Como usar um namespace existente como alias.
• Etapas para habilitar a recuperação de desastres de geográficos por meio do PowerShell ou CLI como alternativa.
• Envie e receba do namespace primário ou secundário atual usando o alias.

Considerações

Observe as seguintes considerações a serem lembradas quanto a esta versão:

• Em seu 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, pode decidir iniciar o failover.
• O fato de que nenhum dado seja replicado significa que sessões atualmente ativas não são replicadas. Além disso, a detecção duplicada e as mensagens agendadas podem não funcionar. Novas sessões, novas mensagens agendadas e novas duplicatas funcionam.
• O failover de uma infraestrutura complexa distribuída deve ser testado pelo menos uma vez.
• A sincronização de entidades pode levar algum tempo, cerca de 50 a 100 entidades por minuto. Assinaturas e regras também são contadas como entidades.

Zonas de Disponibilidades

O SKU do Barramento de Serviço Premium oferece suporte a zonas de disponibilidade, fornecendo locais isolados de falhas dentro da mesma região do Azure. O Barramento de Serviço gerencia 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. Se os aplicativos virem desconexões transitórias do Barramento de Serviço, a lógica de repetição no SDK se reconectará automaticamente ao Barramento de Serviço.

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

Observação

O suporte a Zonas de Disponibilidade para o Barramento de Serviço Premium do Azure só é oferecido nas regiões do Azure em que existem zonas de disponibilidade.

Ao criar 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 definida explicitamente comotrue para habilitar zonas de disponibilidade (se disponível 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 de extremidade privados

Esta seção fornece mais considerações ao usar a recuperação de desastre geográfico com namespaces que usam pontos de extremidade privados. Para saber mais sobre como usar pontos de extremidade privados com o Barramento de Serviço em geral, confira Integrar o Barramento de Serviço do Azure ao Link Privado do Azure.

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 só terá êxito se namespaces primários e secundários tiverem pontos de extremidade privados. Recomendamos que você use as mesmas configurações nos namespaces primário e secundário e nas redes virtuais nas quais os pontos de extremidade privados são criados.

Observação

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 se ele 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 do ponto de extremidade privado são as mesmas, envie uma solicitação Obter filas ao 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 o namespace primário e secundário já existir, a criação do 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.

Observação

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

Configuração recomendada

Ao criar uma configuração de recuperação de desastre para seu aplicativo e Barramento de Serviço, você deve criar pontos de extremidade privados para namespaces de Barramento de Serviço primário e secundário em redes virtuais que hospedam as instâncias primária e secundária 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 executar as seguintes etapas:

• Em ServiceBus-Namespace1-Primary, crie dois pontos de extremidade privados que usam sub-redes de VNET-1 e VNET-2
• Em 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 independente do namespace do Barramento de Serviço. Considere os seguintes cenário:

Failover somente de aplicativo: aqui, o aplicativo não existe na VNET-1, mas passa para a 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 apenas funciona.

Failover somente de namespace do Barramento de Serviço: aqui, novamente, como ambos os pontos de extremidade privados são configurados em ambas as redes virtuais para os namespaces primário e secundário, o aplicativo só funciona.

Observação

Para obter orientação sobre a recuperação de desastre geográfico de uma rede virtual, confira Rede virtual – continuidade dos negócios.

Controle de acesso baseado em função

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

Próximas etapas

• Consulte a referência da API REST de recuperação de desastre em área geográfica aqui.
• Execute o exemplo no GitHub da recuperação de desastre em área geográfica.
• Consulte o exemplo que envia mensagens a um alias da recuperação de desastre em área geográfica.

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

• Filas, tópicos e assinaturas do Barramento de Serviço
• Introdução às filas do Barramento de Serviço
• Como usar tópicos e assinaturas do Barramento de Serviço
• REST API