Partilhar via

Dimensionar uma instância do Azure Managed Redis

  • Aplica-se a: ✅ Azure Managed Redis

O Azure Managed Redis tem diferentes ofertas de SKU e camadas que fornecem flexibilidade na escolha do tamanho e 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 reduzir para uma camada menor ou mais apropriada. Este artigo mostra-lhe como dimensionar a sua cache utilizando o portal do Azure, além de ferramentas como o Azure PowerShell e a CLI do Azure.

Observação

Como cada camada do Azure Managed Redis tem quase os mesmos recursos, o dimensionamento normalmente é usado apenas para alterar as características de memória e desempenho. O dimensionamento de caches Redis gerenciados do Azure replicados geograficamente permanece na Visualização Pública.

Tipos de dimensionamento

O Azure Managed Redis suporta o dimensionamento em duas dimensões:

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

  • vCPUs O Azure Managed Redis oferece três escalões (Otimizado para Memória, Equilibrado e Otimizado para Computação) que têm um número crescente de vCPUs para cada nível de memória. O dimensionamento para um escalão com mais vCPUs aumenta o desempenho da sua instância sem exigir que 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 Azure Managed Redis usa a pilha Redis Enterprise. A pilha Redis Enterprise é capaz de usar várias vCPUs, o que significa que o número de vCPUs usadas pela sua instância Redis está diretamente correlacionado com a taxa de transferência e o desempenho de latência.

Escalões de desempenho

Existem quatro escalões do Azure Managed Redis disponíveis, cada um com diferentes caraterísticas de desempenho e níveis de preço.

Importante

Todos os níveis em memória que utilizam mais de 235 GB de armazenamento estão em Visualização Pública, incluindo Otimizado para Memória M350 e superiores; Balanceado B350 e superiores; e Otimizado para Computação X350 e superiores. Todos esses níveis e superiores estão em Visualização Pública.

Todos os níveis otimizados para Flash estão em Visualização pública.

Níveis e SKUs em resumo

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

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

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

  • Computação otimizada Projetado para cargas de trabalho de alto desempenho que exigem taxa de transferência máxima, com uma baixa relação memória/vCPU (2:1). É ideal para aplicações que exigem o máximo desempenho.

    Uma imagem de uma tabela que mostra uma comparação de skus e camadas.

Aqui está o nível que armazena dados tanto na memória como no disco:

  • Flash otimizado (visualização) 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.

    Uma imagem de uma tabela que mostra os níveis de otimização para Flash numa tabela que mostra o uso de armazenamento.

Desempenho (Débito e Latência)

Para obter referências de desempenho e mais informações sobre como medir o desempenho de cada SKU e escalão, consulte Testes de desempenho com o Azure Managed Redis

Quando dimensionar

Pode utilizar as funcionalidade de monitorização do Azure Managed Redis para monitorizar o bom funcionamento e o desempenho da sua cache. Utilize estas informações para determinar quando dimensionar a cache.

Pode monitorizar as seguintes métricas para determinar se o dimensionamento é necessário.

  • Processador
    • Uma utilização elevada da CPU significa que o servidor do Redis não consegue acompanhar os pedidos de todos os clientes. O dimensionamento para mais vCPUs ajuda a distribuir solicitações em vários processos Redis. O dimensionamento também ajuda a distribuir a encriptação/desencriptação e a ligação/desligamento de TLS, acelerando as instâncias de cache que utilizam TLS.
  • Utilização de Memória
    • A elevada utilização da memória indica que o tamanho dos dados é demasiado grande para o tamanho atual da cache. Considere dimensionar para um tamanho de cache com maior memória. Ao reduzir a memória, você precisa garantir que o uso de memória do cache atual seja menor do que o novo tamanho de memória que deseja usar. Não é possível colocar um conjunto de dados grande em um tamanho de cache menor.
  • Ligações de cliente
    • Cada tamanho de cache tem um limite para o número de ligações de clientes que pode suportar. Se as ligações do cliente estiverem próximas do limite do tamanho da cache, considere a possibilidade de dimensionar para um tamanho de memória maior ou para um escalão de desempenho superior.
    • Para obter mais informações sobre limites de ligação por tamanho de cache, consulte Testes de desempenho com o Azure Managed Redis.
  • Largura de Banda de Rede
    • Se o servidor do Redis exceder a largura de banda disponível, os pedidos dos clientes podem expirar porque o servidor não consegue transmitir os dados ao cliente com rapidez suficiente. Para ver a utilização da largura de banda do lado do servidor, verifique as métricas “Leitura da Cache” e “Escrita da Cache”. Se o servidor do Redis estiver a exceder a largura de banda de rede disponível, considere dimensionar para um escalão de desempenho superior ou um tamanho de cache maior.
    • A escolha da política de clusters afeta a largura de banda da rede disponível. Geralmente, a política de cluster OSS tem maior largura de banda de rede do que a política de cluster Enterprise. Para obter mais informações, veja Política de Clusters
    • Para obter mais informações sobre a largura de banda de rede disponível por tamanho de cache, consulte Testes de desempenho com o Azure Managed Redis.

Para obter mais informações sobre como determinar o escalão de preço da cache a ser utilizado, consulte Escolher o escalão certo.

Para mais informações sobre como otimizar o processo de escalabilidade, consulte o guia de melhores práticas para escalabilidade.

Limitações do dimensionamento do Azure Managed Redis

  • Não pode dimensionar dos escalões Otimizado para Memória, Equilibrado, ou Otimizado para Computação para o escalão Otimizado para Flash, ou vice-versa.
  • Ao reduzir a memória da instância do Redis, o uso atual da memória da instância do Redis deve ser menor do que o tamanho da nova memória pretendida. 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 o vCPU para a sua instância Redis, só pode dimensionar 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, durante o dimensionamento, o endereço IP subjacente da instância do Redis pode mudar. O registo DNS para a instância muda e é transparente para a maioria das aplicações. 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 que permitam 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 do registro DNS.
  • O dimensionamento de uma instância num grupo de georreplicação tem mais algumas limitações. Consulte Existem limitações de dimensionamento com a georreplicação? para obter mais informações.
  • Ao reduzir a escala, só se pode dimensionar para determinados níveis. Para obter mais informações, consulte Por que só posso reduzir para um subconjunto de SKUs menores?.

Como dimensionar

Nesta secção, descrevemos como escalar uma cache Azure Managed Redis.

Escalar através do portal do Azure

Observação

O dimensionamento de caches Redis gerenciados do Azure replicados geograficamente permanece na Visualização Pública.

  1. Para dimensionar seu cache, navegue até o cache no portal do Azure e selecione Dimensionar no menu Recurso.

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

    Importante

    Se você selecionar uma SKU que não pode ser dimensionada, a opção Salvar será desabilitada. Consulte a seção Limitações do dimensionamento do Azure Managed Redis para obter detalhes sobre quais opções de dimensionamento são permitidas.

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

Dimensionar usando o PowerShell

Pode dimensionar as suas instâncias do Azure Managed Redis com o PowerShell utilizando o cmdlet Update-AzRedisEnterpriseCache. Pode modificar a propriedade Sku para selecionar o escalão e a SKU de que necessita. O exemplo seguinte mostra como dimensionar uma cache designada myCache para uma instância X20 Otimizada para Computação (24 GB).

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

Escalar usando a CLI do Azure

Para dimensionar as suas instâncias do Azure Managed Redis utilizando a CLI do Azure, chame o comando comando az redisenterprise update. Pode modificar a propriedade sku para selecionar o escalão e a SKU de que necessita. O exemplo seguinte mostra como dimensionar uma cache designada myCache para uma instância X20 Otimizada para Computação (24 GB).

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

FAQ sobre Escalabilidade

A lista seguinte contém respostas a perguntas frequentes sobre o dimensionamento do Azure Managed Redis.

Posso dimensionar dentro ou entre escalões?

Pode sempre dimensionar para um escalão de desempenho superior com o mesmo tamanho de memória ou um tamanho de memória superior dentro do mesmo escalão de desempenho. Para mudar para um nível de desempenho mais baixo ou tamanho de memória menor, recomendamos que o utilizador execute a API REST "listskusforscaling" para obter a lista de SKUs para os quais pode escalar.

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

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

Você pode dimensionar para um tamanho de memória menor somente se o uso atual de memória for menor do que o tamanho de memória menor pretendido. Se o uso atual de memória for maior do que o tamanho menor pretendido, sua solicitação de dimensionamento falhará. Você pode reduzir o uso atual da memória ao excluir pares chave-valor indesejados ou ao executar a operação de flush.

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

Após o dimensionamento, tenho que alterar o nome da cache ou as chaves de acesso?

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 dimensiona uma instância do Redis, um dos nós do cluster do Redis é desligado e aprovisionado novamente para o novo tamanho. Depois que os dados são totalmente transferidos, o outro nó executa um failover semelhante a seguir, antes de realizar a reconfiguração. O encerramento e a reconfiguração são semelhantes ao processo que ocorre durante uma atualização ou uma falha em um dos nós de uma cache.
  • Quando você dimensiona para uma instância com mais vCPUs, novos fragmentos são provisionados e adicionados ao cluster de servidores Redis. Os dados são então redistribuídos por todos os fragmentos.

Para obter mais informações sobre como o Azure Managed Redis trata da fragmentação, consulte Configuração da fragmentação.

Perco dados da minha cache durante o dimensionamento?

  • Se o modo de elevada disponibilidade estiver ativado, todos os dados deverão ser preservados durante as operações de dimensionamento.
  • Se você estiver dimensionando para um nível de memória menor, precisará garantir que o uso de memória atual seja menor do que o novo tamanho de memória pretendido. Se o uso atual da memória 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-chave a serem excluídos.
  • Se o modo de elevada disponibilidade estiver desativado, os dados são todos perdidos e a cache fica indisponível durante a operação de dimensionamento.

Meu cache está disponível durante o dimensionamento?

  • As instâncias do Azure Managed Redis com o modo de elevada disponibilidade ativado permanecem disponíveis durante a operação de dimensionamento. No entanto, podem ocorrer falhas de ligação durante o dimensionamento destas caches. Estas falhas de ligação são tipicamente curtas e os clientes do Redis podem geralmente restabelecer a sua ligação instantaneaamente.
  • Se o modo de elevada disponibilidade estiver desativado, a instância do Azure Managed Redis fica offline durante as operações de dimensionamento.

Existem limitações de dimensionamento com a georreplicação?

O dimensionamento de caches replicados geograficamente está em Visualização pública. Com a georreplicação ativa configurada, não é possível misturar e combinar tamanhos de cache num grupo de georreplicação. Como resultado, o dimensionamento dos caches em um grupo de replicação geográfica requer mais algumas etapas. Consulte Dimensionamento de instâncias num grupo de georreplicação para obter instruções.

Reduzir a escala para um tamanho de memória menor ou para um número menor de fragmentos não é suportado para caches geo-replicadas. Para obter mais informações, consulte Quantos fragmentos cada SKU Redis Gerenciado do Azure usa para descobrir fragmentos em seu cluster.

Quanto tempo demora o dimensionamento?

O tempo de escalonamento depende de alguns fatores. Seguem-se alguns fatores que podem afetar o tempo de dimensionamento.

  • Quantidade de dados: quantidades maiores de dados demoram mais tempo a ser replicadas
  • Elevados pedidos de escrita: um maior número de escritas significa mais réplicas de dados entre os nós ou fragmentos
  • Elevada utilização da CPU: uma utilização mais elevada da CPU significa que o servidor do Redis está ocupado e que estão disponíveis ciclos de CPU limitados para concluir a redistribuição dos dados

Geralmente, quando dimensiona uma instância sem dados, demora cerca de 10 minutos.

Como posso saber quando o dimensionamento está concluído?

No portal do Azure, pode ver a operação de dimensionamento em curso. Quando o dimensionamento estiver concluído, o status do cache mudará para Em execução ao exibir Visão geral no menu Recurso.

O Azure Managed Redis utiliza clustering?

Ao contrário do Azure Cache for Redis, o Azure Managed Redis utiliza clustering em todos os escalões e SKU. O clustering permite otimizações de desempenho significativas. Cada SKU Azure Managed Redis é configurada para um número otimizado de fragmentos para o número de vCPU disponíveis. O número de fragmentos não é configurável pelo utilizador.

Quantos fragmentos utiliza cada SKU do Azure Managed Redis?

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

Como é que as chaves são distribuídas num cluster?

De acordo com a documentação do Redis sobre o modelo de distribuição de chaves : O espaço de chave é dividido em 16 384 blocos. É aplicado um hash a cada chave, que é então associada a um destes slots, distribuídos pelos nós do cluster. Pode configurar qual parte da chave será convertida em hash para garantir que várias chaves estejam localizadas num mesmo fragmento através de etiquetas hash.

  • Chaves com uma etiqueta hash – se alguma parte da chave estiver incluída em { e }, o hash será aplicado apenas a essa parte da chave para efeitos de determinar o bloco hash de uma chave. Por exemplo, as três chaves que se seguem devem estar localizadas na mesma extensão: {key}1, {key}2 e {key}3, dado que o hash apenas é aplicado à parte key do nome. Para obter uma lista completa das especificações das etiquetas hash das chaves, veja Etiquetas das chaves hash.
  • Chaves sem símbolo de hash - o nome completo da chave é utilizado para hashing, resultando numa distribuição estatisticamente uniforme através dos fragmentos da cache.

Para um melhor desempenho e taxa de transferência, recomendamos que as chaves sejam distribuídas uniformemente. Se estiver a utilizar chaves com uma etiqueta hash, é da responsabilidade da aplicação garantir que as chaves são distribuídas uniformemente.

Para obter mais informações, veja Modelo de distribuição de chaves, Fragmentação de dados do Redis Cluster e Etiquetas de hash das chaves.

Qual é o maior tamanho de cache que posso criar?

O maior tamanho de cache que pode ter é de 4,5 TB, denominado instância A4500 Otimizada para Flash. Preços da Cache do Azure para Redis.

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

Para manter a compatibilidade com o número de fragmentos e vCPU, é possível reduzir apenas para algumas SKUs específicas. Você pode ver para quais SKUs a sua instância de Redis pode escalar para baixo verificando as opções disponíveis na seção de Escala do portal do Azure. Você também pode executar o seguinte comando da CLI.

Você pode ver para quais SKUs a sua instância de Redis pode escalar para baixo verificando as opções disponíveis na seção de Escala 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 OSS ou Enterprise Cluster?

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

Conteúdo relacionado

  • Last updated on