Arquitetura do Redis Gerenciado do Azure

O Redis Gerenciado do Azure é executado na pilha Redis Enterprise, que oferece vantagens significativas em relação à edição da comunidade do Redis. As informações a seguir fornecem mais detalhes sobre como o Redis Gerenciado do Azure é projetado, incluindo informações que podem ser úteis para os usuários de energia.

Comparação com o Cache do Azure para Redis

As camadas Básica, Standard e Premium do Cache do Azure para Redis são executadas na edição da comunidade do Redis. Esta edição de comunidade do Redis tem várias limitações significativas, incluindo o thread único. Essa limitação reduz significativamente o desempenho e torna o dimensionamento 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:

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

Melhorias de arquitetura do Redis Gerenciado do Azure

O Redis Gerenciado do Azure usa uma arquitetura mais avançada que se parece com esta:

Há várias diferenças:

• Cada máquina virtual (ou nó) executa vários processos de servidor Redis (chamados de fragmentos) 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 principais do Redis estão na mesma VM/nó. Em vez disso, os fragmentos primários e de réplica são distribuídos entre ambos os nós. Como os fragmentos primários usam mais recursos de CPU do que fragmentos de réplica, essa abordagem permite que mais fragmentos primários sejam executados em paralelo.
• Cada nó tem um proxy de alto desempenho processo para gerenciar os fragmentos, lidar com o gerenciamento de conexões e disparar a autorrecuperação.

Essa arquitetura permite um desempenho mais alto e recursos avançados, como replicação geográfica ativa.

Clustering

Cada instância do Redis Gerenciado do Azure é configurada internamente para usar clusterização, em todas as camadas e SKUs. O Redis Gerenciado do Azure é baseado no Redis Enterprise, que pode usar vários fragmentos por nó. Essa funcionalidade inclui instâncias menores que são configuradas apenas para usar um único fragmento. O clustering é uma maneira de dividir os dados na instância do Redis entre os vários processos do Redis, também chamados de fragmentação. O Redis Gerenciado do Azure oferece três políticas de cluster que determinam qual protocolo está disponível para clientes Redis para se conectar à instância de cache.

Políticas de cluster

O Redis Gerenciado do Azure oferece três políticas de clustering: OSS, Enterprise e Não Clusterizado. A política de cluster do OSS é boa para a maioria dos aplicativos porque dá suporte a maior taxa de transferência máxima, mas cada versão tem suas próprias vantagens e desvantagens.

• Se você estiver migrando de uma topologia não clusterizada Basic, Standard ou Premium, considere usar a clusterização OSS para melhorar o desempenho. Use configurações não clusterizados somente se o aplicativo não puder dar suporte a topologias OSS ou Enterprise. A política de clustering do OSS implementa a mesma API que o software de código aberto do Redis. A API do Cluster Redis permite que o cliente Redis se conecte diretamente a fragmentos em cada nó Redis, minimizando a latência e otimizando a taxa de transferência de rede. A taxa de transferência é dimensionada quase linearmente à medida que o número de fragmentos e vCPUs aumenta. A política de clustering do OSS geralmente oferece a menor latência e o melhor desempenho de taxa de transferência. No entanto, a política de cluster do OSS requer que sua biblioteca de clientes dê suporte à API de Cluster Redis. Hoje, quase todos os clientes Redis dão suporte à API de Cluster Redis, mas a compatibilidade pode ser um problema para versões de cliente mais antigas ou bibliotecas especializadas.

Você não pode usar a política de clustering do OSS com o módulo RediSearch.

O protocolo de clustering do OSS exige que o cliente faça as conexões de fragmento corretas. A conexão inicial é feita pela porta 10000. A conexão com nós individuais utiliza portas na faixa 85XX. As portas 85xx podem ser alteradas ao longo do tempo e você não deve codificá-las em seu aplicativo. Os clientes Redis que dão suporte a clustering usam o comando CLUSTER NODES para determinar as portas exatas usadas para os shards primário e de réplica e fazer as conexões de shard para você.

A política de clustering empresarial é uma configuração mais simples que usa um único ponto de extremidade para todas as conexões dos clientes. Quando você usa a política de clustering Enterprise, ela roteia todas as solicitações para um único nó Redis que atua como um proxy. Esse nó roteia internamente as solicitações para o nó correto no cluster. A vantagem dessa abordagem é que ela faz com que os Redis Gerenciados do Azure pareçam não clusterizados para os usuários. Isso significa que as bibliotecas de clientes redis não precisam dar suporte ao Clustering Redis para obter algumas das vantagens de desempenho do Redis Enterprise. O uso de um único ponto de extremidade aumenta a retrocompatibilidade e simplifica a conexão. A desvantagem é que o proxy de nó único pode ser um gargalo, na utilização de computação ou na taxa de transferência de rede.

A política de clustering da Enterprise é a única que você pode usar com o módulo RediSearch. Embora a política de cluster Enterprise faça com que uma instância do Redis Gerenciado do Azure 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 e menores. Os cenários para usar a política de agrupamento não agrupado incluem:

• Ao migrar de um ambiente do Redis que não esteja fragmentado. Por exemplo, as topologias não fragmentadas de 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 agente de mensagens e não precisar de fragmentação.

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

• Essa política só se aplica às camadas redis gerenciadas do Azure que são menores ou iguais a 25 GB.
• Ele não tem um desempenho tão eficiente quanto outras políticas de clustering, pois as CPUs só podem operar em multithread com o software Redis Enterprise quando o cache está fragmentado.
• Se você quiser aumentar a escala do cache Redis Gerenciado do Azure, primeiro deve alterar a configuração do cluster.
• Se você estiver migrando de uma topologia não clusterizada Básico, Padrão ou Premium, considere usar clusters OSS para melhorar o desempenho. Use configurações não clusterizados somente se o aplicativo não puder dar suporte a topologias OSS ou Enterprise.

Dimensionamento ou adição de nós

O software principal do Redis Enterprise escalona usando VMs maiores ou expande horizontalmente por adicionar mais nós ou VMs. As duas opções de dimensionamento adicionam mais memória, mais vCPUs e mais fragmentos. Devido a essa redundância, o Redis Gerenciado do Azure não fornece a capacidade de controlar o número específico de nós usados em cada configuração. Esse detalhe de implementação é abstraído para evitar confusão, complexidade e configurações abaixo do ideal. Em vez disso, cada SKU é projetado com uma configuração de nó que otimiza vCPUs e memória. Alguns SKUs do Azure Redis Gerenciado usam dois nós, enquanto outros usam mais.

Comandos de várias chaves

Como as instâncias do Redis Gerenciado do Azure usam uma configuração clusterizada, você pode conferir exceções CROSSSLOT em comandos que operam em várias chaves. O comportamento varia dependendo da política de clustering usada. Se você usar a política de clustering do OSS, todas as chaves em comandos multichave deverão ser mapeadas para o mesmo slot de hash.

Você também pode ver CROSSSLOT erros com a política de clustering Enterprise. Somente os seguintes comandos multichave são permitidos entre slots com clustering Enterprise: DEL, MSET, MGET, EXISTS, UNLINK e TOUCH.

Em bancos de dados Active-Active, comandos de gravação multichave (DEL, MSET, UNLINK) só podem ser executados em chaves que estão no mesmo slot. No entanto, os seguintes comandos multichavem são permitidos entre slots em bancos de dados Active-Active: MGET, EXISTSe TOUCH. Para obter mais informações, consulte clustering banco de dados.

Configuração de fragmentação

Cada SKU do Redis Gerenciado do Azure executa um número específico de processos do servidor Redis, chamados simplesmente de shards, em paralelo. A relação entre o desempenho da taxa de transferência, o número de fragmentos e o número de vCPUs disponíveis em cada instância é complexa. Você não pode alterar manualmente o número de fragmentos.

Para um determinado tamanho de memória, a versão otimizada para memória tem o menor número de vCPUs e fragmentos, enquanto a versão otimizada para computação tem a mais alta.

Aumentar o número de fragmentos geralmente aumenta o desempenho, pois as operações do Redis podem ser executadas em paralelo. Mas, se nenhuma vCPU estiver disponível para executar comandos, o desempenho pode cair.

Os shards são mapeados para otimizar o uso de cada vCPU, ao mesmo tempo que reservam ciclos de vCPU para o processo do servidor Redis, o agente de gerenciamento e as tarefas do sistema operacional, que também influenciam no desempenho. Os aplicativos cliente que você cria interagem com o Redis Gerenciado do Azure como se fosse um banco de dados lógico único. O serviço gerencia o roteamento entre os vCPUs e partições.

Para aumentar o número de fragmentos em uma SKU, use uma camada maior nessa SKU. Você também pode alterar os SKUs para atender às suas necessidades de desempenho.

A tabela a seguir mostra a proporção de vCPUs para fragmentos primários em um determinado tamanho de camada. Os dados nas colunas não representam uma garantia de que esse é o número de vCPUs ou fragmentos. 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 de Tamanho com vCPUs/fragmentos primários.

¹ A proporção de vCPUs para fragmentos primários em um determinado tamanho de camada não representa uma garantia para a SKU ou a camada.

Versão otimizada para flash

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

¹ Essas camadas estão em versão prévia pública.

² A proporção de vCPUs para fragmentos primários em um determinado tamanho de camada não representa uma garantia para a SKU ou a camada.

Execução sem modo de alta disponibilidade habilitado

Você pode executar sem o modo de ALTA DISPONIBILIDADE (HA) habilitado. Essa configuração significa que sua instância do Redis não tem a replicação habilitada e não tem acesso ao SLA de disponibilidade. Não execute no modo não-HA fora dos cenários de desenvolvimento e teste. Não é possível desabilitar a alta disponibilidade em uma instância que você já criou. Você pode habilitar a alta disponibilidade em uma instância que não a tenha. Como uma instância em execução sem alta disponibilidade usa menos VMs e nós, as vCPUs não são usadas com eficiência, portanto, o desempenho pode ser menor.

Memória reservada

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

Redução vertical

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

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 Otimizada para Flash permite que você troque algum desempenho por eficiência de preço.

Em instâncias otimizadas para Flash, 20% do espaço em cache está na RAM, enquanto os outros 80% usam o armazenamento Flash. Todas as chaves são armazenadas na RAM, enquanto os valores são armazenados no armazenamento Flash ou na RAM. O software Redis determina de forma inteligente o local dos valores. Os valores Frequentes são armazenados na RAM, enquanto os valores Não frequentes que são menos usados são mantidos no Flash. Antes que os dados sejam lidos ou gravados, eles devem movidos para a RAM, tornando-se dados Frequentes.

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

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

Cargas de trabalho adequadas para a camada Otimizada para Flash

As cargas de trabalho que são bem executadas na camada Otimizada para Flash geralmente têm as seguintes características:

• Cargas de trabalho com uso intenso de leitura, com uma alta taxa de comandos de leitura para gravar comandos.
• O acesso se concentra em um subconjunto de chaves que você usa muito mais frequentemente do que o restante do conjunto de dados.
• Valores relativamente grandes em comparação com nomes de chave. (Como os nomes de chave são sempre armazenadas na RAM, os 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 Flash

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

• Cargas de trabalho com uso intenso de gravação.
• Padrões de acesso a dados aleatórios ou uniformes na maior parte do conjunto de dados.
• Nomes de chave longos com tamanhos de valor relativamente pequenos.

Conteúdo relacionado

• Escalonar uma instância do Redis Gerenciado pelo Azure