How to configure parameters when you create an Alibaba Cloud Elasticsearch cluster - Elasticsearch: Central de Documentação do Alibaba Cloud

Ao criar um cluster do Alibaba Cloud Elasticsearch, configure as especificações e o armazenamento dos diferentes tipos de nó conforme suas necessidades de negócio. Um cluster do Elasticsearch é composto por nós de dados, nós do Kibana, nós mestres dedicados, nós warm, nós frozen e nós de coordenação, cada um com responsabilidades distintas.

Nó de dados

Os nós de dados armazenam dados de índice e executam indexação, busca e agregação. Esses nós exigem alto desempenho de CPU, memória e I/O. Se os recursos forem insuficientes, adicione novos nós de dados ao cluster.

Nota

Se o cluster possuir nós mestres dedicados, os nós de dados funcionarão exclusivamente como nós de dados.
Caso não existam nós mestres dedicados, os nós de dados atuarão simultaneamente como nós de dados e nós mestres dedicados.
Os clusters do Alibaba Cloud Elasticsearch utilizam uma de duas arquiteturas de plano de controle: básica (v2) ou nativa da nuvem (v3). Na arquitetura v2, aumentar a escala de um cluster sem nós mestres dedicados aciona uma reinicialização. Se a carga geral do cluster for baixa e seus índices possuírem shards de réplica, o cluster poderá permanecer disponível durante a reinicialização. No entanto, em cenários de alta carga de escrita e consulta, podem ocorrer tempos limite de acesso. Por isso, execute essas operações fora dos horários de pico.

Parâmetro	Descrição
Especificações do nó de dados	Recomendamos o uso de nós de dados com 2 vCPUs e 4 GiB de memória em ambientes de teste e nós de dados com especificações superiores em ambientes de produção.
Tipo de disco do nó de dados	ESSD (Padrão): Oferece baixa latência, alto throughput e tempos de resposta rápidos. Ideal para aplicações sensíveis à latência ou cargas de trabalho intensivas em I/O. Para mais informações sobre as especificações do ESSD, consulte Especificações de nó. Para mais informações sobre desempenho, consulte ESSDs. Ultra Disk: Fornece armazenamento econômico. Adequado para cenários de log e análise que envolvem grandes volumes de dados. Standard SSD: Oferece alto IOPS e capacidade de resposta. Indicado para cenários de análise e busca online. Nota Visualize os tipos de disco suportados na página de compra. Após a criação do cluster, não é possível alterar os tipos de disco dos nós nele contidos.
Nível de desempenho do ESSD	Se você definir o parâmetro Tipo de Disco do Nó de Dados como ESSD, configure este parâmetro.
Criptografia de disco do nó de dados	A criptografia de disco oferece segurança máxima de dados sem exigir alterações adicionais em seus negócios e aplicações. Contudo, ela pode causar um pequeno impacto no desempenho do cluster. A criptografia de disco é gratuita. Nenhuma taxa adicional é gerada ao ler ou gravar dados em discos criptografados.
Espaço de armazenamento por nó de dados	O espaço de armazenamento de cada nó de dados depende do tipo de disco. Unidade: GiB. ESSD: Suporta até 6 TiB de espaço de armazenamento. Ultra Disk: Suporta até 20 TiB de espaço de armazenamento para clusters Elasticsearch V6.7, V7.7 e posteriores. Para outras versões, o espaço máximo é de 5 TiB. Standard SSD: Suporta até 6 TiB de espaço de armazenamento para clusters Elasticsearch V6.7, V7.7 e posteriores. Para outras versões, o espaço máximo é de 2 TiB. Nota Ao redimensionar um Ultra Disk com espaço de armazenamento superior a 2.560 GiB, apenas uma atualização blue-green pode ser realizada, pois o disco foi projetado para operar em arrays de disco ou RAID 0.
Número de nós de dados	A quantidade de nós adquirida deve ser um múltiplo do número de zonas. Importante Um cluster com apenas dois nós de dados apresenta altos riscos de split-brain e baixa estabilidade. Em clusters de versões anteriores, como V6.X ou V5.X, com apenas dois nós de dados, pode não ser possível selecionar um nó mestre dedicado caso seja necessária uma reinicialização, o que pode interromper os serviços do cluster. Portanto, configure este parâmetro de acordo com as necessidades do seu negócio.

Nó do Kibana

O valor do parâmetro Kibana Node pode ser apenas Yes.
Um nó do Kibana com 1 vCPU e 2 GiB de memória é gratuito. Entretanto, utilize essa configuração apenas para fins de teste.
Devido ao impacto no desempenho e na estabilidade do cluster, adquira um nó do Kibana com 2 vCPUs e 4 GiB de memória ou especificações superiores.

Nó mestre dedicado

Use nós mestres dedicados para realizar operações no cluster, como criar e excluir índices, rastrear nós e alocar shards. A estabilidade desses nós é fundamental para a saúde do cluster. Por padrão, qualquer nó pode atuar como mestre dedicado. Como operações de indexação, busca e consulta consomem muitos recursos de CPU, memória e I/O, adquira nós mestres dedicados para separá-los dos nós de dados e garantir a estabilidade do ambiente.

Importante

Se os nós mestres dedicados do seu cluster forem gratuitos, eles passarão a ser cobrados após um upgrade de configuração do cluster.
Ao realizar uma alteração blue-green em um cluster sem nós mestres dedicados implantado na arquitetura antiga (V2), os nós de dados serão reiniciados na próxima alteração feita no cluster. Por esse motivo, adquira nós mestres dedicados.

Parâmetro	Descrição
Nó mestre dedicado	Para melhorar a estabilidade dos seus serviços, adquira nós mestres dedicados. Em clusters Elasticsearch multizona, o valor padrão deste parâmetro é Yes e não pode ser alterado. Nota Não é possível liberar nós mestres dedicados já adquiridos. Após a criação do cluster, você pode adquirir nós mestres dedicados ao fazer um upgrade de configuração.
Especificações do nó mestre dedicado	Consulte a página de compra para ver as especificações suportadas.
Tipo de disco do nó mestre dedicado	ESSD (Padrão): Oferece baixa latência, alto throughput e tempos de resposta rápidos. Ideal para aplicações sensíveis à latência ou cargas de trabalho intensivas em I/O. Para mais informações sobre as especificações do ESSD, consulte Especificações de nó. Para mais informações sobre desempenho, consulte ESSDs. Ultra Disk: Fornece armazenamento econômico. Adequado para cenários de log e análise que envolvem grandes volumes de dados. Standard SSD: Oferece alto IOPS e capacidade de resposta. Indicado para cenários de análise e busca online. Verifique os tipos de disco suportados na página de compra.
Espaço de armazenamento do nó mestre dedicado	O valor deste parâmetro pode ser apenas 20G.
Número de nós mestres dedicados	O valor deste parâmetro pode ser apenas 3.

Nó warm

Se sua carga de trabalho envolver ambos os tipos de dados abaixo, adote uma arquitetura hot-warm, que combina nós hot de alto desempenho com nós warm de grande capacidade:

Dados hot: Índices frequentemente consultados, com alta carga de escrita e sensíveis à latência.
Dados warm: Índices raramente consultados, predominantemente somente leitura ou com escritas mínimas. Geralmente são dados históricos.

Ao distribuir dados hot e warm em tipos diferentes de nós, você evita que a contenção de recursos causada pelos dados warm afete o desempenho dos dados hot, reduz significativamente os custos de armazenamento e melhora a eficiência e a estabilidade geral do cluster.

Para mais informações, consulte "Hot-Warm" Architecture in Elasticsearch 5.x.

Nota

Se houver nós mestres dedicados adquiridos, os nós warm funcionarão exclusivamente como nós warm.

Caso contrário, os nós warm também atuarão como nós mestres dedicados.

Parâmetro	Descrição
Nó warm	É possível desativar nós warm adquiridos. Se o cluster travar ao desativar um nó warm, consulte O que fazer se o cluster travar após a desativação de um nó warm?
Especificações do nó warm	Para informações sobre as especificações suportadas, consulte a página de compra. Em cenários com altos requisitos de I/O e armazenamento, também é possível usar tipos de instância econômicos com disco local, como o tipo `20 vCPUs, 88 GiB memory (SATA: 8 × 7300 GiB)`. As seguintes restrições se aplicam a instâncias com disco local: Apenas instâncias com kernel aprimorado V7.17, implantadas na arquitetura de plano de controle nativo da nuvem (v3) em duas ou três zonas de disponibilidade, suportam tipos de instância com disco local. Para instâncias na arquitetura v3, alterações blue-green no nível do nó, como expansão de nós, não são suportadas em tipos de instância com disco local. Nota Configure pelo menos uma réplica ao usar um tipo de instância com disco local para evitar perda de dados nos discos locais. Não é possível converter um tipo de instância com disco local para um tipo com disco em nuvem. Se a arquitetura da sua aplicação não garantir a confiabilidade dos dados, crie o cluster usando um tipo de instância com disco em nuvem. Snapshots no nível da máquina não são suportados para instâncias com disco em nuvem.
Tipo de disco do nó warm	Ultra Disk e ESSD são suportados.
Criptografia de disco do nó warm	A criptografia de disco oferece segurança máxima de dados sem exigir alterações adicionais em seus negócios e aplicações. Contudo, ela pode causar um pequeno impacto no desempenho do cluster. A criptografia de disco é gratuita. Nenhuma taxa adicional é gerada ao ler ou gravar dados em discos criptografados. Nota Não é possível desativar a criptografia em discos já criptografados. Não é possível ativar a criptografia em discos já adquiridos. Durante um upgrade de configuração do cluster, também não é possível habilitar a criptografia para discos existentes. No entanto, se você adquirir novos discos em nuvem durante o upgrade, poderá ativar a criptografia para eles.
Espaço de armazenamento do nó warm	O valor mínimo deste parâmetro é 500. Unidade: GiB.
Número de nós warm	A quantidade de nós adquirida deve ser um múltiplo do número de zonas.

Após a aquisição de nós warm, o sistema adiciona o parâmetro -Enode.attr.box_type aos parâmetros de inicialização do nó, conforme mostrado na tabela a seguir.

Tipo de nó	Parâmetro de inicialização
Nó de dados	-Enode.attr.box_type=hot
Nó warm	-Enode.attr.box_type=warm

Nós frozen

O nó frozen atua como camada de computação para o recurso Searchable Snapshot. Ele mantém metadados de índices, gerencia um cache compartilhado local e busca blocos de dados necessários sob demanda no Object Storage Service (OSS) para consultas. Ao armazenar dados históricos como snapshots no Alibaba Cloud OSS, os nós frozen podem reduzir os custos de armazenamento em até 90%, mantendo as capacidades de busca.

Os nós frozen são suportados apenas em instâncias V8.17.0 e posteriores. Após ativar os nós frozen, não é possível desativá-los. Para desativá-los, entre em contato com o suporte técnico.
Como os dados ficam armazenados no OSS, os nós frozen não exigem discos locais de grande capacidade. Configure memória suficiente para melhorar a taxa de acerto do cache.
Para exemplos detalhados, consulte Searchable Snapshot.

Parâmetro	Descrição
Nó frozen	Ao adquirir uma nova instância V8.17.0, marque a caixa de seleção na seção de especificações da instância para ativar este recurso.
Especificações do nó frozen	Recomendamos um tipo de instância com 4 vCPUs e 16 GiB de memória ou superior. A memória do nó frozen mantém metadados de índices e gerencia o cache compartilhado. Memória suficiente melhora a taxa de acerto do cache. Consulte a página de compra para ver as especificações suportadas.
Tipo de disco do nó frozen	Ultra Disk e ESSD são suportados. Os discos locais servem apenas como cache compartilhado; os dados são persistidos no OSS.
Espaço de armazenamento do nó frozen	Recomendamos 500 GiB ou mais. O espaço em disco local funciona como cache compartilhado. O cache utiliza 90% do espaço total em disco do nó ou o espaço total menos 100 GiB, o que for menor. Uma política Least Recently Used (LRU) remove blocos de dados frios. Quanto maior o espaço em disco, maior a taxa de acerto do cache.
Número de nós frozen	A quantidade de nós adquirida deve ser um múltiplo do número de zonas de disponibilidade.

Após a aquisição de nós frozen, o sistema adiciona o parâmetro -Enode.attr.box_type aos parâmetros de inicialização do nó, conforme mostrado na tabela a seguir.

Tipo de nó	Parâmetro de inicialização
nó de dados	-Enode.attr.box_type=hot
nó warm	-Enode.attr.box_type=warm
nó frozen	-Enode.attr.box_type=frozen

Nó cliente

Adquira nós clientes para compartilhar a sobrecarga de CPU dos nós de dados. Isso melhora o desempenho de processamento e a estabilidade do serviço do cluster. Para serviços intensivos em CPU, como aqueles que exigem muitas consultas agregadas, utilize nós clientes.

Parâmetro	Descrição
Nó de coordenação	Não é possível liberar nós clientes adquiridos para um cluster implantado na arquitetura de controle nativa da nuvem (cluster V7.16 ou posterior). Verifique na página de compra se é possível liberar os nós clientes do seu cluster.
Especificações do nó de coordenação	Consulte a página de compra para ver as especificações suportadas.
Tipo de disco do nó de coordenação	O valor deste parâmetro pode ser apenas Ultra Disk.
Espaço de armazenamento do nó de coordenação	O valor deste parâmetro pode ser apenas 20G.
Número de nós de coordenação	A quantidade de nós adquirida deve ser um múltiplo do número de zonas.

Referências

Para mais informações sobre como adquirir um cluster Elasticsearch, consulte Criar um cluster do Alibaba Cloud Elasticsearch.
Para mais detalhes sobre os nós, consulte Node | Elasticsearch Guide.
Para informações sobre preços das especificações de nós, consulte Pricing.

FAQ

Cluster travado após desativar um nó warm

1. Verifique se regras de alocação de nós baseadas em `box_type` foram configuradas manualmente no cluster (ou seja, se índices estão sendo forçados a alocar em nós marcados como `warm`)

Consulte a configuração index.routing.allocation.require.box_type de todos os índices existentes.

GET */_settings/index.routing.allocation.require.box_type

Se a saída for {"index.routing.allocation.require.box_type": "warm"}, o índice deve ser alocado em nós onde box_type=warm.
Verifique se existe alguma regra de alocação box_type configurada em modelos de índice.

Consulte todos os modelos de índice para verificar se há uma regra de alocação box_type configurada. Se um modelo retornar "index.routing.allocation.require.box_type": "warm", todos os novos índices serão alocados em nós warm por padrão.

Quando um novo índice é criado, ele herda a configuração do modelo. Se esse valor estiver definido no modelo, todos os índices subsequentes aplicarão automaticamente essa regra.
GET _ilm/policy?filter_path=*.policy.phases.warm.actions.allocate.require.box_type

Consulta a configuração de alocação de nós para a fase warm de todas as políticas de Index Lifecycle Management (ILM).

Se um índice estiver alocado em um nó warm, desligar os nós de dados frios através de uma operação de scale-down fará com que a alteração do cluster fique bloqueada, exibindo o status Change is blocked:

2. Solução

Remova a configuração box_type da política

# First, stop ILM.
POST _ilm/stop

# View the specific ILM policy.
GET _ilm/policy/your_policy_name

# Update the ILM policy and remove the box_type configuration from the warm phase.
PUT _ilm/policy/your_policy_name
{
  "policy": {
    "phases": {
      "warm": {
        "actions": {
          "allocate": {
            "require": {
              "box_type": null  # Remove this configuration.
            }
          }
        }
      },
      "hot": {
        "actions": {
          "allocate": {
            "require": {
              "box_type": null  # If present, remove this as well.
            }
          }
        }
      }
    }
  }
}

# If the require field under allocate is empty, delete the entire allocate action.
# Alternatively, retain only other necessary allocation rules, such as the number of replicas.

Remova a configuração box_type do modelo de índice

# View the specific template name.
GET _template/?filter_path=*.settings.index.routing.allocation.require.box_type
# Update the template and remove the box_type configuration.
PUT _template/your_template_name
{
  "settings": {
    "index.routing.allocation.require.box_type": null
  }
}
# Alternatively, resubmit the complete template definition without the box_type field.

Remova a configuração box_type do índice

# Remove the box_type configuration for a specific index.
PUT /your_index_name/_settings
{
  "index.routing.allocation.require.box_type": null
}
# Remove the configuration for all indexes in a batch.
{
  "index.routing.allocation.require.box_type": null
}