As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Redimensionamento de cluster on-line
A refragmentação consiste na adição e remoção de fragmentos ou nós de seu cluster bem como na redistribuição de espaços importantes. Como resultado, vários itens têm impacto na operação de refragmentação, como a carga no cluster, a utilização de memória e o tamanho geral dos dados. Para obter a melhor experiência, recomendamos que você siga as práticas gerais recomendadas de cluster para distribuição padrão uniforme de workload. Além disso, recomendamos as etapas a seguir.
Antes de iniciar a refragmentação, recomendamos o seguinte:
Teste sua aplicação: teste o comportamento da sua aplicação durante a refragmentação em um ambiente de preparação, se possível.
-
Receba uma notificação prévia de problemas de escalabilidade: a refragmentação é uma operação que demanda uso intensivo de computação. Por causa disso, recomendamos manter a utilização da CPU abaixo de 80 por cento em instâncias de vários núcleos e abaixo de 50 por cento em instâncias de núcleo único durante a refragmentação. Monitore as métricas ElastiCache (Redis OSS) e inicie a refragmentação antes que seu aplicativo comece a observar problemas de escalabilidade. As métricas úteis para acompanhar são
CPUUtilization,NetworkBytesIn,NetworkBytesOut,CurrConnections,NewConnections,FreeableMemory,SwapUsageeBytesUsedForCacheItems. Garanta memória livre suficiente disponível antes da redução de escala na horizontal: se você estiver reduzindo a escala na horizontal, garanta que a memória livre disponível nos fragmentos a serem retidos é, pelo menos, 1,5 vez maior do que a memória usada nos fragmentos que você planeja remover.
Inicie a refragmentação em horários fora de pico: essa prática ajuda a reduzir a latência e o impacto de throughput no cliente durante a operação de refragmentação. Ela também ajuda a concluir a refragmentação com mais rapidez à medida que mais recursos podem ser usados na redistribuição de slots.
Analise o comportamento de tempo limite do cliente: alguns clientes podem observar maior latência durante o redimensionamento de cluster online. Configurar sua biblioteca de cliente com um tempo limite maior pode ajudar dando tempo para o sistema se conectar mesmo em condições de carga maiores no servidor. Em algum casos, você pode abrir um grande número de conexões com o servidor. Nesses casos, considere adicionar o recuo exponencial para uma nova conexão lógica. Fazer isso pode ajudar a evitar uma intermitência de novas conexões acessando o servidor ao mesmo tempo.
Carregue suas funções em cada fragmento — Ao escalar seu cluster, ElastiCache replicará automaticamente as funções carregadas em um dos nós existentes (selecionados aleatoriamente) para o (s) novo (s) nó (s). Se seu cluster tiver o Redis OSS 7.0 ou superior e seu aplicativo usar as funções do Redis OSS
, recomendamos carregar todas as suas funções em todos os fragmentos antes de escalar para que seu cluster não tenha funções diferentes em fragmentos diferentes.
Após a refragmentação, observe o seguinte:
-
A redução da escala horizontalmente pode ser parcialmente bem-sucedida se não houver memória suficiente disponível nos fragmentos de destino. Se isso ocorrer, analise a memória disponível e refaça a operação, se necessário. Os dados nos fragmentos de destino não serão excluídos.
Slots com itens grandes não são migrados. Especificamente, slots com itens maiores do que 256 MB após a serialização não são migrados.
Os comandos
FLUSHALLeFLUSHDBnão são compatíveis em scripts Lua durante uma operação de reestilhaçamento. Antes do Redis OSS 6, oBRPOPLPUSHcomando não era suportado se ele operasse no slot que está sendo migrado.
