Arquitetura do Redis Gerenciado do Azure (versão prévia)
O Redis Gerenciado do Azure (versão prévia) é 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.
Importante
O Azure Managed Redis está atualmente em PREVIEW. Veja os Termos de Uso Complementares para Versões Prévias do Microsoft Azure para obter termos legais que se aplicam aos recursos do Azure que estão em versão beta, versão prévia ou que, de outra forma, ainda não foram lançados em disponibilidade geral.
Comparação com o Cache do Azure para Redis
As camadas Básica, Standard e Premium do Cache do Azure para Redis foram criadas na edição da comunidade do Redis. Esta versão do Redis tem várias limitações significativas, incluindo ter thread único por design. Isso reduz significativamente o desempenho e torna o dimensionamento menos eficiente, pois mais vCPUs não são totalmente utilizadas pelo serviço. 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 contém 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ó é capaz de executar um único processo de servidor Redis devido ao design de thread único 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 também recursos avançados, como replicação geográfica ativa
Clustering
Como o Redis Enterprise é capaz de usar vários fragmentos por nó, cada instância do Redis Gerenciado do Azure é configurada internamente para usar o clustering, em todas as camadas e SKUs. Isso 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 duas 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 duas opções para a política de clustering: OSS e Enterprise. A política de cluster do OSS é recomendada para a maioria dos aplicativos porque dá suporte a uma taxa de transferência máxima mais alta, mas há vantagens e desvantagens para cada versão.
A política de clustering do OSS implementa a mesma API de Cluster Redis que a edição da comunidade 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, permitindo que a taxa de transferência seja dimensionada quase linearmente à medida que o número de fragmentos e vCPUs aumenta. A política de clustering do OSS geralmente fornece a melhor latência e 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. A política de clustering OSS também só pode ser usado com o módulo RediSearch.
A política de clustering Enterprise é uma configuração mais simples que expõe um único ponto de extremidade para conexões de cliente. O uso da política de clustering Enterprise roteia todas as solicitações para um único nó Redis que, em seguida, é usado como um proxy, roteando internamente as solicitações para o nó correto no cluster. A vantagem dessa abordagem é que ela faz com que o Redis Gerenciado do Azure pareça não clusterizado 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, aumentando a compatibilidade com versões anteriores e tornando a conexão mais simples. 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 Enterprise é a única que pode ser usada 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 multi-chave.
Dimensionamento ou adição de nós
O software principal do Redis Enterprise é capaz de escalar verticalmente (usando VMs maiores) ou escalar horizontalmente (adicionando mais nós/VMs). Em última análise, qualquer ação de dimensionamento realiza a mesma coisa: adicionar mais memória, mais vCPUs e mais fragmentos. Devido a essa redundância, o Redis Gerenciado do Azure não oferece 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 o usuário evitar confusão, complexidade e configurações abaixo do ideal. Em vez disso, cada SKU é projetado com uma configuração de nó para maximizar vCPUs e memória. Alguns SKUs do Redis Gerenciados do Azure usam apenas dois nós, enquanto outros usam mais.
Comandos de várias chaves
Como as instâncias redis gerenciadas do Azure são projetadas com uma configuração clusterizada, você pode ver CROSSSLOT exceções 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, os comandos de várias chaves exigirão que todas as chaves sejam 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 de várias chaves são permitidos entre slots com clustering Enterprise: DEL, MSET, MGET, EXISTS, UNLINK e TOUCH.
Em bancos de dados Active-Active, os comandos de gravação de várias chaves (DEL, MSET, UNLINK) só podem ser executados em chaves que estão no mesmo slot. No entanto, os seguintes comandos multichave são permitidos entre slots em bancos de dados Active-Active: MGET, EXISTS e TOUCH. Para obter mais informações, consulte clustering banco de dados.
Configuração de fragmentação
Cada SKU do Redis Gerenciado do Azure é configurado para executar um número específico de processos de servidor Redis, fragmentos 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 é complicada. A adição de fragmentos geralmente aumenta o desempenho, pois as operações do Redis podem ser executadas em paralelo. No entanto, se os fragmentos não forem capazes de executar comandos porque nenhuma vCPU está disponível para executar comandos, o desempenho poderá realmente ser removido. A tabela a seguir mostra a configuração de fragmentação para cada SKU do Azure Managed Redis. Esses fragmentos são mapeados para otimizar o uso de cada vCPU, reservando ciclos de vCPU para tarefas de proxy, agente de gerenciamento e sistema operacional do Redis Enterprise que também afetam o desempenho.
Observação
O número de fragmentos e vCPUs usados em cada SKU pode mudar ao longo do tempo, pois o desempenho é otimizado pela equipe do Redis Gerenciado do Azure.
| Tiers | Flash Otimizado | Otimizado para memória | Balanced | Computação otimizada |
|---|---|---|---|---|
| Tamanho (GB) | vCPUs/fragmentos primários | vCPUs/fragmentos primários | vCPUs/fragmentos primários | vCPUs/fragmentos primários |
| 0.5 | - | - | 2/1 | - |
| 1 | - | - | 2/1 | - |
| 3 | - | - | 2/1 | 4/2 |
| 6 | - | - | 2/1 | 4/2 |
| 12 | - | 2/1 | 4/2 | 8/6 |
| 24 | - | 4/2 | 8/6 | 16/12 |
| 60 | - | 8/6 | 16/12 | 32/24 |
| 120 | - | 16/12 | 32/24 | 64/48 |
| 180 | - | 24/24 | 48/48 | 96/96 |
| 240 | 8/6 | 32/24 | 64/48 | 128/96 |
| 360 | - | 48/48 | 96/96 | 192/192 |
| 480 | 16/12 | 64/48 | 128/96 | 256/192 |
| 720 | 24/24 | 96/96 | 192/192 | 384/384 |
| 960 | 32/24 | 128/192 | 256/192 | - |
| 1440 | 48/48 | 192/192 | - | - |
| 1920 | 64/48 | 256/192 | - | - |
| 4500 | 144/96 | - | - | - |
Execução sem modo de alta disponibilidade habilitado
É possível executar sem o modo de alta disponibilidade (HA) habilitado. Isso 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 recomendamos a execução no modo não HA fora dos cenários de desenvolvimento/teste. Não é possível desabilitar a alta disponibilidade em uma instância que já foi criada. No entanto, 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/nós, as vCPUs não podem ser utilizadas 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, não há suporte para redução de escala no redis Gerenciado do Azure. Para obter mais informações, consulte Pré-requisitos/limitações de dimensionamento de redis gerenciados 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 está sendo 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 provavelmente serã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 é focado em um subconjunto de chaves que são usadas com muito mais frequência 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.