Downgrade a cluster - Elasticsearch: Central de Documentação do Alibaba Cloud

Quando o tráfego de negócios oscila entre horários de pico e fora de pico, a utilização de recursos de um cluster Alibaba Cloud Elasticsearch pode permanecer baixa por longos períodos. Faça o downgrade do cluster para reduzir as especificações dos nós, diminuir a quantidade de nós ou alterar o tipo de armazenamento. Assim, os recursos se adequam à demanda do negócio e os custos são otimizados.

Precauções

Um downgrade pode causar atrasos no service, conflitos de configuração e alterações no faturamento. Leia as precauções abaixo antes de prosseguir.

Estabilidade do service

A tabela a seguir descreve as regras de estabilidade do service aplicáveis durante uma alteração de configuração do cluster.

Condição	Impacto	Mitigação
O cluster está sob alta carga e não possui réplicas de índice. Alta carga significa escritas ou consultas com alta concorrência durante o downgrade, com uso de CPU superior a 60% ou uso de memória heap da JVM superior a 50%.	Timeouts de acesso ocasionais	Ative um mecanismo de nova tentativa no cliente. Aumente o número de réplicas de índice para pelo menos 1 antes do downgrade.
O número de nós de dados é 2 ou menos após o downgrade.	Possível perda de dados	Garanta que cada índice tenha pelo menos 1 réplica antes do downgrade. Se o downgrade remover nós de dados, migre os dados desses nós primeiro.

Os valores de alta carga na tabela anterior indicam quando podem ocorrer timeouts de acesso durante uma alteração de configuração. Eles não correspondem aos limiares de validação verificados pelo sistema ao enviar um pedido de downgrade. Para consultar os limiares de validação, veja Segurança de carga em Verificações pré-downgrade.

Janela de manutenção — Execute o downgrade durante horários de menor movimento do negócio.
Endereços IP dos nós — Após a conclusão da alteração, os endereços IP dos nós no cluster mudam.

Aviso

Se você ativar a validação fraca para downgrade, o sistema flexibiliza a validação de recursos realizada antes do procedimento. Isso pode resultar em recursos insuficientes e afetar a estabilidade do cluster e os serviços. A indisponibilidade de service causada por um downgrade realizado com essa opção ativada não é coberta pelo Acordo de Nível de Serviço (SLA). A validação fraca vem desativada por padrão e seu uso não é recomendado. Avalie totalmente os riscos antes de ativá-la.

Restrições de configuração

Espaço de armazenamento de nós de dados — Apenas clusters na arquitetura de controle cloud-native (v3) suportam downgrade do espaço de armazenamento de nós de dados. Um cluster na arquitetura de controle v2 não suporta redução da capacidade de disco de um único nó, e não é possível fazer downgrade do espaço de armazenamento de um cluster v2 pelo console ou por uma API. Para reduzir o espaço de armazenamento de um cluster v2, entre em contato com o suporte técnico. Para reduzir a capacidade total de disco sem auxílio do suporte técnico, reduza a escala de nós de dados. Essa operação altera o número de nós no cluster.
Versão do cluster — Não é possível atualizar a versão do cluster durante o downgrade.
Tipos de nó por operação — Uma única operação de downgrade pode alterar apenas um tipo de nó.
Nós de dados elásticos — Nós de dados elásticos não podem sofrer downgrade.
Intervalo entre alterações — Duas operações consecutivas de downgrade no mesmo cluster devem ter um intervalo mínimo de 30 minutos.
Número de nós após o downgrade — O impacto do downgrade na quantidade de nós depende do método de atualização:
Atualização in-place — O número de nós permanece o mesmo. Apenas as especificações dos nós ou o espaço de armazenamento mudam.
Atualização blue-green — O sistema adiciona primeiro a mesma quantidade de novos nós que a contagem atual e migra os dados para eles. Após a conclusão da migração, os nós antigos são removidos. O número final de nós equivale à quantidade exigida pelas especificações alvo do downgrade. Um aumento temporário no número de nós durante esse processo é normal.

Restrições de especificação de CPU e memória

Regra básica — A CPU e a memória alvo devem ser pelo menos metade da CPU e memória atuais.
Especificações não permitidas — As seguintes especificações não podem ser usadas como alvo de downgrade: 1-core 2 GiB, 2-core 2 GiB, 2-core 4 GiB e 4-core 4 GiB.
Nós Kibana — 2-core 2 GiB é um alvo válido de downgrade para um nó Kibana, mesmo que essa especificação apareça na lista de não permitidos para outros tipos de nó.
Caso especial — Se for obrigatório fazer downgrade para uma especificação não permitida, crie um novo cluster e migre seus dados.

Impacto nos custos

Após o envio de um pedido de downgrade, o sistema realiza o faturamento com base na configuração atualizada. Para conhecer as regras de faturamento, consulte pay-as-you-go e subscription.

Verificações pré-downgrade

Realizar um downgrade sem as verificações abaixo pode travar o cluster, causar perda de dados ou tornar o service indisponível. Verifique cada item antes de enviar o pedido de downgrade.

Saúde do cluster

Execute GET _cluster/health para garantir que o status do cluster seja GREEN.

Segurança de carga

Um cluster suporta downgrade se atender às condições da tabela a seguir.

Tipo de nó	Uso de CPU	Uso de heap da JVM
Nó mestre dedicado	O pico de uso de um único nó nas últimas 24 horas é inferior a 30%.	O pico de uso de um único nó nas últimas 24 horas é inferior a 25%.
Outros tipos de nó	Ambas as condições devem ser atendidas: o pico de uso de um único nó nas últimas 24 horas é inferior a 50% e a média de uso de todos os nós nas últimas 24 horas é inferior a 30%.	Ambas as condições devem ser atendidas: o pico de uso de um único nó nas últimas 24 horas é inferior a 50% e a média de uso de todos os nós nas últimas 24 horas é inferior a 30%.

Os limiares na tabela anterior correspondem aos valores de validação verificados pelo sistema ao enviar um pedido de downgrade. A avaliação ocorre ao longo de um período estatístico do último dia (últimas 24 horas), e não com base nos valores em tempo real exibidos na página de monitoramento. O pico de uso é o maior uso atingido por um único nó no último dia. A média de uso é a utilização média de todos os nós no último dia. Portanto, mesmo que o valor atual em tempo real esteja baixo, a validação ainda bloqueará o pedido se o pico de uso de um único nó ou a média de uso de todos os nós tiver ultrapassado o limiar em qualquer momento do último dia quando você clique em Downgrade Configuration na página Instances e enviar o pedido. Esses limiares de validação diferem dos valores de alta carga que descrevem o risco de timeouts de acesso durante uma alteração de configuração. Para consultar os valores de alta carga, veja Estabilidade do service em Precauções.

Se uma mensagem indicar que o uso de CPU está acima do limiar de validação ao enviar o pedido, verifique o pico de uso de um único nó e a média de uso de todos os nós no último dia comparando-os aos limiares listados para cada tipo de nó na tabela anterior. Envie o pedido de downgrade novamente somente após ambas as métricas caírem abaixo dos limiares.

Prontidão dos índices

Execute GET _cat/indices?v para verificar se algum índice possui status CLOSE. Caso exista tal índice, execute POST /<index_name>/_open para abrir temporariamente esses índices. Como os índices são abertos apenas temporariamente, feche-os novamente após a conclusão da alteração se o seu negócio não exigir que permaneçam abertos. Um índice fechado pode causar falha na alteração de configuração das seguintes maneiras:
- O status do cluster não consegue atingir GREEN, chegando no máximo a YELLOW. O Elasticsearch exige status GREEN antes de executar certas alterações de configuração sensíveis, como ajustes nas regras de alocação de shards.
- O cluster realoca shards durante a alteração de configuração. Shards de um índice fechado não podem participar da realocação, fazendo com que operações dependentes do status GREEN falhem.
Execute GET _cat/indices?v para confirmar que o número de réplicas de cada índice é pelo menos 1.

Para uma instância multizona, garanta que o número de réplicas de qualquer índice no cluster seja menor que o número de zonas durante a alteração. (Recomendado) Defina o número de réplicas como 1 e aumente-o manualmente após a conclusão da alteração.

Se os índices contiverem muitos fragmentos de documentos excluídos, esses fragmentos consomem espaço significativo em disco. Um downgrade de disco pode falhar na validação ou reportar erro quando o espaço restante for insuficiente. Durante horários de menor movimento, execute um force merge para remover fragmentos de documentos excluídos e liberar espaço em disco antes de fazer o downgrade do disco.

Downgrade no console

É possível fazer downgrade de um cluster Alibaba Cloud Elasticsearch no console ou chamando uma operação de API. Para o método via API, consulte UpdateInstance. O procedimento a seguir descreve o método pelo console.

Escolha uma aba com base na alteração desejada. Use a aba Downgrade specifications, disk type, and space para reduzir especificações de nós, tipo de disco ou espaço em disco. A redução de escala de nós de dados oferece duas entradas: a página Remove Data Nodes e Number of data nodes na página Downgrade Configuration. Um cluster na cloud-native control architecture (v3) pode ter sua escala reduzida diminuindo Number of data nodes diretamente na página Downgrade Configuration, portanto use a aba Downgrade specifications, disk type, and space para essa operação. Utilize a aba Scale in data nodes se a página de downgrade exibir The current page does not support decreasing the number of nodes of this type. For data nodes, go to the cluster data node scale-in page.

Downgrade specifications, disk type, and space

Na lista Instances, clique no ícone de mais à direita da instância alvo e selecione Downgrade Configuration no menu suspenso.

Outra entrada: Na página Basic Information, clique em Configuration Update e depois em Downgrade.
Na página Downgrade Configuration, ajuste os parâmetros de configuração conforme as necessidades do seu negócio.

Os parâmetros ajustáveis variam conforme o tipo e a versão do cluster. Prevalecem as opções exibidas na página Downgrade Configuration.
- Node storage type — Os downgrades seguem esta ordem, do maior para o menor desempenho. Para restrições sobre especificações de CPU e memória, consulte Restrições de especificação de CPU e memória em Precauções.
  - Discos locais: de SSD local (disco local NVMe SSD) para SATA local (disco local SATA HDD).
    
    Local disks são dispositivos de disco rígido local na máquina física onde reside a instância ECS. Eles fornecem acesso a armazenamento local para a instância ECS e são adequados para cenários de negócios com requisitos muito altos de desempenho de I/O de armazenamento e armazenamento em massa econômico.
  - ESSD: Um ESSD (Enterprise SSD) combina rede 25 GE e tecnologia RDMA para oferecer até um milhão de operações aleatórias de leitura/gravação por disco e baixa latência de caminho único. Um disco ESSD PL0 não pode sofrer downgrade para SSD padrão.
  - Discos de geração anterior: de SSD padrão para ultra disk e basic disk. Esses discos estão sendo descontinuados em algumas regiões e zonas. (Recomendado) Selecione um ESSD ao escolher um disco.
- Downgrade of data node storage space (only for clusters in the cloud-native control architecture (v3)) — Para manter a estabilidade do cluster, o uso do espaço em disco após o downgrade deve ser inferior a 60%. Antes do downgrade, certifique-se de que: uso atual do disco < espaço em disco após o downgrade × 0,6.
  
  Na página Basic Information da instância, verifique Control Architecture e confirme se o valor é cloud-native control architecture (v3). Para opções disponíveis em um cluster na arquitetura de controle v2, consulte Restrições de configuração em Precauções.
- Downgrade of the number of data nodes (scale in data nodes) — Na seção Select Change Items, clique em data node e diminua Number of data nodes para reduzir a escala de nós de dados.
  
  Nota
  A página de downgrade de alguns clusters não suporta a diminuição do número de nós. Se, após diminuir Number of data nodes, a página exibir The current page does not support decreasing the number of nodes of this type. For data nodes, go to the cluster data node scale-in page., mude para a aba Scale in data nodes e conclua a redução de escala pela entrada Remove Data Nodes.
- Weak validation for downgrade (desativado por padrão, não recomendado) — Ao ativar essa opção, o sistema flexibiliza a validação de recursos realizada antes do downgrade. Para riscos de estabilidade e SLA associados a essa opção, consulte Estabilidade do service em Precauções.
  
  Não é necessário especificar o método de atualização. O sistema seleciona automaticamente o método ideal (atualização in-place ou blue-green) com base nos itens de configuração alterados.
Leia e confirme os Terms of Service e o Service Level Agreement. Se estiver de acordo, clique em Buy Now. O sistema cobra taxas com base no seu método de faturamento.

Scale in data nodes

Se a página Downgrade Configuration exibir The current page does not support decreasing the number of nodes of this type. For data nodes, go to the cluster data node scale-in page., reduza a escala de nós de dados na página Remove Data Nodes.

Na página Basic Information da instância, clique em Configuration Update e depois em Remove Data Nodes.
Selecione o tipo de nó e a quantidade de nós a remover conforme as necessidades do seu negócio.

Os parâmetros ajustáveis variam conforme o tipo e a versão do cluster. Prevalece a página do console. Neste exemplo, o cluster executa Enhanced Edition 8.17.0.

Em Select Node Type, escolha data node ou cold data node. As opções disponíveis dependem da configuração real do cluster. Current Number of Nodes indica a quantidade existente de nós desse tipo. Em Number of Nodes to Remove, insira o número de nós que deseja remover desta vez.
Clique em OK. O sistema executa a operação de redução de escala e calcula as taxas com base na configuração do cluster e no seu método de faturamento.

O Alibaba Cloud Elasticsearch realiza automaticamente uma verificação de segurança dos nós antes da redução de escala. Se a verificação falhar, resolva o erro conforme a mensagem apresentada e tente a redução novamente.

Se os nós de dados que você deseja remover contiverem dados, o sistema solicitará a migração deles. Para mais informações, consulte Migração e rollback de dados.

Durante a alteração, o status do cluster muda para Initializing. O desempenho do cluster pode oscilar brevemente e falhas transitórias de requisição podem ocorrer. Após a conclusão da alteração, o status do cluster é atualizado para Normal. Para confirmar que a nova configuração entrou em vigor, consulte Monitorar progresso e verificar o downgrade.

Migração e rollback de dados

Esta seção aplica-se apenas à redução de escala de nós de dados. Para manter a segurança dos dados, os nós de dados removidos não devem conter informações. Se os nós selecionados possuírem dados, o sistema solicitará a migração. Após a migração, nenhum dado de índice permanece nos nós selecionados e nenhum novo dado é gravado neles.

Migração de dados

Na seção Remove Data Nodes, clique em Data Migration Tool na barra de prompt.

O Data Migration Tool utiliza o filtro de alocação de shards do Elasticsearch para realizar uma migração suave de dados. Seu negócio não percebe o processo de migração.
Na caixa de diálogo Migrate Data, selecione um método de migração de nós.

Defina Migration Node Type como data node e insira o Number of Nodes to Migrate. O sistema recomenda inteligentemente os endereços IP dos nós a migrar com base na distribuição de dados e na saúde do cluster. Confirme a segurança dos dados uma segunda vez. Marque a caixa de seleção para concordar com o Alibaba Cloud Elasticsearch Data Migration Service Agreement e clique em OK.
Selecione o acordo de migração de dados e clique em OK.

A tabela a seguir descreve os métodos de migração de nós.

Parâmetro	Descrição
Smart Migration	O sistema seleciona automaticamente os nós de dados a migrar com base em suas sugestões.
Custom	Selecione manualmente os nós de dados a migrar.

Rollback de dados

A migração de dados é um processo longo. Durante esse período, alterações no status do cluster ou nos dados podem causar falha na migração. É possível visualizar os detalhes em Task List. Após a falha ou conclusão da migração de dados, faça o rollback dos nós migrados seguindo estas etapas:

Faça login no console Kibana do seu cluster Elasticsearch.

Para instruções, consulte Log on to the Kibana console.

Nota
Os exemplos aqui usam Elasticsearch V6.7.0. As operações podem variar ligeiramente em outras versões.
No menu de navegação à esquerda, escolha Management > Dev Tools.

No Console, execute o comando a seguir para obter os endereços IP dos nós migrados.

GET _cluster/settings

Após a execução bem-sucedida do comando, o seguinte resultado é retornado.

{
  "transient": {
    "cluster": {
      "routing": {
        "allocation": {
          "exclude": {
            "_ip": "192.168.xx.xx,192.168.xx.xx,192.168.xx.xx"
          }
        }
      }
    }
  }
}

Execute o comando a seguir para fazer rollback dos dados nos nós migrados.

Faça rollback dos dados em parte dos nós. Remova da configuração os nós que terão rollback, mas mantenha aqueles que não serão revertidos.

PUT _cluster/settings
{
  "transient": {
    "cluster": {
      "routing": {
        "allocation": {
          "exclude": {
            "_ip": "192.168.xx.xx,192.168.xx.xx"
          }
        }
      }
    }
  }
}

Faça rollback dos dados em todos os nós.

PUT _cluster/settings
{
  "transient": {
    "cluster": {
      "routing": {
        "allocation": {
          "exclude": {
            "_ip": null
          }
        }
      }
    }
  }
}

Execute o comando a seguir para verificar se o rollback de dados foi concluído.
```
GET _cluster/settings
```
Após a execução bem-sucedida do comando, se o resultado retornado não contiver os endereços IP dos nós migrados, a tarefa de rollback de migração para esses nós estará concluída. Também é possível determinar isso observando se os shards foram realocados para os nós correspondentes.

Nota

Durante a migração ou rollback de dados, execute o comando GET _cat/shards?v para visualizar o status da tarefa.

Monitorar progresso e verificar o downgrade

Monitorar o progresso da alteração

No canto superior direito da página Basic Information da instância, clique no ícone More (três linhas horizontais) para abrir o painel Task List. Na aba Change Progress, visualize informações como horário de início da alteração, tipo de alteração, status e porcentagem de conclusão.

Clique em Show Details para ver os detalhes da alteração.

Verificar o resultado do downgrade

Após a conclusão do downgrade, confirme na página Basic Information do cluster se a configuração entrou em vigor:

O status do cluster retornou a Normal.
Contagem de nós e especificações de armazenamento — Confirme se o número de nós, as especificações de armazenamento e o espaço em disco correspondem às suas expectativas.
Balanceamento de shards — Execute GET _cat/allocation?v para verificar a distribuição de shards. Se houver desequilíbrio, resolva o problema seguindo Solutions for uneven cluster load.

Se a alteração de configuração falhar

Visualize o status e os detalhes da alteração na aba Change Progress do painel Task List e siga as etapas de solução de problemas em O que fazer se uma alteração de configuração de cluster falhar? na seção FAQ deste tópico.

FAQ

What do I do if a cluster configuration change fails?
Can I change the cloud disk type for an Elasticsearch instance?
Will changing the cluster configuration affect the Elasticsearch service?
Does the cluster automatically rebalance shards after the number of nodes changes?
What do I do if I chose the wrong configuration when purchasing an Elasticsearch instance?
Can I downgrade an instance specification after upgrading it? If so, how?
Why can't I downgrade cold data nodes?
Por que o número de nós aumenta após um downgrade de disco?

O Elasticsearch ajusta o número de nós para atingir a capacidade de disco alvo. Portanto, a quantidade de nós pode aumentar após um downgrade de disco.
Instâncias Logstash suportam downgrades?

Instâncias Logstash não suportam operações de downgrade. Para ajustar a configuração de uma instância Logstash, crie uma nova instância e migre seus dados. As operações de downgrade descritas neste tópico aplicam-se apenas a instâncias Elasticsearch.
Por que não recebi reembolso após um downgrade? Como é calculado o reembolso do downgrade?

Valor do reembolso de downgrade = taxas restantes da especificação original − taxas de compra da nova especificação. Se o resultado calculado por essa regra for menor que 0, as taxas restantes da especificação original não são suficientes para cobrir as taxas de compra da nova especificação, e nenhum reembolso é emitido. Não receber reembolso após um downgrade é um resultado normal nesse caso. Você pode verificar as taxas deste downgrade com base na regra anterior. Detalhes como prazo de chegada do reembolso e canais disponíveis estão sujeitos a description of downgrade refund rules.
O que fazer se a mensagem "The order configuration parameters do not meet the validation conditions" aparecer ao mudar de assinatura para pagamento conforme o uso?

Quando esse erro aparece após clicar em Switch to Pay-as-you-go, geralmente é causado pela compatibilidade da versão da arquitetura da instância. (Recomendado) Atualize a arquitetura da instância para V3 primeiro e envie novamente a solicitação de mudança para pagamento conforme o uso. Se a mensagem sobre parâmetros de configuração do pedido persistir após a atualização, ou se a versão da arquitetura da instância não puder ser atualizada, anote o RequestID retornado com o erro e abra um ticket para que o suporte técnico investigue e resolva o problema.
O que fazer se o downgrade estiver indisponível ou aparecer um aviso sobre recursos insuficientes?

No Alibaba Cloud Console, vá até a parte inferior da página Downgrade Configuration e ative Weak validation for downgrade para ignorar algumas verificações de recursos, incluindo avisos sobre recursos insuficientes durante uma redução de escala. Após concluir a redução, realize o balanceamento de shards novamente. Ativar a validação fraca ou forçar um downgrade apresenta riscos à estabilidade do cluster e pode causar indisponibilidade do service ou perda de dados. Prossiga apenas após compreender e aceitar esses riscos.