Recuperação de Desastres Geográficos do barramento de serviço do Azure

O recurso Service Bus Recuperação de Desastre Geográfico é uma das opções para isolar os aplicativos do Azure Service Bus contra interrupções e desastres e tem como objetivo principal ajudar a preservar a integridade da configuração do aplicativo composto.

Observação

Esse recurso está disponível para o nível Premium do Azure Service Bus.

O recurso Recuperação de Desastre Geográfico garante que toda a configuração de um namespace (entidades, configuração, propriedades) seja continuamente replicada de um namespace primário para um namespace secundário com o qual está emparelhado e permite iniciar uma movimentação de failover única. do primário para o secundário a qualquer momento. A movimentação de failover aponta novamente o nome de 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, tal replicação requer não apenas a replicação dos dados da mensagem, mas de cada mudança de estado no broker, que é oferecida no recurso Geo-Replication (Public Preview).
• 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
  • Assinaturas da Grade de Eventos do Azure
• 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ópicos e operar namespaces correspondentes em configurações ativas/ativas para lidar com interrupções e desastres, não se apoie nesse conjunto de recursos de Recuperação de Desastres Geográficos, mas use o recurso de replicação geográfica ou siga o orientação de replicação.

Termos e conceitos básicos

O recurso Recuperação de Desastre Geográfico implementa recuperação de desastres de metadados e depende de namespaces primários e secundários de recuperação de desastres. O recurso Recuperação de Desastre Geográfico está disponível apenas para o nível 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. Em Alias, insira um alias para o emparelhamento do Recuperação de Desastre Geográfico.

   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 Geo-DR Alias ​​​​na página do namespace principal selecionando Recuperação Geográfica no menu esquerdo.

   

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 pendentes do Recuperação de Desastre Geográfico sejam concluídas antes de mudar para o secundário. Alternativamente, 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 do 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 destinatários) conectam-se automaticamente ao 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 secundário 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 da configuração do Recuperação de Desastre Geográfico ou exclua o antigo namespace primário.

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. O failback não é suportado; por exemplo, como em um cluster SQL.

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 .NET e configurações necessárias no Microsoft Entra ID 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 exemplo de código.
• Como usar um namespace existente como 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 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.

Pontos de extremidade privados

Essa 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 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 Recuperação de Desastres Geográficos de uma rede virtual, veja Rede Virtual - Continuidade de 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

• Veja a referência de API REST do Recuperação de Desastre Geográfico aqui.
• Execute o exemplo de Recuperação de Desastre Geográfico no GitHub.
• Veja o exemplo de Recuperação de Desastre Geográfico que envia mensagens para um alias.

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