Quais são as práticas recomendadas para as camadas Enterprise e Enterprise Flash
Aqui estão as práticas recomendadas ao usar as camadas Enterprise e Enterprise Flash do Cache do Azure para Redis.
Redundância entre Zonas
É altamente recomendável implantar novos caches em uma configuração redundante de zona. A redundância de zona garante que os nós Redis Enterprise estejam 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 obter 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 armazenam seus dados, e um nó de quorum. O aumento da capacidade dimensiona o número de nós de dados em incrementos de número par.
Há também outro nó chamado nó de quórum. 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 quórum. Os clientes não são cobrados pelo nó de quorum e não há outra cobrança pelo uso da redundância de zona além das taxas de largura de banda intrazonal.
Dimensionamento
Nas camadas Enterprise e Enterprise Flash do Cache do Azure para Redis, recomendamos priorizar a expansão em vez da expansão. Priorize a expansão porque as camadas Enterprise são criadas no Redis Enterprise, que é capaz de utilizar mais núcleos de CPU em VMs maiores.
Por outro lado, a recomendação oposta é verdadeira para as camadas Basic, Standard e Premium, que são construídas em Redis de código aberto. Nesses níveis, recomenda-se priorizar a expansão em detrimento da expansão na maioria dos casos.
Compartilhamento e utilização da CPU
Nas camadas Basic, Standard e Premium do 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 é single-threaded, utilizando uma vCPU em cada nó primário e em 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 diferentes tarefas, monitoramento de integridade e carga TLS, entre outras.
Quando você usa clustering, o efeito é espalhar dados por mais nós com um fragmento por nó. Ao aumentar o número de fragmentos, você aumenta linearmente o número de vCPUs usadas, 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 do Cache Redis do Azure podem usar várias vCPUs para tarefas em segundo plano e de monitoramento, mas apenas as camadas Enterprise e Enterprise Flash podem utilizar várias vCPUs por VM para fragmentos Redis. A tabela mostra o número de vCPUs efetivas usadas para cada configuração de SKU e capacidade (ou seja, scale-out).
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
| Capacidade | VCPUs eficazes |
|---|---|
| 2 | 1 |
| 4 | 2 |
| 6 | 6 |
E10
| Capacidade | VCPUs eficazes |
|---|---|
| 2 | 2 |
| 4 | 6 |
| 6 | 6 |
| 8 | 16 |
| 10 | 20 |
E20
| Capacidade | VCPUs eficazes |
|---|---|
| 2 | 2 |
| 4 | 6 |
| 6 | 6 |
| 8 | 16 |
| 10 | 20 |
E50
| Capacidade | VCPUs eficazes |
|---|---|
| 2 | 6 |
| 4 | 6 |
| 6 | 6 |
| 8 | 30 |
| 10 | 30 |
E100
| Capacidade | VCPUs eficazes |
|---|---|
| 2 | 6 |
| 4 | 30 |
| 6 | 30 |
| 8 | 30 |
| 10 | 30 |
E200
| Capacidade | VCPUs eficazes |
|---|---|
| 2 | 30 |
| 4 | 60 |
| 6 | 60 |
| 8 | 120 |
| 10 | 120 |
E400
| Capacidade | VCPUs eficazes |
|---|---|
| 2 | 60 |
| 4 | 120 |
| 6 | 120 |
| 8 | 240 |
| 10 | 240 |
F300
| Capacidade | VCPUs eficazes |
|---|---|
| 3 | 6 |
| 9 | 30 |
F700
| Capacidade | VCPUs eficazes |
|---|---|
| 3 | 30 |
| 9 | 30 |
F1500
| Capacidade | VCPUs eficazes |
|---|---|
| 3 | 30 |
| 9 | 90 |
Clustering na Empresa
As camadas Enterprise e Enterprise Flash são inerentemente agrupadas, em contraste com as camadas Basic, 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 OSS é recomendada para a maioria dos aplicativos porque oferece suporte a uma taxa de transferência máxima mais alta, mas há vantagens e desvantagens em cada versão.
A política de cluster OSS implementa a mesma API de Cluster Redis que o Redis de código aberto. 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 da rede. Como resultado, a escalabilidade quase linear é obtida ao dimensionar o cluster com mais nós. A política de clustering OSS geralmente fornece o melhor desempenho de latência e taxa de transferência, mas requer que sua biblioteca de cliente ofereça suporte ao Clustering Redis. A política de cluster OSS também não pode ser usada com o módulo RediSearch.
A política de cluster Enterprise é uma configuração mais simples que utiliza um único ponto de extremidade para todas as conexões de cliente. O uso da política de cluster Enterprise roteia todas as solicitações para um único nó Redis que é usado como proxy, roteando internamente as solicitações para o nó correto no cluster. A vantagem dessa abordagem é que as bibliotecas de cliente Redis não precisam oferecer suporte ao Clustering Redis para aproveitar vários nós. A desvantagem é que o proxy de nó único pode ser um gargalo, tanto na utilização da computação quanto na taxa de transferência da rede. A política de cluster Enterprise é a única que pode ser usada com o módulo RediSearch.
Comandos multiteclas
Como as camadas Enterprise usam 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 cluster OSS, os comandos de várias teclas 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 cluster Enterprise. Somente os seguintes comandos multichave são permitidos em slots com cluster Enterprise: DEL, MSET, MGET, EXISTS, UNLINKe TOUCH.
Em bancos de dados Ativo-Ativo, os comandos de gravação de várias teclas (DEL, MSETUNLINK, ) só podem ser executados em chaves que estejam no mesmo slot. No entanto, os seguintes comandos de várias teclas são permitidos entre slots em bancos de dados Active-Active: MGET, EXISTSe TOUCH. Para obter mais informações, consulte Clustering de banco de dados.
Práticas recomendadas do Enterprise Flash
A camada Enterprise Flash utiliza armazenamento NVMe Flash e RAM. Como o armazenamento Flash é de menor custo, o uso da camada Enterprise Flash permite que você troque algum desempenho por eficiência de preço.
Em instâncias Enterprise Flash, 20% do espaço em cache está 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. A localização dos valores é determinada de forma inteligente pelo software Redis. Os valores "Hot" que são acessados fequently são armazenados na RAM, enquanto os valores "Cold" que são menos comumente 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 optará pelo melhor desempenho, a instância primeiro preencherá a RAM disponível antes de adicionar itens ao armazenamento Flash. Isto 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 completa, pois apenas a RAM está sendo usada.
- À medida que você grava mais dados no cache, a proporção de dados na RAM em comparação com o armazenamento Flash diminuirá, 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 Enterprise Flash
As cargas de trabalho que provavelmente funcionarão bem na camada Enterprise Flash geralmente têm as seguintes características:
- Leitura pesada, com uma alta proporção de comandos de leitura para escrever comandos.
- O acesso é focado em um subconjunto de chaves que são usadas com muito mais frequência 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, 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:
- Escreva cargas de trabalho pesadas.
- Acesso aleatório ou uniforme a dados na maior parte do conjunto de dados.
- Nomes de chaves longos com tamanhos de valor relativamente pequenos.
Lidando com cenários de região inativa 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 do 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 se uma região ficar inativa.
- Certifique-se de que os firewalls estejam 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 alterna para diferentes chaves de acesso ao direcionar 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 no 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 inativo. Considere monitorar a memória disponível no cache e desvincular se houver pressão de memória, especialmente para cargas de trabalho de gravação pesadas.
Também é possível usar um padrão de disjuntor. Use o padrão para redirecionar automaticamente o tráfego de um cache que sofre uma interrupção de região 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 o Balanceador de Carga do Azure, para habilitar o redirecionamento.
Persistência de dados vs 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 os dados quando um cache fica inativo. 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 estão acessíveis aos usuários.
Muitos clientes querem 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 de importação/exportação . Você pode exportar cópias de dados de cache no formato RDB diretamente para sua conta de armazenamento escolhida e acionar a exportação de dados com a frequência necessária. A exportação pode ser acionada a partir do portal ou usando as ferramentas CLI, PowerShell ou SDK.