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

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

Esse recurso 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 considerado como sendo estendido para 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. A promoção de um ponto secundário indica o FQDN do namespace (nome de domínio totalmente qualificado) 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 dos negócios e a recuperação de desastres

A replicação geográfica garante a recuperação de desastres e a continuidade dos negócios para todos os dados de streaming em seu namespace. Ao replicar dados entre regiões, as organizações podem proteger contra perda de dados e garantir que seus aplicativos permaneçam operacionais mesmo em caso de interrupção regional. Esse recurso é crucial para aplicativos críticos 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 estejam 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 atualizações

A replicação geográfica também pode ser usada para facilitar a migração de dados, a manutenção e as atualizações do sistema. 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ária-secundária. Em um determinado momento há apenas uma região primária, que está atendendo produtores e consumidores. A secundária atua como uma região de espera de acesso frequente, o que significa que não é possível interagir com essas regiões secundárias. No entanto, elas são executadas na mesma configuração que a região primária, permitindo uma promoção rápida, pronta para intervir após a conclusão da promoção.

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

• Modelo de replicação primário-secundário: A replicação geográfica é construída no modelo de replicação primário-secundário, no qual, em um determinado momento, há apenas um namespace primário que atende os produtores e consumidores de eventos.
• Os Hubs de Eventos executam replicação totalmente gerenciada de byte a byte de metadados, dados de eventos e deslocamento do consumidor entre secundários com os níveis de consistência configurados.
• Nome do host de namespace único — Após a configuração bem-sucedida de um namespace habilitado para replicação geográfica, os usuários poderão usar o nome do host do namespace no aplicativo cliente deles. O nome do host se comporta de maneira independente 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 primária. A antiga região primária se torna uma região secundária.
• Não é possível ler ou gravar 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 a resolução de interrupções. As métricas estão disponíveis, o que pode ajudar a automatizar a promoção do lado do cliente. 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	Diagramar
Antes do failover (promoção da secundária)
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 saber as diferenças entre as duas configurações, pois elas têm um impacto sobre seus aplicativos e sua consistência de dados.

Replicação assíncrona

Usando a replicação assíncrona, todas as solicitações são confirmadas no primário, após o qual uma confirmação é enviada ao cliente. A replicação para as regiões secundárias ocorre de maneira assíncrona. Os usuários podem configurar a quantidade máxima aceitável de tempo de retardo — o deslocamento do 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 aumentar além do atraso máximo de replicação configurado pelo usuário, o primário iniciará a limitação das solicitações de entrada.

Replicação síncrona

Usando a replicação síncrona, todas as solicitações são replicadas para a região secundária, que precisa fazer commit e confirmar a operação antes de se fazer commit na região primária. Dessa maneira, seu aplicativo publica na velocidade necessária para publicar, replicar, confirmar e fazer commit. Além disso, isso também significa que seu aplicativo está vinculado à disponibilidade de ambas as regiões. Se a região secundária ficar defasada ou não estiver disponível, as mensagens não serão reconhecidas e confirmadas e a região primária limitará as solicitações de entrada.

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

Com a replicação síncrona:

• A latência é maior devido às operações de commit distribuídas.
• A disponibilidade está vinculada à disponibilidade de duas regiões. Se uma região falhar, o namespace não estará disponível.

Por outro lado, a replicação síncrona fornece a maior garantia de que seus dados estão seguros. Se você tiver replicação síncrona, quando fizermos commit, ela será confirmada em todas as regiões configuradas para replicação geográfica, fornecendo a melhor garantia de dados.

Com a replicação assíncrona:

• A latência é afetada minimamente.
• 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.

Dessa forma, ela não fornece a garantia absoluta de que todas as regiões tenham os dados antes de fazer commit deles como ocorre na replicação síncrona, e podem ocorrer duplicação ou perda de dados. No entanto, como você não é mais afetado imediatamente quando apenas uma região fica indisponível ou não está disponí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 da replicação síncrona para assíncrona ou da replicação assíncrona para síncrona. Se você for da replicação assíncrona para síncrona, sua região secundária será configurada como síncrona depois que o retardo atingir zero. Se a execução estiver com um retardo contínuo por qualquer motivo, talvez seja necessário pausar seus publicadores para que o retardo chegue a zero e seu modo possa ser alternado para replicação síncrona. Os motivos para ter a replicação síncrona habilitada, em vez de replicação assíncrona, estão vinculados à importância dos dados, às necessidades comerciais específicas ou às razões de conformidade, em vez da disponibilidade do aplicativo.

Seleção de região secundária

Para habilitar o recurso de replicação geográfica, você precisa usar uma região primária e secundária em que o recurso esteja habilitado. O recurso de replicação geográfica depende da capacidade de replicar mensagens publicadas da região primária para a secundária. Se a região secundária estiver em outro continente, isso terá um grande impacto no retardo da replicação da região primária para a secundária. Se você 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 dados e metadados. Dessa forma, os clientes podem executar as seguintes tarefas de gerenciamento:

• Configurar a replicação geográfica – 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 de replicação – a replicação síncrona e assíncrona é definida quando Geo-Replication está configurada, mas também pode ser alternada posteriormente.
• Disparar promoção/failover – todas as promoções são iniciadas pelo cliente.
• Remover um secundário – se a qualquer momento você quiser remover uma região secundária, poderá fazê-lo depois que os dados na região secundária forem excluídos.

Critérios para disparar a promoção

Aqui estão alguns casos em que uma promoção de uma secundária para primária pode ser disparada.

• Interrupção regional: se houver uma interrupção regional que afete a região primária, você deverá 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, promover a região secundária pode ajudar a manter a alta disponibilidade para aplicativos críticos.

• Recuperação de desastre: no caso de um desastre afetar 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 dos Hubs de Eventos, promover a região secundária poderá ajudar a atenuar esses problemas.

É recomendável testar ocasionalmente mecanismos de failover para garantir que o plano de continuidade dos negócios seja eficaz e que seus aplicativos possam alternar diretamente 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 retardo de replicação nos logs de Métricas do Aplicativo.

• Habilitar logs de Métricas do Aplicativo no namespace dos Hubs de Eventos seguindo Monitoramento dos Hubs de Eventos – Hubs de Eventos do Azure | Microsoft Learn.

• Depois que os logs de Métricas do Aplicativo 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 do Aplicativo, 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 retardo 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 da replicação em segundos entre a região primária e a secundária.

Publicando dados

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

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

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

Os aplicativos do publicador não podem acessar diretamente namespaces nas regiões secundárias.

Consumir dados

O consumo de aplicativos pode consumir dados usando o nome do host do namespace de um namespace com o recurso de replicação geográfica habilitado. As operações do consumidor não têm suporte desde o momento em que a promoção é iniciada até que a promoção seja concluída.

Gerenciamento de deslocamento/ponto de verificação

Os aplicativos que consomem eventos podem continuar a manter o gerenciamento de deslocamento, pois eles fariam isso com um namespace não geográfico replicado. Nenhuma consideração especial é necessária para o gerenciamento de offset para namespaces com replicação geográfica ativada.

Kafka

Os deslocamentos são confirmados diretamente nos Hubs de Eventos e replicados entre regiões. Portanto, os consumidores podem começar a consumir de onde pararam na região primária.

Aqui estão a lista de clientes do Apache Kafka com suporte –

No caso de outras bibliotecas, há suporte para as versões da API abaixo –

SDK/AMQP dos Hubs de Eventos

Para AMQP, o ponto de verificação é gerenciado pelos usuários por meio de um armazenamento de ponto de verificação, como o Armazenamento de Blobs do Azure ou uma solução de armazenamento personalizada. Se houver um failover, o repositório de pontos de verificação deverá estar disponível na região secundária para que os clientes possam recuperar os dados do ponto de verificação e evitar a perda de mensagens.

A versão mais recente do SDK dos Hubs de Eventos fez algumas alterações na representação de ponto de verificação para dar suporte a failovers. É recomendável usar as versões mais recentes dos SDKs, mas também há suporte para versões anteriores dos SDKs abaixo.

Considerações

Observe as seguintes considerações para levar em conta este recurso:

• Em 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, você poderá decidir iniciar a promoção.
• A promoção de uma infraestrutura complexa distribuída deve ser testado pelo menos uma vez.

Preços

O preço varia de acordo com a camada que você escolher, mas geralmente tem dois parâmetros –

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

Clusters dedicados

O uso da replicação geográfica com Os 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 daqueles que estão sendo replicados geograficamente. Esses clusters dedicados são cobrados separadamente com base no número de CUs (Unidades de Capacidade) alocadas para cada um.

Quando a replicação geográfica está habilitada, a única cobrança adicional é a taxa de largura de banda para os dados replicados do primário para o secundário. Esta cobrança depende da região primária.

Namespaces Premium

Para namespaces Premium, habilitar a replicação geográfica provisiona o mesmo número de PUs (unidades de processamento) na região secundária. Portanto, 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 foi provisionado com 4 PU, você será cobrado por

• 4 PUs na região primária,
• 4 PUs 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 o custo de largura de banda de transferência de dados de replicação geográfica serão exibidos com os detalhes abaixo —

Pontos de extremidade 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 endpoints privados com Event Hubs, consulte Integrate Azure Event Hubs with Azure Private Link.

Ao implementar a Replicação Geográfica para um namespace dos 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 dos Hubs de Eventos, usando sub-redes da VNET-1 e VNET-2, respectivamente. Além disso, os VNETs devem ser configurados com emparelhamento entre regiões, para que os clientes possam se comunicar com qualquer um dos pontos de extremidade privados. Por fim, o DNS precisa ser gerenciado de forma que todos os clientes obtenham as informações 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 dessa abordagem é que o failover pode ocorrer independentemente na camada do aplicativo ou no namespace dos Hubs de Eventos:

• Failover somente de aplicativo: nesse cenário, o aplicativo passa de VNET-1 para VNET-2. Como os pontos de extremidade privados estão configurados em ambas as VNET-1 e VNET-2, para os namespaces primário e secundário, o aplicativo continua operando sem interrupções normalmente.
• Failover apenas no namespace dos Hubs de Eventos: da mesma forma, se o failover ocorrer somente no nível do namespace dos Hubs de Eventos, o aplicativo permanecerá operacional, pois os pontos de extremidade privados estarão configurados em ambas as redes virtuais.

Seguindo essas diretrizes, você pode garantir mecanismos de failover robustos e confiáveis para os namespaces dos Hubs de Eventos usando pontos de extremidade privados.

Conteúdo relacionado

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