Azure Event Hubs - Recuperação de desastres geográficos
A resiliência contra interrupções desastrosas de recursos de processamento de dados é um requisito para muitas empresas e, em alguns casos, até mesmo exigido pelas regulamentações do setor.
Os Hubs de Eventos do Azure já espalham o risco de falhas catastróficas de máquinas individuais ou até mesmo racks completos entre clusters que abrangem vários domínios de falha em um datacenter. Ele implementa mecanismos transparentes de deteção de falhas e failover, de modo que o serviço continue a operar dentro dos níveis de serviço garantidos e, normalmente, sem interrupções percetíveis no caso de tais falhas. Se você criar um namespace de Hubs de Eventos com zonas de disponibilidade habilitadas, reduzirá ainda mais o risco de interrupção e habilitará a alta disponibilidade. Com as zonas de disponibilidade, o risco de interrupção é ainda mais espalhado por três instalações fisicamente separadas, e o serviço tem reservas de capacidade suficientes para lidar instantaneamente com a perda completa e catastrófica de toda a instalação.
O modelo de cluster de Hubs de Eventos do Azure totalmente ativo com suporte à zona de disponibilidade fornece resiliência contra falhas graves de hardware e até mesmo perda catastrófica de instalações inteiras do datacenter. Ainda assim, pode haver situações graves com destruição física generalizada contra as quais mesmo essas medidas não podem se defender suficientemente.
O recurso de recuperação de desastres geográficos dos Hubs de Eventos foi projetado para facilitar a recuperação de um desastre dessa magnitude e abandonar definitivamente uma região do Azure com falha e sem precisar alterar as configurações do aplicativo. Abandonar uma região do Azure normalmente envolverá vários serviços e esse recurso visa principalmente ajudar a preservar a integridade da configuração do aplicativo composto.
O recurso de 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 e permite que você inicie uma mudança de failover única 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 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.
Interrupções e desastres
É importante notar a distinção entre "interrupções" 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 outros dados. Um exemplo dessa interrupção pode ser uma falha de energia no datacenter. Algumas interrupções são apenas perdas de conexão curtas devido a problemas transitórios ou de rede.
Um desastre é definido como a perda permanente ou de longo prazo de um cluster de Hubs de Eventos, região do Azure ou datacenter. A região ou o datacenter podem ou não ficar disponíveis novamente ou podem ficar inativos por horas ou dias. Exemplos de tais desastres são incêndios, inundações ou terremotos. Um desastre que se torna permanente pode causar a perda de algumas mensagens, eventos ou outros dados. No entanto, na maioria dos casos, não deve haver perda de dados e as mensagens podem ser recuperadas assim que o data center estiver em backup.
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 transitórias ou temporárias. Para obter uma discussão detalhada sobre recuperação de desastres no Microsoft Azure, consulte este artigo.
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 SKUs padrão, premium e dedicados. 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 principal é "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 |
Nota
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.
Configuração
Primeiro, crie ou use um namespace primário existente e um novo namespace secundário e, em seguida, emparelhe 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.
Crie o namespace principal.
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.
No portal do Azure, navegue até seu namespace principal.
Selecione Geo-recuperação no menu à esquerda e selecione Iniciar emparelhamento na barra de ferramentas.
Na página Iniciar emparelhamento, siga estes passos:
- Selecione um namespace secundário existente ou crie um em uma região diferente. Neste exemplo, um namespace existente é selecionado.
- Para Alias, insira um alias para o emparelhamento geo-dr.
- Em seguida, selecione Criar.
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.
Na página Alias 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 diretamente para o namespace principal/secundário.
Nesta página Visão geral , você pode executar as seguintes ações:
Quebre o emparelhamento entre namespaces primários e secundários. Selecione Quebrar emparelhamento na barra de ferramentas.
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.
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, 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:
Se ocorrer outra interrupção, você deseja poder falhar novamente. Portanto, configure outro namespace passivo e atualize o emparelhamento.
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.
Ativação pós-falha manual
Esta seção mostra como fazer failover manualmente usando o portal do Azure, CLI, PowerShell, C#, etc.
No portal do Azure, navegue até seu namespace principal.
Selecione Geo-recuperação no menu à esquerda.
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:
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.
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.
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.
O failover de uma infraestrutura distribuída complexa deve ser ensaiado pelo menos uma vez.
A sincronização de entidades pode levar algum tempo, aproximadamente 50-100 entidades por minuto.
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.
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.
Zonas de Disponibilidade
Os Hubs de Eventos dão suporte a Zonas de Disponibilidade, fornecendo locais isolados por 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 entre centros de dados na zona de disponibilidade.
Ao criar um namespace, você verá a seguinte mensagem realçada quando seleciona uma região com zonas de disponibilidade.
Nota
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 desativá-lo no portal. Você pode usar o comando da CLI do Azure com ou usar o comando az eventhubs namespaceNew-AzEventHubNamespace PowerShell com para criar um namespace com --zone-redundant=false-ZoneRedundant=false redundância de zona desabilitada.
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 o 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.
Configuração recomendada
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ários e secundários: EventHubs-Namespace1-Primary, EventHubs-Namespace2-Secondary. Você precisa fazer as seguintes etapas:
- Em EventHubs-Namespace1-Primary, crie dois pontos de extremidade privados que usam sub-redes de VNET-1 e VNET-2
- Em EventHubs-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 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á no VNET-1, mas será movido para o 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 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.
Próximos passos
Analise os exemplos ou a documentação de referência a seguir.