Quais são as melhores práticas para as camadas Enterprise e Enterprise Flash
Veja as melhores práticas ao usar as camadas Enterprise e Enterprise Flash do Cache do Azure para Redis.
Redundância de Zona
Recomendamos que você implante novos caches em uma configuração com redundância de zona. A redundância de zona garante que os nós do Redis Enterprise sejam distribuídos entre três zonas de disponibilidade, aumentando a redundância de interrupções no nível do data center. O uso da redundância de zona aumenta a disponibilidade. Para mais informações, consulte Contratos de Nível de Serviço (SLA) para Serviços Online.
A redundância de zona é importante na camada Enterprise porque sua instância de cache sempre usa pelo menos três nós. Dois nós são nós de dados, que mantêm seus dados e um nó de quorum. Aumentar a capacidade dimensiona o número de nós de dados em incrementos de número par.
Há também outro nó chamado nó de quorum. Esse nó monitora os nós de dados e seleciona automaticamente o novo nó primário se houver um failover. A redundância de zona garante que os nós sejam distribuídos uniformemente em três zonas de disponibilidade, minimizando o potencial de perda de quorum. Os clientes não são cobrados pelo nó de quorum e não há nenhuma outra cobrança pelo uso da redundância de zona além dos encargos de largura de banda intra zonal.
Scaling
Nas camadas Enterprise e Enterprise Flash do Cache do Azure para Redis, recomendamos priorizar a escala vertical em vez da escalar horizontal. Priorize a escala vertical porque as camadas Enterprise são criadas no Redis Enterprise, que tem capacidade de utilizar mais núcleos de CPU em VMs maiores.
Por outro lado, a recomendação oposta é verdadeira para as camadas Básica, Standard e Premium, que são criadas em Redis de software livre. Nessas camadas, recomendamos priorizar a escala horizontal em vez da escala vertical na maioria dos casos.
Fragmentação e utilização da CPU
Nas camadas Básica, Standard e Premium de Cache do Azure para Redis, determinar o número de CPUs virtuais (vCPUs) utilizadas é simples. Cada nó Redis é executado em uma VM dedicada. O processo do servidor Redis é de thread único, utilizando uma vCPU em cada nó primário e cada nó de réplica. As outras vCPUs na VM ainda são usadas para outras atividades, como coordenação de fluxo de trabalho para tarefas diferentes, monitoramento de integridade e carga TLS, entre outras.
Quando você usa clustering, o efeito é espalhar dados entre mais nós com um fragmento por nó. Ao aumentar o número de fragmentos, você aumenta linearmente o número de vCPUs que usa, com base no número de fragmentos no cluster.
O Redis Enterprise, por outro lado, pode usar várias vCPUs para a própria instância do Redis. Em outras palavras, todas as camadas de Cache do Azure para Redis podem usar várias vCPUs para tarefas em segundo plano e monitoramento, mas apenas as camadas Enterprise e Enterprise Flash são capazes de utilizar várias vCPUs por VM para fragmentos redis. A tabela mostra o número de vCPUs eficazes usadas para cada SKU e a configuração de capacidade (ou seja, expansão).
As tabelas mostram o número de vCPUs usadas para os fragmentos primários, não os fragmentos de réplica. Os fragmentos não mapeiam um para um para o número de vCPUs. As tabelas ilustram apenas vCPUs, não fragmentos. Algumas configurações usam mais fragmentos do que vCPUs disponíveis para aumentar o desempenho em alguns cenários de uso.
E5
| Capacity | VCPUs eficazes |
|---|---|
| 2 | 1 |
| 4 | 2 |
| 6 | 6 |
E10
| Capacity | VCPUs eficazes |
|---|---|
| 2 | 2 |
| 4 | 6 |
| 6 | 6 |
| 8 | 16 |
| 10 | 20 |
E20
| Capacity | VCPUs eficazes |
|---|---|
| 2 | 2 |
| 4 | 6 |
| 6 | 6 |
| 8 | 16 |
| 10 | 20 |
E50
| Capacity | VCPUs eficazes |
|---|---|
| 2 | 6 |
| 4 | 6 |
| 6 | 6 |
| 8 | 30 |
| 10 | 30 |
E100
| Capacity | VCPUs eficazes |
|---|---|
| 2 | 6 |
| 4 | 30 |
| 6 | 30 |
| 8 | 30 |
| 10 | 30 |
E200
| Capacity | VCPUs eficazes |
|---|---|
| 2 | 30 |
| 4 | 60 |
| 6 | 60 |
| 8 | 120 |
| 10 | 120 |
E400
| Capacity | VCPUs eficazes |
|---|---|
| 2 | 60 |
| 4 | 120 |
| 6 | 120 |
| 8 | 240 |
| 10 | 240 |
F300
| Capacity | VCPUs eficazes |
|---|---|
| 3 | 6 |
| 9 | 30 |
F700
| Capacity | VCPUs eficazes |
|---|---|
| 3 | 30 |
| 9 | 30 |
F1500
| Capacity | VCPUs eficazes |
|---|---|
| 3 | 30 |
| 9 | 90 |
Clustering em Enterprise
As camadas Enterprise e Enterprise Flash são inerentemente clusteradas, em contraste com as camadas Básica, Standard e Premium. A implementação depende da política de clustering selecionada. As camadas Enterprise oferecem 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 o Redis de software livre. A API do Cluster Redis permite que o cliente Redis se conecte diretamente a cada nó Redis, minimizando a latência e otimizando a taxa de transferência de rede. Como resultado, a escalabilidade quase linear é obtida ao escalar o cluster com mais nós. A política de clustering do OSS geralmente fornece a melhor latência e desempenho de taxa de transferência, mas exige que sua biblioteca de clientes dê suporte ao Clustering Redis. 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 as bibliotecas de clientes do Redis não precisam dar suporte ao Clustering Redis para aproveitar vários nós. 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.
Comandos de várias chaves
Como as camadas Enterprise usam uma configuração clusterizado, 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.
Melhores práticas do Enterprise Flash
A camada Enterprise Flash utiliza armazenamento Flash NVMe e RAM. Como o armazenamento Flash é de menor custo, o uso da camada Enterprise Flash permite que você troque um pouco de desempenho por eficiência de preço.
Em instâncias do Enterprise 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 local dos valores é determinado de forma inteligente pelo software Redis. 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 optará pelo melhor desempenho, a instância primeiro preencherá a RAM disponível antes de adicionar itens ao armazenamento Flash. Isso tem algumas implicações para o desempenho:
- Ao testar com baixo uso de memória, o desempenho e a latência podem ser significativamente melhores do que com uma instância de cache cheia, pois apenas a RAM está sendo usada.
- À medida que você grava mais dados no cache, a proporção de dados em RAM em comparação com o armazenamento Flash diminuirá, normalmente fazendo com que o desempenho de latência e taxa de transferência também diminua.
Cargas de trabalho adequadas para a camada Enterprise Flash
As cargas de trabalho que provavelmente funcionarão bem na camada Enterprise 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, isso pode se tornar um gargalo para o crescimento da memória.)
Cargas de trabalho que não são adequadas para a camada Enterprise Flash
Algumas cargas de trabalho têm características de acesso menos otimizadas para o design da camada 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.
Manipulando cenários de região para baixo com replicação geográfica ativa
A replicação geográfica ativa é um recurso poderoso para aumentar drasticamente a disponibilidade ao usar as camadas Enterprise de Cache do Azure para Redis. No entanto, você deve tomar medidas para preparar seus caches se houver uma interrupção regional.
Por exemplo, considere estas dicas:
- Identifique com antecedência para qual outro cache no grupo de replicação geográfica alternar para se uma região ficar inoperante.
- Verifique se os firewalls estão definidos para que todos os aplicativos e clientes possam acessar o cache de backup identificado.
- Cada cache no grupo de replicação geográfica tem sua própria chave de acesso. Determine como o aplicativo alternará para diferentes chaves de acesso ao ter como destino um cache de backup.
- Se um cache no grupo de replicação geográfica ficar inativo, um acúmulo de metadados começará a ocorrer em todos os caches do grupo de replicação geográfica. Os metadados não podem ser descartados até que as gravações possam ser sincronizadas novamente com todos os caches. Você pode impedir o acúmulo de metadados forçando a desvinculação do cache que está inativo. Considere monitorar a memória disponível no cache e desvincular se houver pressão de memória, especialmente para cargas de trabalho pesadas de gravação.
Também é possível usar um padrão de disjuntor. Use o padrão para redirecionar automaticamente o tráfego de um cache que enfrenta uma interrupção de região e para um cache de backup no mesmo grupo de replicação geográfica. Use serviços do Azure, como o Gerenciador de Tráfego do Azure ou Azure Load Balancer para habilitar o redirecionamento.
Persistência de dados versus Backup de Dados
O recurso de persistência de dados nas camadas Enterprise e Enterprise Flash foi projetado para fornecer automaticamente um ponto de recuperação rápida para dados quando um cache fica inoperante. A recuperação rápida é possível armazenando o arquivo RDB ou AOF em um disco gerenciado montado na instância de cache. Os arquivos de persistência no disco não são acessíveis aos usuários.
Muitos clientes desejam usar a persistência para fazer backups periódicos dos dados em seu cache. Não recomendamos que você use a persistência de dados dessa maneira. Em vez disso, use o recurso importação/exportação. Você pode exportar cópias de dados de cache no formato RDB diretamente para sua conta de armazenamento escolhida e disparar a exportação de dados com a frequência necessária. A exportação pode ser disparada no portal ou usando as ferramentas CLI, PowerShell ou SDK.