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.
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.
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 estiver habilitado, as métricas serão capturadas separadamente para cada fragmento e poderão ser exibidas no Cache do Azure para Redis usando o menu Recurso.
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.
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ê dimensiona um cache para cima ou para baixo programaticamente (por exemplo, usando o PowerShell ou a CLI do Azure), quaisquer maxmemory-reserved ou maxfragmentationmemory-reserved são ignorados como parte da solicitação de atualização. Somente a alteração de escala é respeitada. Você pode atualizar essas configurações de memória após a conclusão da operação de dimensionamento.
Colocar um cluster em escala executa o comando MIGRATE, que é um comando caro. Para 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.
Atenção
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
Para escalonar seu cache, navegue até ele no portal do Azure e selecione Escalar no menu Recurso.
Para escalar verticalmente, escolha um Tipo de cache diferente e escolha Salvar.
Importante
No momento, você só pode escalar verticalmente. Você não pode reduzir verticalmente.
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 escalar horizontalmente.
Enquanto o cache escala para a nova camada, uma notificação Escalando o Cache Redis é exibida.
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?
- 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 não são alterados durante uma operação de dimensionamento.
Como funciona o dimensionamento?
- Quando você dimensiona um cache Basic para um tamanho diferente, o cache é 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.
- Ao dimensionar ou migrar seu cache para um cluster diferente, o endereço IP subjacente do cache pode ser alterado. 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 o cache ou configurar NSGs ou firewalls que permitem o tráfego para o cache, seu aplicativo poderá ter problemas para se conectar após as atualizações de 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ê dimensiona um cache Standard ou Premium para um tamanho menor, os dados podem ser perdidos se o tamanho de dados original exceder o novo tamanho menor. 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 o dimensionamento.
Esses recursos não podem ser adicionados depois que você cria o cache Premium:
- Injetando redes virtuais
- 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.
Meu cache está 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ê 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 Enterprise do Cache do Azure para Redis.
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. Os seguintes fatores 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: carga de servidor mais alta significa que o servidor Redis está ocupado e ciclos limitados de CPU 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 a dois fragmentos quando ele não estiver sob cargas pesadas. Se você tiver mais fragmentos, o tempo de dimensionamento não aumentará de forma linear.
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?
Importante
Ao usar as camadas Enterprise ou Enterprise FLash, você tem a opção de modo de cluster do OSS ou 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 a seçãoClustering.
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 Redis requer que cada cliente se conecte a cada fragmento diretamente no modo de clustering e também define novas respostas de erro, como MOVED na 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 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 na ramificação instável do repositório Redis no GitHub. Esta versão implementa o suporte básico quando iniciado com o switch -c . Para mais informações, veja Brincando com o cluster em https://redis.iono tutorial de cluster 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.
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 que você habilitar 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.
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?
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.
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 a seçãoClustering.
Quantos fragmentos os caches da camada de serviço Enterprise usam?
Ao contrário dos caches de camadas 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 a seção Configuração de fragmentação.
Próximas etapas
