Hubs de Eventos do Azure – Recuperação de desastre geográfico

  • Artigo

Este artigo descreve o recurso de recuperação de desastres geográfica, que replica metadados e está em disponibilidade geral. Não descreve o recurso de replicação geográfica em visualização pública, que replica tanto dados quanto metadados. Para obter mais informações, consulte Replicação geográfica.

O modelo de cluster dos Hubs de Eventos do Azure totalmente ativo com suporte à zona de disponibilidade fornece resiliência contra interrupções de hardware e datacenter. No entanto, se ocorrer um desastre em que uma região inteira e todas as zonas se tornem indisponíveis, você poderá usar a recuperação de desastre geográfico para recuperar a carga de trabalho e a configuração do aplicativo. A recuperação de desastre geográfico garante que toda a configuração de um namespace (Hubs de Eventos, Grupos de Consumidores e configurações) seja replicada continuamente de um namespace primário para um secundário quando emparelhado.

O recurso de recuperação de desastre de área geográfica dos Hubs de Eventos do Azure é uma solução de recuperação de desastre. Os conceitos e o fluxo de trabalho descritos neste artigo se aplicam a cenários de desastre e não a interrupções temporárias. Para uma discussão detalhada sobre a recuperação de desastre no Microsoft Azure, consulte este artigo. Com a recuperação de desastre geográfico, você pode iniciar uma migração de failover única do primário para o secundário a qualquer momento. A migração de failover aponta para o namespace secundário o nome do alias escolhido para o namespace. Após a migração, o emparelhamento é removido. O failover é quase instantâneo depois de iniciado.

Importante

  • O recurso permite a continuidade instantânea de operações com a mesma configuração, mas não replica os dados de evento. A menos que o desastre tenha causado a perda de todas as zonas, os dados de evento preservados no Hub de Eventos primário após o failover serão recuperáveis e os eventos históricos poderão ser obtidos a partir daí quando o acesso for restaurado. Para replicar os dados de evento e operar namespaces correspondentes nas 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.
  • As atribuições de RBAC (controle de acesso baseado em função) do Microsoft Entra às entidades 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.

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 apenas para as camadas standard, premium e dedicada. 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.
  • 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 um 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 hubs de eventos e grupos de consumidores — e suas propriedades do serviço que estão associadas ao namespace. Somente entidades e suas configurações são replicadas automaticamente. Mensagens e eventos não são replicados.
  • Failover: o processo de ativação do namespace secundário.

Pares de namespace com suporte

Há suporte para as seguintes combinações de namespaces primários e secundários:

Camada de namespace primário Camada permitida de namespace secundário
Standard Padrão, dedicado
Premium Premium
Dedicado Dedicado

Importante

Não é possível emparelhar namespaces que estão no mesmo cluster dedicado. Você pode emparelhar namespaces que estão em clusters separados.

Instalação e fluxo de failover

A seção a seguir é uma visão geral do processo de failover e explica como configurar o failover inicial.

Captura de tela mostrando a visão geral do processo de failover.

Observação

O recurso de recuperação de desastre geográfico não dá suporte a failover automático.

Instalação

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.

  2. Crie o namespace secundário 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.

    Captura de tela mostrando a página de recuperação geográfica de um namespace do recurso Hubs de Eventos com o botão Iniciar Emparelhamento selecionado.

  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 é selecionado.
    2. Para alias, insira um alias para o emparelhamento de geo-dr.
    3. Em seguida, selecione Criar.

    Captura de tela mostrando a seleção do namespace secundário para o emparelhamento.

  6. Você deverá ver a página Alias de Geo-DR. Você também pode navegar até essa página no namespace primário selecionando Recuperação geográfica no menu esquerdo.

    Captura de tela mostrando a página Alias de Geo-DR (Recuperação de Desastres Geográfica) mostrando os namespaces primário e secundário.

  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.

  8. Nesta página de Visão geral, você pode executar as seguintes ações:

    1. Quebrar 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. Selecione Failover na barra de ferramentas.

      Captura de tela mostrando os menus Interromper Emparelhamento e Failover na página Alias de Geo-DR do Hubs de Eventos.

      Aviso

      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.

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, de modo que failovers automáticos raramente são possíveis, já que os failovers precisam ser executados em sincronia com o subsistema ou a infraestrutura restantes.

Exemplo

Em um exemplo desse cenário, considere uma solução de ponto de venda (PDV) que emita mensagens ou eventos. Os Hubs de Eventos transmitem esses eventos para uma solução de mapeamento ou de reformatação, que encaminha dados mapeado para outro sistema para processamento adicional. Nesse ponto, todos esses sistemas podem ser hospedados na mesma região do Azure. A decisão sobre quando fazer o failover e em qual parte depende do fluxo de dados na infraestrutura.

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.

Fluxo do failover

Se você iniciar o failover, as duas etapas são necessárias:

  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.

Imagem mostrando o fluxo de failover.

Failover manual

Esta seção mostra como fazer failover manualmente usando o portal do Azure, CLI, PowerShell, C# etc.

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

  2. Selecione Recuperação geográfica no menu esquerdo.

  3. Faça failover manualmente para o namespace secundário. Selecione Failover na barra de ferramentas.

    Aviso

    O failover ativará o namespace secundário e removerá o namespace primário do emparelhamento de recuperação de desastre geográfico. Crie outro namespace para ter um novo par de recuperação de desastre geográfico.

Gerenciamento

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

Considerações

Observe as seguintes considerações a serem lembradas:

  1. Por design, a recuperação de desastre geográfico dos Hubs de Eventos não replica dados e, portanto, você não pode reutilizar o valor de deslocamento antigo do hub de eventos primário no hub de eventos secundário. É recomendável reiniciar o receptor de eventos com um dos seguintes métodos:

    • EventPosition.FromStart() – se você quiser ler todos os dados em seu hub de eventos secundário.
    • EventPosition.FromEnd() – se você quiser ler todos os novos dados da hora da conexão com o hub de eventos secundário.
    • EventPosition.FromEnqueuedTime(dateTime) – se você desejar ler todos os dados recebidos em seu hub de eventos secundário a partir de uma determinada data e hora.

  2. 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.

  3. 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, mensagens programadas e novas duplicatas funcionarão.

  4. O failover de uma infraestrutura complexa distribuída deve ser testado pelo menos uma vez.

  5. A sincronização de entidades pode levar algum tempo, cerca de 50 a 100 entidades por minuto.

  6. Alguns aspectos do plano de gerenciamento do namespace secundário tornam-se somente leitura enquanto o emparelhamento de recuperação geográfica está ativo.

  7. O plano de dados do namespace secundário será somente leitura enquanto o emparelhamento de recuperação geográfica estiver ativo. O plano de dados do namespace secundário aceitará solicitações GET para habilitar a validação de controles de acesso e conectividade do cliente.

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 aprender a usar pontos de extremidade privados com Hubs de Eventos em geral, confira Configurar pontos de extremidade privados.

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á sucesso se os 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 um 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 nem se funcionará 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 iguais nos namespaces primário e secundário, envie uma solicitação de leitura (por exemplo: Obter Hub de Eventos) 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 o namespace primário e o 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.

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.

Ao criar uma configuração de recuperação de desastre para seu aplicativo e namespaces dos Hubs de Eventos, você deve criar pontos de extremidade privados para namespaces de Hubs de Eventos primários e secundários 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 e VNET-2, e os namespaces primários e secundários EventHubs-Namespace1-Primary e EventHubs-Namespace2-Secondary. Você precisa executar as seguintes etapas:

  • Em EventHubs-Namespace1-Primary, crie dois pontos de extremidade privados que usem sub-redes de VNET-1 e VNET-2
  • Em EventHubs-Namespace2-Secondary, crie dois pontos de extremidade privados que usem as mesmas sub-redes de VNET-1 e VNET-2

Pontos de extremidade privados e redes virtuais

A vantagem dessa abordagem é que o failover pode ocorrer na camada de aplicativo independente do namespace dos Hubs de Eventos. Considere os seguintes cenário:

Failover somente de aplicativo: aqui, o aplicativo não existirá no VNET-1, mas migrará para VNET-2. Como ambos os pontos de extremidade privados são configurados em VNET-1 e VNET-2 para os namespaces primários e secundários, o aplicativo funcionará normalmente.

Failover somente de namespace dos Hubs de Eventos: aqui, novamente, como os pontos de extremidade privados são configurados em ambas as redes virtuais para namespaces primários e secundários, o aplicativo simplesmente funcionará.

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 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.

Conteúdo relacionado

Revise os seguintes exemplos ou documentação de referência.