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.
Antes de migrar, reveja as principais diferenças entre o Azure Cache for Redis e o Azure Managed Redis para que possa planear de forma eficaz.
Importante
Uma competência de agente de migração Redis está disponível para ajudar a responder a questões relacionadas com migração e preparar um plano de migração adaptado ao seu ambiente. Para mais informações, consulte a competência do agente de migração do Redis.
Porque é que o Azure Managed Redis é mais eficiente
O Azure Managed Redis é construído sobre a pilha de software Redis Enterprise, que proporciona melhorias significativas de desempenho em relação ao Redis open-source utilizado pelas camadas Basic, Standard e Premium. A Redis Enterprise utiliza uma arquitetura multi-thread que consegue gerir mais operações por segundo, entregar latências mais baixas e fazer um uso mais eficiente do hardware subjacente. Isto significa que, para a mesma quantidade de memória e computação, o Azure Managed Redis pode servir um throughput substancialmente superior em comparação com a cache equivalente de nível Basic, Standard ou Premium.
Além disso, o Azure Managed Redis suporta estruturas de dados avançadas através de módulos Redis (como RediSearch, RedisJSON e RedisBloom) que não estão disponíveis nos níveis Basic, Standard ou Premium. Para saber mais sobre a arquitetura, consulte a arquitetura Azure Managed Reddis.
Diferenças principais entre características/funcionalidades
Aqui estão as diferenças importantes a ter em conta ao passar do Basic, Standard ou Premium para Azure Managed Redis:
Estrutura do SKU. O Azure Managed Redis organiza SKUs de forma diferente do Azure Cache for Redis. Em vez de SKUs baseados em níveis (Basic, Standard, Premium), onde as funcionalidades variam consoante o nível, os SKUs Azure Managed Redis baseiam-se em duas dimensões: tamanho da memória e nível de desempenho (Balanced, Memory Optimized ou Compute Optimized). Todas as funcionalidades de alta disponibilidade e recuperação de desastres (HADR) — incluindo redundância de zonas, persistência de dados, geo-replicação e importação/exportação — estão disponíveis em todos os tamanhos e níveis de desempenho. Já não precisa de escolher um SKU de nível superior só para aceder a estas capacidades.
Alta disponibilidade vs. não alta disponibilidade. O Azure Managed Redis dá-lhe a opção de implementar com ou sem alta disponibilidade. A opção não-HA é pensada para cargas de trabalho não produtivas e de desenvolvimento/teste, onde se querem reduzir custos. As instâncias não-HA não têm um SLA e podem sofrer perda de dados durante a manutenção. Em contraste, os níveis Básico, Padrão e Premium não oferecem esta flexibilidade — o Básico não tem HA, enquanto o Standard e o Premium sempre a incluem.
Agrupamento. O Azure Managed Redis está configurado em cluster por padrão e oferece duas políticas de clustering: clustering OSS e clustering empresarial. Recomendamos escolher a clusterização OSS para alcançar o melhor desempenho. Se estiver atualmente a usar uma cache Basic ou Standard não clusterizada, a configuração da sua biblioteca cliente Redis pode exigir alterações para funcionar com uma instância clusterizada (por exemplo, gerir
MOVEDredirecionamentos usando uma biblioteca cliente consciente do cluster). Se a sua aplicação exigir absolutamente uma instância não clusterizada, o Azure Managed Redis oferece um modo não clusterizado para caches até 25 GB.Isolamento de rede. O Azure Managed Redis não suporta injeção virtual de rede nem a configuração de regras de firewall baseadas em IP. Se a sua instância Azure Cache for Redis atual usa injeção virtual de rede para isolamento de rede, precisa de mudar para o Azure Private Link com a sua nova instância Azure Managed Redis.
Dimensionamento. O Azure Managed Redis suporta a alteração do tamanho da memória e do nível de desempenho.
Microsoft Entra ID. Ambos os serviços suportam autenticação Microsoft Entra ID. No entanto, o Azure Managed Redis atualmente não suporta o Microsoft Entra ID RBAC.
Atualizações agendadas. O Azure Cache for Redis suporta a configuração de uma janela de atualização agendada para atualizações do Redis. O Azure Managed Redis suporta atualizações agendadas, atualmente em preview.
Suporte para TLS e portas não-TLS. No Azure Cache para níveis Redis Basic, Standard e Premium, a mesma instância de cache pode suportar simultaneamente tanto ligações TLS (porta 6380) como texto simples (porta 6379), permitindo que diferentes aplicações se liguem usando qualquer um dos modos. No Azure Managed Redis, a cache suporta apenas um modo de cada vez — TLS ou não-TLS. Uma vez escolhido o modo durante a criação do cache, todas as aplicações que se ligam a esse cache devem usar o mesmo modo.
Redundância de zonas. O Azure Managed Redis é redundante por zona por defeito quando a alta disponibilidade está ativada e a região suporta múltiplas zonas de disponibilidade. Em comparação, a redundância de zonas só está disponível no escalão Premium (e em visualização preliminar no Standard).
Bases de dados. Os níveis Basic, Standard e Premium suportam múltiplas bases de dados Redis (até 16 por defeito, configuráveis até 64 no Premium). O Azure Managed Redis suporta apenas uma única base de dados (base de dados 0). Se a sua aplicação usar várias bases de dados, precisa de refatorar o seu modelo de dados para usar uma única base de dados ou usar prefixos de chave para separar logicamente os dados antes de migrar.
Geo-replicação. O Azure Managed Redis suporta geo-replicação ativa, que permite operações de leitura e escrita entre caches ligadas em diferentes regiões. O nível premium suporta apenas geo-replicação passiva, onde a cache secundária é apenas de leitura. Ao contrário do Azure Cache para Redis, o Azure Managed Redis não suporta um comando explícito de failover. Em vez disso, a sua aplicação precisa de mudar para uma instância Azure Managed Redis geo-replicada diferente quando detetar que uma das regiões está fora de serviço.
Persistência de dados. O Azure Managed Redis suporta persistência de dados em todos os SKUs. No Azure Cache para Redis, a persistência só está disponível no nível Premium.
Módulos Redis. O Azure Managed Redis suporta módulos Redis como RediSearch, RedisJSON, RedisBloom e RedisTimeSeries. Estes módulos não estão disponíveis nos níveis Básico, Padrão ou Premium.
Importar/Exportar. O Azure Managed Redis suporta importação e exportação RDB em todos os SKUs. No Azure Cache para Redis, esta funcionalidade só está disponível no nível Premium.
Notificações do Keyspace. As notificações de keyspace são suportadas no Azure Cache para Redis, mas atualmente não estão disponíveis no Azure Managed Redis.
Reiniciar. O Azure Cache for Redis suporta o reinício manual dos nós de cache. Esta operação não está disponível no Azure Managed Redis, que gere automaticamente as operações dos nós. Se usar o Reboot para limpar dados da sua cache, então o Azure Managed Redis oferece o Flush como operação de gestão. As APIs Azure Managed Redis para simular eventos de manutenção e testar a resiliência das suas aplicações estão no roadmap.
Principais diferenças para aplicações cliente
Analise estas diferenças ao planear as atualizações da sua candidatura:
| Descrição das funcionalidades | Cache do Azure para Redis | Redis Gerido pelo Azure |
|---|---|---|
| Sufixo DNS (para a nuvem pública do Azure) | .redis.cache.windows.net |
<region>.redis.azure.net |
| Porta TLS | 6380 | 10000 |
| Porta não-TLS | 6379 | 10000 |
| Portas TLS de nós individuais | 13XXX | 85xx |
| Porta não-TLS de nó individual | 15XXX | 85xx |
| Suporte para clustering | Apenas clusterização OSS | software de código aberto e clustering de empresas |
| Não clusterizado/independente | Sim (Básico, Standard, Premium até 120GB) | Sim (modo não clusterizado, até 25 GB apenas) |
| Versão Redis | 6 | 7.4 |
| Versões TLS suportadas | 1.2 e 1.3 | 1.2 e 1.3 |
Escolha o tamanho e SKU corretos para o Azure Managed Redis
Escolher o Azure Managed Redis SKU certo envolve dois passos: selecionar o tamanho de memória correto e depois selecionar o nível de desempenho certo.
Passo A: Escolha o tamanho de memória correto
- Identifique o tamanho da memória da sua cache atual. Vai ao portal Azure, abre a tua cache Basic, Standard ou Premium e anota o tamanho da memória na página de Visão Geral (por exemplo, C3 = 13 GB, P2 = 13 GB).
Observação
Para caches Premium em clusters: para clusters particionados, escolha um tamanho que tenha memória total equivalente em todos os shards.
Encontre um SKU de tamanho semelhante no Azure Managed Redis. Procure um SKU Azure Managed Redis que ofereça a mesma ou maior quantidade de memória utilizável. Ao comparar tamanhos, note-se que o Azure Managed Redis reserva aproximadamente 20% de memória para operações do sistema e overhead. Tenha em conta esta reserva ao selecionar um tamanho — por exemplo, os SKUs B10/M10/X10 oferecem 12 GB de memória total, mas aproximadamente 9,6 GB de memória utilizável para os seus dados após a reserva.
Otimiza com base no uso real de memória. Em vez de igualar o tamanho nominal da cache, reveja a métrica de Memória Usada da sua cache existente do Azure Monitor. Verifique o pico de utilização de memória no último mês para identificar um SKU que se ajuste melhor. Se o seu uso real de memória for bem abaixo do tamanho da cache, poderá conseguir selecionar um SKU Azure Managed Redis mais pequeno e económico.
Passo B: Escolha o nível de desempenho certo
O Azure Managed Redis oferece três níveis de desempenho — Balanceado, Otimizado em Memória e Otimizado para Computação. Selecione com base nas características da sua carga de trabalho:
- Equilibrado — Um bom ponto de partida caso não tenhas a certeza. Oferece uma mistura saudável de memória e computação.
- Otimizado para Memória — Escolha esta opção se a sua carga de trabalho for intensiva em memória e mais propensa a ficar sem memória antes da CPU.
- Compute Optimized — Escolha esta opção se a sua carga de trabalho for intensiva em rendimento ou sensível à latência.
Para obter mais informações, consulte Escolhendo a camada correta.
Considerações adicionais
- Desative a alta disponibilidade para migrações de níveis básicos. Se estiver a migrar de uma cache Basic (que não tem replicação nem SLA), desative a alta disponibilidade na sua nova instância Azure Managed Redis. Isto reduz para metade o custo e proporciona uma configuração comparável para cargas de trabalho de desenvolvimento/teste.