Partilhar via

Configurar a replicação geográfica passiva para instâncias do Cache Premium do Azure para Redis

  • Artigo

Neste artigo, você aprenderá a configurar a replicação geográfica passiva em um par de instâncias do Cache do Azure para Redis usando o portal do Azure.

A replicação geográfica passiva vincula duas instâncias do Cache do Azure para Redis de camada Premium e cria uma relação de replicação de dados ativo-passivo . Ativo-passivo significa que há um par de caches, primário e secundário, que têm seus dados sincronizados. Mas você só pode escrever para um lado do par, o primário. O outro lado do par, o cache secundário, é somente leitura.

Compare ativo-passivo com ativo-ativo, onde você pode gravar em ambos os lados do par e sincroniza com o outro lado.

Com a replicação geográfica passiva, as instâncias de cache normalmente estão localizadas em diferentes regiões do Azure, embora isso não seja necessário. Uma instância atua como primária e a outra como secundária. O primário lida com solicitações de leitura e gravação, e o primário propaga alterações para o secundário.

A ativação pós-falha não é automática. Para obter mais informações sobre como usar o failover, consulte Iniciar um failover de geoprimário para geosecundário.

Nota

A replicação geográfica passiva foi projetada como uma solução de recuperação de desastres.

Âmbito da disponibilidade

Escalão de serviço Básico, Standard Premium Empresa, Enterprise Flash
Disponível Não Sim Sim

A replicação geográfica passiva só está disponível na camada Premium do Cache do Azure para Redis. As camadas Enterprise e Enterprise Flash também oferecem replicação geográfica, mas essas camadas usam uma versão mais avançada chamada replicação geográfica ativa.

Pré-requisitos de replicação geográfica

Para configurar a replicação geográfica entre dois caches, os seguintes pré-requisitos devem ser atendidos:

  • Ambos os caches são caches de camada Premium.
  • Ambos os caches devem ter apenas uma réplica por primário por fragmento.
  • Ambos os caches estão na mesma assinatura do Azure.
  • O cache vinculado secundário tem o mesmo tamanho de cache ou um tamanho de cache maior do que o cache vinculado primário. Para usar o failover geográfico, ambos os caches devem ter o mesmo tamanho.
  • Ambos os caches são criados e em um estado de execução.
  • Ambos os caches estão executando a mesma versão do servidor Redis.

Nota

A transferência de dados entre regiões do Azure é cobrada a taxas de largura de banda padrão.

Alguns recursos não são compatíveis com a replicação geográfica:

  • A persistência não é suportada com a replicação geográfica.
  • Caches com mais de uma réplica não podem ser replicados geograficamente.
  • O clustering é suportado se ambos os caches tiverem clustering habilitado e tiverem o mesmo número de fragmentos.
  • Há suporte para caches na mesma rede virtual (VNet).
  • Caches em diferentes VNets são suportados com advertências. Consulte Posso usar a replicação geográfica com meus caches em uma VNet? para obter mais informações.

Depois que a replicação geográfica for configurada, as seguintes restrições se aplicam ao seu par de cache vinculado:

  • O cache vinculado secundário é somente leitura. Você pode ler a partir dele, mas não pode gravar nenhum dado nele. Se você optar por ler a partir da instância Geo-Secondary quando uma sincronização de dados completa estiver acontecendo entre o Geo-Primary e o Geo-Secondary, a instância Geo-Secondary lançará erros em qualquer operação Redis contra ela até que a sincronização completa de dados seja concluída. Os erros indicam que uma sincronização de dados completa está em andamento. Além disso, os erros são lançados quando Geo-Primary ou Geo-Secondary é atualizado e em alguns cenários de reinicialização. As aplicações de leitura do Geo-Secundário devem ser construídas para voltar ao Geo-Primário sempre que o Geo-Secundário estiver lançando tais erros.

  • Todos os dados que estavam no cache vinculado secundário antes do link ser adicionado são removidos. No entanto, se a replicação geográfica for removida posteriormente, os dados replicados permanecerão no cache vinculado secundário.

  • Não é possível dimensionar nenhum dos caches enquanto os caches estiverem vinculados.

  • Não é possível alterar o número de fragmentos se o cache tiver clustering habilitado.

  • Não é possível habilitar a persistência em nenhum dos caches.

  • Você pode exportar de qualquer cache.

  • Não é possível Importar para o cache vinculado secundário.

  • Não é possível excluir o cache vinculado ou o grupo de recursos que os contém até desvincular os caches. Para obter mais informações, consulte Por que a operação falhou quando tentei excluir meu cache vinculado?

  • Se os caches estiverem em regiões diferentes, os custos de saída da rede se aplicarão aos dados movidos entre regiões. Para obter mais informações, consulte Quanto custa replicar meus dados entre regiões do Azure?

  • A ativação pós-falha não é automática. Você deve iniciar o failover do cache vinculado primário para o secundário. Para obter mais informações sobre como usar o failover, consulte Iniciar um failover de geoprimário para geosecundário.

  • Não é possível adicionar links privados a caches que já estejam replicados geograficamente. Para adicionar uma ligação privada a uma cache georreplicada: 1. Desassocie a georreplicação. 2. Adicione uma Ligação Privada 3. Por último, volte a associar a georreplicação.

  1. Para vincular dois caches juntos para replicação geográfica, primeiro selecione Replicação geográfica no menu Recurso do cache que você pretende que seja o cache vinculado primário. Em seguida, selecione Adicionar link de replicação de cache no painel de trabalho.

    Captura de tela mostrando o menu de replicação geográfica do cache.

  2. Selecione o nome do cache secundário pretendido na lista Caches compatíveis. Se o cache secundário não for exibido na lista, verifique se os pré-requisitos de replicação geográfica para o cache secundário foram atendidos. Para filtrar os caches por região, selecione a região no mapa para exibir apenas esses caches na lista Caches compatíveis.

    Captura de tela mostrando caches compatíveis para vinculação com replicação geográfica.

    Você também pode iniciar o processo de vinculação ou exibir detalhes sobre o cache secundário usando o menu de contexto.

    Captura de tela mostrando o menu de contexto de replicação geográfica.

  3. Selecione Link para vincular os dois caches e iniciar o processo de replicação.

    Captura de tela mostrando como vincular caches para replicação geográfica.

  4. Você pode exibir o progresso do processo de replicação usando a replicação geográfica no menu Recurso.

    Captura de ecrã a mostrar o estado atual da Ligação.

    Você também pode exibir o status da vinculação usando Visão geral no menu Recurso para os caches primário e secundário.

    Captura de tela que destaca como exibir o status de vinculação para os caches primário e secundário.

    Quando o processo de replicação estiver concluído, o status de provisionamento de link será alterado para Succeeded.

    Captura de tela mostrando o status de vinculação de cache como Succeeded.

    O cache vinculado primário permanece disponível para uso durante o processo de vinculação. O cache vinculado secundário não estará disponível até que o processo de vinculação seja concluído.

URL geo-primário

Depois que os caches são vinculados, uma URL é gerada para cada cache que sempre aponta para o cache geoprimário. Se um failover for iniciado do geoprimário para o geosecundário, a URL permanecerá a mesma e o registro DNS subjacente será atualizado automaticamente para apontar para o novo geoprimário.

Captura de tela mostrando quatro URLs criadas adicionando replicação geográfica.

Três URLs são mostrados:

  • URL geo-primário é um URL proxy com o formato de <cachename>.geo.redis.cache.windows.net. A URL sempre aponta para qualquer cache no par de replicação geográfica que seja o geoprimário atual.
  • O Cache Primário Geográfico Atual é o endereço direto do cache que é atualmente o geoprimário. O endereço não geo.redis.cache.windows.neté redis.cache.windows.net . O endereço listado no campo muda se um failover for iniciado.
  • O Cache Secundário Geográfico Atual é o endereço direto do cache que é atualmente o geo-secundário. O endereço não geo.redis.cache.windows.neté redis.cache.windows.net . O endereço listado no campo muda se um failover for iniciado.

Iniciar um failover de geoprimário para geosecundário

Com uma seleção, você pode acionar um failover do geoprimário para o geosecundário.

Captura de tela de caches vinculados com Failover realçado.

Isso faz com que as seguintes etapas sejam tomadas:

  1. O cache geo-secundário é promovido para geo-primário.
  2. Os registros DNS são atualizados para redirecionar as URLs geoprimárias para a nova geoprimária.
  3. O cache geoprimário antigo é rebaixado para secundário e tenta formar um link para o novo cache geoprimário.

O processo de failover geográfico leva alguns minutos para ser concluído.

Configurações a serem verificadas antes de iniciar o failover geográfico

Quando o failover é iniciado, os caches geoprimário e geosecundário são trocados. Se o novo geoprimário estiver configurado de forma diferente do geosecundário, ele poderá criar problemas para seu aplicativo.

Certifique-se de verificar os seguintes itens:

  • Se estiver a utilizar uma firewall em qualquer uma das caches, certifique-se de que as definições da firewall são semelhantes para que não tenha problemas de ligação.
  • Verifique se ambos os caches estão usando a mesma porta e as mesmas configurações de TLS/SSL
  • Os caches geoprimário e geosecundário têm chaves de acesso diferentes. Se um failover for acionado, certifique-se de que seu aplicativo possa atualizar a chave de acesso que está usando para corresponder à nova geoprimária. Ou, use tokens Microsoft Entra para autenticação de cache, que permitem que você use a mesma credencial de autenticação para o cache geoprimário e geosecundário.

Failover com perda mínima de dados

Os eventos de failover geográfico podem introduzir inconsistências de dados durante a transição, especialmente se o cliente mantiver uma conexão com o geoprimário antigo durante o processo de failover. É possível minimizar a perda de dados em um evento de failover geográfico planejado usando as seguintes dicas:

  • Verifique a métrica de deslocamento de sincronização de dados de replicação geográfica. A métrica é emitida pelo cache geoprimário atual. Essa métrica indica a quantidade de dados que ainda precisam ser replicados para a geoprimária. Se possível, inicie o failover apenas se a métrica indicar que faltam menos de 14 bytes para serem gravados.
  • Execute o comando no geoprimário atual antes de iniciar o CLIENT PAUSE failover. A execução CLIENT PAUSE bloqueia quaisquer novas solicitações de gravação e, em vez disso, retorna falhas de tempo limite para o cliente Cache Redis do Azure. O CLIENT PAUSE comando requer o fornecimento de um período de tempo limite em milissegundos. Certifique-se de que um período de tempo limite suficientemente longo é fornecido para permitir que o failover ocorra. Definir o valor de pausa para cerca de 30 minutos (1.800.000 milissegundos) é um bom lugar para começar. Você sempre pode reduzir esse número conforme necessário.

Não há necessidade de executar o comando CLIENT UNPAUSE, pois o novo geo-primary mantém a pausa do cliente.

Nota

O uso da autenticação baseada em ID do Microsoft Entra para seu cache é recomendado em cenários de failover geográfico porque elimina a dificuldade de gerenciar diferentes chaves de acesso para o cache geoprimário e o cache geosecundário.

  1. Para remover o link entre dois caches e interromper a replicação geográfica, selecione Desvincular caches na replicação geográfica à esquerda.

    Captura de tela mostrando como desvincular caches.

    Quando o processo de desvinculação for concluído, o cache secundário estará disponível para leituras e gravações.

Nota

Quando o link de replicação geográfica é removido, os dados replicados do cache vinculado primário permanecem no cache secundário.

Perguntas frequentes sobre replicação geográfica

Posso usar a replicação geográfica com um cache de camada Standard ou Basic?

Não, a replicação geográfica passiva só está disponível na camada Premium. Uma versão mais avançada da replicação geográfica, chamada replicação geográfica ativa, está disponível na camada Enterprise e Enterprise Flash.

Meu cache está disponível para uso durante o processo de vinculação ou desvinculação?

  • O cache vinculado primário permanece disponível até que o processo de vinculação seja concluído.
  • O cache vinculado secundário não estará disponível até que o processo de vinculação seja concluído.
  • Ambos os caches permanecem disponíveis até que o processo de desvinculação seja concluído.

Quando posso escrever no novo geoprimário depois de iniciar o failover?

Quando o processo de failover é iniciado, você vê a atualização de status de provisionamento de link para Exclusão, o que indica que o link anterior está sendo limpo. Depois que isso for concluído, o status de provisionamento do link será atualizado para Criação. Isso indica que o novo geoprimário está em execução e tentando restabelecer um link de replicação geográfica para o cache geoprimário antigo. Neste ponto, você pode se conectar imediatamente à nova instância de cache geoprimário para leituras e gravações.

Sim, há várias métricas disponíveis para ajudar a acompanhar o status da replicação geográfica. Essas métricas estão disponíveis no portal do Azure.

  • Geo Replication Healthy mostra o status do link de replicação geográfica. O link será exibido como não íntegro se os caches geoprimário ou geosecundário estiverem inativos. Isso normalmente se deve a operações de correção padrão, mas também pode indicar uma situação de falha.
  • O Atraso de Conectividade de Replicação Geográfica mostra o tempo desde a última sincronização de dados bem-sucedida entre geoprimário e geosecundário.
  • O Deslocamento de Sincronização de Dados de Replicação Geográfica mostra a quantidade de dados que ainda precisam ser sincronizados com o cache geosecundário.
  • Geo Replication Fully Sync Event Started indica que uma ação de sincronização completa foi iniciada entre os caches geoprimário e geosecundário. Isso ocorre se a replicação padrão não puder acompanhar o número de novas gravações.
  • O evento de sincronização completa da replicação geográfica concluído indica que uma ação de sincronização completa foi concluída.

Há também uma pasta de trabalho pré-criada chamada Painel de Replicação Geográfica que inclui todas as métricas de integridade da replicação geográfica em uma exibição. O uso dessa exibição é recomendado porque agrega informações emitidas somente das instâncias de cache geoprimária ou geosecundária.

Não, você só pode vincular dois caches ao usar a replicação geográfica passiva. A replicação geográfica ativa suporta até cinco caches vinculados.

Não, ambos os caches devem estar na mesma assinatura do Azure.

Sim, desde que o cache vinculado secundário seja maior do que o cache vinculado primário. No entanto, você não pode usar o recurso de failover se os caches tiverem tamanhos diferentes.

Posso usar a replicação geográfica com clustering habilitado?

Sim, desde que ambos os caches tenham o mesmo número de fragmentos.

Posso usar a replicação geográfica com meus caches em uma rede virtual?

Recomendamos usar o Azure Private Link sobre injeção de VNet na maioria dos casos. Para obter mais informações, consulte Migrar de caches de injeção de VNet para caches de Link Privado.

Embora ainda seja tecnicamente possível usar a injeção de VNet ao replicar geograficamente seus caches, recomendamos o Azure Private Link.

Importante

O Cache Redis do Azure recomenda o uso do Azure Private Link, que simplifica a arquitetura de rede e protege a conexão entre pontos de extremidade no Azure. Pode ligar-se a uma instância da Cache do Azure a partir da rede virtual através de um ponto final privado, que é atribuído a um endereço IP privado numa sub-rede na rede virtual. O Azure Private Link é oferecido em todas as nossas camadas, inclui o suporte para o Azure Policy e a gestão simplificada de regras do NSG. Para saber mais, veja a Documentação do Private Link. Para migrar as caches injetadas da VNet para o Private Link, veja Migrar das caches de injeção da VNet para as caches do Private Link.

Para obter mais informações sobre o suporte à replicação geográfica com redes virtuais, consulte Replicação geográfica usando injeção de rede virtual com caches Premium.

Qual é o cronograma de replicação para a replicação geográfica do Redis?

A replicação é contínua e assíncrona. Isso não acontece em um horário específico. Todas as gravações feitas no primário são replicadas instantânea e assíncronamente no secundário.

Quanto tempo demora a replicação geográfica?

A replicação é incremental, assíncrona e contínua e o tempo gasto não é muito diferente da latência entre regiões. Em determinadas circunstâncias, o cache secundário pode ser solicitado para fazer uma sincronização completa dos dados do primário. O tempo de replicação, nesse caso, depende de muitos fatores, como: carga no cache primário, largura de banda de rede disponível e latência entre regiões. Descobrimos que o tempo de replicação para um par completo de 53 GB replicado geograficamente pode ser de 5 a 10 minutos. Você pode controlar a quantidade de dados que ainda precisam ser replicados usando a Geo Replication Data Sync Offset métrica no monitor do Azure.

O ponto de recuperação de replicação está garantido?

Para caches em um modo replicado geograficamente, a persistência está desabilitada. Se um par replicado geograficamente estiver desvinculado, como um failover iniciado pelo cliente, o cache vinculado secundário manterá seus dados sincronizados até esse ponto do tempo. Nestas situações, não é garantido qualquer ponto de recuperação.

Para obter um ponto de recuperação, exporte de qualquer cache. Mais tarde, você pode Importar para o cache vinculado primário.

Posso usar o PowerShell ou a CLI do Azure para gerenciar a replicação geográfica?

Sim, a replicação geográfica pode ser gerenciada usando o portal do Azure, o PowerShell ou a CLI do Azure. Para obter mais informações, consulte os documentos do PowerShell ou os documentos da CLI do Azure.

Quanto custa replicar meus dados entre regiões do Azure?

Quando você usa a replicação geográfica, os dados do cache vinculado primário são replicados para o cache vinculado secundário. Não há cobrança pela transferência de dados se os dois caches vinculados estiverem na mesma região. Se os dois caches vinculados estiverem em regiões diferentes, a taxa de transferência de dados será o custo de saída da rede dos dados que se movem em qualquer uma das regiões. Para obter mais informações, consulte Detalhes de preços de largura de banda.

Por que a operação falhou quando tentei excluir meu cache vinculado?

Os caches replicados geograficamente e seus grupos de recursos não podem ser excluídos enquanto vinculados até que você remova o link de replicação geográfica. Se você tentar excluir o grupo de recursos que contém um ou ambos os caches vinculados, os outros recursos do grupo de recursos serão excluídos, mas o grupo de recursos permanecerá no deleting estado e todos os caches vinculados no grupo de recursos permanecerão no running estado. Para excluir completamente o grupo de recursos e os caches vinculados dentro dele, desvincule os caches conforme descrito em Remover um link de replicação geográfica.

Que região devo usar para meu cache vinculado secundário?

Em geral, recomendamos que seu cache exista na mesma região do Azure que o aplicativo que o acessa. Para aplicativos com regiões primárias e de fallback separadas, recomendamos que seus caches primário e secundário existam nessas mesmas regiões. Para obter mais informações sobre regiões emparelhadas, consulte Práticas recomendadas – Regiões emparelhadas do Azure.

Posso configurar um firewall com replicação geográfica?

Sim, você pode configurar um firewall com replicação geográfica. Para que a replicação geográfica funcione ao lado de um firewall, verifique se o endereço IP do cache secundário foi adicionado às regras de firewall do cache primário. No entanto, se o acesso à rede pública estiver desativado no cache e apenas o Ponto de Extremidade Privado estiver habilitado, o uso do Firewall no cache não será suportado.

Próximos passos

Saiba mais sobre os recursos do Cache do Azure para Redis.