Compartilhar via

Dimensionar uma instância do Redis Gerenciado do Azure (versão prévia)

  • Artigo

O Redis Gerenciado do Azure (versão prévia) tem diferentes ofertas de SKU e camada que fornecem flexibilidade na escolha de tamanho e desempenho do cache. Você pode escalar verticalmente para um tamanho de memória maior ou mudar para uma camada com mais desempenho de computação. Este artigo mostra como escalar seu cache no portal do Azure, além de ferramentas como o Azure PowerShell e a CLI do Azure.

Observação

Como cada camada do Redis Gerenciado do Azure tem praticamente os mesmos recursos, o dimensionamento normalmente é usado apenas para alterar as características de memória e desempenho.

Importante

Atualmente, há suporte apenas para dimensionamento para tamanhos de memória maiores ou uma camada de desempenho mais alta. Ainda não há suporte para reduzir tamanhos de memória ou para uma camada com menor desempenho.

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.

  • 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 da edição da comunidade do Redis, que só pode utilizar uma única vCPU, o Redis Gerenciado do Azure usa a pilha Redis Enterprise, que é capaz de usar várias vCPUs. Isso 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.

Três camadas são para dados na memória:

  • Otimizado para memória. Ideal para casos de uso com uso intensivo de memória que exigem uma alta proporção de memória para vCPU (8:1), mas não precisam do mais alto desempenho de rendimento. 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.
  • Balanceado (Memória + Computação). Oferece uma proporção balanceada de memória para vCPU (4:1), tornando-o ideal para cargas de trabalho padrão. Ele fornece um equilíbrio íntegro de recursos de memória e computação.
  • Computação otimizada. Projetado para cargas de trabalho de alto desempenho que exigem rendimento máximo, com baixa proporção de memória para vCPU (2:1). É ideal para aplicativos que exigem o mais alto desempenho.

Uma camada armazena dados na memória e no disco:

  • Flash Otimizado. 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.

Camadas e SKUs rapidamente

Tabela mostrando as diferentes configurações de memória e vCPU para cada SKU e camada do Redis Gerenciado do Azure.

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.
  • 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 de 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.

Observação

Para obter mais informações sobre como otimizar o processo de escalonamento, confira o guia de práticas recomendadas para colocação em escala

Pré-requisitos/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.
  • Você não pode reduzir horizontalmente de para um SKU com menos vCPUs. (Entre camadas ou dentro de uma camada.)
  • Você não pode reduzir verticalmente para um tamanho de memória menor, mesmo que ela tenha as mesmas ou mais vCPUs.
  • 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 seu cache ou para configurar NSGs ou firewalls que permitem o tráfego para o cache, seu aplicativo poderá ter problemas para se conectar algum tempo após a atualização do 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.

Como dimensionar

Dica

Você pode alterar o tamanho da memória e a camada de desempenho em uma operação.

Escalar usando o portal do Azure

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

    Captura de tela mostrando a opção Escalar selecionada no menu Recurso de um cache Enterprise.

  2. Para escalar verticalmente, escolha um Tipo de cache diferente e escolha Salvar.

    Importante

    Se você selecionar um SKU que não pode ser dimensionado, a opção Salvar será desabilitada. Examine a seção pré-requisitos/limitações de dimensionamento do Redis Gerenciado do Azure seção para obter detalhes sobre quais opções de dimensionamento são permitidas.

    Captura de tela mostrando as camadas de serviço Enterprise no painel de trabalho.

  3. Enquanto o cache escala para a nova camada, uma notificação Escalando o Cache Redis é exibida.

    Captura de tela mostrando a notificação de colocação em escala de um cache Enterprise.

  4. Quando o dimensionamento for concluído, o status será alterado de Dimensionando para Executando.

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 myGroup -Name myCache -Sku ComputeOptimized_X20

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 "myCache" --resource-group "myGroup" --sku "ComputeOptimized_X20"

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?

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 menor ou tamanho de memória menor, consulte os pré-requisitos/limitações de dimensionamento do Redis Gerenciado do Azure.

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

Não, o nome do cache e as chaves permanecem inalterados 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, os dados transferidos e, em seguida, o outro nó faz um failover semelhante antes de ser reprovisionado. Isso é semelhante ao processo que ocorre durante a aplicação de patch ou uma falha de um dos nós de cache.
  • Ao dimensionar 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 os dados do 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 reduzindo verticalmente para um nível de memória menor, os dados poderão ser perdidos se o tamanho dos dados exceder o novo tamanho menor quando o cache for reduzido. Se dados forem perdidos ao se reduzir, as chaves serão removidas usando a política de remoção allkeys-lru .
  • 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.

O cache estará 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?

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.

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 for concluído, o status do cache será alterado para Executando.

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.

Qual é a diferença entre as políticas de cluster do OSS e do Enterprise?

A política de cluster do OSS é a mesma que a abordagem de clustering usada no Redis da edição da comunidade. Normalmente, a política de cluster do OSS tem um desempenho maior. A política de cluster empresarial implementa o clustering para que ele apareça em um cliente como uma instância não clusterizada do Redis. Essa abordagem pode ter menos desempenho, mas pode evitar problemas de compatibilidade do cliente. No momento, não é possível alternar entre políticas de cluster em uma instância em execução. Para obter mais informações, consulte Política de cluster.

Próximas etapas