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

A replicação geográfica dos 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 várias regiões do Azure. Se sua região primária sofrer uma interrupção, você poderá promover uma região secundária para manter seus aplicativos de streaming em execução com perda mínima de dados.

As seções a seguir explicam como a replicação geográfica funciona, comparam os modos de replicação síncrona e assíncrona e descrevem como gerenciar 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 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.

Continuidade dos negócios e 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 de dados global

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 ou 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 usa um modelo de replicação primária-secundária para replicar metadados e dados. A qualquer momento, há uma única região primária que atende tanto produtores quanto consumidores. A região secundária atua como uma região de espera quente, portanto, você não pode interagir com a região secundária. No entanto, ela opera com a mesma configuração da região primária, o que significa que pode assumir rapidamente o controle após a promoção.

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

• Modelo de replicação primária-secundária – a replicação geográfica é criada em um modelo de replicação primário-secundário, em que, em um determinado momento, há apenas um namespace primário que atende aos produtores de eventos 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 – depois de configurar com êxito um namespace habilitado para replicação geográfica, use o nome do host do namespace em seu aplicativo cliente. 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 você 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.
• Você pode adicionar ou remover regiões secundárias.
• Consistência de replicação – duas configurações de consistência de replicação estão disponíveis: 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

Duas configurações de consistência de replicação estão disponíveis: síncrona e assíncrona. Entenda as diferenças entre essas duas configurações porque elas afetam seus aplicativos e sua consistência de dados.

Replicação assíncrona

Quando você usa a replicação assíncrona, o primário confirma todas as solicitações e envia uma confirmação ao cliente. A replicação para as regiões secundárias ocorre de maneira assíncrona. Você pode definir o tempo máximo de atraso aceitável — o desfasamento do lado do serviço entre a ação mais recente na região primária e na região 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

Quando você usa a replicação síncrona, o sistema envia todas as solicitações para o local secundário. O local secundário confirma a operação antes que o local primário a confirme. Consequentemente, sua aplicação publica na velocidade necessária para realizar as etapas de publicação, replicação, confirmação e confirmação definitiva. Esse processo significa que seu aplicativo depende da disponibilidade de ambas as regiões. Se a região secundária estiver atrasada ou não estiver disponível, a região primária não reconhecerá nem confirmará mensagens e reduzirá 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 depende da 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. Com a replicação síncrona, os dados são confirmados em todas as regiões configuradas para replicação geográfica, garantindo a máxima segurança dos dados.

Com a 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.

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

Você pode alterar o modo de replicação depois de configurar a replicação geográfica. Você pode alternar de síncrono para assíncrono ou de assíncrono para síncrono. Se você alternar de assíncrono para síncrono, a região secundária será configurada como síncrona após o atraso atingir zero. Se você estiver enfrentando um atraso contínuo por qualquer motivo, talvez seja necessário pausar seus editores até que o atraso chegue a zero e seu modo possa mudar para síncrono. Os motivos para habilitar a replicação síncrona, 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, use regiões primárias e secundárias em que o recurso está habilitado. O recurso de replicação geográfica depende de ser capaz de replicar mensagens publicadas do primário para as regiões secundárias. Se a região secundária estiver em outro continente, essa opção terá um grande impacto no atraso de replicação do primário para a região secundária. Se você estiver usando a replicação geográfica por motivos de disponibilidade, escolha regiões secundárias no mesmo continente sempre que possível. Para entender melhor a latência induzida pela distância geográfica, consulte Azure estatísticas de latência de ida e volta da rede.

Gerenciamento de replicação geográfica

O recurso de replicação geográfica permite configurar uma região secundária para a qual replicar metadados e dados. Dessa forma, você pode executar as seguintes tarefas de gerenciamento:

• Configurar a replicação geográfica – você pode configurar regiões secundárias em qualquer namespace novo ou existente em uma região habilitando o recurso de replicação geográfica.
• Configurar a consistência de replicação – Definir replicação síncrona e assíncrona ao configurar a replicação geográfica. Você também pode alternar essa configuração mais tarde.
• Disparar promoção/failover – todas as promoções são iniciadas pelo cliente.
• Remover uma região secundária – se você quiser remover uma região secundária, poderá fazê-lo. Os dados na região secundária são excluídos.

Critérios para disparar a promoção

Aqui estão alguns casos em que pode ocorrer a promoção de um nível secundário para o primário.

• Interrupção regional: se houver uma interrupção regional que afete a região primária, promova 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.

Ocasionalmente, teste os mecanismos de failover para garantir que o plano de continuidade dos negócios seja eficaz e seus aplicativos possam alternar perfeitamente para a região secundária quando necessário.

Monitorando a replicação de dados

Você pode monitorar o progresso do trabalho de replicação verificando a métrica de retardo de replicação nos logs de Métricas do Aplicativo.

• Ative os logs de métricas de aplicativos no seu namespace do Event Hubs seguindo as instruções em Monitoramento dos Hubs de Eventos do Azure Hubs - Hubs de Eventos do Azure | Microsoft Learn.

• Depois de ativar os registros de métricas de aplicativos, gere e utilize dados do namespace por alguns minutos antes de começar a ver os registros.

• Para exibir os logs de Métricas do Aplicativo, vá para a seção Monitoramento da página Hubs de Eventos e selecione Logs no menu à esquerda. Use 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 mostra o atraso de replicação em segundos entre a região primária e secundária.

Publicando dados

Os aplicativos de publicação podem enviar dados para 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. Você não precisa fazer nenhuma alteração em SDKs do plano de dados ou aplicativos cliente.

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.

Consumindo dados

Os aplicativos consumidores podem consumir dados utilizando o nome de host de um namespace cujo recurso de replicação geográfica esteja ativado. As operações de atendimento ao consumidor não são oferecidas desde o momento em que a promoção começa até que a promoção seja concluída.

Gerenciamento de pontos de verificação e deslocamento

Os aplicativos que consomem eventos podem gerenciar o deslocamento da mesma forma que fazem com um namespace sem replicação geográfica. Namespaces habilitados para replicação geográfica não precisam de consideração especial para o gerenciamento de offset.

Kafka

Os consumidores enviam os deslocamentos diretamente para os Hubs de Eventos, e o sistema replica esses deslocamentos entre as regiões. Portanto, os consumidores podem começar a consumir de onde pararam na região primária.

Aqui está uma lista de clientes do Apache Kafka com suporte:

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

SDK e AMQP do Hub de Eventos

No AMQP, os usuários gerenciam o ponto de verificação utilizando um repositório de pontos de verificação, como o Armazenamento de Blobs do Azure ou uma solução de armazenamento personalizada. Se ocorrer uma failover, a região secundária deve conter o armazenamento de pontos de verificação para que os clientes possam recuperar os dados desses pontos e evitar a perda de mensagens.

A versão mais recente do SDK dos Hubs de Eventos inclui alterações na representação dos pontos de verificação para oferecer suporte a failovers. Use as versões mais recentes dos SDKs, mas as versões anteriores dos seguintes SDKs também são compatíveis.

Considerações

Tenha em mente as seguintes considerações:

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

Preços

Os preços variam 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

Ao usar a replicação geográfica com clusters dedicados dos Hubs de Eventos, você precisará de pelo menos dois clusters dedicados em regiões separadas. Você pode usar esses clusters para hospedar namespaces diferentes dos que estão sendo replicados geograficamente. Você paga por esses clusters dedicados separadamente com base no número de CUs (Unidades de Capacidade) alocadas para cada um.

Quando você habilita a replicação geográfica, a única cobrança extra é a taxa de largura de banda para os dados replicados de primário para secundário. Esta cobrança depende da região primária.

Namespaces Premium

Para namespaces Premium, ao habilitar a replicação geográfica, você obtém o mesmo número de PUs (unidades de processamento) na região secundária. Você paga pelo número de PUs usadas e pela largura de banda dos dados transferidos entre a região primária e secundária.

Por exemplo, se você ativar a replicação geográfica em um namespace Premium que provisionou com 4 PUs, você pagará 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.

Você paga encargos de largura de banda com base nos dados transferidos entre as regiões primária e secundária.

Medidores de preços

Os medidores de preços relativos à cobrança pela largura de banda de transferência de dados da replicação geográfica aparecem com os seguintes detalhes:

Pontos de extremidade privados

Esta seção fornece considerações adicionais ao usar a replicação geográfica com namespaces que usam pontos de extremidade privados. Para obter informações gerais sobre como usar pontos de extremidade privados com Hubs de Eventos, consulte Integre o Hubs de Eventos do Azure com o Link Privado do Azure.

Ao implementar a replicação geográfica para um namespace dos Hubs de Eventos que usa pontos de extremidade privados, crie pontos de extremidade privados para as regiões primária e secundária. Configure esses endpoints em redes virtuais que abrigam tanto as instâncias primárias quanto as 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. Configura as redes virtuais com emparelhamento entre regiões, para que os clientes possam se comunicar com qualquer um dos endpoints privados. Por fim, gerencie o DNS para que todos os clientes obtenham as informações DNS que apontam 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.

Essa abordagem oferece o benefício de que o failover pode ocorrer independentemente na camada do aplicativo ou no namespace dos Hubs de Eventos:

• Failover de apenas um aplicativo: Nesse cenário, o aplicativo é transferido do VNET-1 para o 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: se o failover ocorrer apenas no nível do namespace dos Hubs de Eventos, o aplicativo permanecerá operacional, pois os pontos de extremidade privados estã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 que usam 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.