Guia Passo a Passo para Configurar um Cluster Básico de Três Nós

Um cluster Elasticsearch de três nós é a menor configuração que eu trataria como um cluster real, em vez de um laboratório. Ele pode eleger um mestre por maioria, manter réplicas longe dos primários e sobreviver à perda de um nó se os dados e as funções estiverem configurados de forma sensata. Ainda não é mágica. Três pequenas VMs com discos cheios não se comportarão como uma plataforma de busca resiliente só porque são três.

Este guia usa um layout moderno básico do Elasticsearch: três nós, todos elegíveis a mestre e capazes de dados, em endereços de rede privada. Esse é um ponto de partida razoável para um ambiente pequeno. Implantações de produção maiores geralmente separam nós mestres dedicados, camadas de dados, nós de ingestão, nós de aprendizado de máquina e nós somente de coordenação. Comece de forma simples aqui, depois divida as funções quando a carga de trabalho justificar.

Os exemplos assumem hosts Linux e instalações via pacote ou arquivo. Ajuste os comandos de serviço para o seu ambiente.

Antes de editar a configuração

Você precisa de três hosts ou VMs separados. Não coloque três "nós" em um único laptop e chame isso de alta disponibilidade. Eles podem ser úteis para testar a descoberta, mas compartilham o mesmo domínio de falha.

Cada host precisa:

• Da mesma versão do Elasticsearch.
• De um IP privado estável ou nome DNS.
• Conectividade de transporte entre nós na porta 9300 por padrão.
• Acesso HTTP na porta 9200 a partir do seu host administrativo ou balanceador de carga, se necessário.
• Disco suficiente para shards primários e de réplica.
• Sincronização de horário via NTP ou serviço similar.
• Um caminho de dados configurado em armazenamento local confiável ou anexado.

Distribuições recentes do Elasticsearch incluem um JDK empacotado. Se seu pacote ou versão exigir um JDK externo, use a versão Java suportada para aquela versão do Elasticsearch, em vez de adivinhar.

Use endereços privados em discovery.seed_hosts. Evite IPs públicos, a menos que você tenha um design muito específico e controles de rede fortes.

Para este guia, os nós são:

node-1  10.0.10.11
node-2  10.0.10.12
node-3  10.0.10.13

Configurar configurações comuns do cluster

Em cada nó, edite elasticsearch.yml. A localização do arquivo depende do método de instalação. Instalações via pacote geralmente usam /etc/elasticsearch/elasticsearch.yml; instalações via arquivo usam config/elasticsearch.yml no diretório extraído.

Defina o mesmo nome de cluster em todos os três nós:

cluster.name: my-three-node-cluster

Defina os hosts de semente de descoberta em todos os três nós:

discovery.seed_hosts:
  - 10.0.10.11:9300
  - 10.0.10.12:9300
  - 10.0.10.13:9300

Defina os nós mestres iniciais apenas para a primeira inicialização:

cluster.initial_master_nodes:
  - node-1
  - node-2
  - node-3

Os valores devem corresponder a node.name, não a endereços IP, a menos que seus nomes de nó sejam strings semelhantes a IP. Essa configuração é apenas para formar um cluster novo. Após o cluster ser formado com sucesso, remova cluster.initial_master_nodes de todos os nós e mantenha-o fora de reinicializações futuras. Deixá-lo por perto pode causar confusão durante a recuperação de desastres ou tentativas acidentais de reinicialização.

Vincule à interface privada ou a um valor de host seguro:

network.host: 10.0.10.11
http.port: 9200
transport.port: 9300

Use o IP de cada nó para network.host. 0.0.0.0 é conveniente em exemplos, mas em produção pode expor o Elasticsearch em interfaces que você não pretendia. Se a configuração automática de segurança estiver habilitada em sua versão, você também precisará considerar certificados TLS, registro e autenticação.

Configurar o nome de cada nó

No nó 1:

node.name: node-1
network.host: 10.0.10.11
path.data: /var/lib/elasticsearch
path.logs: /var/log/elasticsearch

No nó 2:

node.name: node-2
network.host: 10.0.10.12
path.data: /var/lib/elasticsearch
path.logs: /var/log/elasticsearch

No nó 3:

node.name: node-3
network.host: 10.0.10.13
path.data: /var/lib/elasticsearch
path.logs: /var/log/elasticsearch

Se você executar vários nós em uma máquina para teste, use valores separados de path.data e path.logs. Para clusters reais, um nó por host geralmente é o modelo mais limpo.

Escolher funções dos nós

Para um pequeno cluster de três nós, todos os três nós podem ter as funções padrão:

node.roles: [ master, data, ingest, remote_cluster_client ]

Isso lhe dá três nós elegíveis a mestre, então a eleição de mestre funciona por maioria. Com três nós elegíveis a mestre, o cluster pode perder um e ainda eleger ou manter um mestre. Se dois desaparecerem, ele não pode tomar decisões de estado do cluster com segurança.

Para um cluster maior, nós dedicados elegíveis a mestre são frequentemente melhores porque trabalho pesado de dados ou ingestão não pode prejudicar as funções de mestre. Esse é um refinamento de escala, não um requisito para esta configuração básica.

Verificar SO e rede básicos

Antes de iniciar o Elasticsearch, teste a conectividade de transporte entre cada par de nós:

nc -vz 10.0.10.11 9300
nc -vz 10.0.10.12 9300
nc -vz 10.0.10.13 9300

Execute esses comandos de cada nó quando possível. Firewalls e grupos de segurança em nuvem devem permitir tráfego de transporte nó a nó. A porta HTTP 9200 é para clientes e chamadas administrativas; a porta de transporte 9300 é o que os nós do cluster usam para se comunicar entre si.

Verifique também a propriedade dos arquivos nos diretórios de dados e logs. O processo do Elasticsearch deve ser capaz de escrever em ambos.

Iniciar os nós

Para instalações via pacote com systemd:

sudo systemctl daemon-reload
sudo systemctl enable elasticsearch
sudo systemctl start elasticsearch
sudo journalctl -u elasticsearch -f

Para instalações via arquivo durante testes:

bin/elasticsearch

Inicie todos os três nós. Eles não precisam iniciar em uma ordem perfeita, mas observe os logs. Você quer ver o cluster se formar uma vez e os nós se juntarem a ele. Se um nó disser que não pode descobrir um mestre, concentre-se em node.name, cluster.name, discovery.seed_hosts, conectividade de transporte e configurações de TLS/segurança.

Assim que o cluster se formar, remova cluster.initial_master_nodes da configuração de cada nó e reinicie mais tarde durante uma janela planejada, se necessário. Não o remova enquanto ainda estiver tentando inicializar pela primeira vez.

Verificar a saúde do cluster

De um host que possa alcançar a porta 9200:

curl -s "http://10.0.10.11:9200/_cluster/health?pretty"

Um cluster novo sem índices de usuário pode mostrar verde com zero shards. Os campos a verificar são status, number_of_nodes e number_of_data_nodes.

Para uma visão compacta:

curl -s "http://10.0.10.11:9200/_cat/health?v"

Em seguida, verifique a associação dos nós:

curl -s "http://10.0.10.11:9200/_cat/nodes?v&h=ip,name,roles,master,cpu,heap.percent,ram.percent,disk.used_percent"

Você deve ver todos os três nós. Um nó terá o marcador de mestre eleito. Todos os três devem mostrar as funções esperadas.

Criar um índice de teste com réplicas

Crie um índice de teste para confirmar o posicionamento dos shards:

curl -X PUT "http://10.0.10.11:9200/test-data-index?pretty"   -H 'Content-Type: application/json'   -d '{
    "settings": {
      "number_of_shards": 3,
      "number_of_replicas": 1
    }
  }'

Verifique os shards:

curl -s "http://10.0.10.11:9200/_cat/shards/test-data-index?v"

Com três shards primários e uma réplica, você deve ver seis cópias de shard espalhadas pelos nós. O Elasticsearch evitará colocar uma réplica no mesmo nó que seu primário.

Se o cluster estiver amarelo, pergunte por quê:

curl -X GET "http://10.0.10.11:9200/_cluster/allocation/explain?pretty"   -H 'Content-Type: application/json'   -d '{}'

Causas comuns são nós de dados elegíveis insuficientes, limites de disco, alocação desabilitada ou regras de consciência de alocação que não correspondem aos atributos do seu nó.

Testar comportamento de falha de um nó

Em um teste não produtivo, pare um nó:

sudo systemctl stop elasticsearch

Verifique a saúde de outro nó:

curl -s "http://10.0.10.12:9200/_cluster/health?pretty"

O cluster ainda deve ter um mestre porque dois dos três nós elegíveis a mestre permanecem. Dependendo do tempo, realocação de shards e posicionamento de réplicas, a saúde pode ser verde ou amarela enquanto o Elasticsearch reage. Inicie o nó novamente e observe a recuperação:

sudo systemctl start elasticsearch
curl -s "http://10.0.10.12:9200/_cat/recovery?v&active_only=true"

Este teste vale a pena fazer antes que o cluster seja importante. Ele ensina como é a recuperação normal, para que um incidente real seja menos surpreendente.

Algumas diretrizes de produção

Habilite e entenda a segurança para sua versão do Elasticsearch. Não exponha uma API HTTP não autenticada à internet ou a uma rede interna ampla.

Faça snapshots antes de depender do cluster. Réplicas protegem contra perda de nós; snapshots protegem contra exclusão, corrupção e erros operacionais.

Monitore o uso de disco, pressão do heap JVM, contagem de nós, saúde do cluster, tarefas pendentes e sucesso de snapshots. Um cluster de três nós é resiliente apenas se tiver capacidade suficiente para se recuperar.

Mantenha a contagem de shards modesta. Muitos shards pequenos criam sobrecarga. Um cluster básico pode ser sobrecarregado por milhares de índices minúsculos, mesmo quando o volume de dados não é grande.

Finalmente, documente as configurações de inicialização e remova cluster.initial_master_nodes após a formação. A maioria dos problemas de configuração de três nós vem de pequenas incompatibilidades: nomes de nós que não correspondem aos nomes de inicialização, portas de transporte bloqueadas, diretórios de dados reutilizados de clusters antigos ou suposições sobre padrões de segurança. Verifique esses primeiro antes de alterar configurações mais exóticas.

Notas de segurança para versões atuais do Elasticsearch

Muitas instalações modernas do Elasticsearch habilitam recursos de segurança durante a configuração. Isso significa que chamadas HTTP podem exigir HTTPS, um certificado CA e credenciais. Se seu cluster foi configurado automaticamente com TLS, uma verificação de saúde pode se parecer mais com isto:

curl --cacert /etc/elasticsearch/certs/http_ca.crt \
  -u elastic \
  https://10.0.10.11:9200/_cluster/health?pretty

Não desabilite a segurança apenas para fazer um comando de tutorial funcionar. Em vez disso, ajuste os exemplos para seus caminhos de certificado e contas de serviço. Para produção, crie usuários nomeados ou chaves de API com os privilégios necessários, em vez de usar o superusuário embutido para o trabalho diário.

O TLS de transporte também pode afetar a junção de nós. Se os nós não puderem se juntar e os logs mencionarem confiança de certificado, incompatibilidade de SAN, falha de handshake ou erros de transporte remoto, verifique os certificados antes de alterar as configurações de descoberta. Uma lista perfeita de discovery.seed_hosts não ajudará nós que se rejeitam durante o handshake TLS.

Falhas comuns na inicialização

Se os nós não formarem um cluster, verifique as coisas simples primeiro.

cluster.name deve corresponder em todos os nós. Um nó com um nome de cluster diferente não se juntará apenas porque aparece na lista de hosts de semente.

node.name deve corresponder aos valores usados em cluster.initial_master_nodes durante a primeira inicialização. Se a configuração disser node-1 mas a inicialização listar es-node-1, a descoberta pode parar.

A porta de transporte deve ser acessível entre os nós. O acesso HTTP na porta 9200 não é suficiente. Use nc, inspeção de grupo de segurança ou capturas de pacotes, se necessário.

Os diretórios de dados não devem conter metadados de um cluster antigo, a menos que você pretenda se juntar exatamente a esse cluster. Reutilizar um disco de um teste anterior pode produzir erros confusos sobre UUIDs de cluster ou inicialização insegura.

Verificações de memória e inicialização são importantes ao vincular a um endereço não loopback. O Elasticsearch pode aplicar verificações para descritores de arquivo, memória virtual, bloqueio de memória e configuração de descoberta. Leia o log de inicialização em vez de tentar cegamente novamente.

Após o cluster estar funcionando

Crie um repositório de snapshots antes que o cluster carregue dados importantes. Réplicas não são backups. Uma exclusão ruim, erro de mapeamento ou bug de aplicativo se replicará rapidamente para todas as cópias.

Registre os nomes dos nós, IPs, funções, caminhos de dados, localizações de certificados e histórico de inicialização em seu runbook. Durante uma interrupção, ninguém quer engenharia reversa para saber se node-2 deve ser elegível a mestre.

Configure alertas para perda de nós, saúde vermelha, saúde amarela prolongada, limites de disco, pressão do heap JVM, snapshots com falha e eleições de mestre frequentes. Um cluster de três nós lhe dá espaço para sobreviver a uma falha, mas apenas se você notar e reparar antes da segunda falha.

Planeje a capacidade pensando na recuperação. Se cada nó estiver com uso de disco muito alto, perder um nó pode deixar muito pouco espaço para as réplicas se reconstruírem. Clusters saudáveis precisam de capacidade extra, não apenas espaço suficiente para os primários de hoje.

Prática de reinicialização contínua

Pratique uma reinicialização contínua antes de precisar de uma para uma atualização de pacote. Reinicie um nó, aguarde sua reintegração, confirme a saúde e a recuperação, depois passe para o próximo nó. Não reinicie todos os três nós de uma vez, a menos que esteja intencionalmente fazendo um desligamento completo do cluster.

Uma sequência simples é:

sudo systemctl restart elasticsearch
curl -s "http://10.0.10.11:9200/_cat/nodes?v"
curl -s "http://10.0.10.11:9200/_cluster/health?pretty"

Se o cluster tiver shards grandes, considere se a alocação atrasada deve ser ajustada antes de reinicializações planejadas. O objetivo é evitar a reconstrução desnecessária de réplicas quando um nó voltará em alguns minutos. Após a manutenção, verifique se a alocação está habilitada e as configurações temporárias foram removidas.

Teste também o comportamento do cliente. Os aplicativos devem usar mais de um endpoint do Elasticsearch ou um balanceador de carga que remova nós com falha. Um cluster de três nós ajuda apenas se os clientes puderem alcançar os nós saudáveis restantes quando um nó estiver inativo.

Um último hábito ajuda: mantenha uma cópia do elasticsearch.yml final para cada nó no gerenciamento de configuração. Edições manuais feitas durante a configuração tendem a divergir, e a divergência é exatamente o que torna a próxima substituição de nó mais difícil do que deveria ser.