Replicação geográfica (visualização pública)

Há dois recursos que fornecem recuperação de desastres geográficos nos Hubs de Eventos do Azure.

• Recuperação de desastres geográficos (DR de metadados), que apenas fornece replicação de metadados.
• Replicação geográfica (visualização pública), que fornece replicação de metadados e dados.

Nota

O recurso de replicação geográfica é suportado apenas pela camada dedicada.

Esses recursos não devem ser confundidos com Zonas de disponibilidade. Ambos os recursos de recuperação geográfica fornecem resiliência entre regiões do Azure, como Leste dos EUA e Oeste dos EUA. O suporte à Zona de Disponibilidade fornece resiliência dentro de uma região geográfica específica, como o Leste dos EUA. Para obter mais informações sobre zonas de disponibilidade, consulte Suporte à zona de disponibilidade de Hubs de eventos.

Importante

• Esse recurso está atualmente em visualização pública e, como tal, não deve ser usado em cenários de produção.
• As seguintes regiões são atualmente suportadas na pré-visualização pública.

Region	Region	Region
AustráliaCentral	AlemanhaNorte	NoruegaOeste
AustráliaCentral2	AlemanhaWestCentral	PolóniaCentral
AustraliaEast	IsraelCentral	África do SulNorte
AustraliaSoutheast	ItáliaNorte	África do SulOeste
BrasilSudeste	JapanEast	SoutheastAsia
CanadaCentral	JapãoOeste	Sul da Índia
CanadáLeste	JioIndiaCentral	EspanhaCentral
CentralIndia	JioIndiaWest	SuéciaCentral
CentralUS	KoreaCentral	SwitzerlandNorth
CentralUSEUAP	CoreiaSul	SuíçaOeste
EastAsia	MéxicoCentral	UAECentral
EastUS2	NorthCentralUS	UAENorth
FranceCentral	Norte da Europa	UKSouth
FrançaSul	NorwayEast	UKWest

Recuperação de desastres de metadados versus replicação geográfica de metadados e dados

O recurso Metadata DR replica informações de configuração para um namespace de um namespace primário para um namespace secundário. Ele suporta um failover único para a região secundária. Durante o failover iniciado pelo cliente, o nome do alias para o namespace é redirecionado para o namespace secundário e, em seguida, o emparelhamento é quebrado. Nenhum dado é replicado além das informações de configuração nem as atribuições de permissão são replicadas.

O recurso de replicação geográfica mais recente replica informações de configuração e todos os dados de um namespace primário para um ou mais namespaces secundários. Quando um failover é executado, o secundário selecionado torna-se o primário e o primário anterior torna-se secundário. Os usuários podem executar um failover de volta ao primário original quando desejado.

O restante deste artigo se concentra no recurso de replicação geográfica. Para obter detalhes sobre o recurso de DR de metadados, consulte Recuperação de disater geográfico de Hubs de Eventos para metadados.

Georreplicação

A visualização pública do recurso de replicação geográfica é suportada para namespaces em clusters dedicados de dimensionamento de autoatendimento de Hubs de Eventos. Você pode usar o recurso com namespaces novos ou existentes em clusters de autoatendimento dedicados. Os seguintes recursos não são suportados com a replicação geográfica:

• Chaves gerenciadas pelo cliente (CMK)
• Identidade gerenciada para captura
• Recursos de rede virtual (pontos de extremidade de serviço ou pontos de extremidade privados)
• Suporte a mensagens grandes (agora em visualização pública)
• Transações Kafka (agora em pré-visualização pública)

Alguns dos principais aspetos da visualização pública da 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.
• FQDN (nome de domínio totalmente qualificado) de namespace estável – O FQDN não precisa ser alterado quando a promoção é executada.
• Consistência de replicação - Há duas configurações de consistência de replicação, síncrona e assíncrona.
• Promoção gerenciada pelo usuário de um secundário para ser o novo primário.

Mudar um secundário para ser um novo primário é feito de duas maneiras:

• Planejado: uma promoção do secundário para o primário, onde o tráfego não é processado até que o novo primário alcance todos os dados mantidos pela instância primária anterior.
• Forçado: como um failover onde o secundário se torna primário o mais rápido possível. O recurso de replicação geográfica replica todos os dados e metadados da região primária para as regiões secundárias selecionadas. O FQDN do namespace sempre aponta para a região primária.

Quando você inicia uma promoção de um secundário, o FQDN aponta para a região selecionada para ser a nova primária. A antiga primária torna-se então secundária. Você pode promover seu secundário para ser o novo principal por outros motivos que não um failover. Esses motivos podem incluir atualizações de aplicativos, testes de failover ou qualquer outra coisa. Nessas situações, é comum voltar atrás quando essas atividades são concluídas.

As regiões secundárias são adicionadas ou removidas a critério do cliente. Existem algumas limitações atuais que merecem ser notadas:

• Não há capacidade de oferecer suporte a exibições somente leitura em regiões secundárias.
• Não há recurso automático de promoção/failover. Todas as promoções são iniciadas pelo cliente.
• As regiões secundárias devem ser diferentes da região primária. Não é possível selecionar outro cluster dedicado na mesma região.
• Apenas um secundário é suportado para visualização pública.

Consistência da 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

Com a replicação assíncrona habilitada, todas as mensagens são confirmadas no primário e, em seguida, enviadas para o secundário. Os usuários podem configurar uma quantidade aceitável de tempo de atraso que o secundário tem para recuperar. Quando o atraso de um secundário ativo é maior do que a configuração de atraso do usuário, a região primária limita as solicitações de publicação de entrada.

Replicação síncrona

Quando a replicação síncrona está habilitada, os eventos publicados são replicados para o secundário, que deve confirmar a mensagem antes que ela seja confirmada no principal. Com a replicação síncrona, seu aplicativo publica na taxa necessária para publicar, replicar, reconhecer e confirmar. Isso também significa que seu aplicativo está vinculado à disponibilidade de ambas as regiões. Se a região secundária ficar inativa, as mensagens não poderão ser reconhecidas ou confirmadas.

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

Com replicação síncrona:

• A latência é maior devido à confirmação distribuída.
• A disponibilidade está ligada à disponibilidade de duas regiões. Se uma região ficar inativa, seu namespace não estará disponível.
• Os dados recebidos residem sempre em pelo menos duas regiões (apenas duas regiões suportadas na pré-visualização pública inicial).

A replicação síncrona oferece a maior garantia de que seus dados estão seguros. Se você tiver replicação síncrona, quando ela for confirmada, ela será confirmada em todas as regiões configuradas para replicação geográfica. No entanto, quando a replicação síncrona está habilitada, a disponibilidade do aplicativo pode ser reduzida devido à dependência da disponibilidade de ambas as regiões.

Habilitar a replicação assíncrona não afeta muito a latência e a disponibilidade do serviço não é afetada pela perda de uma região secundária. A replicação assíncrona não tem a garantia absoluta de que todas as regiões têm os dados antes de serem confirmados, como a replicação síncrona. Você também pode definir a quantidade de tempo que o secundário pode ficar fora de sincronia antes que o tráfego de entrada seja limitado. A configuração pode ser de 5 minutos a 1.440 minutos, que é um dia. Se você deseja usar regiões com uma grande distância entre elas, a replicação assíncrona é provavelmente a melhor opção para você.

A configuração da consistência da replicação pode ser alterada 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 você passar de síncrono para assíncrono, a latência e a disponibilidade do aplicativo melhorarão. Se você passar de assíncrono para síncrono, o secundário será configurado como síncrono depois que o atraso atingir zero. Se você estiver executando com um atraso contínuo por qualquer motivo, talvez seja necessário pausar seus editores para que o atraso chegue a zero e seu modo possa alternar para síncrono.

Os motivos gerais para habilitar a replicação síncrona estão ligados à importância dos dados, às necessidades específicas dos negócios ou aos motivos de conformidade. Se o seu objetivo principal for a disponibilidade do aplicativo em vez da garantia de dados, a consistência assíncrona é provavelmente a melhor escolha.

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 onde o recurso de replicação geográfica está habilitado. Você também precisa ter o cluster de Hubs de Eventos já existente nas regiões primária e secundária.

O recurso de replicação geográfica depende da capacidade de replicar eventos publicados 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 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 e confiabilidade, é 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 | Microsoft Learn.

Gerenciamento de replicação geográfica

O recurso de replicação geográfica permite configurar uma região secundária para replicar a configuração e os dados. Pode:

• Configurar replicação geográfica - As regiões secundárias podem ser configuradas em qualquer namespace existente em um cluster dedicado de autoatendimento em uma região com o conjunto de recursos de replicação geográfica habilitado. Ele também pode ser configurado durante a criação de namespace nos mesmos clusters dedicados. Para selecionar uma região secundária, você deve ter um cluster dedicado disponível nessa região secundária e a região secundária também deve ter o conjunto de recursos de replicação geográfica habilitado para essa região.
• Configurar a consistência da replicação - A replicação síncrona e assíncrona é definida quando a replicação geográfica é configurada, mas também pode ser comutada posteriormente. Com consistência assíncrona, você pode configurar a quantidade de tempo que uma região secundária pode atrasar.
• Disparar promoção/failover - Todas as promoções ou failovers são iniciadas pelo cliente. Durante a promoção, você pode optar por torná-la forçada desde o início, ou até mesmo mudar de ideia depois que uma promoção começar e torná-la forçada.
• Remover uma secundária - Se, a qualquer momento, pretender remover o emparelhamento geográfico entre regiões primárias e secundárias, pode fazê-lo e os dados na região secundária serão eliminados.

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 de eventos podem publicar dados em namespaces replicados geograficamente por meio do FQDN de namespace estável do namespace replicado geo. A abordagem de publicação de eventos é a mesma que o caso não-Geo DR e nenhuma alteração nos aplicativos cliente é necessária.

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

• Durante o período de cortesia de Failover, 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 do atraso de replicação, a carga de trabalho de entrada do editor 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 eventos podem consumir dados usando o FQDN de namespace estável de um namespace replicado geograficamente. As operações do consumidor não são suportadas, desde quando o failover é iniciado até a sua conclusão.

Gestão de Checkpointing/Offset

Os aplicativos que consomem eventos podem continuar a manter o gerenciamento de deslocamento como fariam com um único namespace.

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.

SDK de Hubs de Eventos/AMQP

Os clientes que usam o SDK de Hubs de Eventos precisam atualizar para a versão de abril de 2024 do SDK. A versão mais recente do SDK de Hubs de Eventos oferece suporte a failover com uma atualização para o ponto de verificação. O ponto de verificação é gerenciado por usuários com um armazenamento de ponto de verificação, como o armazenamento de Blob do Azure, ou uma solução de armazenamento personalizada. Se houver um failover, o armazenamento de pontos de verificação deve estar disponível na região secundária para que os clientes possam recuperar dados de pontos de verificação e evitar a perda de mensagens.

Preços

Os preços dos clusters dedicados dos Hubs de Eventos são calculados independentemente da replicação geográfica. 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. Os clusters dedicados usados como instâncias secundárias para replicação geográfica podem ser usados para outras cargas de trabalho. Há uma cobrança pela replicação geográfica com base na largura de banda publicada * o número de regiões secundárias. A taxa de replicação geográfica é dispensada na pré-visualização pública antecipada.

Conteúdos relacionados

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