Arquitetura do Azure Managed Redis

O Azure Managed Redis corre na stack Redis Enterprise , que oferece vantagens significativas em relação à edição comunitária do Redis. As informações a seguir fornecem mais detalhes sobre como o Azure Managed Redis é arquitetado, incluindo informações que podem ser úteis para usuários avançados.

Comparação com o Cache Redis do Azure

Os níveis Básico, Standard e Premium do Azure Cache para Redis funcionam na edição comunitária do Redis. Esta edição comunitária do Redis tem várias limitações significativas, incluindo ser monothreaded. Esta limitação reduz significativamente o desempenho e torna a escalabilidade menos eficiente porque o serviço não utiliza totalmente mais vCPUs. Uma instância típica do Cache do Azure para Redis usa uma arquitetura como esta:

Repara que são usadas duas VMs – uma principal e uma réplica. Estas VMs também são chamadas de nós. O nó primário contém o processo principal do Redis e aceita todas as operações de escrita. A replicação é conduzida de forma assíncrona no nó da réplica para fornecer uma cópia de backup durante manutenção, dimensionamento ou falha inesperada. Cada nó só pode executar um único processo servidor Redis devido ao design de thread único do Redis comunitário.

Melhorias arquitetónicas do Azure Managed Redis

O Azure Managed Redis usa uma arquitetura mais avançada semelhante a esta:

Existem várias diferenças:

• Cada máquina virtual (ou nó) executa vários processos do servidor Redis (denominados shards) em paralelo. Vários fragmentos permitem uma utilização mais eficiente de vCPUs em cada máquina virtual e maior desempenho.
• Nem todos os fragmentos Redis primários estão na mesma VM/nó. Em vez disso, os fragmentos primários e de réplica são distribuídos em ambos os nós. Como os shards primários consomem mais recursos de CPU do que os shards réplica, esta abordagem permite que mais shards primários corram em paralelo.
• Cada nó tem um processo de proxy de alto desempenho para gerenciar os fragmentos, lidar com o gerenciamento de conexões e acionar a autorrecuperação.

Esta arquitetura permite tanto um desempenho superior como funcionalidades avançadas, como a geo-replicação ativa.

Clusterização

Cada instância do Azure Managed Redis é configurada internamente para usar clustering, em todas as camadas e SKUs. O Azure Managed Redis é baseado no Redis Enterprise, que permite utilizar múltiplos fragmentos por nó. Essa capacidade inclui instâncias menores que estão configuradas para usar apenas um único fragmento. O clustering é uma forma de dividir os dados na instância Redis entre múltiplos processos Redis, também chamada de sharding. O Azure Managed Redis oferece três políticas de cluster que determinam qual o protocolo disponível para os clientes Redis ligarem-se à instância de cache.

Políticas de cluster

O Azure Managed Redis oferece três políticas de clustering: OSS,Enterprise e Non-Clustered. A política de cluster OSS é boa para a maioria das aplicações porque suporta um débito máximo mais elevado, mas cada versão tem as suas próprias vantagens e desvantagens.

• Se estiver a migrar de uma topologia não clusterizada Basic, Standard ou Premium, considere usar clustering OSS para melhorar o desempenho. Use configurações não clusterizadas apenas se a sua aplicação não suportar topologias OSS ou Enterprise. A política de clustering OSS implementa a mesma API que o software open-source Redis. A API de Cluster Redis permite que o cliente Redis se ligue diretamente aos shards em cada nó Redis, minimizando a latência e otimizando o rendimento da rede. O rendimento escala de forma quase linear à medida que o número de shards e vCPUs aumenta. A política de clustering OSS oferece geralmente a menor latência e o melhor desempenho de rendimento. No entanto, a política do cluster OSS exige que a sua biblioteca cliente suporte a API do Redis Cluster. Atualmente, quase todos os clientes Redis suportam a API do Cluster Redis, mas a compatibilidade pode ser um problema para versões de cliente mais antigas ou bibliotecas especializadas.

Não podes usar a política de clustering OSS com o módulo RediSearch.

O protocolo de cluster OSS requer que o cliente faça as conexões de fragmento corretas. A conexão inicial é através da porta 10000. A ligação a nós individuais utiliza portas na gama 85XX. As portas 85xx podem mudar ao longo do tempo, e não deves colocá-las diretamente na tua aplicação. Os clientes Redis que suportam clustering usam o comando CLUSTER NODES para determinar as portas exatas usadas para os fragmentos primários e de réplica e fazer as conexões de estilhaços para você.

A política de clustering empresarial é uma configuração mais simples que utiliza um único endpoint para todas as ligações do cliente. Quando utiliza a política de clustering da Enterprise, todos os pedidos são redirecionados para um único nó Redis que atua como proxy. Este nó encaminha internamente os pedidos para o nó correto no cluster. A vantagem dessa abordagem é que ela faz com que o Azure Managed Redis pareça não clusterizado para os usuários. Isto significa que as bibliotecas cliente Redis não precisam de suportar o Clustering Redis para obter algumas das vantagens de desempenho do Redis Enterprise. Usar um único endpoint aumenta a compatibilidade retroativa e torna a ligação mais simples. A desvantagem é que o proxy de nó único pode ser um gargalo tanto na utilização de computação como no débito da rede.

A política de clustering empresarial é a única que pode usar com o módulo RediSearch. Embora a política de cluster Enterprise faça com que uma instância do Azure Managed Redis pareça não estar clusterizada para os usuários, ela ainda tem algumas limitações com comandos de várias chaves.

A política de clustering não clusterizado armazena dados em cada nó sem fragmentação. Aplica-se apenas a caches de 25 GB ou menos. Cenários para utilização da política de clustering não agrupante incluem:

• Ao migrar de um ambiente Redis que não está particionado. Por exemplo, as topologias não fragmentadas dos SKUs Basic, Standard e Premium do Azure Cache para Redis.
• Ao executar comandos de slot cruzado extensivamente e dividir dados em fragmentos causaria falhas. Por exemplo, os comandos MULTI.
• Ao usar o Redis como corretor de mensagens e não requer fragmentação.

As considerações para a utilização da política não agrupada são:

• Esta política aplica-se apenas a níveis do Azure Managed Redis que sejam inferiores ou iguais a 25 GB.
• Não tem o mesmo desempenho que outras políticas de clustering, porque as CPUs só conseguem realizar multithreading com o software Redis Enterprise quando a cache está fragmentada.
• Se quiser aumentar a escala do cache Redis Gerenciado do Azure, primeiro altere a política de cluster.
• Se estiver a migrar de uma topologia não clusterizada Basic, Standard ou Premium, considere usar clusters OSS para melhorar o desempenho. Use configurações não clusterizadas apenas se a sua aplicação não suportar topologias OSS ou Enterprise.

Escalonamento ou adição de nós

O software principal Redis Enterprise escala usando VMs maiores ou expande-se adicionando mais nós ou VMs. Ambas as opções de escalonamento adicionam mais memória, mais vCPUs e mais shards. Devido a esta redundância, o Azure Managed Redis não permite controlar o número específico de nós usados em cada configuração. Este detalhe de implementação é abstraído para evitar confusão, complexidade e configurações subótimas. Em vez disso, cada SKU é projetado com uma configuração de nós que otimiza vCPUs e memória. Alguns SKUs do Azure Managed Redis utilizam dois nós, enquanto outros utilizam mais.

Comandos de várias teclas

Como as instâncias do Azure Managed Redis usam uma configuração clusterizada, pode haver CROSSSLOT exceções em comandos que operam em múltiplas chaves. O comportamento varia dependendo da política de agrupamento utilizada. Se usar a política de clustering OSS, todas as chaves nos comandos multichave devem ser mapeadas para o mesmo slot de hash.

Também pode ver CROSSSLOT erros com a política de clusterização empresarial. Apenas os seguintes comandos multichave são permitidos entre slots com clustering Enterprise: DEL, MSET, MGET, EXISTS, UNLINK, e TOUCH.

Em bases de Active-Active, comandos de escrita multichave (DEL, MSET, UNLINK) só podem ser executados em chaves que estejam no mesmo slot. No entanto, os seguintes comandos multichave são permitidos em bases de dados Active-Active entre slots: MGET, EXISTS e TOUCH. Para mais informações, consulte Agrupamento de bases de dados.

Configuração de compartilhamento

Cada SKU do Azure Managed Redis executa um número específico de processos do servidor Ridis, chamados shards, em paralelo. A relação entre o desempenho de throughput, o número de shards e o número de vCPUs disponíveis em cada instância é complexa. Não podes alterar manualmente o número de fragmentos.

Para um dado tamanho de memória, a versão Otimizada para Memória tem o menor número de vCPUs e shards, enquanto a versão Otimizada para Computação tem o maior número.

Aumentar o número de fragmentos geralmente aumenta o desempenho, pois as operações do Redis podem correr em paralelo. Mas, se não houver vCPUs disponíveis para executar comandos, o desempenho pode diminuir.

Os shards são mapeados para otimizar a utilização de cada vCPU enquanto reservam ciclos de vCPU para o processo do servidor Redis, agente de gestão e tarefas do sistema operativo que também afetam o desempenho. As aplicações clientes que crias interagem com o Azure Managed Redis como se fosse uma única base de dados lógica. O serviço gere o roteamento entre as vCPUs e shards.

Para aumentar o número de fragmentos num SKU, usa um nível maior nesse SKU. Também pode alterar os SKUs para corresponder às suas necessidades de desempenho.

A tabela seguinte mostra a proporção de vCPUs para shards primários em um nível de tamanho determinado. Os dados nas colunas não representam uma garantia de que este é o número de vCPUs ou shards. As tabelas são apenas para ilustração.

Versões otimizadas para memória, balanceadas e otimizadas para computação

Esta tabela mostra um exemplo geral da relação do Tamanho com vCPUs/shards primários.

¹ A proporção de vCPUs para shards primários num determinado tamanho de tier não representa garantia para o SKU ou tier.

Versão otimizada para Flash

Esta tabela mostra um exemplo geral da relação do Tamanho com vCPUs/shards primários.

¹ Estes níveis estão em pré-visualização pública.

² A proporção de vCPUs para shards primários num determinado tamanho de tier não representa garantia para o SKU ou tier.

Em execução sem o modo de alta disponibilidade ativado

Pode correr sem o modo de alta disponibilidade (HA) ativado. Esta configuração significa que a sua instância Redis não tem replicação ativada nem acesso ao SLA de disponibilidade. Não corra em modo não-HA fora de cenários de desenvolvimento e teste. Não podes desativar a alta disponibilidade numa instância que já criaste. Podes ativar alta disponibilidade numa instância que não a tenha. Como uma instância a correr sem alta disponibilidade consome menos VMs e nós, os vCPUs não são usados de forma tão eficiente, pelo que o desempenho pode ser inferior.

Memória reservada

Em cada Instância Redis Gerenciada do Azure, aproximadamente 20% da memória disponível são reservados como um buffer para operações que não sejam de cache, como replicação durante failover e buffer de replicação geográfica ativo. Esse buffer ajuda a melhorar o desempenho do cache e evita a falta de memória.

Redução da escala

A redução de escala não é atualmente suportada no Azure Managed Redis. Para obter mais informações, consulte Limitações de dimensionamento do Azure Managed Redis.

Camada otimizada para Flash

A camada otimizada para Flash utiliza armazenamento flash NVMe e RAM. Como o armazenamento Flash é de menor custo, o uso da camada Flash Optimized permite que você troque algum desempenho por eficiência de preço.

Em instâncias otimizadas para flash, 20% do espaço de cache estão na RAM, enquanto os outros 80% usam armazenamento Flash. Todas as chaves são armazenadas na RAM, enquanto os valores podem ser armazenados em armazenamento Flash ou RAM. O software Redis determina de forma inteligente a localização dos valores. Os valores quentes que são acessados com frequência são armazenados na RAM, enquanto os valores de frio que são menos usados são mantidos no Flash. Antes que os dados sejam lidos ou gravados, eles devem ser movidos para a RAM, tornando-se dados quentes .

Como o Redis otimiza para obter o melhor desempenho, a instância primeiro preenche a RAM disponível antes de adicionar itens ao armazenamento Flash. Preencher a RAM primeiro tem algumas implicações para o desempenho:

• Melhor desempenho e menor latência podem ocorrer ao testar com baixo uso de memória. Testar com uma instância de cache completa pode resultar em menor desempenho porque apenas a RAM é usada na fase de teste de baixo consumo de memória.
• À medida que você grava mais dados no cache, a proporção de dados na RAM em comparação com o armazenamento Flash diminui, normalmente fazendo com que a latência e o desempenho da taxa de transferência também diminuam.

Cargas de trabalho adequadas para a camada otimizada para Flash

Cargas de trabalho que correm bem na camada Otimizada para Flash frequentemente apresentam as seguintes características:

• Leitura pesada, com uma alta proporção de comandos de leitura para comandos de escrita.
• O acesso focava-se num subconjunto de chaves que usas muito mais frequentemente do que o resto do conjunto de dados.
• Valores relativamente grandes em comparação com nomes de chaves. (Como os nomes das chaves são sempre armazenados na RAM, valores grandes podem se tornar um gargalo para o crescimento da memória.)

Cargas de trabalho que não são adequadas para a camada otimizada para o Flash

Algumas cargas de trabalho têm características de acesso menos otimizadas para o design da camada otimizada para o Flash:

• Escreva cargas de trabalho pesadas.
• Padrões de acesso a dados aleatórios ou uniformes na maior parte do conjunto de dados.
• Nomes de chaves longos com tamanhos de valor relativamente pequenos.

Conteúdo relacionado

• Dimensionar uma instância do Azure Managed Redis