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

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

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

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

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

O failover não é automático. Para obter mais informações sobre como usar o failover, confira o artigo Iniciar um failover da primária para a área geográfica secundária.

Observação

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

Escopo de disponibilidade

Camada Básico, Standard Premium Enterprise, Enterprise Flash
Disponível Não Sim Sim

A replicação geográfica passiva só está disponível na camada Premium de Cache do Azure para Redis. Os níveis Enterprise e Enterprise Flash também oferecem replicação geográfica, mas 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:

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

Observação

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

Alguns recursos não têm suporte com a replicação geográfica:

  • Não há suporte para a redundância de zona na replicação geográfica.
  • A persistência não tem suporte com a replicação geográfica.
  • Caches com mais de uma réplica não podem ser replicados geograficamente.
  • O clustering terá suporte se os dois caches tiverem o clustering habilitado e tiverem o mesmo número de fragmentos.
  • Há suporte para caches na mesma rede virtual (VNet).
  • Caches em diferentes VNets têm suporte com ressalvas. Consulte Posso usar a replicação geográfica com meus caches em uma VNets? para obter mais informações.

Depois de configurar a replicação geográfica, as seguintes restrições se aplicam para o par de caches vinculados:

  • O cache vinculado secundário é somente leitura. Você pode ler nele, mas não pode gravar nenhum dado nele. Se você optar por fazer a leitura da instância da área geográfica secundária quando uma sincronização completa de dados está acontecendo entre a área geográfica primária e a secundária, a instância da área geográfica secundária gerará erros em qualquer operação Redis até que a sincronização completa de dados seja concluída. Os erros afirmam que uma sincronização de dados completa está em andamento. Além disso, os erros são gerados quando a área geográfica primária ou a secundária é atualizada e em alguns cenários de reinicialização. Os aplicativos que leem a partir da Área Geográfica Secundária devem ser compilados para retornar à Área Geográfica Primária sempre que a Área Geográfica Secundária 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 escalar o cache enquanto os caches estiverem vinculados.

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

  • Você não pode habilitar a persistência em nenhum dos caches.

  • É possível Exportar de um dos caches.

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

  • Não é possível excluir o link vinculado, nem o grupo de recursos que o 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 serão aplicados aos dados movidos entre as regiões. Para obter mais informações, consulte Quanto custa para replicar meus dados entre regiões do Azure?

  • O failover não é automático. Você deve iniciar o failover do cache vinculado da área geográfica primária para o da área geográfica secundária. Para obter mais informações sobre como usar o failover, confira o artigo Iniciar um failover da primária para a área geográfica secundária.

  • Links privados não podem ser adicionados a caches que já são replicados geograficamente. Para adicionar um link privado a um cache replicado geograficamente: 1. Desvincule a replicação geográfica. 2. Adicione um Link Privado. 3. Por fim, vincule novamente a replicação geográfica.

  1. Para vincular dois caches para replicação geográfica, selecione Replicação geográfica no menu de Recursos do cache no qual se pretende que o cache vinculado primário esteja. Em seguida, selecione Adicionar link de replicação de cache do painel de trabalho.

    Screenshot showing the cache's Geo-replication menu.

  2. Escolha o nome do cache secundário pretendido na lista de 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 os caches da lista Caches compatíveis.

    Screenshot showing compatible caches for linking with geo-replication.

    Também é possível iniciar o processo de vinculação ou exibir detalhes sobre o cache secundário por meio do menu de contexto.

    Screenshot showing the Geo-replication context menu.

  3. Escolha Vincular para vincular dois caches e iniciar o processo de replicação.

    Screenshot showing how to link caches for geo-replication.

  4. Você pode conferir o andamento do processo de replicação usando a opção Replicação Geográfica no menu Recursos.

    Screenshot showing the current Linking status.

    Você pode também conferir o status da vinculação usando a Visão Geral dos caches das áreas geográficas primária e secundária.

    Screenshot that highlights how to view the linking status for the primary and secondary caches.

    Quando o processo de replicação estiver concluído, o Status de provisionamento da vinculação será alterado para Bem-Sucedido.

    Screenshot showing cache linking status as Succeeded.

    O cache vinculado primário permanece disponível para uso durante o processo de vinculação. O cache vinculado secundário somente estará disponível após o processo de vinculação ser concluído.

URL da área geográfica primária

Após os caches terem sido vinculados, é gerado um URL para cada cache, que sempre aponta para o cache da área geográfica primária. Se um failover for iniciado do primário geográfico para o secundário geográfico, a URL permanecerá igual e o registro DNS subjacente será atualizado automaticamente para apontar para o novo primário geográfico.

Screenshot showing four URLs created by adding geo-replication.

Três URLs são mostrados:

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

Como iniciar um failover da área geográfica primária para a área geográfica secundária

Com uma opção selecionada, você pode disparar um failover da área geográfica primária para a área geográfica secundária.

Screenshot of linked caches with Failover highlighted.

Isso faz com que as seguintes etapas sejam executadas:

  1. O cache geográfico secundário é promovido para primário geográfico.
  2. Os registros DNS são atualizados para redirecionar as URLs primárias geográficas para o novo primário geográfico.
  3. O cache primário geográfico antigo é rebaixado para secundário e tenta formar um link para o novo cache primário geográfico.

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 for iniciado, os caches de área geográfica primária e área geográfica secundária são trocados. Se o novo primário geográfico for configurado de modo diferente do secundário geográfico, isso poderá criar problemas para seu aplicativo.

Verifique os seguintes itens primeiro:

  • Se você estiver usando um firewall em qualquer um dos caches, verifique se as configurações de firewall são semelhantes para que não haja problemas de conexão.
  • Verifique se os dois caches estão usando as mesmas configurações de porta e TLS/SSL
  • Os caches geográfico-primário e geográfico secundário têm chaves de acesso diferentes. No caso de um failover ser disparado, certifique-se de que o aplicativo pode atualizar a chave de acesso que estiver usando para corresponder à nova área geográfica primária. Ou use os tokens do Microsoft Entra para autenticação de cache, que permitem usar a mesma credencial de autenticação para o cache geoprincipal e o geosecundário.

Failover com perda mínima de dados

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 primário geográfico 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 primário geográfico atual. Essa métrica indica quantos dados ainda não foram replicados para o primário geográfico. Se possível, apenas inicie o failover se a métrica indicar que menos de 14 bytes permanecerão para serem gravados.
  • Execute o comando CLIENT PAUSE no primário geográfico atual antes de iniciar o failover. A execução de CLIENT PAUSE bloqueia todas as novas solicitações de gravação e, em vez disso, retorna falhas de tempo limite para o cliente Cache do Azure para Redis. O comando CLIENT PAUSE requer fornecer um período de tempo limite em milissegundos. Verifique se um período de tempo limite suficiente é fornecido para permitir que o failover ocorra. Definir esse valor de pausa como cerca de 30 minutos (1,8 milhão de milissegundos) é um bom ponto de partida. Você sempre pode reduzir esse número conforme necessário.

Não é preciso executar o comando CLIENT UNPAUSE, pois o novo primário geográfico mantém a pausa do cliente.

Observação

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

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

    Screenshot showing how to unlink caches.

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

Observação

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

Perguntas frequentes de replicação geográfica

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

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 nas camadas Enterprise e Enterprise Flash.

O 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 somente estará disponível após o processo de vinculação ser concluído.
  • Os caches permanecem disponíveis até que o processo de desvinculação seja concluído.

Quando posso gravar na nova área geográfica primária após iniciar o failover?

Quando o processo de failover for iniciado, você verá o status de provisionamento da vinculação ser atualizado para Excluindo, o que indica que o vínculo anterior está sendo apagado. Quando for concluído, o status de provisionamento da vinculação atualiza para Criando. Isso indica que a nova área geográfica primária está ativa e tentando reestabelecer uma vinculação de replicação geográfica para o cache da área geográfica primária antiga. Neste momento, você conseguirá se conectar imediatamente com a instância de cache da nova área geográfica primária tanto para ler quanto para gravar.

Sim, existem 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.

  • Replicação Geográfica Íntegra mostra o status do link de replicação geográfica. A vinculação será mostrada como não íntegra se os caches da área geográfica primária ou área geográfica secundária estiverem inativos. Normalmente, isso ocorre devido a operações de aplicação de patch padrão, mas também pode indicar uma situação de falha.
  • Retardo de Conectividade de Replicação Geográfica mostra o tempo desde a última sincronização de dados bem-sucedida entre o primário geográfico e o secundário geográfico.
  • Deslocamento de Sincronização de Dados de Replicação Geográfica mostra a quantidade de dados que ainda não foram sincronizados com o cache geográfico secundário.
  • Evento de Sincronização Completa de Replicação Geográfica Iniciado indica que uma ação de sincronização completa foi iniciada entre os caches primário geográfico e secundário geográfico. Isso ocorrerá se a replicação padrão não puder acompanhar o número de novas gravações.
  • Evento de Sincronização Completa de Replicação Geográfica concluído indica que uma ação de sincronização completa foi concluída.

Existe também uma pasta de trabalho pré-configurada intitulada Painel de Controle de Replicação Geográfica que inclui todas as métricas de integridade de replicação geográfica em uma única visualização. O uso dessa visualização é recomendado porque ela agrega informações emitidas exclusivamente pelas instâncias de cache da área geográfica primária ou da área geográfica secundária.

Não. Quando estiver usando a replicação geográfica passiva, você só pode vincular dois caches. A replicação geográfica ativa dá suporte a até cinco caches vinculados.

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

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

Posso usar a replicação geográfica com o 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 VNet?

É recomendável usar o Link Privado do Azure por injeção de VNet na maioria dos casos. Para obter mais informações, consulte Migrar dos caches de injeção de VNet para os caches de Link Privado.

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

Importante

Cache do Azure para Redis recomenda o uso do Link Privado do Azure, que simplifica a arquitetura de rede e protege a conexão entre os pontos de extremidade no Azure. Você pode se conectar a uma instância de cache do Azure a partir da sua rede virtual por meio de um ponto de extremidade privado, que é atribuído a um endereço IP privado em uma sub-rede dentro da rede virtual. Os Links Privados do Azure são oferecidos em todas as nossas camadas, incluem o suporte do Azure Policy e gerenciamento simplificado de regras NSG. Para saber mais, consulte Documentação do Link Privado do Azure. Para migrar os caches injetados na sua VNet para o Link Privado, consulte Migrar de caches injetados na VNet para caches do Link Privado.

Para obter mais informações sobre o suporte para replicação geográfica com VNets, consulte Replicação geográfica usando injeção de VNet com caches Premium.

O que é o cronograma de replicação para replicação geográfica do Redis?

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

Quanto tempo leva a replicação de replicação geográfica?

A replicação é contínua, incremental e assíncrona e o tempo gasto não é muito diferente da latência entre regiões. Em determinadas circunstâncias, às vezes, o secundário pode precisar fazer uma sincronização completa dos dados do primário. O tempo de replicação nesse caso depende de muitos fatores como: a carga no cache primário, a largura de banda disponível e a latência inter-regional. O tempo de replicação estimado para um par completo de 53 GB com replicação geográfica pode ser entre 5 e 10 minutos. Você pode acompanhar a quantidade de dados que ainda não foram replicados usando a métrica Geo Replication Data Sync Offset no Azure Monitor.

O ponto de recuperação de replicação é garantido?

Para caches em um modo de replicação geográfica, a persistência é desabilitada. Se um par com replicação geográfica estiver desvinculado, como um failover iniciado pelo cliente, o cache vinculado secundário manterá seus dados sincronizados até aquele ponto de tempo. Nenhum ponto de recuperação é garantido nessas situações.

Para obter um ponto de recuperação, exporte de um dos caches. Posteriormente, será possível 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 a Documentação do PowerShell ou a Documentação da CLI do Azure.

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

Quando você usa a replicação geográfica, dados do cache vinculado primário são replicados para o cache vinculado secundário. Não há nenhum encargo para a transferência de dados se os dois caches vinculados estiverem na mesma região. Se os dois caches vinculados estiverem em regiões diferentes, o encargo de transferência de dados será o custo de saída de rede da movimentação de dados em qualquer região. Para obter mais informações, consulte Detalhes de preço 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 estiverem vinculados até seja removido o link de replicação geográfica. Se você tentar excluir o grupo de recursos que contém um ou ambos os caches vinculados, outros recursos no grupo de recursos serão excluídos, mas o grupo de recursos permanecerá no estado deleting e quaisquer caches vinculados no grupo de recursos permanecerão no estado running. Para concluir a exclusão do grupo de recursos e os caches vinculados dentro dele, interrompa o vínculo de replicação geográfica conforme descrito em Remover um link de replicação geográfica.

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

Em geral, é recomendável que o 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, é recomendável que os caches primário e secundário existam nas mesmas regiões. Para obter mais informações sobre regiões emparelhadas, consulte Melhores práticas – regiões emparelhadas do Azure.

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

Sim, é possível configurar um firewall com a replicação geográfica. Para que a replicação geográfica funcione junto com 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 desabilitado no cache e apenas o Ponto de Extremidade Privado estiver habilitado, o uso do Firewall no cache não terá suporte.

Próximas etapas

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