Escale uma instância de Cache do Azure para Redis

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

Basicamente, existem duas maneiras de escalar uma Instância de Cache do Azure para Redis:

• Escalar verticalmente aumenta o tamanho da VM (Máquina Virtual) que executa o servidor Redis, adicionando mais memória, CPUs virtuais (vCPUs) e largura de banda de rede. A escala vertical também é chamada de dimensionamento vertical. O oposto de escalar verticalmente é Reduzir verticalmente.

• Reduzir verticalmente divide a instância de cache em mais nós do mesmo tamanho, aumentando a memória, as vCPUs e a largura de banda de rede por meio da paralelização. A redução vertical também é conhecida como escala horizontal ou fragmentação. O oposto de reduzir verticalmente é Reduzir horizontalmente. Na comunidade Redis, a redução vertical é frequentemente chamada de clustering.

Escopo de disponibilidade

Camada	Básico e Standard	Premium	Enterprise e Enterprise Flash
Expansão	Sim	Yes	Sim (versão prévia)
Reduzir verticalmente	Sim	Sim	Não
Escalonamento horizontal	Não	Yes	Sim (versão prévia)
Reduzir horizontalmente	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 seu cache. Use essas informações para determinar quando escalonar o cache.

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

• Carga do Servidor Redis
  • Alta carga do servidor Redis significa que o servidor não consegue manter o ritmo das solicitações de todos os cliente. Como um servidor Redis é um processo encadeamento único, normalmente é mais útil escalar horizontalmente em vez de escalar verticalmente. Escalar horizontalmente permitindo o clustering ajuda a distribuir funções de sobrecarga em vários processos do Redis. O escala horizontal também ajuda a distribuir criptografia/descriptografia e conexão/desconexão TLS, acelerando as instâncias de cache usando TLS.
  • A escala vertical 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 de serviço Enterprise e Enterprise Flash usam o Redis Enterprise em vez do Redis em código aberto. Uma das vantagens dessas camadas de serviço é que o processo do servidor Redis pode aproveitar várias vCPUs. Por isso, escalar verticalmente e horizontalmente essas camadas pode ser útil para reduzir a carga do servidor. Para mais informações, confira Práticas recomendadas para as camadas de serviço Enterprise e Enterprise Flash do Cache do Azure para Redis.
• 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. Escalar verticalmente ou escalar horizontalmente é eficaz aqui.
• 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 do cliente estiverem próximas do limite do tamanho do cache, considere escalar verticalmente para uma camada maior. Escalar horizontalmente não aumenta o número de conexões de cliente com suporte.
  • Para obter mais informações sobre os limites de conexão por tamanho do cache, confira Preço do Cache do Azure para 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. Verifique as métricas de “leitura de cache” e “gravação de cache” para ver a quantidade de largura de banda que o servidor está usando. Se o servidor Redis estiver excedendo a largura de banda da rede disponível, considere a possibilidade de escalar horizontalmente ou verticalmente para um tamanho de cache maior com maior largura de banda de rede.
  • Para caches da camada de serviço Enterprise que usam a Política de cluster Enterprise, a escala horizontal não aumenta a largura de banda da rede.
  • Para obter mais informações sobre largura de banda disponível por tamanho do cache, confira Perguntas frequentes sobre o planejamento do Cache do Azure para Redis.

Para obter mais informações sobre como determinar qual camada de preço de cache usar, confira Escolhendo o nível correto e Perguntas frequentes sobre o planejamento do Cache do Azure para Redis.

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

Você pode escalar verticalmente/horizontalmente para um tipo de preço diferente com as restrições a seguir:

• Você não pode dimensionar de uma camada de preços mais alta para uma camada de preços mais baixa.
  • Não é possível escalonar de um cache Enterprise ou Enterprise Flash para qualquer outra camada de serviço.
  • Você não pode dimensionar de um cache Premium para um cache Standard ou Básico.
  • Você não pode dimensionar de um cache Standard para um cache Básico.
• É possível dimensionar de um cache Básico para um cache Standard, mas não é possível alterar o tamanho simultaneamente. Para um tamanho diferente, realize posteriormente uma operação de dimensionamento para o tamanho desejado.
• Você não pode dimensionar de um cache Básico diretamente para um cache Premium. Primeiro, dimensione do Básico para o Standard em uma única operação de dimensionamento e do Standard para o Premium em uma operação de dimensionamento subsequente.
• Não é possível dimensionar de um tamanho maior para o tamanho C0 (250 MB) . No entanto, você pode escalar para qualquer outro tamanho dentro do mesmo tipo de preço. Por exemplo, você pode escalar de C5 Standard para C1 Standard.
• Não é possível escalonar de um cache Premium, Standard ou Basic para um cache Enterprise ou Enterprise Flash.
• Não é possível escalonar entre Enterprise e Enterprise Flash.

Você pode escalar horizontalmente/verticalmente com as seguintes restrições:

• A escala horizontal só tem suporte nas camadas Premium, Enterprise e Enterprise Flash.
• A redução horizontal só tem suporte na camada Premium.
• Na camada Premium, o clustering deve ser habilitado primeiro, antes de escalar ou reduzir horizontalmente.
• No nível Premium, há suporte em disponibilidade geral para escalar verticalmente até 10 fragmentos. O suporte para até 30 fragmentos está em versão prévia. (Para caches com duas réplicas, o limite de fragmentos é 20. Com três réplicas, o limite de fragmentos é 15.)
• Somente as camadas de serviço Enterprise e Enterprise Flash podem escalar verticalmente e horizontalmente simultaneamente.

Como escalar – camadas de serviço Basic, Standard e Premium

Escalar ou reduzir verticalmente com Basic, Standard e Premium

Escalar e reduzir verticalmente usando o portal do Azure

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

   

2. Selecione um tipo de preço no painel de trabalho e escolha Selecionar.

   

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

   

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

Observação

Quando você escalar ou reduzir verticalmente um cache no portal, as configurações maxmemory-reserved e maxfragmentationmemory-reserved são reduzidas horizontalmente em proporção ao tamanho do cache. Por exemplo, maxmemory-reserved se for definido como 3 GB em um cache de 6 GB e você dimensionar para um cache de 12 GB, as configurações serão atualizadas automaticamente para 6 GB durante o dimensionamento. Quando você reduz verticalmente, o inverso acontece.

Escalar e reduzir verticalmente usando o PowerShell

É possível escalar as instâncias do Cache Redis do Azure com o PowerShell usando o cmdlet Set-AzRedisCache quando as propriedades Size ou Sku forem modificadas. O exemplo a seguir mostra como escalar um cache denominado myCache para um cache de 6 GB na mesma camada de serviço.

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

Para saber mais sobre o dimensionamento com o PowerShell, consulte Para dimensionar um Cache Redis do Azure usando PowerShell.

Escalar e reduzir verticalmente usando a CLI do Azure

Para escalar suas instâncias do Cache do Azure para Redis usando a CLI do Azure, chame o comando az redis update. Use a propriedade sku.capcity para escalar dentro de uma camada, por exemplo, de um cache Standard C0 para Standard C1:

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

Use as propriedades "sku.name" e "sku.family" para escalar verticalmente para uma camada diferente, por exemplo, de um cache Standard C1 para um cache Premium P1:

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

Para saber mais sobre o dimensionamento com o CLI do Azure, consulte Alterar as configurações de um Cache Redis do Azure existente.

Observação

Quando você escala ou reduz verticalmente um cache de forma programada (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. Somente a alteração de escala é respeitada. Essas configurações de memória podem ser atualizadas após a conclusão da operação de colocação em escala.

Escalar ou reduzir horizontalmente – somente Premium

Criar um novo cache escalonado horizontalmente usando clustering

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, do clustering e persistência de dados. Para habilitar o clustering, selecione Habilitar.

   

   Você pode ter até 30 fragmentos no cluster. Depois de selecionar Habilitar, mova o controle deslizante ou digite um número entre 1 e 30 para a 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 no tipo de preço.

   

   Após a criação do cache, você se conecta a ele e o usa como um cache não agrupado. O Redis distribui os dados em todos os fragmentos de cache. Se o diagnóstico for habilitado, as métricas serão capturadas separadamente para cada fragmento e poderão ser visualizadas no Cache do Azure para Redis usando o menu Recurso.

3. Conclua a criação do cache usando o guia de início rápido.

A criação do cache demora um pouco. Monitore o progresso na página Visão Geral do Cache do Azure para Redis. Quando o Status for mostrado como Em execução, o cache estará pronto para uso.

Observação

Há algumas pequenas diferenças necessárias em seu aplicativo cliente quando o cluster é configurado. Para saber mais, confira Preciso fazer alguma alteração no meu aplicativo cliente para usar clustering?

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

Escalar ou reduzir horizontalmente um cache Premium em execução

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 as conexões máximas disponíveis para clientes.

Escalar e reduzir horizontalmente usando o PowerShell

É possível escalar horizontalmente as instâncias do Cache do Azure para Redis com o PowerShell usando o cmdlet Set-AzRedisCache quando a propriedade ShardCount for modificada. O exemplo a seguir mostra como escalar horizontalmente um cache chamado myCache para usar três fragmentos (ou seja, escalar horizontalmente por um fator de três)

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

Para saber mais sobre o dimensionamento com o PowerShell, consulte Para dimensionar um Cache Redis do Azure usando PowerShell.

Escalar e reduzir horizontalmente usando a CLI do Azure

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

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

Para saber mais sobre o dimensionamento com o CLI do Azure, consulte Alterar as configurações de um Cache Redis do Azure existente.

Observação

Quando você escala ou reduz verticalmente um cache de forma programada (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. Somente a alteração de escala é respeitada. Essas configurações de memória podem ser atualizadas após a conclusão da operação de colocação em escala.

Observação

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

Como escalar verticalmente e horizontalmente – camadas de serviço Enterprise e Enterprise Flash

As camadas de serviço Enterprise e Enterprise Flash são capazes de escalar verticalmente e horizontalmente em uma operação. Outras camadas de serviço exigem operações separadas para cada ação.

Cuidado

As camadas Enterprise e Enterprise Flash ainda não dão suporte a operações de redução vertical ou redução horizontal.

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 escalar verticalmente, escolha um Tipo de cache diferente e escolha Salvar.

   Importante

   No momento, você só pode escalar verticalmente. Não é possível reduzir verticalmente.

   

3. Para escalar horizontalmente, aumente o controle deslizante Capacidade. A capacidade aumenta em incrementos de dois. Esse número reflete quantos nós subjacentes do Redis Enterprise 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, você só pode escalar horizontalmente, aumentando a capacidade. Você não pode reduzir horizontalmente.

   

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

   

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

Dimensionar usando o PowerShell

É possível escalar as instâncias do Cache Redis do Azure com o PowerShell usando o cmdlet Set-AzRedisEnterpriseCache. Você pode modificar a propriedade Sku para escalar verticalmente a instância. Você pode modificar a propriedade Capacity para escalar horizontalmente a instância. O exemplo a seguir mostra como escalar um cache chamado myCache para uma instância do Enterprise E20 (25 GB) com capacidade de 4.

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

Dimensionar usando a CLI do Azure

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

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

Perguntas frequentes sobre dimensionamento

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

• Posso escalonar para um cache Premium, por meio dele ou nele?
• 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?
• Posso usar todos os recursos da camada Premium após a escala?
• A configuração dos meus bancos de dados personalizados foi afetada durante o dimensionamento?
• O cache estará disponível durante o dimensionamento?
• Há limitações de dimensionamento com a replicação geográfica?
• Operações sem suporte
• Quanto tempo o dimensionamento leva?
• Como saber quando o dimensionamento é concluído?
• Preciso fazer alguma alteração no meu aplicativo cliente para usar clustering?
• Como as chaves são distribuídas em um cluster?
• Qual é o maior tamanho de cache que eu posso criar?
• Todos os clientes do Redis dão suporte ao clustering?
• Como posso me conectar ao meu cache quando o clustering estiver 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 standard?
• Posso usar clustering com os provedores de Estado de Sessão ASP.NET Redis e Caching de Saída?
• Estou recebendo exceções MOVE ao usar StackExchange.Redis e clustering. O que devo fazer?
• Qual é a diferença entre Clustering de software de código aberto e Clustering Enterprise em caches da camada de serviço Enterprise?
• Quantos fragmentos os caches da camada de serviço Enterprise usam?

Posso escalonar para um cache Premium, por meio dele ou nele?

• Você não pode dimensionar de um cache Premium para um tipo de preço Básico ou Standard.
• Você pode dimensionar de um tipo de preço de cache Premium para outro.
• Você não pode dimensionar de um cache Básico diretamente para um cache Premium. Primeiro, dimensione do Básico para o Standard em uma única operação de dimensionamento e do Standard para o Premium em uma operação de dimensionamento subsequente.
• Você não pode escalar de um cache Premium para um cache Enterprise ou Enterprise Flash.
• Se você habilitou o clustering quando criou o cache Premium, será possível alterar o tamanho do cluster. Se o cache foi criado sem clustering habilitado, é possível configurar o clustering em um momento posterior.

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ê escala um cache Basic para um tamanho diferente, ele é desligado e um novo cache é provisionado usando o novo tamanho. Durante esse tempo, o cache não está disponível e todos os dados em cache são perdidos.
• Quando você dimensiona um cache Básico para um cache Standard, um cache de réplica é provisionado e os dados são copiados do cache primário no cache de réplica. O cache permanece disponível durante o processo de dimensionamento.
• Quando você escala um cache Standard, Premium, Enterprise ou Enterprise Flash para um tamanho diferente, uma das réplicas é desligada e provisionada novamente para o novo tamanho, os dados são transferidos e a outra réplica executa um failover antes de ser provisionada novamente, de forma semelhante ao processo que ocorre durante uma falha em um dos nós de cache.
• Quando você escala horizontalmente um cache clusterizado, novos fragmentos são provisionados e adicionados ao cluster do servidor Redis. Os dados são então refragmentados em todos os fragmentos.
• Quando você dimensiona em um cache clusterizado, os dados são refragmentados primeiro e o tamanho do cluster é reduzido para os fragmentos necessários.
• Em alguns casos, como dimensionar ou migrar seu cache para um cluster diferente, o endereço IP subjacente do cache pode mudar. O registro DNS do cache muda 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.

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

• 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 colocação em escala.
• Quando você dimensiona um cache Básico para um cache Standard, os dados no cache geralmente são preservados.
• Quando você escala um cache Standard, Premium, Enterprise ou Enterprise Flash para um tamanho maior, geralmente, todos os dados são preservados. Quando você reduz um cache Standard ou Premium para um tamanho menor, dados podem ser perdidos se o tamanho dos dados exceder o novo tamanho menor quando ele for reduzido. Se dados forem perdidos ao se reduzir, as chaves serão removidas usando a política de remoção allkeys-lru .

Posso usar todos os recursos da camada Premium após a escala?

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 a escala.

Esses recursos não podem ser adicionados depois que você cria o cache Premium:

• Injeção de VNet
• Adição da redundância de zona
• Usando várias réplicas por primária

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

A configuração dos meus bancos de dados personalizados foi afetada durante o dimensionamento?

Se você configurou um valor personalizado para a databases configuração durante a criação de cache, lembre-se que alguns tipos de preço têm limites de banco de dados diferentes. Algumas considerações ao dimensionar neste cenário:

• Ao reduzir para um tipo de preço com um limite databases menor do que a camada atual:
  • Ao usar o número padrão de databases, que é 16 para todos os tipos de preços, nenhum dado será perdido.
  • Ao usar um número personalizado de databases, que se adequa aos limites do tipo para o qual você está dimensionando, essa configuração databases é mantida e nenhum dado é perdido.
  • Ao usar um número personalizado de databases, que excede os limites do novo tipo, a configuração databases é reduzida para os limites do novo tipo e todos os dados nos bancos de dados removidos são perdidos.
• Ao reduzir para um tipo de preço com o mesmo limite ou com um limite superior do que o tipo atual para databases, sua configuração databases é mantida e nenhum dado é perdido.

Embora os caches Standard, Premium, Enterprise e Enterprise Flash tenham um SLA (Contrato de Nível de Serviço) para disponibilidade, não há SLA para perda de dados.

O cache estará disponível durante o dimensionamento?

• Os caches Standard, Premium, Enterprise e Enterprise Flash permanecem disponíveis durante a operação de colocação em escala. No entanto, falhas de conexão podem ocorrer durante a colocação em escala desses caches e também durante a colocação em escala de caches Basic para Standard. Esses pontos de conexão devem ser pequenos e os clientes do Redis devem ser capazes de restabelecer a conexão imediatamente.
• Para caches Enterprise e Enterprise Flash usando a replicação geográfica ativa, colocar em escala apenas um subconjunto de caches vinculados pode introduzir problemas ao longo do tempo em alguns casos. É recomendável colocar em escala todos os caches no grupo de replicação geográfica juntos, sempre que possível.
• Os caches Basic ficam offline durante o dimensionamento de operações para um tamanho diferente. Os caches Básicos permanecem disponíveis ao dimensionar de Básico para Standard, mas poderão enfrentar um ponto de conexão pequeno. Se ocorrer um ponto de conexão, os clientes do Redis devem ser capazes de restabelecer a conexão imediatamente.

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

Com a replicação geográfica passiva configurada, você pode observar que não é possível escalonar 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 mude o número de fragmentos em um cluster. Desvincule o cache para executar esses comandos. Para obter mais informações, consulte Configurar Replicação geográfica.

Com a replicação geográfica ativa configurada, você não pode escalar um cache. Todos os caches em um grupo de replicação geográfica devem ter o mesmo tamanho e capacidade.

Operações sem suporte

• Você não pode dimensionar de uma camada de preços mais alta para uma camada de preços mais baixa.
  • Você não pode dimensionar de um cache Premium para um cache Standard ou Básico.
  • Você não pode dimensionar de um cache Standard para um cache Básico.
• É possível dimensionar de um cache Básico para um cache Standard, mas não é possível alterar o tamanho simultaneamente. Para um tamanho diferente, realize uma operação de dimensionamento subsequente para o tamanho desejado.
• Você não pode dimensionar de um cache Básico diretamente para um cache Premium. Primeiro, dimensione de Básico para Standard em uma única operação de dimensionamento e de Standard para Premium em uma operação posterior.
• Você não pode escalar de um cache Premium para um cache Enterprise ou Enterprise Flash.
• Não é possível dimensionar de um tamanho maior para o tamanho 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 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
• Alta carga do servidor: uma carga maior do servidor significa que o servidor Redis está ocupado e tem ciclos de CPU limitados para concluir a redistribuição de dados

Em geral, dimensionar um cache sem dados leva cerca de 20 minutos. Para caches clusterizados, o dimensionamento leva cerca de 20 minutos por fragmento com dados mínimos.

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.

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

• Quando o clustering estiver habilitado, somente o banco de dados 0 estará disponível. Se o aplicativo cliente usa vários bancos de dados e tenta fazer leituras ou gravações em um banco de dados diferente de 0, a seguinte exceção é gerada: 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 saber mais, confira Redis Cluster Specification - Implemented subset (Especificação do cluster Redis — subconjunto implementado).

• Se você estiver usando StackExchange.Redis, use a versão 1.0.481 ou posterior. É possível se conectar ao cache usando os mesmos pontos de extremidade, portas e chaves usados ao se conectar a um cache sem o clustering habilitado. 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. Veja Todos os clientes do Redis dão suporte ao clustering?

• 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 estiver usando o provedor de Estado de Sessão ASP.NET Redis, você deverá usar a versão 2.0.1 ou superior. Veja Posso usar clustering com os provedores de Estado de Sessão ASP.NET Redis e Caching de Saída?

Importante

Ao usar as camadas de serviço Enterprise ou Enterprise Flash, você tem a opção de escolher entre o Modo de Cluster de Software de Código Aberto ou o Modo de Cluster Empresarial. O Modo de Cluster de Software de Código Aberto é 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 clustering do Redis Enterprise, que não requer nenhuma alteração do cliente para ser usado. Para obter mais informações, confira o Clustering no Enterprise.

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.

Para obter um código de exemplo sobre como trabalhar com clustering e localizar chaves no mesmo fragmento com o cliente StackExchange.Redis, confira a parte clustering.cs da amostra Olá, Mundo.

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

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

Todos os clientes do Redis dão suporte ao clustering?

Muitas bibliotecas de clientes dão suporte ao clustering do Redis, mas nem todas. Verifique a documentação da biblioteca que você está usando para verificar se a biblioteca e a versão usadas aceitam clustering. StackExchange.Redis é uma biblioteca que aceita as versões mais recentes do clustering. Para obter mais informações sobre outros clientes, confira a seção Playing with the cluster do Redis cluster tutorial.

O protocolo de clustering do Redis requer que cada cliente se conecte a cada fragmento diretamente no modo de clustering e também defina novas respostas de erro, como 'MOVED' e 'CROSSSLOTS'. Quando você tenta usar uma biblioteca de clientes que não dá suporte ao clustering com um cache de modo de cluster, isso pode resultar em um número excessivo de exceções de redirecionamento MOVED ou apenas interromper o aplicativo, caso você esteja fazendo solicitações de várias chaves entre slots.

Observação

Se você estiver usando o 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 mais informações sobre problemas com as exceções move, confira exceções move.

Como posso me conectar ao meu cache quando o clustering estiver habilitado?

Você pode se conectar ao seu cache usando os mesmos pontos de extremidade, portas e chaves usados ao conectar-se a um cache que não tem o clustering habilitado. O Redis gerencia o clustering no back-end para que você não precise gerenciá-lo por meio de seu cliente.

Posso me conectar diretamente aos fragmentos individuais do meu cache?

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

Você precisa usar a opção -p 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 da camada de serviço Premium não habilitados para TLS, as portas estão disponíveis no intervalo 130XX
• Para caches da camada de serviço Premium habilitados para TLS, as portas estão disponíveis no intervalo 150XX
• Para caches Enterprise e Enterprise Flash usando clustering de software de código aberto, a conexão inicial é por meio da porta 10000. A conexão com nós individuais pode ser feita usando portas no intervalo 85XX. As portas 85xx serão alteradas ao longo do tempo e não devem ser codificadas no seu aplicativo.

Posso configurar o clustering para um cache criado anteriormente?

Sim. Primeiro, certifique-se de que o cache está na camada Premium escalando-o verticalmente. Em seguida, você vê as opções de configuração de cluster, incluindo uma opção para habilitar o cluster. Altere o tamanho do cluster após a criação do cache ou depois de ter habilitado o clustering pela primeira vez.

Importante

Não é possível desfazer a habilitação do clustering. Um cache com clustering habilitado e apenas um fragmento se comporta de maneira diferente de um cache do mesmo tamanho sem clustering.

Todos os caches das camadas de serviço Enterprise e Enterprise Flash são sempre clusterizados.

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

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

Posso usar clustering com os provedores de Estado de Sessão ASP.NET Redis e Caching de Saída?

• Provedor de Cache de Saída Redis : sem necessidade de alterações.
• Provedor de Estado de Sessão Redis: para usar o clustering, você deve usar RedisSessionStateProvider 2.0.1 ou superior; do contrário, uma exceção será lançada, que é uma alteração interruptiva. Para saber mais, confira Detalhes da alteração interruptiva v2.0.0.

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

Se você estiver usando StackExchange.Redis e receber exceções MOVE ao usar clustering, verifique se está usando StackExchange.Redis 1.1.603 ou posterior. Para obter instruções sobre como configurar seus aplicativos .NET para usar StackExchange.Redis, confira Configurar os clientes de cache.

Qual é a diferença entre clustering de software de código aberto e clustering empresarial em caches da camada de serviço Enterprise?

O Modo de Cluster de Software de Código Aberto é 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 clustering do Redis Enterprise, que não requer nenhuma alteração do cliente para ser usado. Para obter mais informações, confira o Clustering no Enterprise.

Quantos fragmentos os caches da camada de serviço Enterprise usam?

Ao contrário dos caches das camadas de serviço Basic, Standard e Premium, os caches Enterprise e Enterprise Flash podem aproveitar vários fragmentos em um único nó. Para obter mais informações, confira Fragmentação e utilização da CPU.

Próximas etapas

• Configurar sua configuração de Maxmemory-reserved
• Melhores práticas de dimensionamento