Geo-replicação no Hubs de Eventos do Azure

A geo-replicação do Hubs de Eventos do Azure mantém cópias dos metadados do seu namespace (entidades, configuração e propriedades) e dos dados de eventos em múltiplas regiões do Azure. Se a sua região principal sofrer uma falha, pode promover uma região secundária para manter as suas aplicações de streaming a funcionar com perda mínima de dados.

As secções seguintes explicam como funciona a geo-replicação, comparam modos de replicação síncronos e assíncronos, e descrevem como gerir regiões secundárias.

A replicação geográfica garante que os metadados e os dados de um namespace sejam replicados continuamente de uma região primária para a região secundária. O namespace pode ser pensado como sendo estendido a mais de uma região, com uma região sendo a primária e a outra sendo a secundária.

A qualquer momento, a região secundária pode ser promovida para se tornar uma região primária. Ao promover um secundário, redireciona-se o FQDN (nome de domínio totalmente qualificado) do namespace para a região secundária selecionada, e a região primária anterior é rebaixada para uma região secundária.

Cenários

A geo-replicação dos Event Hubs pode ser usada em múltiplos cenários.

Continuidade de negócio e recuperação após desastre

A replicação geográfica garante a recuperação de desastres e a continuidade de negócios para todos os dados de streaming em seu namespace. Ao replicar dados entre regiões, as organizações podem se proteger contra perda de dados e garantir que seus aplicativos permaneçam operacionais mesmo no caso de uma interrupção regional. Esse recurso é crucial para aplicativos de missão crítica que exigem alta disponibilidade e tempo de inatividade mínimo.

Distribuição global de dados

A replicação geográfica pode ser usada para distribuir dados globalmente, permitindo que os aplicativos acessem dados da região mais próxima. Isso reduz a latência e melhora o desempenho de cargas de trabalho localizadas em diferentes partes do mundo.

Soberania e conformidade dos dados

Organizações que operam em múltiplos países ou regiões muitas vezes precisam de cumprir as leis de soberania de dados que exigem que os dados sejam armazenados dentro de limites geográficos específicos. A replicação geográfica permite que essas organizações repliquem dados para regiões que estão em conformidade com as regulamentações locais, garantindo que elas atendam aos requisitos legais e, ao mesmo tempo, mantenham uma plataforma de dados unificada.

Migração e upgrades

A replicação geográfica também pode ser usada para facilitar a migração, a manutenção e as atualizações do sistema de dados. As organizações podem migrar seu namespace proativamente de uma região primária para uma secundária para permitir qualquer manutenção e atualizações na região primária.

Conceitos básicos

A funcionalidade de geo-replicação utiliza um modelo de replicação primário-secundário para replicar metadados e dados. Em qualquer momento, existe uma única região principal que serve tanto produtores como consumidores. A região secundária funciona como uma região de reserva quente, por isso não podes interagir com a região secundária. No entanto, corre na mesma configuração da região principal, o que significa que pode assumir a função rapidamente após a promoção.

Alguns dos aspetos-chave da funcionalidade de geo-replicação são:

• Modelo de replicação primário-secundário – A geo-replicação é construída sobre um modelo primário-secundário, onde, num dado momento, existe apenas um namespace primário que serve os produtores e consumidores de eventos.
• Os Hubs de Eventos executam replicação byte-a-byte totalmente gerenciada de metadados, dados de eventos e deslocamento do consumidor entre secundários com os níveis de consistência configurados.
• Nome de host único do espaço de nomes - Depois de configurar com sucesso um espaço de nomes com geo-replicação habilitada, use o nome de host do espaço de nomes no seu aplicativo cliente. O nome do host se comporta de forma agnóstica das regiões primárias e secundárias configuradas e sempre aponta para a região primária.
• Quando inicias uma promoção, o hostname aponta para a região selecionada para ser a nova região principal. A antiga primária torna-se uma região secundária.
• Não se pode ler nem escrever nas regiões secundárias.
• Promoção gerenciada pelo cliente da região primária para a secundária, fornecendo total propriedade e visibilidade para resolução de interrupções. Estão disponíveis métricas, que podem ajudar a automatizar a promoção do lado do cliente.
• Podes adicionar ou remover regiões secundárias.
• Consistência de replicação - Estão disponíveis duas definições de consistência de replicação: síncrona e assíncrona.

Estado	Diagrama
Antes do failover (promoção do secundário)
Após o failover (promoção do secundário)

Modos de replicação

Estão disponíveis duas configurações de consistência de replicação: síncrona e assíncrona. Compreende as diferenças entre estas duas configurações porque afetam as suas aplicações e a consistência dos seus dados.

Replicação assíncrona

Quando utilizas replicação assíncrona, o primário faz commit de todos os pedidos e depois envia uma confirmação ao cliente. A replicação para as regiões secundárias acontece de forma assíncrona. Podes configurar a quantidade máxima aceitável de tempo de atraso – a diferença do lado do serviço entre as ações mais recentes nas regiões primária e secundária. O serviço replica continuamente os dados e metadados, garantindo que o atraso permaneça o menor possível. Se o atraso de um secundário ativo crescer além do atraso máximo de replicação configurado pelo usuário, o primário começará a limitar as solicitações de entrada.

Replicação síncrona

Quando se usa replicação síncrona, o sistema envia todos os pedidos para a localização secundária. A localização secundária confirma e valida a operação antes da localização principal se comprometer. Como resultado, a sua aplicação publica à velocidade necessária para publicar, replicar, reconhecer e comprometer. Este processo significa que a sua candidatura depende da disponibilidade de ambas as regiões. Se a região secundária atrasar ou não estiver disponível, a região primária não reconhece nem confirma mensagens e trava os pedidos recebidos.

Comparação da consistência da replicação

Com replicação síncrona :

• A latência é maior devido às operações de confirmação distribuídas.
• A disponibilidade depende da disponibilidade de duas regiões. Se uma região ficar inativa, seu namespace não estará disponível.

Por outro lado, a replicação síncrona oferece a maior garantia de que seus dados estão seguros. Com a replicação síncrona, os dados efetuam commits em todas as regiões que configurou para geo-replicação, oferecendo a máxima segurança de dados.

Com replicação assíncrona :

• A latência é minimamente afetada.
• A perda de uma região secundária não afeta imediatamente a disponibilidade. No entanto, a disponibilidade é afetada assim que o atraso máximo de replicação configurado é atingido.

Assim, não tem a garantia absoluta de que todas as regiões tenham os dados antes do commit, como acontece a replicação síncrona, e pode ocorrer perda ou duplicação de dados. No entanto, como já não é imediatamente afetado quando uma única região fica atrasada ou indisponível, a disponibilidade da aplicação melhora, além de ter uma latência mais baixa.

Pode alterar o modo de replicação depois de configurar a geo-replicação. Podes alternar de síncrono para assíncrono ou de assíncrono para síncrono. Se mudares de assíncrono para síncrono, a região secundária é configurada como síncrona depois de o lag atingir zero. Se estiveres a executar com um lag contínuo por qualquer motivo, poderás precisar de pausar os publicadores para que o lag atinja zero e permitir que o modo mude para síncrono. As razões para permitir a replicação síncrona, em vez da replicação assíncrona, estão ligadas à importância dos dados, necessidades específicas do negócio ou razões de conformidade, e não à disponibilidade da sua aplicação.

Seleção de região secundária

Para ativar a funcionalidade de geo-replicação, use as regiões primárias e secundárias onde a funcionalidade está ativada. A funcionalidade de geo-replicação depende da capacidade de replicar mensagens publicadas das regiões primárias para as secundárias. Se a região secundária estiver noutro continente, esta escolha tem um grande impacto no atraso de replicação da região primária para a secundária. Se estiveres a usar geo-replicação por razões de disponibilidade, escolhe regiões secundárias no mesmo continente sempre que possível. Para compreender melhor a latência induzida pela distância geográfica, veja Azure estatísticas de latência de ida e volta da rede.

Gerenciamento de replicação geográfica

A funcionalidade de geo-replicação permite-lhe configurar uma região secundária para a qual replicar metadados e dados. Assim, pode realizar as seguintes tarefas de gestão:

• Configurar geo-replicação - Pode configurar regiões secundárias em qualquer namespace novo ou existente numa região ativando a funcionalidade de geo-replicação.
• Configure a consistência da replicação - Defina a replicação síncrona e assíncrona quando configurar a geo-replicação. Também podes mudar esta definição mais tarde.
• Promoção de gatilho/failover - Todas as promoções são iniciadas pelo cliente.
• Remover uma região secundária - Se quiser remover uma região secundária, pode fazê-lo. Os dados na região secundária são eliminados.

Critérios para desencadear a promoção

Aqui estão alguns casos em que pode ser desencadeada uma promoção de um sistema secundário para um sistema principal.

• Interrupção regional: Se houver uma interrupção regional a afetar a região principal, promova a região secundária para garantir a continuidade do negócio e minimizar o tempo de inatividade.

• Atividades de manutenção: Durante as atividades de manutenção planeada na região primária, promover a região secundária pode ajudar a manter uma elevada disponibilidade para aplicações críticas à missão.

• Recuperação de desastres: No caso de um desastre que afete a região principal, promover a região secundária garante que os seus dados permaneçam acessíveis e que as suas aplicações continuam a funcionar.

• Problemas de desempenho: Se a região principal estiver a enfrentar problemas de desempenho que afetam a disponibilidade ou fiabilidade dos seus Centros de Eventos, promover a região secundária pode ajudar a mitigar esses problemas.

Ocasionalmente, teste mecanismos de failover para garantir que o plano de continuidade do negócio é eficaz e que as suas aplicações podem mudar facilmente para a região secundária quando necessário.

Monitorando a replicação de dados

Pode monitorizar o progresso do trabalho de replicação verificando a métrica de atraso de replicação nos registos de Métricas de Aplicação.

• Ative os registos de Métricas de Aplicação no espaço de nomes dos seus Event Hubs seguindo Monitoring Hubs de Eventos do Azure - Hubs de Eventos do Azure | Microsoft Aprende.

• Depois de ativar os registos de Métricas de Aplicação, produza e consuma dados do namespace durante alguns minutos antes de começar a ver os registos.

• Para visualizar os registos de Métricas de Aplicação, vá à secção de Monitorização da página de Centros de Eventos e selecione Registos no menu esquerdo. Use a consulta seguinte para encontrar o atraso de replicação (em segundos) entre os namespaces primário e secundário.

  AzureDiagnostics
    | where TimeGenerated > ago(1h)
    | where Category == "ApplicationMetricsLogs"
    | where ActivityName_s == "ReplicationLag"
  

• A coluna count_d mostra o atraso de replicação em segundos entre a região primária e a secundária.

Publicação de dados

As aplicações de publicação podem enviar dados para namespaces geo-replicados utilizando o hostname do namespace com geo-replicação ativa. A abordagem de publicação é a mesma do caso sem geo-replicação. Não precisas de fazer alterações aos SDKs do plano de dados ou às aplicações clientes.

A publicação de eventos pode não estar disponível durante as seguintes circunstâncias:

• Depois de solicitar a promoção de uma região secundária, a região primária existente rejeita quaisquer novos eventos publicados no hub de eventos.
• Quando o atraso de replicação entre as regiões primária e secundária atinge a duração máxima permitida, a carga de trabalho de entrada do publicador pode ser limitada.

Os aplicativos do Publisher não podem acessar diretamente nenhum namespace nas regiões secundárias.

Consumo de dados

As aplicações consumidoras podem consumir dados ao utilizar o hostname do espaço de nomes com a funcionalidade de geo-replicação ativada. As operações de consumo não são suportadas desde o início da promoção até ao fim da promoção.

Checkpointing e gestão de offset

Aplicações que consomem eventos podem manter a gestão de "offset" da mesma forma que o fazem com um "namespace" que não é geo-replicado. Namespaces com geo-replicação não precisam de consideração especial para a gestão de offsets.

Kafka

Os consumidores comprometem os offsets diretamente nos Event Hubs, e o sistema replica os offsets por várias regiões. Assim, os consumidores podem começar a consumir de onde pararam na região principal.

Aqui está uma lista de clientes Apache Kafka suportados:

Para outras bibliotecas, o suporte depende da versão da API:

SDK dos Centros de Eventos e AMQP

Para o AMQP, os utilizadores gerem o ponto de verificação usando um armazenamento de pontos de verificação, como o armazenamento Blob do Azure ou uma solução de armazenamento personalizada. Se houver um failover, a região secundária deve ter o armazenamento de ponto de verificação para que os clientes possam recuperar dados dos pontos de verificação e evitar a perda de dados das mensagens.

A versão mais recente do SDK do Event Hubs inclui alterações à representação dos pontos de controlo para suportar failovers. Use as versões mais recentes dos SDKs, mas também são suportadas versões anteriores dos seguintes SDKs.

Considerações

Não se esqueça das seguintes considerações:

• No planeamento da sua promoção, considere o fator tempo. Por exemplo, se você perder a conectividade por mais de 15 a 20 minutos, poderá decidir iniciar a promoção.
• Deves ensaiar a promoção de uma infraestrutura distribuída complexa pelo menos uma vez.

Preços

O preço varia consoante o nível escolhido, mas geralmente tem dois parâmetros:

• A taxa de computação para o cluster ou namespace.
• A taxa de largura de banda para os dados a ser replicados entre as regiões primária e secundária.

Clusters dedicados

Quando usa geo-replicação com clusters dedicados dos Event Hubs, precisa de pelo menos dois clusters dedicados em regiões separadas. Pode usar estes clusters para hospedar namespaces diferentes daquele que está a ser geo-replicado. Paga-se por estes clusters dedicados separadamente, com base no número de Unidades de Capacidade (CUs) atribuídas a cada um.

Quando ativas a geo-replicação, o único custo adicional é o custo de largura de banda para os dados replicados do primário para o secundário. Esta cobrança depende da localização da região primária.

Namespaces premium

Para os namespaces Premium, quando ativas a geo-replicação, obténs o mesmo número de unidades de processamento (PUs) na região secundária. Paga pelo número de PUs que usa e pela largura de banda dos dados transferidos entre a região primária e a secundária.

Por exemplo, se ativar a geo-replicação num namespace Premium que provisionou com 4 PUs, paga por

• 4 UPs na região primária,
• 4 UPs na região secundária,
• Cobrança de replicação geográfica por GB de dados replicados.

Pagas taxas de largura de banda com base nos dados transferidos entre as regiões primária e secundária.

Dispositivos de cálculo de preços

Os medidores de preços para a taxa de largura de banda de transferência de dados de geo-replicação apresentam os seguintes detalhes:

Terminais privados

Esta secção fornece considerações adicionais ao utilizar geo-replicação com namespaces que utilizam endpoints privados. Para informações gerais sobre o uso de endpoints privados com Event Hubs, veja Integrar Hubs de Eventos do Azure com Azure Private Link.

Quando implementas geo-replicação para um namespace de Event Hubs que usa endpoints privados, cria endpoints privados tanto para a região primária como para a secundária. Configure estes endpoints contra redes virtuais que alojam tanto instâncias primárias como secundárias da sua aplicação. Por exemplo, se você tiver duas redes virtuais, VNET-1 e VNET-2, precisará criar dois pontos de extremidade privados no namespace Hubs de Eventos, usando sub-redes de VNET-1 e VNET-2, respectivamente. Configure as redes virtuais com peering entre regiões, para que os clientes possam comunicar-se com qualquer um dos endpoints privados. Finalmente, gere o DNS para que todos os clientes recebam a informação DNS que aponta o endpoint do namespace (namespacename.servicebus.windows.net) para o endereço IP do endpoint privado na região primária atual.

Esta abordagem oferece o benefício de que o failover pode ocorrer independentemente na camada da aplicação ou no espaço de nomes Event Hubs:

• Failover exclusivo para aplicação: Neste cenário, a aplicação migra do VNET-1 para o VNET-2. Como os endereços privados estão configurados em VNET-1 e VNET-2 para os namespaces primários e os secundários, o aplicativo continua a funcionar sem interrupções.
• Failover apenas ao nível do namespace dos Event Hubs: Se o failover ocorrer apenas ao nível do namespace dos Event Hubs, a aplicação continua operacional porque os endpoints privados estão configurados em ambas as redes virtuais.

Ao seguir estas orientações, pode garantir mecanismos de failover robustos e fiáveis para os namespaces dos seus Event Hubs que utilizam endpoints privados.

Conteúdos relacionados

Para saber como usar o recurso de replicação geográfica, consulte Usar replicação geográfica.