Replicação geográfica dos Hubs de Eventos do Azure

O recurso de replicação geográfica de Hubs de Eventos fornece replicação de metadados (entidades, configuração e propriedades) e dados (cargas úteis de eventos) para o namespace, permitindo continuidade de negócios e recuperação de desastres.

Esse recurso garante que os metadados e 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 replicação geográfica dos Hubs de Eventos pode ser usada em vários cenários diferentes, conforme descrito aqui.

Garantindo a continuidade de negócios e a recuperação de desastres

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 de dados

As organizações que operam em vários países/regiões geralmente precisam 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

O recurso de replicação geográfica implementa metadados e replicação de dados em um modelo de replicação primário-secundário. Em um determinado momento, há uma única região primária, que está servindo tanto produtores quanto consumidores. A secundária atua como uma região de espera quente, o que significa que não é possível interagir com essas regiões secundárias. No entanto, eles são executados na mesma configuração da região principal, permitindo uma rápida elevação, estando prontos para intervir após a conclusão dessa elevação.

Alguns dos principais aspetos do recurso de replicação de dados geográficos são:

• Modelo de replicação primária-secundária – A replicação geográfica é construída no modelo de replicação primária-secundária, onde em um determinado momento há apenas um namespace primário que atende 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 de namespace único - Após a configuração bem-sucedida de um namespace habilitado para Geo-Replication, os usuários podem usar o nome de host do namespace em 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 um cliente inicia uma promoção, o nome do host 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 é possível ler ou 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. As regiões secundárias podem ser adicionadas ou removidas a critério do cliente.
• Consistência de replicação - Há duas configuraçõ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

Há duas configurações de consistência de replicação, síncrona e assíncrona. É importante conhecer as diferenças entre as duas configurações, pois elas têm impacto em seus aplicativos e na consistência dos dados.

Replicação assíncrona

Usando a replicação assíncrona, todas as solicitações são confirmadas no primário, após o que uma confirmação é enviada ao cliente. A replicação para as regiões secundárias acontece de forma assíncrona. Os utilizadores podem configurar a quantidade máxima aceitável de tempo de latência - a compensação no lado do serviço entre a ação mais recente 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

Usando a replicação síncrona, todas as solicitações são replicadas para o secundário, que deve confirmar e confirmar a operação antes de confirmar no primário. Como tal, a sua aplicação publica ao ritmo necessário para publicar, replicar, reconhecer e confirmar. Além disso, isso também significa que seu aplicativo está vinculado à disponibilidade de ambas as regiões. Se a região secundária estiver atrasada ou indisponível, as mensagens não serão reconhecidas e confirmadas, e a principal limitará as solicitações recebidas.

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 está ligada à 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. Se você tiver replicação síncrona, quando a confirmarmos, ela será confirmada em todas as regiões configuradas para Replicação Geográfica, fornecendo a melhor garantia 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 quando o atraso máximo de replicação configurado é atingido.

Como tal, ele não tem a garantia absoluta de que todas as regiões têm os dados antes de confirmá-los, como a replicação síncrona, e a perda ou duplicação de dados pode ocorrer. No entanto, como você não é mais afetado imediatamente quando uma única região fica atrasada ou indisponível, a disponibilidade do aplicativo melhora, além de ter uma latência menor.

O modo de replicação pode ser alterado após a configuração da Replicação Geográfica. Você pode ir de síncrono para assíncrono ou de assíncrono para síncrono. Se passar de assíncrono para síncrono, o secundário será configurado como síncrono depois de o atraso atingir zero. Se estiver a funcionar com um atraso contínuo por qualquer razão, talvez seja necessário pausar os seus publicadores para que o atraso chegue a zero e o seu modo possa passar para síncrono. Os motivos para habilitar a replicação síncrona, em vez da replicação assíncrona, estão ligados à importância dos dados, às necessidades específicas dos negócios ou aos motivos de conformidade, e não à disponibilidade do seu aplicativo.

Seleção de região secundária

Para habilitar o recurso de replicação geográfica, você precisa usar regiões primárias e secundárias onde o recurso está habilitado. O recurso de replicação geográfica depende da capacidade de replicar mensagens publicadas das regiões primária para a secundária. Se a região secundária estiver em outro continente, isso terá um grande impacto no atraso de replicação da região primária para a secundária. Se estiver usando a Replicação Geográfica por motivos de disponibilidade, é melhor que as regiões secundárias estejam pelo menos no mesmo continente, sempre que possível. Para entender melhor a latência induzida pela distância geográfica, você pode aprender mais com as estatísticas de latência de ida e volta da rede do Azure.

Gerenciamento de replicação geográfica

O recurso de replicação geográfica permite que os clientes configurem uma região secundária para a qual replicar metadados e dados. Como tal, os clientes podem executar as seguintes tarefas de gestão:

• Configurar replicação geográfica - As regiões secundárias podem ser configuradas em qualquer namespace novo ou existente em uma região com o recurso Geo-Replication habilitado.
• Configurar a consistência da replicação - A replicação síncrona e assíncrona é configurada quando se configura Geo-Replication, mas pode ser alterada posteriormente.
• Promoção de gatilho/failover - Todas as promoções são iniciadas pelo cliente.
• Remover uma região secundária - Se, a qualquer momento, pretender remover uma região secundária, pode fazê-lo após o que os dados na região secundária são eliminados.

Critérios para desencadear a promoção

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

• Interrupção regional: se houver uma interrupção regional que afete a região primária, você deve promover a região secundária para garantir a continuidade dos negócios e minimizar o tempo de inatividade.

• Atividades de manutenção: Durante as atividades de manutenção planejadas na região primária, a promoção da região secundária pode ajudar a manter a alta disponibilidade para aplicativos de missão crítica.

• Recuperação de desastres: no caso de um desastre que afete a região primária, promover a região secundária garante que seus dados permaneçam acessíveis e seus aplicativos continuem funcionando.

• Problemas de desempenho: se a região primária estiver enfrentando problemas de desempenho que afetam a disponibilidade ou a confiabilidade de seus Hubs de Eventos, promover a região secundária pode ajudar a mitigar esses problemas.

Recomenda-se testar ocasionalmente mecanismos de failover para garantir que o plano de continuidade de negócios seja eficaz e que seus aplicativos possam alternar perfeitamente para a região secundária quando necessário.

Monitorando a replicação de dados

Os usuários podem monitorar o progresso do trabalho de replicação monitorando a métrica de atraso de replicação nos logs do Application Metrics.

• Habilite os logs de Métricas de Aplicativo em seu namespace de Hubs de Eventos após o Monitoramento de Hubs de Eventos do Azure - Hubs de Eventos do Azure | Microsoft Learn.

• Depois que os logs do Application Metrics estiverem habilitados, você precisará produzir e consumir dados do namespace por alguns minutos antes de começar a ver os logs.

• Para exibir os logs de Métricas de Aplicativos, navegue até a seção Monitoramento da página Hubs de Eventos e selecione Logs no menu à esquerda. Você pode usar a consulta a seguir para localizar 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 indica o atraso de replicação em segundos entre a região primária e secundária.

Publicação de dados

Os aplicativos de publicação podem publicar dados em namespaces replicados geograficamente por meio do nome de host do namespace habilitado para replicação geográfica. A abordagem de publicação é a mesma que o caso de não-Replicação Geográfica e nenhuma alteração nos SDKs do plano de dados ou nos aplicativos cliente é necessária.

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.

Consumindo dados

Os aplicativos que consomem podem consumir dados usando o nome de host do namespace de um namespace com o recurso de replicação geográfica habilitado. As operações do consumidor não são suportadas a partir do momento em que a promoção é iniciada até que a promoção seja concluída.

Gestão de Pontos de Verificação/Deslocamento

Os aplicativos que consomem eventos podem continuar a manter o gerenciamento de deslocamento como fariam com um namespace não replicado geograficamente. Nenhuma consideração especial é necessária para a gestão de offset para namespaces ativados para replicação geográfica.

Kafka

As compensações são confirmadas diretamente nos Hubs de Eventos e as compensações são replicadas entre regiões. Portanto, os consumidores podem começar a consumir de onde pararam na região primária.

Aqui está a lista de clientes Apache Kafka que são suportados -

No caso de outras bibliotecas, as que usam as versões de API abaixo são suportadas -

SDK de Hubs de Eventos/AMQP

Para AMQP, o ponto de verificação é gerido por utilizadores através de um repositório de pontos de verificação, como o armazenamento Blob do Azure ou uma solução de armazenamento personalizada. Se ocorrer um failover, o armazenamento de pontos de verificação deve estar disponível na região secundária para que os clientes possam recuperar os dados dos pontos de verificação e evitar a perda de mensagens.

A versão mais recente do SDK de Hubs de Eventos fez algumas alterações na representação de pontos de verificação para oferecer suporte a failovers. Recomendamos o uso das versões mais recentes dos SDKs, mas as versões anteriores dos SDKs abaixo também são suportadas.

Considerações

Observe as seguintes considerações a ter em mente com esse recurso:

• No seu planejamento de promoção, 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 a promoção.
• A promoção de uma infraestrutura distribuída complexa deve ser ensaiada pelo menos uma vez.

Preços

O preço varia de acordo com o nível escolhido, mas geralmente tem 2 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

O uso da replicação geográfica com Hubs de Eventos dedicados exige que você tenha pelo menos dois clusters dedicados em regiões separadas, que podem ser usados para hospedar namespaces diferentes daquele que está sendo replicado geograficamente. Esses clusters dedicados são cobrados separadamente com base no número de Unidades de Capacidade (UCs) alocadas a cada um.

Quando a replicação geográfica está habilitada, a única cobrança adicional é a cobrança 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 namespaces Premium, habilitar a replicação geográfica provisiona o mesmo número de unidades de processamento (PUs) na região secundária. Assim, você paga pelo número de PUs que está usando e pela largura de banda dos dados transferidos entre a região primária e secundária.

Por exemplo, se você habilitar a replicação geográfica em um namespace Premium que tenha sido provisionado com 4 PU, você será cobrado 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.

A largura de banda é cobrada com base nos dados transferidos entre as regiões primária e secundária.

Medidores de Preços

Os medidores de preços para a cobrança pela largura de banda de transferência de dados replicados geograficamente serão exibidos com os seguintes detalhes:

Terminais privados

Esta seção fornece considerações adicionais ao usar Geo-Replication com namespaces que utilizam pontos de extremidade privados. Para obter informações gerais sobre como usar pontos de extremidade privados com o Azure Event Hubs, consulte Integrar o Azure Event Hubs com o Azure Private Link.

Ao implementar Geo-Replication para um namespace de Hubs de Eventos que usa pontos de extremidade privados, é importante criar pontos de extremidade privados para as regiões primária e secundária. Esses pontos de extremidade devem ser configurados em redes virtuais que hospedam instâncias primárias e secundárias do seu aplicativo. 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. Além disso, as VNETs devem ser configuradas com emparelhamento entre regiões, para que os clientes possam comunicar-se com qualquer um dos pontos de extremidade privados. Finalmente, o DNS precisa ser gerenciado de tal forma que todos os clientes obtenham as informações de DNS, que devem apontar o ponto de extremidade do namespace (namespacename.servicebus.windows.net) para o endereço IP do ponto de extremidade privado na região primária atual.

A vantagem desta abordagem é que o failover pode ocorrer independentemente na camada de aplicação ou no namespace do Hub de Eventos.

• Failover somente de aplicativo: nesse cenário, o aplicativo é movido de VNET-1 para 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 no namespace de Event Hubs: Da mesma forma, se o failover ocorrer apenas ao nível do namespace de Event Hubs, a aplicação permanecerá operacional porque os endpoints privados estão configurados em ambas as redes virtuais.

Seguindo estas diretrizes, pode garantir mecanismos de failover robustos e fiáveis para os seus namespaces de Hubs de Eventos, usando pontos finais privados.

Conteúdos relacionados

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