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

  • Artigo

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.

Os Hubs de Eventos do Azure espalham o risco de falhas catastróficas de máquinas individuais ou, até mesmo, de racks completos em clusters que abrangem vários domínios de falha em um data center. Eles implementam mecanismos de failover e de detecção de falha transparente, de modo que o serviço continuará a operar dentro dos níveis de serviço garantidos e, normalmente, sem interrupções perceptíveis quando da ocorrência de tais falhas. Se você criar um namespace dos Hubs de Eventos com zonas de disponibilidade habilitadas, isso reduz ainda mais o risco de interrupção e habilita a alta disponibilidade. Com as zonas de disponibilidade, o risco de interrupção é distribuído em três instalações fisicamente separadas, e o serviço terá reservas de capacidade suficientes para lidar instantaneamente com a perda total e catastrófica de uma instalação completa.

O modelo de cluster ativo dos Hubs de Eventos do Azure com suporte à zona de disponibilidade fornece resiliência contra graves falhas 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 dos Hubs de Eventos 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 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 namespace secundário quando emparelhado, além de permitir que você inicie um failover somente uma vez, do primário para o secundário a qualquer momento. A movimentação de failover reapontará o nome do alias escolhido para o namespace para o namespace secundário e, em seguida, interromperá o emparelhamento. 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.

Interrupções e desastres

É importante observar a distinção entre "interrupção" e "desastres". Uma interrupção é a indisponibilidade temporária dos Hubs de Eventos 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 for corrigido, os Hubs de Eventos ficarão disponíveis 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 dos Hubs de Eventos, 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 inativo 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 poderão ser recuperadas depois que do backup do data center.

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 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 apenas para os SKUs padrão, premium e dedicado. 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 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 os grupos de consumidores; e suas propriedades do serviço que sã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

Observação

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.

Image showing the overview of failover process

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.

    Initiate pairing from the primary namespace

  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.

    Select the secondary namespace

  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.

    Geo-DR alias page

  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.

      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.

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.

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.

Image showing the failover flow

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 os dados e, portanto, você não pode reutilizar o valor de deslocamento antigo do seu hub de eventos primário em seu 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 mensagens programadas 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.

Zonas de Disponibilidades

Os Hubs de Eventos oferecem suporte às zonas de disponibilidade fornecendo locais isolados de falhas em uma região do Azure. O suporte a zonas de disponibilidade só está disponível em regiões do Azure com zonas de disponibilidade. Os metadados e os dados (eventos) são replicados nos datacenters da zona de disponibilidade.

Ao criar um namespace, você vê a seguinte mensagem realçada quando seleciona uma região com zonas de disponibilidade.

Image showing the Create Namespace page with region that has availability zones

Observação

Quando você usa o portal do Azure, a redundância de zona por meio do suporte para zonas de disponibilidade é habilitada automaticamente. Não é possível desabilitar isso no portal. Você pode usar o comando az eventhubs namespace da CLI do Azure com --zone-redundant=false ou usar o comando New-AzEventHubNamespace do PowerShell com -ZoneRedundant=false para criar um namespace com redundância de zona desabilitada.

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, além destes namespaces primários e secundários: EventHubs-Namespace1-Primary, EventHubs-Namespace2-Secondary. Você precisa executar 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

Private endpoints and virtual networks

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á na VNET-1, mas mudará para VNET-2. Uma vez que ambos os pontos de extremidade privados estão configurados tanto na VNET-1 quanto na VNET-2 para os namespaces primário e secundário, o aplicativo simplesmente funcionará.

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.

Próximas etapas

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