Configurar a replicação geográfica ativa para instâncias do Redis Gerenciado do Azure (versão prévia)

Artigo
11/19/2024

Neste artigo, você aprenderá a configurar um cache ativo replicado geograficamente usando o portal do Azure.

A replicação geográfica ativa agrupa até cinco instâncias do Redis Gerenciado do Azure (versão prévia) em um único cache que se estende por regiões do Azure. Todas as instâncias atuam como os caches primários locais. Um aplicativo decide qual instância ou instâncias usar para solicitações de leitura e gravação.

Observação

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

Como a replicação geográfica ativa funciona

A replicação geográfica ativa usa CRDTs (tipos de dados replicados sem conflito) para distribuir perfeitamente dados entre instâncias do Redis que podem ser distribuídas entre continentes. Essas instâncias são conectadas em uma configuração ativa-ativa, em que as gravações em uma instância são refletidas automaticamente nas outras instâncias no mesmo grupo de replicação geográfica. Essa replicação de dados bidirecional difere das abordagens de replicação ativa-passiva unidirecional, em que os dados são replicados do primário para uma réplica geográfica, mas não da outra direção. Essa é uma ferramenta poderosa que normalmente é usada de várias maneiras:

Fornecendo latência local distribuindo o cache mais próximo dos usuários. Usando uma rede de instâncias ativas do Redis replicadas geograficamente, você pode colocar os caches geograficamente mais próximos dos usuários em cada região, reduzindo a latência e melhorando o desempenho do aplicativo.
Sincronizando aplicativos globais. Como os caches replicados geograficamente aparecem como uma única instância do Redis, você pode distribuir dados globalmente sem precisar segmentar dados por regiões. Por exemplo, você pode usar um único conjunto classificado do Redis para fornecer um placar de líderes de jogos para usuários em todo o mundo, em vez de fornecer um placar de líderes separado para cada região geográfica.
Reduzindo o tempo de inatividade e o risco de interrupções regionais. Como cada instância do Redis no grupo de replicação geográfica está constantemente sendo atualizada com os dados mais recentes das outras instâncias do grupo, os dados são bem preservados no caso de uma interrupção regional. Os aplicativos podem alternar temporariamente para usar uma das outras instâncias do grupo e, quando a região voltar a ficar online, a instância do Redis será automaticamente recarregada com dados de outros caches replicados geograficamente.

Para obter uma análise mais detalhada de como a replicação geográfica ativa funciona, consulte a Distribuição geográfica Ativa-Ativa (baseada em CRDTS)

Escopo de disponibilidade

Camada	Otimizada para Memória, Balanceada, Computação Otimizada	Otimizada para Flash
Disponível	Sim (exceto B0 e B1)	Sim

Importante

Os SKUs B0 e B1 balanceadas não oferecem suporte à replicação geográfica ativa.

Pré-requisitos da replicação geográfica ativa

Existem algumas restrições ao usar a replicação geográfica ativa:

A replicação geográfica ativa só tem suporte quando o Redis Gerenciado do Azure está em uma configuração de alta disponibilidade (ou seja, está usando a replicação).
Somente os módulos RediSearch e RedisJSON são suportados
Na camada Otimizado para Flash, somente a política de despejo Nenhuma Remoção pode ser utilizada. Todas as políticas de remoção têm suporte nas outras camadas.
A persistência de dados não é suportada porque a replicação geográfica ativa fornece uma experiência superior.
Todos os caches em um grupo de replicação geográfica devem ter a mesma configuração. Por exemplo, todos os caches devem ter a mesma configuração de SKU, capacidade, política de remoção, política de clustering, módulos e TLS.
Se uma instância em um grupo de replicação geográfica for dimensionada, as outras instâncias desse grupo deverão ser dimensionadas para o mesmo tamanho antes que qualquer dimensionamento adicional possa ocorrer. Consulte Instâncias de dimensionamento em um grupo de replicação geográfica para obter mais informações.
Você não pode usar os comandos FLUSHALL e FLUSHDB do Redis ao usar a replicação geográfica ativa. A proibição dos comandos impede a exclusão não intencional de dados. Em vez disso, use a operação de liberação.

Criar ou ingressar em um grupo de replicação geográfica ativa

Ao criar um novo recurso Redis Gerenciado do Azure, selecione a guia Avançado. Conclua a primeira parte do formulário, incluindo a política de clustering. Para obter mais informações sobre como escolher a Política de clustering, consulte Clustering no Redis Gerenciado do Azure.
Selecione Configurar para configurar a Replicação geográfica ativa.
Crie um novo grupo de replicação para uma primeira instância de cache. Ou selecione um existente na lista.
Selecione Configurar para concluir.
Aguarde até que o primeiro cache seja criado com êxito. Quando concluído, você verá Configurado definido para Replicação geográfica ativa. Repita as etapas acima para cada instância de cache no grupo de replicação geográfica.

Adicionar uma instância existente a um grupo de replicação geográfica ativo

Para adicionar uma instância de cache existente a um grupo de replicação geográfica ativo, você pode usar a API REST para executar uma ação de vinculação forçada.

Todos os dados na instância de cache vinculada serão descartados. A instância também ficará temporariamente indisponível por vários minutos ao ingressar no grupo de replicação geográfica. O suporte ao portal e à CLI ainda não estão disponíveis para esse recurso.

Remover de um grupo de replicação geográfica ativa

Para remover uma instância de cache de um grupo de replicação geográfica ativa, basta excluir a instância. Em seguida, as instâncias restantes se reconfiguram automaticamente.

Forçar-desvincular se houver uma interrupção de região

A replicação geográfica ativa é um recurso poderoso para aumentar drasticamente a disponibilidade ao usar o Redis Gerenciado do Azure. No entanto, você deve tomar medidas para preparar seus caches se houver uma interrupção regional.

Por exemplo, considere estas dicas:

Identifique com antecedência para qual outro cache no grupo de replicação geográfica alternar para se uma região ficar inoperante.
Verifique se os firewalls estão definidos para que todos os aplicativos e clientes possam acessar o cache de backup identificado.
Cada cache no grupo de replicação geográfica tem sua própria chave de acesso. Determine como o aplicativo alternará para diferentes chaves de acesso ao ter como destino um cache de backup.
Se um cache no grupo de replicação geográfica ficar inativo, um acúmulo de metadados começará a ocorrer em todos os caches do grupo de replicação geográfica. Os metadados não podem ser descartados até que as gravações possam ser sincronizadas novamente com todos os caches. Você pode impedir o acúmulo de metadados forçando a desvinculação do cache que está inativo. Considere monitorar a memória disponível no cache e desvincular se houver pressão de memória, especialmente para cargas de trabalho pesadas de gravação.

Também é possível usar um padrão de disjuntor. Use o padrão para redirecionar automaticamente o tráfego de um cache que enfrenta uma interrupção de região e para um cache de backup no mesmo grupo de replicação geográfica. Use serviços do Azure, como o Gerenciador de Tráfego do Azure ou Azure Load Balancer para habilitar o redirecionamento.

Caso um dos caches em seu grupo de replicação não esteja disponível devido à interrupção da região, você pode forçar a remoção do cache indisponível do grupo de replicação.

Você deve remover o cache indisponível porque os caches restantes no grupo de replicação começam a armazenar os metadados que não foram compartilhados com o cache indisponível. Quando isso acontece, os caches disponíveis no grupo de replicação podem ficar sem memória.

Acesse o portal do Azure e selecione um dos caches no grupo de replicação que ainda está disponível.
Selecione para replicação geográfica ativa no menu de recursos à esquerda para ver as configurações no painel de trabalho.
Selecione o cache que você precisa forçar-desvincular marcando a caixa.
Selecione forçar desvinculação e OK para confirmar.
Depois que a disponibilidade da região afetada for restaurada, você precisará excluir o cache afetado e recriá-lo para adicioná-lo de volta ao grupo de replicação.

Configurar a replicação geográfica ativa usando a CLI do Azure ou o PowerShell

CLI do Azure

Use a CLI do Azure para criar um novo grupo de cache e replicação geográfica ou para adicionar um novo cache a um grupo de replicação geográfica existente. Para obter mais informações, confira az redisenterprise create.

Criar uma nova instância do Redis Gerenciado do Azure em um novo grupo de replicação geográfica usando a CLI do Azure

Este exemplo cria uma nova instância do Redis Gerenciado do Azure Balanceado B10 chamada Cache1 na região Leste dos EUA. Em seguida, o cache é adicionado a um novo grupo de replicação geográfica ativa chamado replicationGroup:

az redisenterprise create --location "East US" --cluster-name "Cache1" --sku "Balanced_B10" --resource-group "myResourceGroup" --group-nickname "replicationGroup" --linked-databases id="/subscriptions/34b6ecbd-ab5c-4768-b0b8-bf587aba80f6/resourceGroups/myResourceGroup/providers/Microsoft.Cache/redisEnterprise/Cache1/databases/default"

Para configurar a replicação geográfica ativa corretamente, a ID da instância de cache que está sendo criada deve ser adicionada com o parâmetro --linked-databases. A ID está no formato:

/subscriptions/<your-subscription-ID>/resourceGroups/<your-resource-group-name>/providers/Microsoft.Cache/redisEnterprise/<your-cache-name>/databases/default

Criar uma nova instância do Redis Gerenciado do Azure em um grupo de replicação geográfica existente usando a CLI do Azure

Esse exemplo cria uma nova instância de cache Balanceado B10 chamada Cache2 na região Oeste dos EUA. Em seguida, o script adiciona o cache ao grupo de replicação geográfica ativa replicationGroup criado em um procedimento anterior. Dessa forma, ele é vinculado a uma configuração ativa-ativa com o Cache1.

az redisenterprise create --location "West US" --cluster-name "Cache2" --sku "Balanced_B10" --resource-group "myResourceGroup" --group-nickname "replicationGroup" --linked-databases id="/subscriptions/34b6ecbd-ab5c-4768-b0b8-bf587aba80f6/resourceGroups/myResourceGroup/providers/Microsoft.Cache/redisEnterprise/Cache1/databases/default" --linked-databases id="/subscriptions/34b6ecbd-ab5c-4768-b0b8-bf587aba80f6/resourceGroups/myResourceGroup/providers/Microsoft.Cache/redisEnterprise/Cache2/databases/default"

Como antes, você precisa listar o Cache1 e o Cache2 usando o parâmetro --linked-databases.

Azure PowerShell

Use o Azure PowerShell para criar um cache e um grupo de replicação geográfica ou para adicionar um cache a um grupo de replicação geográfica existente. Para obter mais informações, confira New-AzRedisEnterpriseCache.

Criar uma nova instância do Redis Gerenciado do Azure em um novo grupo de replicação geográfica usando o PowerShell

Este exemplo cria uma nova instância de cache do Redis Gerenciado do Azure Balanceado B10 chamada Cache1 na região Leste dos EUA. Em seguida, o cache é adicionado a um novo grupo de replicação geográfica ativa chamado replicationGroup:

New-AzRedisEnterpriseCache -Name "Cache1" -ResourceGroupName "myResourceGroup" -Location "East US" -Sku "Balanced_B10" -GroupNickname "replicationGroup" -LinkedDatabase '{id:"/subscriptions/34b6ecbd-ab5c-4768-b0b8-bf587aba80f6/resourceGroups/myResourceGroup/providers/Microsoft.Cache/redisEnterprise/Cache1/databases/default"}'

Para configurar a replicação geográfica ativa corretamente, a ID da instância de cache que está sendo criada deve ser adicionada com o parâmetro -LinkedDatabase. A ID está no formato:

/subscriptions/<your-subscription-ID>/resourceGroups/<your-resource-group-name>/providers/Microsoft.Cache/redisEnterprise/<your-cache-name>/databases/default

Criar uma nova instância do Redis Gerenciado do Azure em um grupo de replicação geográfica existente usando o PowerShell

Esse exemplo cria uma nova instância de cache Balanceado B10 chamada Cache2 na região Oeste dos EUA. Em seguida, o script adiciona o cache ao grupo de replicação geográfica ativa “ReplicationGroup”, criado no procedimento anterior. O resultado é que os dois caches, Cache1 e Cache2, ficam vinculados em uma configuração ativa-ativa.

New-AzRedisEnterpriseCache -Name "Cache2" -ResourceGroupName "myResourceGroup" -Location "West US" -Sku "Balanced_B10" -GroupNickname "replicationGroup" -LinkedDatabase '{id:"/subscriptions/34b6ecbd-ab5c-4768-b0b8-bf587aba80f6/resourceGroups/myResourceGroup/providers/Microsoft.Cache/redisEnterprise/Cache1/databases/default"}', '{id:"/subscriptions/34b6ecbd-ab5c-4768-b0b8-bf587aba80f6/resourceGroups/myResourceGroup/providers/Microsoft.Cache/redisEnterprise/Cache2/databases/default"}'

Como antes, você precisa listar o Cache1 e o Cache2 usando o parâmetro -LinkedDatabase.

Dimensionamento de instâncias em um grupo de replicação geográfica

É possível dimensionar instâncias configuradas para usar a replicação geográfica ativa. No entanto, um grupo de replicação geográfica com uma combinação de diferentes tamanhos de cache pode apresentar problemas. Para evitar que esses problemas ocorram, todos os caches em um grupo de replicação geográfica precisam ter o mesmo tamanho e nível de desempenho.

Como o dimensionamento requer a alteração do tamanho ou da camada e é difícil dimensionar simultaneamente todas as instâncias no grupo de replicação geográfica, o Redis Gerenciado do Azure tem um mecanismo de bloqueio. Se você dimensionar uma instância em um grupo de replicação geográfica, a VM subjacente será dimensionada, mas a memória disponível será limitada ao tamanho original até que as outras instâncias também sejam ampliadas. E quaisquer outras operações de dimensionamento para as instâncias restantes são bloqueadas até corresponderem à mesma configuração que o primeiro cache a ser dimensionado.

Exemplo de dimensionamento

Por exemplo, você pode ter três instâncias em seu grupo de replicação geográfica, todas as instâncias Otimizadas para Memória M10:

Nome da Instância	Redis00	Redis01	Redis02
Tipo	M10 Otimizado para Memória	M10 Otimizado para Memória	M10 Otimizado para Memória

Digamos que você queira escalar verticalmente cada instância neste grupo de replicação geográfica para uma instância de Computação Otimizada X20. Primeiro, você dimensionaria um dos caches para uma X20:

Nome da Instância	Redis00	Redis01	Redis02
Tipo	Computação Otimizada X20	M10 Otimizado para Memória	M10 Otimizado para Memória

Neste ponto, as instâncias Redis01 e Redis02 só podem escalar verticalmente uma instância X20 de Computação Otimizada. Todas as outras operações de dimensionamento são bloqueadas.

Observação

A instância Redis00 não está impedida de dimensionar ainda mais neste momento. Mas ela será bloqueada uma vez Redis01 ou Redis02 será dimensionada para ser um X20 de Computação Otimizada.

Depois que cada instância tiver sido dimensionada para a mesma camada e tamanho, todos os bloqueios de dimensionamento serão removidos:

Nome da Instância	Redis00	Redis01	Redis02
Tipo	Computação Otimizada X20	Computação Otimizada X20	Computação Otimizada X20

Operação de liberação

Devido ao potencial de perda inadvertida de dados, você não pode usar os comandos FLUSHALL e FLUSHDB do Redis com nenhuma instância de cache residente em um grupo de replicação geográfica. Em vez disso, use o botão Liberar Cache(s) localizado na parte superior do painel de trabalho Replicação geográfica ativa.

A captura de tela mostrando a replicação geográfica ativa selecionada no menu de recursos e o recurso Liberar cache tem uma caixa vermelha ao redor.

Liberar caches usando a CLI do Azure ou o PowerShell

A CLI do Azure e o PowerShell também podem ser usados para disparar uma operação de liberação. Para obter mais informações sobre como usar a CLI do Azure, consulte az redisenterprise database flush. Para obter mais informações sobre como usar o PowerShell, consulte Invoke-AzRedisEnterpriseCacheDatabaseFlush.