Partilhar via

Dimensionar uma instância do Azure Managed Redis (pré-visualização)

  • Artigo

O Azure Managed Redis (pré- visualização) tem diferentes ofertas de SKU e escalões que fornecem flexibilidade na escolha do tamanho e desempenho da cache. Pode dimensionar para um tamanho de memória maior ou mudar para um escalão com mais desempenho de computação. 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.

Nota

Uma vez que cada escalão do Azure Managed Redis tem praticamente as mesmas funcionalidades, o dimensionamento é normalmente utilizado apenas para alterar as caraterísticas de memória e de desempenho.

Importante

Atualmente, só é suportado o dimensionamento para tamanhos de memória maiores ou para um escalão de desempenho superior. A redução vertical para tamanhos de memória inferiores ou para um escalão de desempenho inferior ainda não é suportado.

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.

  • 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 da edição comunitária do Redis, que apenas pode utilizar uma única vCPU, o Azure Managed Redis utiliza a pilha Redis Enterprise, que pode utilizar várias vCPUs. Isto significa que o número de vCPUs utilizadas pela sua instância do Redis está diretamente relacionado com o desempenho do débito e da 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.

Três escalões 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 relação memória/vCPU (8:1), mas não precisam do mais alto desempenho de taxa de transferência. Oferece um ponto de preço mais baixo para cenários nos quais é necessária menos potência de processamento ou débito, tornando-o numa 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. Proporciona um equilíbrio saudável de recursos de memória e computação.
  • Otimizado para Computação. 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 mais alto desempenho.

Um escalão armazena dados na memória e no disco:

  • Otimizado para Flash. Permite que os clusters do Redis movam automaticamente os dados acedidos com menos frequência da memória (RAM) para o armazenamento NVMe. Isto reduz o desempenho, mas permite um dimensionamento económico das caches com grandes conjuntos de dados.

Níveis e SKUs em resumo

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

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.

  • CPU
    • Uma utilização elevada da CPU significa que o servidor do Redis não consegue acompanhar os pedidos de todos os clientes. Aumentar verticalmente para mais vCPUs ajuda a distribuir pedidos entre vários processos do 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.
  • 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 exceder o tempo limite porque o servidor não consegue enviar 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.

Nota

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

Pré-requisitos/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.
  • Não é possível reduzir a escala para uma SKU com menos vCPUs. (Entre escalões ou dentro de um escalão.)
  • Não é possível reduzir para um tamanho de memória menor, mesmo que ela tenha as mesmas ou mais vCPUs.
  • 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 utilizar um endereço IP para configurar a ligação à cache, ou para configurar NSG ou firewalls que permitam o tráfego para a cache, a sua aplicação poderá ter problemas em se ligar algum tempo após as atualizações do registo 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.

Como dimensionar

Gorjeta

Pode alterar o tamanho da memória e o escalão de desempenho numa única operação.

Dimensionar usando o portal do Azure

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

    Captura de tela mostrando Escala selecionada no menu Recurso para um cache Enterprise.

  2. Para aumentar a escala, 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. Analise a seção Pré-requisitos/limitações do dimensionamento do Azure Managed Redis para obter detalhes sobre quais opções de dimensionamento são permitidas.

    Captura de tela mostrando as camadas Enterprise no painel de trabalho.

  3. Enquanto o cache está sendo dimensionado para a nova camada, uma notificação de Cache Redis de Dimensionamento é exibida.

    Captura de tela mostrando a notificação de dimensionamento de um cache Enterprise.

  4. Quando o dimensionamento estiver concluído, o status mudará de Dimensionamento para Execução.

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

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

FAQ sobre Dimensionamento

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 dimensionar para um escalão de desempenho inferior ou para um tamanho de memória menor, consulte os Pré-requisitos/limitações do dimensionamento do Azure Managed Redis.

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

Não, o nome da cache e as chaves permanecem inalterados 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. Em seguida, os dados são transferidos e o outro nó faz uma ativação pós-falha semelhante antes de ser aprovisionado novamente. Isto é semelhante ao processo que ocorre durante a aplicação de correções ou uma ativação pós-falha de um dos nós da cache.
  • Quando dimensionar para uma instância com mais vCPUs, são aprovisionados e adicionados novos fragmentos ao cluster do servidor do 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 estiver a reduzir verticalmente para um nível de memória mais pequeno, os dados podem perder-se caso o tamanho dos dados exceda o novo tamanho mais pequeno quando a cache for reduzida verticalmente. Se os dados forem perdidos durante a redução vertical, as chaves serão expulsas utilizando a política de expulsão allkeys-lru.
  • 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.

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

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.

Quanto tempo demora o dimensionamento?

A duração do dimensionamento depende de alguns fatores. Seguem-se alguns fatores que podem afetar a duração do 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 estado da cache será alterado para Em execução.

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 e é atribuída a um desses blocos, que são distribuídos pelos nós do cluster. Pode configurar a que parte da chave é aplicado o hash para garantir que várias chaves estão localizadas na mesma extensão com 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 etiqueta hash – o nome de chave completo é utilizado para hashing, o que resulta numa distribuição estatisticamente uniforme através das extensões da cache.

Para um melhor desempenho e débito, 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, Extensão de dados do Cluster de Redis e Etiquetas 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.

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

A política de cluster OSS é a mesma que a abordagem de clustering utilizada na edição do Redis da comunidade. Normalmente, a política de clusters OSS é mais eficiente. A política de clusters Enterprise implementa o clustering para que apareça num cliente como uma instância do Redis sem cluster. Esta abordagem pode ter um desempenho inferior, mas pode evitar problemas de compatibilidade com o cliente. Atualmente, não é possível alternar entre políticas de clusters numa instância em execução. Para obter mais informações, veja Política de Clusters.

Próximos passos