Partilhar via

Azure Event Hubs - Recuperação de desastres geográficos

  • Artigo

Este artigo descreve o recurso de recuperação de desastres geográficos que replica metadados e está disponível em geral. Ele não descreve o recurso de replicação geográfica de visualização pública, que replica dados e metadados. Para obter mais informações, consulte Replicação geográfica.

O modelo de cluster de 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 um desastre em que uma região inteira e todas as zonas não estiverem disponíveis, você poderá usar a recuperação de desastres geográficos para recuperar sua carga de trabalho e a configuração do aplicativo. A recuperação de desastres geográficos 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 namespace secundário quando emparelhado.

O recurso de recuperação de desastres geográficos dos Hubs de Eventos 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 temporárias. Para obter uma discussão detalhada sobre recuperação de desastres no Microsoft Azure, consulte este artigo. Com a recuperação de desastres geográficos, você pode iniciar uma mudança de failover única do primário para o secundário a qualquer momento. A movimentação de failover aponta o nome de alias escolhido para o namespace para o namespace secundário. Após a mudança, o emparelhamento é então removido. O failover é quase instantâneo uma vez iniciado.

Importante

  • O recurso permite a continuidade instantânea de operações com a mesma configuração, mas não replica os dados do evento. A menos que o desastre tenha causado a perda de todas as zonas, os dados de eventos preservados no Hub de Eventos principal após o failover serão recuperáveis e os eventos históricos poderão ser obtidos de lá assim que o acesso for restaurado. Para replicar dados de eventos 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.
  • 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.

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 os níveis padrão, premium e dedicado. 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.
  • Namespace primário/secundário: os namespaces que correspondem ao alias. O namespace primário está 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 hubs de eventos e grupos de consumidores e suas propriedades do serviço associadas ao namespace. Somente entidades e suas configurações são replicadas automaticamente. As mensagens e os eventos não são replicados.
  • Failover: O processo de ativação do namespace secundário.

Pares de namespace suportados

As seguintes combinações de namespaces primário e secundário são suportadas:

Camada de namespace principal Camada de namespace secundária permitida
Standard Padrão, Dedicado
Premium Premium
Dedicada Dedicada

Importante

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

Configuraçã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.

Nota

O recurso de recuperação de desastres geográficos não suporta um failover automático.

Configurar

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

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

    Captura de tela que mostra a página de Recuperação geográfica de um namespace de Hubs de Eventos com o botão Iniciar Emparelhamento selecionado.

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

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

  6. Você deve ver a página Geo-DR Alias . Você também pode navegar para esta página a partir do namespace principal selecionando Geo-recovery no menu à esquerda.

    Captura de tela que mostra a página Alias Geo-DR mostrando os namespaces primário e secundário.

  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.

  8. Nesta 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. Selecione Failover na barra de ferramentas.

      Captura de tela que mostra os menus Emparelhamento de Quebra e Failover na página Alias Geo-DR dos Hubs de Eventos.

      Aviso

      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.

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

Exemplo

Em um exemplo desse cenário, considere uma solução de Ponto de Venda (POS) que emite mensagens ou eventos. Os Hubs de Eventos passam esses eventos para alguma solução de mapeamento ou reformatação, que encaminha os dados mapeados para outro sistema para processamento posterior. Nesse ponto, todos esses sistemas podem estar hospedados na mesma região do Azure. A decisão de quando e qual parte fazer failover depende do fluxo de dados em sua infraestrutura.

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.

Fluxo de failover

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

  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.

Imagem mostrando o fluxo de failover.

Ativação pós-falha 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é seu namespace principal.

  2. Selecione Geo-recuperação no menu à esquerda.

  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 Geo-Disaster Recovery. Crie outro namespace para ter um novo par de recuperação de desastres geográficos.

Gestão

Se você cometeu um erro; Por exemplo, você emparelhou as regiões erradas durante a configuração inicial, você pode quebrar 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 ter em mente:

  1. Por design, a recuperação de desastres geográficos dos Hubs de Eventos não replica dados e, portanto, você não pode reutilizar o valor de deslocamento antigo do hub de eventos principal no hub de eventos secundário. Recomendamos reiniciar o recetor de eventos com um dos seguintes métodos:

    • EventPosition.FromStart() - Se desejar, leia todos os dados no seu hub de eventos secundário.
    • EventPosition.FromEnd() - Se você deseja ler todos os novos dados do momento da conexão com seu hub de eventos secundário.
    • EventPosition.FromEnqueuedTime(dateTime) - Se você deseja ler todos os dados recebidos em seu hub de eventos secundário a partir de uma determinada data e hora.

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

  3. O fato de nenhum dado ser replicado significa que as sessões ativas atuais não são replicadas. Além disso, a deteção de duplicados e mensagens agendadas podem não funcionar. Novas sessões, mensagens agendadas e novas duplicatas funcionarão.

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

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

  6. Alguns aspetos do plano de gerenciamento para o 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 da conectividade do cliente e dos controles de acesso.

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 Hubs de Eventos em geral, consulte 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 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 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 ou 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 de ponto de extremidade privado são as mesmas em namespaces primários e secundários, 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 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.

Ao criar uma configuração de recuperação de desastres para seu aplicativo e namespaces de 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 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ário e secundário: EventHubs-Namespace1-Primary, EventHubs-Namespace2-Secondary. Você precisa fazer as seguintes etapas:

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

Pontos finais privados e redes virtuais

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

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

Failover somente de namespace de Hubs de Eventos: 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 funcionará.

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

Conteúdos relacionados

Analise os exemplos ou a documentação de referência a seguir.