Dimensionar uma instância do Azure Cache for Redis

Importante

O Cache do Azure para Redis anunciou seu cronograma de desativação para todas as SKUs. Recomendamos mover as suas instâncias existentes do Azure Cache para Redis para Azure Managed Redis o mais rápido possível.

Para mais detalhes sobre a aposentadoria:

• Cache do Azure para Aposentadoria Redis: o que saber e como preparar
• Perguntas frequentes sobre a descontinuação do Cache do Azure para Redis

O Cache Redis do Azure tem diferentes ofertas de camada que fornecem flexibilidade na escolha do tamanho e dos recursos do cache. Por meio do dimensionamento, você pode alterar o tamanho, a camada e o número de nós depois de criar uma instância de cache para corresponder às necessidades do seu aplicativo. 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.

Tipos de dimensionamento

Há fundamentalmente duas maneiras de dimensionar um Cache do Azure para Instância Redis:

• A expansão aumenta o tamanho da máquina virtual (VM) que executa o servidor Redis, adicionando mais memória, CPUs virtuais (vCPUs) e largura de banda de rede. A expansão também é chamada escala vertical. O oposto de aumentar é diminuir.

• O dimensionamento horizontal divide a instância de cache em mais nós do mesmo tamanho, aumentando a memória, as vCPUs e a largura de banda da rede através da paralelização. A expansão também é conhecida como escala horizontal ou sharding. O oposto de dimensionar para fora é reduzir a escala. Na comunidade Redis, o dimensionamento horizontal é frequentemente chamado clustering.

Âmbito da disponibilidade

Escalão de serviço	Básico e Standard	Premium	Enterprise e Enterprise Flash
Expandir	Sim	Sim	Sim
Reduzir Verticalmente	Sim	Sim	Não
Escalar Horizontalmente	Não	Sim	Sim
Escala em	Não	Sim	Não

Quando dimensionar

Você pode usar os recursos de monitoramento do Cache Redis do Azure para monitorar a integridade e o desempenho do cache. Utilize estas informações para determinar quando dimensionar a cache.

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

• Carga do servidor Redis
  • Alta carga do servidor Redis significa que o servidor é incapaz de acompanhar o ritmo das solicitações de todos os clientes. Como um servidor Redis é um processo de thread único, normalmente é mais útil escalar horizontalmente em vez de escalar verticalmente. A expansão habilitando o clustering ajuda a distribuir funções de sobrecarga em vários processos Redis. A expansão também ajuda a distribuir a criptografia e a descriptografia TLS, bem como a conexão e desconexão, acelerando as instâncias de cache que usam TLS.
  • A expansão ainda pode ser útil para reduzir a carga do servidor, porque as tarefas em segundo plano podem aproveitar mais vCPUs e liberar o thread para o processo principal do servidor Redis.
  • As camadas Enterprise e Enterprise Flash usam Redis Enterprise em vez de Redis de código aberto. Uma das vantagens dessas camadas é que o processo do servidor Redis pode tirar proveito de várias vCPUs. Com várias vCPUs, tanto o dimensionamento vertical como o horizontal nestas camadas podem ser úteis para reduzir a carga do servidor.
• 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. Tanto o aumento da capacidade quanto o aumento horizontal são eficazes aqui.
• 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 conexões do cliente estiverem próximas do limite para o tamanho do cache, considere expandir para uma camada maior. A expansão não aumenta o número de conexões de cliente suportadas.
  • Para obter mais informações sobre limites de conexão por tamanho de cache, consulte Preços do Cache do Azure para 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 Redis estiver excedendo a largura de banda de rede disponível, você deve considerar a expansão ou dimensionamento para um tamanho de cache maior com maior largura de banda de rede.
  • Para caches do nível Enterprise usando a política de cluster Enterprise, o dimensionamento não aumenta a largura de banda da rede.
  • Para obter mais informações sobre a largura de banda disponível na rede por tamanho de cache, consulte Perguntas frequentes sobre planejamento do Cache do Azure para Redis.
• Varreduras internas do Defender
  • Nos caches C0 e C1 Standard, enquanto a verificação interna do Defender está a ser executada nas VMs, pode-se ver pequenos picos de carga no servidor não causados por um aumento nas solicitações de cache. As solicitações apresentam uma latência mais alta enquanto as verificações internas do Defender são executadas nestas camadas várias vezes por dia. Os caches nas camadas C0 e C1 têm apenas um núcleo para multitarefa, dividindo o trabalho de atender às solicitações internas de varredura do Defender e do Redis. Você pode reduzir o efeito dimensionando para uma oferta de camada mais alta com vários núcleos de CPU, como C2.
  • O aumento do tamanho do cache nas camadas mais altas ajuda a resolver quaisquer problemas de latência. Além disso, no nível C2 , você tem suporte para até 2.000 conexões de cliente.

Para obter mais informações sobre como determinar a camada de preço de cache a ser usada, consulte Escolhendo a camada certa e Perguntas frequentes sobre planejamento do Cache do Azure para Redis.

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 Cache do Azure para Redis

Você pode aumentar ou diminuir para um nível de preço diferente com as seguintes restrições:

• Não é possível escalar de um nível de preço mais alto para um nível de preço mais baixo.
  • Não é possível escalar de um cache Enterprise ou Enterprise Flash para outra camada qualquer.
  • Não é possível dimensionar de um cache Premium para um cache Standard ou Basic.
  • Não é possível dimensionar de um cache padrão para um cache básico .
• Você pode dimensionar de um cache Básico para um cache Padrão , mas não pode alterar o tamanho ao mesmo tempo. Se você precisar de um tamanho diferente, poderá posteriormente fazer uma operação de dimensionamento para o tamanho desejado.
• Não é possível dimensionar de um cache Básico diretamente para um cache Premium . Primeiro, escale de Basic para Standard em uma única operação de dimensionamento e, em seguida, de Standard para Premium na próxima operação de dimensionamento.
• Não é possível redimensionar de um tamanho maior para o tamanho C0 (250 MB). No entanto, você pode dimensionar para qualquer outro tamanho dentro do mesmo nível de preço. Por exemplo, você pode escalar de C5 Standard para C1 Standard.
• Não é possível dimensionar de um cache Premium, Standard ou Basic para um cache Enterprise ou Enterprise Flash .
• Não é possível dimensionar entre Enterprise e Enterprise Flash.

Você pode expandir/aumentar com as seguintes restrições:

• A expansão só é suportada nas camadas Premium, Enterprise e Enterprise Flash.
• Reduzir escala é suportado apenas no nível Premium.
• Na camada Premium, o clustering deve ser habilitado primeiro antes de aumentar ou diminuir a escala.
• No nível Premium, o suporte para scale out de até 10 fragmentos está geralmente disponível. O suporte para até 30 fragmentos está em versão preliminar. (Para caches com duas réplicas, o limite de fragmentos é 20. Com três réplicas, o limite passa a ser 15.)
• Somente as camadas Enterprise e Enterprise Flash podem ser dimensionadas e expandidas simultaneamente.

Como dimensionar - níveis Básico, Standard e Premium

Aumente e diminua a escala com Basic, Standard e Premium

Ajuste a escala para cima e para baixo usando o portal do Azure

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

   

2. Escolha um nível de preço no painel de trabalho e, em seguida, escolha Selecionar.

   

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

   

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

Nota

Quando o cache é dimensionado para cima ou para baixo através do portal, as definições maxmemory-reserved e maxfragmentationmemory-reserved ajustam-se automaticamente na proporção do tamanho do cache. Por exemplo, se maxmemory-reserved estiver definido como 3 GB em um cache de 6 GB e você dimensionar para cache de 12 GB, as configurações serão atualizadas automaticamente para 6 GB durante o dimensionamento. Quando você reduz a escala, acontece o inverso.

Escalar para cima e para baixo usando o PowerShell

Você pode dimensionar o Azure Cache para Redis com o PowerShell usando o cmdlet Set-AzRedisCache quando as propriedades Size ou Sku forem modificadas. O exemplo a seguir mostra como dimensionar um cache nomeado myCache para um cache de 6 GB na mesma camada.

   Set-AzRedisCache -ResourceGroupName myGroup -Name myCache -Size 6GB

Para obter mais informações sobre dimensionamento com o PowerShell, consulte Para dimensionar um Cache do Azure para Redis usando o PowerShell.

Aumente e diminua a escala usando a CLI do Azure

Para dimensionar seu Cache do Azure para instâncias Redis usando a CLI do Azure, chame o comando az redis update . Use a propriedade sku.capacity para escalar dentro de um nível, por exemplo, de um cache padrão C0 para C1.

az redis update --cluster-name myCache --resource-group myGroup --set "sku.capacity"="2"

Use as propriedades 'sku.name' e 'sku.family' para escalar para uma camada diferente, por exemplo, de um cache C1 padrão para um cache P1 Premium:

az redis update --cluster-name myCache --resource-group myGroup --set "sku.name"="Premium" "sku.capacity"="1" "sku.family"="P"

Para obter mais informações sobre dimensionamento com a CLI do Azure, consulte Alterar configurações de um Cache do Azure para Redis existente.

Nota

Quando dimensiona um cache para aumentar ou diminuir programaticamente (por exemplo, usando o PowerShell ou a CLI do Azure), qualquer maxmemory-reserved ou maxfragmentationmemory-reserved é ignorado como parte da solicitação de atualização. Apenas a sua alteração de escala é considerada. Você pode atualizar essas configurações de memória após a conclusão da operação de dimensionamento.

Escalar para fora e para dentro - Apenas Premium

Criar um novo cache que será expandido usando clusters

O clustering é habilitado durante a criação do cache no painel de trabalho, quando você cria um novo Cache do Azure para Redis.

1. Use o guia de início rápido Criar um cache Redis de código aberto para começar a criar um novo cache usando o portal do Azure.

2. Na guia Avançado para uma instância de cache premium, defina as configurações para porta não-TLS, clustering e persistência de dados. Para habilitar o clustering, selecione Ativar.

   

   Você pode ter até 30 fragmentos no cluster. Depois de selecionar Ativar, deslize o controle deslizante ou digite um número entre 1 e 30 para Contagem de fragmentos e selecione OK.

   Cada fragmento é um par de cache primário/réplica gerenciado pelo Azure. O tamanho total do cache é calculado multiplicando o número de fragmentos pelo tamanho do cache selecionado na camada de preço.

   

   Depois que o cache é criado, você se conecta a ele e o usa como um cache não clusterizado. O Redis distribui os dados pelos fragmentos de cache. Se o diagnóstico estiver habilitado, as métricas serão capturadas separadamente para cada fragmento e poderão ser exibidas no Cache Redis do Azure usando o menu Recurso.

3. Termine a criação do cache usando o guia de arranque rápido.

Demora um pouco para o cache ser criado. Você pode monitorar o progresso na página Visão geral do Cache do Azure para Redis. Quando Status é exibido como Em execução, o cache está pronto para uso.

Nota

Há algumas pequenas diferenças necessárias em seu aplicativo cliente quando o clustering é configurado. Para obter mais informações, consulte Preciso fazer alterações no meu aplicativo cliente para usar clustering?

Para obter um código de exemplo sobre como trabalhar com clustering com o cliente StackExchange.Redis, consulte a parte clustering.cs do exemplo Hello World .

Dimensionar um cache Premium em execução para aumentar ou diminuir

Para alterar o tamanho do cluster em um cache premium que você criou anteriormente e já está em execução com o clustering habilitado, selecione Tamanho do cluster no menu Recurso.

Para alterar o tamanho do cluster, use o controle deslizante ou digite um número entre 1 e 30 na caixa de texto Contagem de fragmentos. Em seguida, selecione OK para salvar.

Aumentar o tamanho do cluster aumenta a taxa de transferência máxima e o tamanho do cache. Aumentar o tamanho do cluster não aumenta o máximo de conexões disponíveis para os clientes.

Expandir e reduzir em PowerShell

Você pode expandir suas instâncias do Azure Cache for Redis com o PowerShell usando o cmdlet Set-AzRedisCache quando a propriedade ShardCount for modificada. O exemplo a seguir mostra como dimensionar um cache nomeado myCache para usar três fragmentos (ou seja, dimensionar por um fator de três)

   Set-AzRedisCache -ResourceGroupName myGroup -Name myCache -ShardCount 3

Para obter mais informações sobre dimensionamento com o PowerShell, consulte Para dimensionar um Cache do Azure para Redis usando o PowerShell.

Dimensionar para cima e para baixo usando a CLI do Azure

Para dimensionar o seu Cache do Azure para instâncias Redis usando a CLI do Azure, chame o comando az redis update e utilize a propriedade shard-count. O exemplo a seguir mostra como dimensionar um cache nomeado myCache para usar três fragmentos (ou seja, dimensionar por um fator de três).

az redis update --cluster-name myCache --resource-group myGroup --set shard-count=3

Para obter mais informações sobre dimensionamento com a CLI do Azure, consulte Alterar configurações de um Cache do Azure para Redis existente.

Nota

Quando dimensiona um cache para aumentar ou diminuir programaticamente (por exemplo, usando o PowerShell ou a CLI do Azure), qualquer maxmemory-reserved ou maxfragmentationmemory-reserved é ignorado como parte da solicitação de atualização. Apenas a sua alteração de escala é considerada. Você pode atualizar essas configurações de memória após a conclusão da operação de dimensionamento.

Nota

O dimensionamento de um cluster executa o comando MIGRATE , que é um comando caro. Para um impacto mínimo, considere executar esta operação fora do horário de pico. Durante o processo de migração, você vê um pico na carga do servidor. O dimensionamento de um cluster é um processo de longa execução e o tempo necessário depende do número de chaves e do tamanho dos valores associados a essas chaves.

Como aumentar e reduzir a escala - níveis Enterprise e Enterprise Flash

As camadas Enterprise e Enterprise Flash podem ser aumentadas e ampliadas numa única operação. Outros níveis exigem operações separadas para cada ação.

Atenção

As camadas Enterprise e Enterprise Flash ainda não suportam redução de escala ou dimensionamento interno nas operações.

Escalar através do portal do Azure

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

   

2. Para aumentar a escala, escolha um tipo de cache diferente e, em seguida, escolha Salvar.

   Importante

   Você só pode aumentar a escala neste momento. Não é possível reduzir a escala.

   

3. Para dimensionar, aumente o slider de Capacidade. A capacidade aumenta em incrementos de dois. Esse número reflete quantos nós Redis Enterprise subjacentes estão sendo adicionados. Esse número é sempre um múltiplo de dois para refletir os nós que estão sendo adicionados para fragmentos primários e de réplica.

   Importante

   Neste momento, só pode aumentar a capacidade. Não é possível escalar internamente.

   

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

   

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

Dimensionar usando o PowerShell

Você pode dimensionar seu Cache do Azure para instâncias Redis com o PowerShell usando o cmdlet Update-AzRedisEnterpriseCache . Você pode modificar a Sku propriedade para dimensionar a instância. Você pode modificar a Capacity propriedade para dimensionar a instância. O exemplo a seguir mostra como dimensionar um cache nomeado myCache para uma instância Enterprise E20 (25 GB) com capacidade de 4.

   Update-AzRedisEnterpriseCache -ResourceGroupName myGroup -Name myCache -Sku Enterprise_E20 -Capacity 4

Escalar usando a CLI do Azure

Para dimensionar seu Cache do Azure para instâncias Redis usando a CLI do Azure, chame o comando az redisenterprise update . Você pode modificar a sku propriedade para dimensionar a instância. Você pode modificar a capacity propriedade para dimensionar a instância. O exemplo a seguir mostra como dimensionar um cache nomeado myCache para uma instância Enterprise E20 (25 GB) com capacidade de 4.

az redisenterprise update --cluster-name "myCache" --resource-group "myGroup" --sku "Enterprise_E20" --capacity 4

FAQ sobre Escalabilidade

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

• Posso dimensionar para, de ou dentro de uma cache Premium?
• Após o dimensionamento, tenho que alterar o nome da cache ou as chaves de acesso?
• Como funciona o dimensionamento?
• Perco dados da minha cache durante o dimensionamento?
• Posso usar todas as funcionalidades do nível Premium após o escalonamento?
• Minha configuração de bancos de dados personalizados é afetada durante o dimensionamento?
• Meu cache está disponível durante o dimensionamento?
• Existem limitações de dimensionamento com a georreplicação?
• Operações que não são suportadas
• Quanto tempo demora o escalonamento?
• Como posso saber quando o dimensionamento está concluído?
• Preciso fazer alguma alteração no meu aplicativo cliente para usar clustering?
• Como é que as chaves são distribuídas num cluster?
• Qual é o maior tamanho de cache que posso criar?
• Todos os clientes Redis suportam clustering?
• Como faço para me conectar ao meu cache quando o clustering está habilitado?
• Posso me conectar diretamente aos fragmentos individuais do meu cache?
• Posso configurar o clustering para um cache criado anteriormente?
• Posso configurar o clustering para um cache básico ou padrão?
• Posso usar clustering com os provedores Redis ASP.NET Session State e Output Caching?
• Estou recebendo exceções MOVE ao usar o StackExchange.Redis e clustering, o que devo fazer?
• Qual é a diferença entre OSS Clustering e Enterprise Clustering em caches de camada empresarial?
• Quantos fragmentos os caches de camada Enterprise usam?

Posso dimensionar para, de ou dentro de um cache Premium?

• Não é possível escalar de um cache Premium para uma camada de preços básica ou padrão.
• Você pode escalar de um nível de preço de cache Premium para outro.
• Não é possível dimensionar de um cache Básico diretamente para um cache Premium . Primeiro, escale de Basic para Standard em uma operação de escalonamento e, em seguida, de Standard para Premium em uma operação de escalonamento posterior.
• Não é possível dimensionar de um cache Premium para um cache Enterprise ou Enterprise Flash .
• Se você habilitou o clustering quando criou o cache Premium , pode alterar o tamanho do cluster. Se o cache foi criado sem clustering habilitado, você pode configurar o clustering posteriormente.

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

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

Como funciona o dimensionamento?

• Quando você dimensiona um cache básico para um tamanho diferente, o cache é desligado e um novo cache é provisionado usando o novo tamanho. Durante esse tempo, o cache fica indisponível e todos os dados no cache são perdidos.
• Quando você dimensiona um cache Básico para um cache Padrão , um cache de réplica é provisionado e os dados são copiados do cache primário para o cache de réplica. O cache permanece disponível durante o processo de dimensionamento.
• Quando se dimensiona um Standard, Premium, Enterprise ou Enterprise Flash cache para um tamanho diferente, uma das réplicas é desligada e reprovisionada para o novo tamanho e os dados são transferidos, e em seguida, a outra réplica faz um failover antes de ser reprovisionada, de modo semelhante ao processo que ocorre durante uma falha de um dos nós do cache.
• Quando você dimensiona um cache clusterizado, novos fragmentos são provisionados e adicionados ao cluster de servidor Redis. Os dados são então redistribuídos por todos os fragmentos.
• Quando se escala um cache clusterizado, os dados são primeiro redistribuídos e, em seguida, o tamanho do cluster é reduzido para o número necessário de fragmentos.
• Ao dimensionar ou migrar o cache para um cluster diferente, o endereço IP subjacente do cache pode ser alterado. O registro DNS do cache é alterado e transparente para a maioria dos aplicativos. No entanto, se você usar um endereço IP para configurar a conexão com o cache ou configurar NSGs ou firewalls que permitam o tráfego para o cache, seu aplicativo poderá ter problemas para se conectar após as atualizações do registro DNS.

Perco dados da minha cache durante o dimensionamento?

• Quando você dimensiona um cache básico para um novo tamanho, todos os dados são perdidos e o cache fica indisponível durante a operação de dimensionamento.
• Quando você dimensiona um cache Básico para um cache Padrão , os dados no cache geralmente são preservados.
• Ao dimensionar um Standard, Premium, Enterprise ou Enterprise Flash cache para um tamanho maior, todos os dados normalmente são preservados. Quando você dimensiona um cache Standard ou Premium para um tamanho menor, os dados podem ser perdidos se o tamanho original exceder o novo tamanho menor. Se os dados forem perdidos durante a redução de escala, as chaves serão removidas utilizando a política de expulsão allkeys-lru.

Posso usar todos os recursos do nível Premium depois de escalar?

Não, alguns recursos só podem ser definidos quando você cria um cache na camada Premium e não estão disponíveis após o dimensionamento.

Estes recursos não podem ser adicionados depois de criar o cache Premium:

• Injetar redes virtuais
• Adicionando redundância de zona
• Usando várias réplicas por principal

Para usar qualquer um desses recursos, você deve criar uma nova instância de cache na camada Premium.

Minha configuração de bancos de dados personalizados é afetada durante o dimensionamento?

Se você configurou um valor personalizado para a configuração durante a criação do databases cache, lembre-se de que algumas camadas de preços têm limites de bancos de dados diferentes. Aqui estão algumas considerações ao dimensionar neste cenário:

• Quando você escala para uma camada de preço com um limite menor databases do que a camada atual:
  • Se estiveres a usar o número padrão de databases, que é 16 para todos os níveis de preço, nenhum dado será perdido.
  • Se você estiver usando um número personalizado que esteja dentro dos databases limites da camada para a qual você está dimensionando, essa databases configuração será mantida e nenhum dado será perdido.
  • Se utilizares um número personalizado de databases que excede os limites da nova camada, a configuração databases será ajustada aos limites da nova camada e todos os dados nos bancos de dados removidos serão perdidos.
• Quando você escala para um nível de preço com o mesmo limite ou maior databases do que o nível atual, sua databases configuração é mantida e nenhum dado é perdido.

Embora os caches Standard, Premium, Enterprise e Enterprise Flash tenham um SLA para disponibilidade, não há SLA para perda de dados.

Meu cache está disponível durante o dimensionamento?

• Os caches Flash Standard, Premium, Enterprise e Enterprise permanecem disponíveis durante a operação de dimensionamento. No entanto, interrupções na conexão podem ocorrer durante o dimensionamento desses caches, assim como ao dimensionar caches do tipo Basic para Standard. Espera-se que esses blips de conexão sejam pequenos e os clientes redis geralmente podem restabelecer sua conexão instantaneamente.
• Para caches Enterprise e Enterprise Flash que usam replicação geográfica ativa, dimensionar apenas um subconjunto de caches vinculados pode introduzir problemas ao longo do tempo em alguns casos. Sempre que possível, recomendamos o dimensionamento de todos os caches no grupo de replicação geográfica.
• Os caches básicos ficam offline durante as operações de dimensionamento para um tamanho diferente. Os caches básicos permanecem disponíveis ao dimensionar de Basic para Standard, mas podem ter uma ligeira interrupção de conexão. Se ocorrer um blip de conexão, os clientes Redis geralmente podem restabelecer sua conexão instantaneamente.

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

Com a replicação geográfica passiva configurada, você pode notar que não é possível dimensionar um cache ou alterar os fragmentos em um cluster. Um link de replicação geográfica entre dois caches impede que você dimensione a operação ou altere o número de fragmentos em um cluster. Você deve desvincular o cache para emitir esses comandos. Para obter mais informações, consulte Configurar a replicação geográfica.

Com a replicação geográfica ativa configurada, você pode dimensionar um cache com algumas limitações. Todos os caches em um grupo de replicação geográfica devem ter o mesmo tamanho e capacidade. Para obter mais informações, consulte Configurar a replicação geográfica ativa para instâncias do Enterprise Azure Cache for Redis.

Operações que não são suportadas

• Não é possível escalar de um nível de preço mais alto para um nível de preço mais baixo.
  • Não é possível dimensionar de um cache Premium para um cache Standard ou Basic.
  • Não é possível dimensionar de um cache padrão para um cache básico .
• Você pode dimensionar de um cache Básico para um cache Padrão , mas não pode alterar o tamanho ao mesmo tempo. Se você precisar de um tamanho diferente, poderá fazer uma operação de dimensionamento para o tamanho desejado posteriormente.
• Não é possível dimensionar de um cache Básico diretamente para um cache Premium . Primeiro, escalone de Basic para Standard numa operação de dimensionamento e depois escalone de Standard para Premium numa operação posterior.
• Não é possível dimensionar de um cache Premium para um cache Enterprise ou Enterprise Flash .
• Não é possível dimensionar de um tamanho maior para o C0 (250 MB).

Se uma operação de dimensionamento falhar, o serviço tentará reverter a operação e o cache será revertido para o tamanho original.

Quanto tempo demora o dimensionamento?

O tempo de escalonamento depende de alguns fatores. Os seguintes fatores podem afetar quanto tempo leva o dimensionamento:

• Quantidade de dados: quantidades maiores de dados levam mais tempo para serem replicadas.
• Solicitações de gravação elevadas: Um maior número de gravações significa mais replicações de dados entre nós ou partições.
• Alta carga do servidor: maior carga do servidor significa que o servidor Redis está ocupado e ciclos de CPU limitados estão disponíveis para concluir a redistribuição de dados.

Dimensionar um cache não é uma ação trivial e pode levar muito tempo. Pode levar de uma a duas horas para dimensionar um cache com um ou dois fragmentos quando este não estiver sob cargas pesadas. Se você tiver mais fragmentos, o tempo para escalar não aumenta de forma linear.

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.

Preciso fazer alguma alteração no meu aplicativo cliente para usar clustering?

• Quando o clustering está habilitado, somente o banco de dados 0 está disponível. Se o aplicativo cliente usa vários bancos de dados e tenta ler ou gravar em um banco de dados diferente de zero, ocorre a seguinte exceção: Unhandled Exception: StackExchange.Redis.RedisConnectionException: ProtocolFailure on GET --->StackExchange.Redis.RedisCommandException: Multiple databases are not supported on this server; cannot switch to database: 6

  Para obter mais informações, consulte Especificação do cluster Redis - subconjunto implementado.

• Se você estiver usando StackExchange.Redis, deverá usar 1.0.481 ou posterior. Você se conecta ao cache usando os mesmos pontos de extremidade, portas e chaves que usa ao se conectar a um cache onde o clustering está desabilitado. A única diferença é que todas as leituras e gravações devem ser feitas no banco de dados 0.

  Outros clientes podem ter requisitos diferentes. Consulte Todos os clientes Redis suportam clustering? para obter mais informações.

• Se seu aplicativo usa várias operações de chave em lote em um único comando, todas as chaves devem estar localizadas no mesmo fragmento. Para localizar chaves no mesmo fragmento, consulte Como as chaves são distribuídas em um cluster?.

• Se você estiver usando o Redis ASP.NET provedor de Estado de Sessão, deverá usar 2.0.1 ou superior. Consulte Posso usar clustering com os provedores Redis ASP.NET Session State e Output Caching? para obter mais informações.

Importante

Ao usar as camadas Enterprise ou Enterprise FLash, você pode escolher entre o Modo de Cluster OSS ou o Modo de Cluster Empresarial. O Modo Cluster OSS é o mesmo que o clustering na camada Premium e segue a especificação de clustering de código aberto. O Modo de Cluster Empresarial pode ter um desempenho menor, mas usa o cluster Redis Enterprise, que não requer nenhuma alteração no cliente para ser usado. Para obter mais informações, consulte Clustering.

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.

Para obter um código de exemplo sobre como trabalhar com clustering e localizar chaves no mesmo fragmento com o cliente StackExchange.Redis, consulte a parte clustering.cs do exemplo Hello World .

Qual é o maior tamanho de cache que posso criar?

O maior tamanho de cache que você pode ter é de 4,5 TB. Esse resultado é um cache F1500 clusterizado com capacidade 9. Para obter mais informações, consulte Preços do Cache do Azure para Redis.

Todos os clientes Redis suportam clustering?

Muitas bibliotecas de clientes suportam clustering Redis, mas não todas. Verifique a documentação da biblioteca que está a utilizar para verificar se está a utilizar uma biblioteca e uma versão que suportem clustering. StackExchange.Redis é uma biblioteca que suporta clustering, em suas versões mais recentes. Para obter mais informações sobre outros clientes, consulte a secção Trabalhar com o cluster do tutorial do cluster Redis.

O protocolo de clustering do Redis requer que cada cliente se conecte diretamente a cada fragmento no modo de clusteamento, e inclusive define novas respostas de erro, como MOVED na CROSSSLOTS. Quando tenta utilizar uma biblioteca de cliente que não suporta clustering com um cache em modo cluster, o resultado pode ser muitas exceções de redirecionamento MOVED ou apenas interromper a sua aplicação se estiver a fazer pedidos multichave entre slots.

Nota

Se você estiver usando StackExchange.Redis como seu cliente, verifique se está usando a versão mais recente do StackExchange.Redis 1.0.481 ou posterior para que o clustering funcione corretamente. Para obter mais informações sobre quaisquer problemas com exceções de movimentação, consulte exceções de movimentação.

Como faço para me conectar ao meu cache quando o clustering está habilitado?

Você pode conectar-se ao cache usando os mesmos endpoints, portas, e chaves que usa ao conectar-se a um cache que não tem clustering habilitado. O Redis gerencia o clustering no back-end para que você não precise gerenciá-lo a partir do seu cliente.

Posso me conectar diretamente aos fragmentos individuais do meu cache?

O protocolo de clustering requer que o cliente faça as conexões de estilhaço corretas, portanto, o cliente deve fazer conexões de compartilhamento para você. Dito isso, cada fragmento consiste em um par de cache primário/réplica, conhecido coletivamente como instância de cache. Você pode se conectar a essas instâncias de cache usando o utilitário Redis-CLI na ramificação instável do repositório Redis no GitHub. Esta versão implementa suporte básico quando iniciada com o interruptor -c. Para obter mais informações, consulte Interagindo com o cluster em https://redis.io no tutorial do cluster Redis.

Você precisa usar o -p switch para especificar a porta correta à qual se conectar. Use o comando CLUSTER NODES para determinar as portas exatas usadas para os nós primário e de réplica. Os seguintes intervalos de portas são usados:

• Para caches de nível Premium não-TLS, as 130XX portas estão disponíveis no intervalo
• Para caches da camada Premium ativados para TLS, as portas estão disponíveis no intervalo 150XX
• Para caches Enterprise e Enterprise Flash usando cluster OSS, a conexão inicial é através da porta 10000. A ligação a nós individuais pode ser feita utilizando portas na gama de 85XX. As portas 85xx mudarão com o tempo e não devem ser codificadas em seu aplicativo.

Posso configurar o clustering para um cache criado anteriormente?

Sim. Primeiro, certifique-se de que o seu cache esteja na camada Premium aumentando-o. Em seguida, você pode ver as opções de configuração do cluster, incluindo uma opção para habilitar o cluster. Altere o tamanho do cluster depois que o cache for criado ou depois de habilitar o clustering pela primeira vez.

Importante

Não é possível desfazer a ativação do clustering. Uma memória cache com agrupamento ativado e apenas um fragmento comporta-se de forma diferente de uma memória cache do mesmo tamanho sem agrupamento.

Todos os caches das camadas Enterprise e Enterprise Flash estão sempre agrupados.

Posso configurar o clustering para um cache básico ou padrão?

O clustering só está disponível para caches Premium, Enterprise e Enterprise Flash.

Posso usar clustering com os provedores Redis ASP.NET Session State e Output Caching?

• Provedor de Cache de Saída Redis - sem necessidade de alterações.
• Provedor de Estado de Sessão Redis - para usar clustering, deve-se usar o RedisSessionStateProvider 2.0.1 ou superior; caso contrário, será gerada uma exceção, o que constitui uma alteração disruptiva. Para obter mais informações, consulte v2.0.0 Breaking Change Details.

Estou recebendo exceções MOVE ao usar o StackExchange.Redis e clustering, o que devo fazer?

Se você estiver usando StackExchange.Redis e receber MOVE exceções ao usar clustering, certifique-se de estar usando StackExchange.Redis 1.1.603 ou posterior.

Qual é a diferença entre OSS Clustering e Enterprise Clustering em caches de camada Enterprise?

O Modo Cluster OSS é o mesmo que o clustering na camada Premium e segue a especificação de clustering de código aberto. O Modo de Cluster Empresarial pode ter menos desempenho, mas usa o cluster Redis Enterprise, que não requer nenhuma alteração no cliente para ser usado. Para obter mais informações, consulte Clustering.

Quantos fragmentos os caches de camada Enterprise usam?

Ao contrário dos caches de nível Básico, Standard e Premium, os caches Enterprise e Enterprise Flash podem tirar proveito de várias fragmentações num único nó. Para obter mais informações, consulte Configuração de Sharding.

Próximos passos

• Configure a sua configuração de maxmemory-reserved
• Melhores práticas de dimensionamento