Dimensionar uma instância do Redis Gerenciado do Azure

O Redis Gerenciado do Azure tem diferentes ofertas de SKU e camada que fornecem flexibilidade na escolha do tamanho e do desempenho do cache. Você pode dimensionar para um tamanho de memória maior ou mudar para uma camada com mais desempenho de computação. Você também pode diminuir para um nível menor ou mais apropriado. Este artigo mostra como escalar seu cache no portal do Azure, além de ferramentas como o Azure PowerShell e a CLI do Azure.

Tipos de dimensionamento

O Redis Gerenciado do Azure dá suporte ao dimensionamento em duas dimensões:

• Memória Aumentando a memória aumenta o tamanho da instância do Redis, permitindo que você armazene mais dados. Ao reduzir a memória, você precisa garantir que o uso de memória atual seja menor que o novo tamanho de memória que você deseja usar.

• O VCPUs Azure Managed Redis oferece três camadas (Otimizado para Memória, Balanceado e Computação otimizada) que têm um número crescente de vCPUs para cada nível de memória. O dimensionamento para uma camada com mais vCPUs aumenta o desempenho da instância sem exigir que você aumente a memória. Ao contrário das camadas Básica, Standard e Premium do Cache do Azure para Redis que utilizam apenas uma única vCPU, o Redis Gerenciado do Azure usa a pilha Redis Enterprise. A pilha Redis Enterprise é capaz de usar várias vCPUs, o que significa que o número de vCPUs usados pela instância do Redis correlaciona-se diretamente com o desempenho de taxa de transferência e latência.

Níveis de desempenho

Há quatro camadas de Redis Gerenciados do Azure disponíveis, cada uma com diferentes características de desempenho e níveis de preço.

Níveis e SKUs em resumo

Aqui estão três níveis que armazenam dados na memória:

• Otimizado para memória Ideal para casos de uso com uso intensivo de memória que exigem uma alta taxa de memória para vCPU (8:1), mas não precisam do desempenho de taxa de transferência mais alto. Ele fornece um ponto de preço mais baixo para cenários em que menos poder de processamento ou taxa de transferência é necessário, tornando-o uma excelente opção para ambientes de desenvolvimento e teste.

• Equilibrado (Memória + Computação) Oferece uma taxa equilibrada de memória para vCPU (4:1), tornando esta opção ideal para cargas de trabalho padrão. Essa camada fornece um equilíbrio saudável de recursos de memória e computação.

• Computação otimizada Projetado para cargas de trabalho com uso intensivo de desempenho que exigem taxa de transferência máxima, com uma baixa taxa de memória para vCPU (2:1). É ideal para aplicativos que exigem o desempenho mais alto.

  

Aqui está a camada que armazena dados na memória e no disco:

• Otimizado para Flash (versão prévia) Permite que os clusters Redis movam automaticamente dados acessados com menos frequência da memória (RAM) para o armazenamento NVMe. Isso reduz o desempenho, mas permite o dimensionamento econômico de caches com grandes conjuntos de dados.

  

Desempenho (taxa de transferência e latência)

Para obter parâmetros de comparação de desempenho e mais informações sobre como medir o desempenho de cada SKU e camada, consulte Teste de desempenho com o Redis Gerenciado do Azure

Quando dimensionar

Você pode usar os recursos de monitoramento do Redis Gerenciado do Azure para monitorar a integridade e o desempenho do cache. Use essas informações para determinar quando escalonar o cache.

Você pode monitorar as métricas a seguir para determinar se é preciso escalonar.

• CPU
  • O alto uso da CPU significa que o servidor Redis não consegue acompanhar as solicitações de todos os clientes. Escalar verticalmente para mais vCPUs ajuda a distribuir solicitações em vários processos do Redis. O dimensionamento também ajuda a distribuir criptografia/descriptografia do TLS e conexão/desconexão, acelerando instâncias de cache usando TLS.
• Uso de Memória
  • O uso de memória alta indica que o tamanho dos dados é muito grande para o tamanho do cache atual. Considere a possibilidade de dimensionar para um tamanho de cache com memória maior. Ao reduzir a memória, você precisa garantir que o uso da memória do cache atual seja menor do que o novo tamanho de memória que você deseja usar. Você não pode colocar um conjunto de dados grande em um tamanho de cache menor.
• Conexões de cliente
  • Cada tamanho de cache tem um limite para o número de conexões de cliente às quais ele pode dar suporte. Se as conexões de cliente estiverem próximas do limite para o tamanho do cache, considere dimensionar para um tamanho de memória maior ou uma camada de desempenho mais alta.
  • Para obter mais informações sobre limites de conexão por tamanho de cache, consulte Teste de desempenho com o Azure Managed Redis.
• Largura de banda da rede
  • Se o servidor Redis exceder a largura de banda disponível, as solicitações de clientes poderão atingir o tempo limite porque o servidor não pode enviar dados por push para o cliente de forma rápida o suficiente. Para ver a quantidade de largura de banda do lado do servidor que está sendo usada, verifique as métricas "Leitura de Cache" e "Gravação de Cache". Se o servidor Redis estiver excedendo a largura de banda de rede disponível, considere o dimensionamento para uma camada de desempenho mais alta ou um tamanho de cache maior.
  • A escolha da política de cluster afeta a largura de banda de rede disponível. Em geral, a política de cluster do OSS tem maior largura de banda de rede do que a política de cluster Enterprise. Para obter mais informações, consulte Política de cluster
  • Para obter mais informações sobre a largura de banda disponível na rede pelo tamanho do cache, consulte Teste de desempenho com Redis Gerenciados do Azure.

Para obter mais informações sobre como determinar o tipo de preço de cache a ser usado, consulte Escolhendo a camada certa.

Para obter mais informações sobre como otimizar o processo de dimensionamento, consulte as práticas recomendadas para o guia de dimensionamento.

Limitações de dimensionamento do Redis Gerenciado do Azure

• Você não pode dimensionar das camadas Otimizada para memória, Balanceada ou Computação otimizada para a camada Otimizada para Flash ou vice-versa.
• Ao reduzir a memória da instância do Redis, o uso de memória atual da instância do Redis deve ser menor do que o novo tamanho de memória pretendido. Para obter mais informações, consulte O que acontece com meus dados se eu dimensionar para um tamanho de memória menor?.
• Ao reduzir a memória ou a vCPU para sua instância do Redis, você só pode fazer o dimensionamento para SKUs que tenham uma configuração de vCPU e shard compatível com a configuração da sua instância atual.
• Em alguns casos, ao dimensionar, o endereço IP subjacente da instância do Redis pode ser alterado. O registro DNS para a instância é alterado e é transparente para a maioria dos aplicativos. No entanto, se você usar um endereço IP para configurar a conexão com sua instância do Redis ou para configurar NSGs ou firewalls permitindo o tráfego para a instância do Redis, seu aplicativo poderá ter problemas para se conectar em algum momento após as atualizações de registro DNS.
• O dimensionamento de uma instância em um grupo de replicação geográfica tem mais algumas limitações. Veja Se há limitações de dimensionamento com replicação geográfica? Para obter mais informações.
• Quando você reduz verticalmente, você só pode dimensionar para determinadas camadas. Para obter mais informações, consulte Por que só posso reduzir para um subconjunto menor de SKUs?.

Como escalar

Nesta seção, descrevemos como dimensionar um cache Redis Gerenciado do Azure.

Escalar usando o portal do Azure

1. Para escalonar seu cache, navegue até ele no portal do Azure e selecione Escalar no menu Recurso.

2. Para dimensionar suas vCPUs, escolha um tipo de Cache diferente e, em seguida, escolha Salvar.

   Importante

   Se você selecionar um SKU que não pode ser dimensionado, a opção Salvar será desabilitada. Revise a seção Limitações de Dimensionamento do Redis Gerenciado do Azure para obter detalhes sobre quais opções de dimensionamento são permitidas.

3. Quando o dimensionamento é concluído, o status muda de Dimensionamento para Execução ao exibir a seção Visão geral do menu Recurso.

Dimensionar usando o PowerShell

Você pode dimensionar suas instâncias redis gerenciadas do Azure com o PowerShell usando o cmdlet Update-AzRedisEnterpriseCache. Você pode modificar a propriedade Sku para selecionar a camada e a SKU necessárias. O exemplo a seguir mostra como dimensionar um cache chamado myCache para uma instância de Computação Otimizada X20 (24 GB).

   Update-AzRedisEnterpriseCache -ResourceGroupName <your-group> -Name <your-cache-name> -Sku <sku-name>

Dimensionar usando a CLI do Azure

Para escalar suas instâncias do Redis Gerenciado do Azure usando a CLI do Azure, chame o comando az redisenterprise update. Você pode modificar a propriedade sku para selecionar a camada e a SKU necessárias. O exemplo a seguir mostra como dimensionar um cache chamado myCache para uma instância de Computação Otimizada X20 (24 GB).

az redisenterprise update --cluster-name <your-cache-name> --resource-group <your-resource-group> --sku <name-of-sku>

Perguntas frequentes sobre dimensionamento

A lista a seguir contém respostas para perguntas frequentes sobre o dimensionamento do Redis Gerenciado do Azure.

• Posso dimensionar dentro ou entre camadas?
• O que acontece com meus dados se eu dimensionar para um tamanho de memória menor?
• Depois do dimensionamento, é necessário alterar minhas chaves de acesso ou o nome do cache?
• Como funciona o dimensionamento?
• Perco os dados do meu cache durante a colocação em escala?
• Meu cache está disponível durante o dimensionamento?
• Há limitações de dimensionamento com a replicação geográfica?
• Quanto tempo o dimensionamento leva?
• Como saber quando o dimensionamento é concluído?
• O Redis Gerenciado do Azure usa clustering?Quantos fragmentos cada SKU redis gerenciado do Azure usa?
• Como as chaves são distribuídas em um cluster?
• Qual é o maior tamanho de cache que eu posso criar?
• Por que só posso reduzir para um subconjunto de SKUs menores?
• A Política de Clustering pode ser alterada depois de selecionar o OSS ou o Enterprise Cluster?

Posso dimensionar dentro ou entre camadas?

Você sempre pode dimensionar para uma camada de desempenho mais alta com o mesmo tamanho de memória ou um tamanho de memória maior dentro da mesma camada de desempenho. Para dimensionar para uma camada de desempenho inferior ou um tamanho de memória menor, recomendamos que você execute a API REST "listskusforscaling" para obter a lista de SKUs para as quais você pode dimensionar.

az redisenterprise list-skus-for-scaling --cluster-name <your-redis-instance> --resource-group <your-resource-group>

O que acontece com meus dados se eu dimensionar para um tamanho de memória menor?

Você só poderá dimensionar para um tamanho de memória menor se o uso de memória atual for menor do que o tamanho de memória menor pretendido. Se o uso de memória atual for maior do que o tamanho menor pretendido, sua solicitação de dimensionamento falhará. Você pode reduzir o uso atual de memória excluindo pares chave-valor indesejados ou executando a operação de limpeza.

az redisenterprise database flush --cluster-name <your-redis-instance> --resource-group <your-resource-group>

Depois do dimensionamento, é necessário alterar minhas chaves de acesso ou o nome do cache?

Não, o nome do cache e as chaves de acesso não são alterados durante uma operação de dimensionamento.

Como funciona o dimensionamento?

• Quando você dimensiona uma instância do Redis, um dos nós no cluster Redis é desligado e reprovisionado para o novo tamanho. Em seguida, as transferências de dados são concluídas e o outro nó faz um failover semelhante antes da reaprovisionamento. O desligamento e o reprovisionamento são semelhantes ao processo que ocorre durante a aplicação de um patch ou uma falha de um dos nós de um cache.
• Quando você dimensiona para uma instância com mais vCPUs, novos fragmentos são provisionados e adicionados ao cluster do servidor Redis. Os dados são então refragmentados em todos os fragmentos.

Para obter mais informações sobre como o Redis Gerenciado do Azure lida com a fragmentação, consulte Configuração de fragmentação.

Perco dados de meu cache durante a colocação em escala?

• Se o modo de alta disponibilidade estiver habilitado, todos os dados deverão ser preservados durante operações de dimensionamento.
• Se você estiver dimensionando para um nível de memória menor, precisará garantir que o uso da memória atual seja menor do que o novo tamanho de memória pretendido. Se o uso de memória atual for maior do que o tamanho de memória SKU pretendido, você poderá liberar seus dados usando a operação Flush ou escolher manualmente os valores de chave a serem excluídos.
• Se o modo de alta disponibilidade estiver desabilitado, todos os dados serão perdidos e o cache não estará disponível durante a operação de dimensionamento.

Meu cache está disponível durante o dimensionamento?

• As instâncias redis gerenciadas do Azure com modo de alta disponibilidade habilitado permanecem disponíveis durante a operação de dimensionamento. No entanto, os blips de conexão podem ocorrer durante o dimensionamento desses caches. Esses blips de conexão normalmente são curtos e os clientes Redis geralmente podem restabelecer sua conexão instantaneamente.
• Se o modo de alta disponibilidade estiver desabilitado, a instância do Redis Gerenciado do Azure estará offline durante operações de dimensionamento.

Há limitações de dimensionamento com a replicação geográfica?

O dimensionamento de caches geograficamente replicados está em Visualização Pública. Com a replicação geográfica ativa configurada, você não pode misturar e corresponder aos tamanhos de cache em um grupo de replicação geográfica. Como resultado, o dimensionamento dos caches em um grupo de replicação geográfica requer mais algumas etapas. Consulte Instâncias de dimensionamento em um grupo de replicação geográfica para obter instruções.

Não há suporte para diminuir para um tamanho de memória menor ou uma contagem menor de fragmentos para caches com replicação geográfica. Para obter mais informações, consulte Quantos fragmentos cada SKU do Redis Gerenciado do Azure usa para descobrir fragmentos em seu cluster.

Quanto tempo o dimensionamento leva?

O tempo de dimensionamento depende de alguns fatores. Aqui estão alguns fatores que podem afetar quanto tempo o dimensionamento leva.

• Quantidade de dados: quantidades maiores de dados levam mais tempo para serem replicadas
• Solicitações de gravação alta: maior número de gravações significa mais replicações de dados entre nós ou fragmentos
• Alto uso da CPU: uso mais alto da CPU significa que o servidor Redis está ocupado e ciclos limitados de CPU estão disponíveis para concluir a redistribuição de dados

Geralmente, quando você dimensiona uma instância sem dados, leva aproximadamente 10 minutos.

Como saber quando o dimensionamento é concluído?

No portal do Azure, você pode ver a operação de dimensionamento em andamento. Quando o dimensionamento é concluído, o status do cache é alterado para Execução ao exibir Visão geral no menu Recurso.

O Redis Gerenciado do Azure usa clustering?

Ao contrário do Cache do Azure para Redis, o Redis Gerenciado do Azure usa clustering em todas as camadas e SKUs. O clustering permite otimizações significativas de desempenho. Cada SKU do Redis Gerenciado do Azure é configurado para um número otimizado de fragmentos para o número de vCPUs disponíveis. O número de fragmentos não é configurável pelo usuário.

Quantos fragmentos cada SKU redis gerenciado do Azure usa?

Como o Redis Gerenciado do Azure é executado no software Redis Enterprise, os fragmentos podem ser usados em uma configuração mais densa do que no Redis da comunidade. Para saber mais sobre o número específico de fragmentos usados em cada SKU, consulte Configuração de fragmentação.

Como as chaves são distribuídas em um cluster?

De acordo com a documentação do Redis sobre o modelo de distribuição de chaves: o espaço da chave é dividido em 16.384 slots. Cada chave é resumida e atribuída a um desses slots, que são distribuídos entre os nós do cluster. Você pode configurar qual parte da chave é resumida para garantir que várias chaves estejam localizadas no mesmo fragmento usando hashtags.

• Chaves com marca hash – se alguma parte da chave estiver entre { e }, somente essa parte da chave terá hash, a fim de determinar o slot de hash de uma chave. Por exemplo, as três chaves a seguir devem estar localizadas no mesmo fragmento: {key}1, {key}2 e {key}3, uma vez que apenas a parte key do nome está entre chaves. Para obter uma lista completa das especificações da marca hash de chaves, confira Keys hash tags.
• Chaves sem uma marca de hash: todo o nome da chave é usado para hash, resultando em uma distribuição estatisticamente uniforme entre os fragmentos do cache.

Para obter um melhor desempenho e uma melhor taxa de transferência, recomendamos distribuir as chaves por igual. Se você estiver usando chaves com uma hashtag, é responsabilidade do aplicativo garantir que as chaves sejam distribuídas uniformemente.

Para saber mais, confira Keys distribution model, Redis Cluster data sharding e Keys hash tags.

Qual é o maior tamanho de cache que eu posso criar?

O maior tamanho de cache que você pode ter é de 4,5 TB, chamado de instância A4500 otimizada para Flash. Preço do Cache do Azure para Redis.

Por que só eu posso diminuir para um subconjunto de SKUs menores?

Para manter a compatibilidade com o número de fragmentos e vCPU, você tem permissão para reduzir horizontalmente apenas para determinadas SKUs. Você pode ver para quais SKUs sua instância do Redis pode reduzir verificando as opções disponíveis na seção Dimensionar do portal do Azure. Você também pode executar o comando da CLI a seguir.

Você pode ver para quais SKUs sua instância do Redis pode reduzir verificando as opções disponíveis na seção Dimensionar do portal do Azure.

az redisenterprise list-skus-for-scaling --cluster-name <your-redis-instance> --resource-group <your-resource-group>

A Política de Clustering pode ser alterada depois de selecionar o OSS ou o Enterprise Cluster?

Depois de definir uma política de clustering para OSSCluster ou EnterpriseCluster ao criar um cache, você não poderá alterá-la. Para mudar para uma política de clustering diferente, você deve excluir o cache Redis e recriá-lo com a configuração desejada. Somente os caches com a política Não Agrupada podem ser atualizados para uma configuração agrupada após a implantação.

Conteúdo relacionado

• Melhores práticas de dimensionamento