Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Este artigo explica por que e como migrar do Cache Redis do Azure (incluindo as camadas Basic, Standard, Premium e Enterprise) para o Azure Managed Redis.
Você aprende sobre:
- Os benefícios de escolher o Azure Managed Redis em relação às camadas anteriores.
- Principais diferenças de características entre os serviços.
- Estratégias para migrar seus dados de cache.
- Formas de garantir um processo de migração suave.
- Orientação sobre como selecionar a SKU Redis Gerenciada do Azure e a camada de desempenho corretas para suas necessidades.
- Considerações e recomendações para atualizar seus aplicativos cliente.
Quer esteja a utilizar os escalões Basic, Standard, Premium ou Enterprise ou OSS, este guia ajuda-o a planear e executar a migração para o Azure Managed Redis.
O documento divide-se em duas secções. Um deles é sobre instâncias empresariais. O outro é sobre as camadas Basic, Standard e Premium do Cache do Azure para Redis.
- Benefícios da mudança do Enterprise para o Azure Managed Redis
- Benefícios da mudança de caches Basic, Standard ou Premium para o Azure Managed Redis
Benefícios da mudança do Enterprise para o Azure Managed Redis
O Azure Managed Redis baseia-se no software avançado Redis Enterprise. O Azure Managed Redis é uma oferta de primeira parte do Azure, o que significa que não há nenhum componente do Azure Marketplace envolvido e os usuários não precisam fazer transações com o Marketplace separadamente. Você provisiona, gerencia e paga pelo Azure Managed Redis como qualquer outro serviço ou produto nativo do Azure.
O Azure Managed Redis não precisa do nó de quorum que leva a recursos subutilizados e limita as regiões ou nuvens onde o Cache do Azure para Redis Enterprise pode ser oferecido. O Azure Managed Redis agora está disponível na maioria das regiões do Azure com planos de suporte em outras nuvens soberanas. Para obter mais informações sobre o nó de quórum, consulte tiers Enterprise e Enterprise Flash. Ao remover o nó de quorum não utilizado, você obtém maior eficiência de custos porque todos os nós podem ser usados como nós de dados.
O Azure Managed Redis é redundante de zona por padrão.
Você pode usar o Azure Managed Redis sem alta disponibilidade (HA) para seus ambientes de desenvolvimento e teste. O uso de ambientes de não produção sem HA reduz pela metade o custo da sua instância.
A estrutura de SKU para o Azure Managed Redis baseia-se nas suas necessidades de memória e desempenho. Em vez de gerenciar fatores de escala ou capacidade como no Cache do Azure para Redis Enterprise, você pode selecionar entre três camadas de desempenho no Azure Managed Redis. Para obter mais informações, consulte Escolhendo a camada correta.
Por fim, o Azure Managed Redis oferece a autenticação Microsoft Entra ID quando você cria um cache para melhorar a postura de segurança da sua carga de trabalho.
Comparação de funcionalidades
| Característica | Azure Cache para Redis Enterprise | Redis Gerido pelo Azure |
|---|---|---|
| Versão Redis | 7.2 | 7.4 |
| Política de agrupamento | OSS, Empresa | OSS, Empresarial, Não Clusterizado |
| Geo-replication | Active | Active |
| SLA | Até 99.999% | Até 99.999% |
| Redundância entre zonas | Yes | *Sim com alta disponibilidade |
| Modo não-HA | No | Sim (para desenvolvimento/teste) |
| Persistência de dados | Sim (em pré-visualização) | Yes |
| Escalonamento | Yes | Yes |
| Suporte à versão TLS | 1.2,1.3 | 1.2,1.3 |
| Autenticação do Microsoft Entra ID | No | Yes |
| Suporte da Região do Azure | Limitado | Extensivo |
| Suporte do Azure Sovereign Cloud | No | Sim (em breve) |
| Sufixo DNS do nome do host | <name>.<region>.redisenterprise.cache.azure.net |
<name>.<region>.redis.azure.net |
* Quando a Alta Disponibilidade está habilitada, o Azure Managed Redis é redundante de zona em regiões com várias Zonas de Disponibilidade.
Considerações ao mudar de Enterprise para o Azure Managed Redis
O Azure Managed Redis usa a mesma pilha de software que o Cache do Azure para Redis Enterprise, portanto, seus aplicativos existentes usando a camada Enterprise não precisam de muitas alterações. A exceção significativa é a necessidade de alterar as credenciais de conexão.
Nome de host e sufixo diferentes
Embora o software principal do Azure Cache para Redis Enterprise e do Azure Redis Gerido seja semelhante, o sufixo DNS para o nome de host do seu cluster Redis é diferente. Quando você move para o Azure Managed Redis, seu aplicativo precisa alterar o nome de host do cluster Redis. Se você usar chaves de acesso para se conectar ao cache, também deverá atualizar a chave de acesso que ele usa para se conectar ao cache.
Importante
Considere atualizar o código que se conecta ao cache. Em vez de usar chaves de acesso, use o Microsoft Entra ID. Recomendamos o uso do Microsoft Entra ID em vez de chaves de acesso.
Escolhendo o tamanho e o SKU do Azure Managed Redis corretos
O Azure Managed Redis oferece muitos tamanhos de memória e três camadas de desempenho. Você pode ler mais informações sobre tamanhos de memória e camadas de desempenho aqui Escolhendo a camada certa.
Identificar o tamanho da memória da instância existente do Azure Cache para Redis Enterprise
As instâncias do Cache do Azure para Redis Enterprise podem ser dimensionadas para fornecer mais memória e mais recursos de computação, por isso é importante observar o fator de expansão para seu cache. A expansão também está relacionada à capacidade, que é essencialmente o número de máquinas virtuais em execução para o cluster.
Para escolher o tamanho certo da memória Redis Gerenciada do Azure:
- Vá para o portal do Azure e selecione Visão geral no menu de recursos.
- Verifique o campo Status na Visão geral da sua instância Enterprise. O campo Status mostra o tamanho da memória da instância do Redis Enterprise.
Vejamos um cenário possível.
Observando o painel Status na visão geral , você verá Executando - Enterprise 8GB (2 x 4GB). Essa notação significa que o cache está usando atualmente um E5 Enterprise SKU com uma escala de 2, produzindo um cache de 8 GB. Portanto, você deve começar com pelo menos 10 GB de cache no Azure Managed Redis.
Nesse caso, use qualquer uma das camadas que oferecem 12 GB de memória.
| SKU | Escalão de serviço |
|---|---|
| M10 | Otimizado para Memória |
| B10 | Balanced |
| X10 | Otimizado para Processamento |
Identificar a camada de desempenho
Você também deve considerar se sua carga de trabalho consome muita memória ou computação. Se é mais provável que sua instância Enterprise atual fique sem memória antes da CPU, sua carga de trabalho consome muita memória. Considere escolher entre a camada de desempenho Memória otimizada.
Se a carga de trabalho for intensiva em termos de taxa de transferência ou tiver muita latência, então a carga de trabalho é intensiva em termos de computação. Considere escolher entre a camada de desempenho Compute Optimized.
Se não tiver certeza, você pode começar com a camada de desempenho equilibrado, pois ela oferece uma combinação saudável de memória e desempenho.
Se você estiver usando a camada Redis Enterprise Flash, escolha a camada Otimizada para Flash.
Criar uma nova instância do Azure Managed Redis
Depois de escolher a camada de memória e desempenho para sua nova instância do Azure Managed Redis, você pode criar a nova instância do Azure Managed Redis. Para obter mais informações sobre como criar um cache, consulte Guia de início rápido: criar uma instância Redis gerenciada do Azure.
Em seguida, você precisa escolher uma estratégia para mover seus dados. E, finalmente, você precisa atualizar seu aplicativo para usar o novo cache.
Atualizar aplicativo para se conectar à instância do Azure Managed Redis
Depois de criar uma nova instância do Redis Gerenciado do Azure, você deve alterar o ponto de extremidade/nome do host do Redis e a chave de acesso em seu aplicativo para apontar para sua nova instância do Redis Gerenciado do Azure. Recomendamos publicar esta alteração de ponto de extremidade fora do horário comercial, pois resulta numa interrupção momentânea na conectividade.
Note
Se te ligares à tua instância Redis Enterprise existente por um endpoint privado, assegura-te de que o teu novo cache Redis gerido do Azure também está emparelhado com a rede virtual da tua aplicação. O novo cache deve ter uma configuração semelhante à instância existente do Redis Enterprise.
Verifique se o aplicativo está sendo executado conforme o esperado e exclua a instância anterior do Redis Enterprise.
Movendo seus dados do cache corporativo para um novo cache Redis gerenciado do Azure
Ao migrar para a instância do Azure Managed Redis, você precisa considerar a melhor maneira de mover seus dados da instância existente do Redis Enterprise para sua nova instância do Azure Managed Redis. Se seu aplicativo pode tolerar a perda de dados ou tem outros mecanismos para reidratar o cache sem efeitos negativos, ignore esta etapa e prossiga para as próximas etapas.
Se seu aplicativo precisar garantir que os dados também sejam migrados para a nova instância do Azure Managed Redis, escolha uma das seguintes opções:
Exportação e importação de dados usando um arquivo RDB
- Prós: Preserva o instantâneo de dados.
- Contras: Risco de perda de dados se as gravações ocorrerem após o snapshot.
Aqui está o procedimento básico de exportação/importação:
- Exporte RDB do cache Redis Enterprise existente para sua conta de Armazenamento do Azure.
- Importe dados da conta de Armazenamento do Azure para um novo cache Redis gerenciado do Azure.
- Leia mais sobre exportação/importação de dados aqui Importar e exportar dados no Azure Managed Redis.
Estratégia Dual-Write
- Prós: Zero tempo de inatividade, transição segura.
- Contras: Requer configuração temporária de cache duplo.
Aqui está o procedimento básico de gravação dupla:
- Modifique a sua aplicação para gravar tanto no cache existente Azure Cache para Redis Enterprise como no novo cache Azure Redis Gerido.
- Continue lendo e gravando a partir do cache Redis Enterprise.
- Após sincronização de dados suficiente, alterne as leituras para o Azure Managed Redis e exclua a instância do Redis Enterprise
Migração programática usando RIOT-X
RIOT-X fornece uma maneira de migrar seu conteúdo do Enterprise para o Azure Managed Redis. Para obter mais informações, consulte Migração de dados com RIOT-X para Redis gerenciados do Azure.
- Prós: Controle total, personalizável.
- Contras: Requer esforço de desenvolvimento.
Benefícios da mudança de caches Basic, Standard ou Premium para o Azure Managed Redis
Se você usa qualquer um dos SKUs OSS, Basic, Standard ou Premium, mudar para o Azure Managed Redis oferece mais recursos em todos os níveis de cache.
Aqui está uma tabela que compara os recursos do Cache Redis do Azure com os recursos do Azure Managed Redis:
| Descrição do recurso | Básico OSS |
Standard OSS |
Premium OSS |
Balanced RAM |
Otimizado para Memória RAM |
Otimizado para Processamento RAM |
|---|---|---|---|---|---|---|
| Availability | N/A | 99.9% | 99.9% | Até 99.999% | Até 99.999% | Até 99.999% |
| Encriptação de dados em trânsito | Yes | Yes | Yes | Yes | Yes | Yes |
| Isolamento de rede | Yes | Yes | Yes | Yes | Yes | Yes |
| Expansão/redução | Yes | Yes | Yes | Yes | Yes | Yes |
| Redução de escala/entrada | Yes | Yes | Yes | No | No | No |
| Clustering OSS | No | No | Yes | Yes | Yes | Yes |
| Persistência de dados | No | No | Yes | Yes | Yes | Yes |
| Redundância entre zonas | No | Sim (pré-visualização) | Yes | *Sim com alta disponibilidade | *Sim com alta disponibilidade | *Sim com alta disponibilidade |
| Geo-replication | No | No | Sim (Passivo) | Sim (Ativo) | Sim (ativo) | Sim (ativo) |
| Logs de auditoria de conexão | No | No | Yes | Yes(Event-based) | Yes(Event-based) | Yes(Event-based) |
| Módulos Redis | No | No | No | Yes | Yes | Yes |
| Importar/Exportar | No | No | Yes | Yes | Yes | Yes |
| Reboot | Yes | Yes | Yes | No | No | No |
| Atualizações agendadas | Yes | Yes | Yes | No | No | No |
| Autenticação do Microsoft Entra ID | Yes | Yes | Yes | Yes | Yes | Yes |
| Microsoft Entra ID RBAC | Yes | Yes | Yes | No | No | No |
| Notificação do Keyspace | Yes | Yes | Yes | No | No | No |
| Disponibilidade não elevada | N/A | No | No | Yes | Yes | Yes |
OSS refere-se ao Cache Redis do Azure
AMR refere-se ao Azure Managed Redis
* Quando a Alta Disponibilidade está habilitada, o Azure Managed Redis é redundante de zona em regiões com várias Zonas de Disponibilidade.
Aqui estão algumas outras diferenças a serem consideradas ao implementar o Azure Managed Redis. Considere estas alterações no aplicativo cliente:
| Descrição do recurso | Cache do Azure para Redis | Redis Gerido pelo Azure |
|---|---|---|
| Sufixo DNS (apenas para a nuvem PROD) | .redis.cache.windows.net |
<region>.redis.azure.net |
| Porta TLS | 6380 | 10000 |
| Porta não-TLS | 6379 | Não suportado |
| Portas TLS de nó individual | 13XXX | 85xx |
| Porta não-TLS de nó individual | 15XXX | Não suportado |
| Suporte para clustering | Modo de cluster OSS | Modos de cluster OSS e Enterprise |
| Comandos não suportados | Comandos não suportados | Comandos de várias teclas |
| Disponibilidade regional | Todas as regiões do Azure | * Consulte a lista de regiões após esta secção. |
| Versão Redis | 6 | 7.4 |
| Versões TLS suportadas | 1.2 e 1.3 | 1.2 e 1.3 |
Migrar seu cache Básico, Standard ou Premium para o Azure Managed Redis
Com base na tabela, aqui estão alguns mapeamentos entre o Cache do Azure para SKUs Redis e opções para caches no Azure Managed Redis.
Note
Usar a opção não Alta Disponibilidade do Azure Managed Redis para migrar SKUs básicas
| Cache do Azure para Redis | Redis Gerido pelo Azure | Memória adicional (%) |
|---|---|---|
| Básico/Padrão - C0 | Equilibrado - B0 | 50 |
| Básico/Padrão - C1 | Equilibrado - B1 | 0 |
| Básico/Padrão - C2 | Equilibrado - B3 | 17 |
| Básico/Padrão - C3 | Equilibrado - B5 | 0 |
| Básico/Padrão - C4 | Memória otimizada – M10* | -8 |
| Básico/Padrão – C4 | Memória otimizada – M20** | 46 |
| Básico/Padrão - C5 | Memória otimizada – M20* | -8 |
| Básico/Padrão – C5 | Memória otimizada – M50** | 57 |
| Básico/Padrão - C6 | Memória otimizada - M50 | 12 |
| Premium - P1 | Equilibrado - B5 | 0 |
| Premium - P2 | Equilibrado - B10* | -8 |
| Premium - P2 | Equilibrado - B20** | 46 |
| Premium - P3 | Equilibrado - B20* | -8 |
| Premium - P3 | Equilibrado - B50** | 57 |
| Premium - P4 | Equilibrado - B50 | 12 |
| Premium - P5 | Equilibrado - B100 | 0 |
- * Esta opção é para eficiência de custos. Verifique se o pico de memória total usada no mês passado é menor do que a memória Redis gerenciada do Azure sugerida para escolher essa opção.
- ** Esta opção é para consumo de memória abundante.
Cache do Azure para Redis Premium em cluster
- Para cluster fragmentado, escolha uma camada otimizada para memória que tenha memória total equivalente.
- Para clusters com mais de uma réplica de leitura, escolha uma camada otimizada para computação com memória total equivalente como réplica primária.
Opções de migração
Os aplicativos cliente devem ser capazes de usar uma instância do Azure Managed Redis que tenha diferentes modos de clustering e pontos de extremidade. O Cache do Azure para Redis e o Azure Managed Redis são compatíveis, portanto, nenhuma alteração no código do aplicativo, além das configurações de conexão, é necessária para a maioria dos cenários.
Saiba mais nas secções:
Opções para migrar o Cache Redis do Azure para o Redis Gerenciado do Azure
| Option | Advantages | Disadvantages |
|---|---|---|
| Criar um novo cache | Mais simples de implementar. | Necessidade de preencher novamente os dados para o novo cache, que pode não funcionar com muitos aplicativos. |
| Exportar e importar dados via arquivo RDB | Compatível com qualquer cache Redis em geral. | Alguns dados podem ser perdidos se forem gravados no cache existente após a geração do arquivo RDB. |
| Escrita dupla de dados em dois caches | Sem perda de dados ou tempo de inatividade. Operações ininterruptas do cache existente. Teste mais fácil do novo cache. | Precisa de dois caches por um longo período de tempo. |
| Migrar dados programaticamente | Controle total sobre como os dados são movidos. | Requer código personalizado. |
Crie uma nova Instância Redis Gerida do Azure
Esta abordagem tecnicamente não é uma migração. Se perder dados não for uma preocupação, a forma mais fácil de passar para o nível Azure Managed Redis é criar uma nova instância de cache e ligar a sua aplicação a ela. Por exemplo, se você usar o Redis como um cache look-aside para registros de banco de dados, poderá facilmente reconstruir o cache desde o início. As etapas gerais para implementar esta opção são:
- Crie uma nova instância do Azure Managed Redis.
- Atualize seu aplicativo para usar a nova instância.
- Exclua a instância antiga do Cache do Azure para Redis.
Exportar dados para um arquivo RDB e importá-los para o Azure Managed Redis
Esta opção é aplicável apenas a caches de nível premium. O Redis de código aberto define um mecanismo padrão para tirar um instantâneo do conjunto de dados na memória de um cache e salvá-lo em um arquivo. Outro cache Redis pode ler o arquivo RDB que foi exportado. A camada premium do Cache do Azure para Redis dá suporte à exportação de dados de uma instância de cache por meio de arquivos RDB. Você pode usar um arquivo RDB para transferir dados de uma instância existente do Cache do Azure para Redis para a instância do Azure Managed Redis.
As etapas gerais para implementar esta opção são:
- Crie uma nova instância do Azure Managed Redis que seja do mesmo tamanho (ou maior que) a instância existente do Cache do Azure para Redis.
- Exporte o arquivo RDB da instância existente do Cache do Azure para Redis usando estas instruções de exportação ou o cmdlet de Exportação do PowerShell
- Importe o arquivo RDB para a nova instância do Azure Managed Redis usando estas instruções de importação ou o cmdlet PowerShell Import
- Atualize seu aplicativo para usar a nova cadeia de conexão de instância do Azure Managed Redis.
Gravar em dois caches Redis simultaneamente durante o período de migração
Em vez de mover dados diretamente entre caches, você pode usar seu aplicativo para gravar dados em um cache existente e em um novo que você está configurando. O aplicativo ainda lê dados do cache existente inicialmente. Quando o novo cache tiver os dados necessários, você altera a aplicação para esse cache e aposenta o antigo. Digamos, por exemplo, que você use o Redis como um armazenamento de sessão e as sessões de aplicativo sejam válidas por sete dias. Depois de gravar nos dois caches por uma semana, você terá certeza de que o novo cache contém todas as informações de sessão não expiradas. Você pode confiar nele com segurança a partir desse ponto sem se preocupar com a perda de dados.
As etapas gerais para implementar esta opção são:
- Crie uma nova instância do Azure Managed Redis que seja do mesmo tamanho (ou maior que) a instância existente do Cache do Azure para Redis.
- Modifique o código da aplicação para escrever nas instâncias nova e original.
- Continue lendo os dados da instância original até que a nova instância seja suficientemente preenchida com dados.
- Atualize o código do aplicativo para leitura e gravação somente a partir da nova instância.
- Exclua a instância original.
Migrar programaticamente
Crie um processo de migração personalizado lendo programaticamente dados de uma instância existente do Cache do Azure para Redis e gravando-os na instância do Azure Managed Redis. Existem duas ferramentas de código aberto que você pode experimentar:
-
Redis-copy
- Essa ferramenta de código aberto pode ser usada para copiar dados de uma instância do Cache Redis do Azure para outra. Essa ferramenta é útil para mover dados entre instâncias de cache em diferentes regiões do Cache do Azure. Uma versão compilada também está disponível. Você também pode encontrar o código-fonte para ser um guia útil para escrever sua própria ferramenta de migração.
-
RIOT
- A RIOT é outra ferramenta de migração popular testada pela comunidade Redis. É um utilitário de linha de comando projetado para ajudá-lo a obter dados dentro e fora do Redis.
Note
Esta ferramenta não é oficialmente suportada pela Microsoft.
As etapas gerais para implementar esta opção são:
- Crie uma VM na região onde o cache existente está localizado. Se o conjunto de dados for grande, escolha uma VM relativamente poderosa para reduzir o tempo de cópia.
- Crie uma nova instância do Azure Managed Redis.
- Libere os dados do novo cache para garantir que ele esteja vazio. Esta etapa é necessária porque a própria ferramenta de cópia não substitui nenhuma chave existente no cache de destino. Importante: Certifique-se de NÃO liberar do cache de origem.
- Use um aplicativo como a ferramenta de código aberto mencionada anteriormente para automatizar a cópia de dados do cache de origem para o destino. Lembre-se de que o processo de cópia pode demorar um pouco para ser concluído, dependendo do tamanho do seu conjunto de dados.
Disponibilidade regional para o Azure Managed Redis
O Azure Managed Redis está continuamente a expandir-se para novas regiões. Para verificar a disponibilidade por região, consulte Produtos disponíveis por região.