Guida Passo-Passo per Configurare un Cluster Base a Tre Nodi

Un cluster Elasticsearch a tre nodi è la configurazione più piccola che considererei un vero cluster piuttosto che un laboratorio. Può eleggere un master a maggioranza, mantenere le repliche lontane dai primari e sopravvivere alla perdita di un nodo se i dati e i ruoli sono configurati in modo sensato. Non è ancora magia. Tre piccole VM con dischi pieni non si comporteranno come una piattaforma di ricerca resiliente solo perché sono tre.

Questa guida utilizza un layout Elasticsearch moderno di base: tre nodi, tutti eleggibili come master e capaci di gestire dati, su indirizzi di rete privati. Questo è un punto di partenza ragionevole per un ambiente piccolo. Le distribuzioni di produzione più grandi spesso separano nodi master dedicati, tier di dati, nodi di ingest, nodi di machine learning e nodi solo di coordinamento. Inizia in modo semplice qui, poi suddividi i ruoli quando il carico di lavoro lo giustifica.

Gli esempi presuppongono host Linux e installazioni tramite pacchetto o archivio. Adatta i comandi di servizio al tuo ambiente.

Prima di modificare la configurazione

Hai bisogno di tre host o VM separati. Non mettere tre "nodi" su un singolo laptop e chiamarlo altamente disponibile. Possono essere utili per testare la scoperta, ma condividono lo stesso dominio di guasto.

Ogni host necessita di:

• La stessa versione di Elasticsearch.
• Un IP privato stabile o un nome DNS.
• Connettività di trasporto tra i nodi sulla porta 9300 per impostazione predefinita.
• Accesso HTTP sulla porta 9200 dal tuo host amministrativo o load balancer, se necessario.
• Spazio disco sufficiente per shard primari e repliche.
• Sincronizzazione dell'ora tramite NTP o un servizio simile.
• Un percorso dati configurato su storage locale o collegato affidabile.

Le distribuzioni recenti di Elasticsearch includono un JDK integrato. Se il tuo pacchetto o versione richiede un JDK esterno, utilizza la versione Java supportata per quella release di Elasticsearch piuttosto che indovinare.

Utilizza indirizzi privati in discovery.seed_hosts. Evita IP pubblici a meno che tu non abbia un design molto specifico e forti controlli di rete.

Per questa guida, i nodi sono:

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

Configurare le impostazioni comuni del cluster

Su ogni nodo, modifica elasticsearch.yml. La posizione del file dipende dal metodo di installazione. Le installazioni tramite pacchetto usano comunemente /etc/elasticsearch/elasticsearch.yml; le installazioni tramite archivio usano config/elasticsearch.yml nella directory estratta.

Imposta lo stesso nome del cluster su tutti e tre i nodi:

cluster.name: my-three-node-cluster

Imposta gli host seed di scoperta su tutti e tre i nodi:

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

Imposta i nodi master iniziali solo per il primo bootstrap:

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

I valori devono corrispondere a node.name, non agli indirizzi IP, a meno che i nomi dei nodi non siano stringhe simili a IP. Questa impostazione è solo per formare un cluster nuovo di zecca. Dopo che il cluster si è formato con successo, rimuovi cluster.initial_master_nodes da tutti i nodi e tienilo fuori dai riavvii futuri. Lasciarlo in giro può causare confusione durante il disaster recovery o tentativi accidentali di re-bootstrap.

Associa all'interfaccia privata o a un valore host sicuro:

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

Utilizza l'IP di ciascun nodo per network.host. 0.0.0.0 è comodo negli esempi, ma in produzione può esporre Elasticsearch su interfacce che non intendevi. Se la configurazione automatica della sicurezza è abilitata nella tua versione, dovrai anche considerare certificati TLS, enrollment e autenticazione.

Configurare il nome di ciascun nodo

Sul nodo 1:

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

Sul nodo 2:

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

Sul nodo 3:

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

Se esegui più nodi su una macchina per un test, usa valori separati per path.data e path.logs. Per cluster reali, un nodo per host è solitamente il modello più pulito.

Scegliere i ruoli dei nodi

Per un piccolo cluster a tre nodi, tutti e tre i nodi possono portare i ruoli standard:

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

Questo ti dà tre nodi eleggibili come master, quindi l'elezione del master funziona a maggioranza. Con tre nodi eleggibili come master, il cluster può perderne uno e ancora eleggere o mantenere un master. Se due sono spariti, non può prendere decisioni sullo stato del cluster in modo sicuro.

Per un cluster più grande, i nodi dedicati eleggibili come master sono spesso migliori perché il lavoro pesante sui dati o l'ingest non può affamare i compiti del master. Questo è un perfezionamento di scaling, non un requisito per questa configurazione di base.

Verificare le basi del sistema operativo e della rete

Prima di avviare Elasticsearch, testa la connettività di trasporto tra ogni coppia di nodi:

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

Esegui questi comandi da ciascun nodo quando possibile. I firewall e i gruppi di sicurezza cloud devono permettere il traffico di trasporto da nodo a nodo. La porta HTTP 9200 è per i client e le chiamate di amministrazione; la porta di trasporto 9300 è ciò che i nodi del cluster usano per comunicare tra loro.

Controlla anche la proprietà dei file sulle directory dei dati e dei log. Il processo Elasticsearch deve essere in grado di scrivere in entrambe.

Avviare i nodi

Per installazioni tramite pacchetto con systemd:

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

Per installazioni tramite archivio durante i test:

bin/elasticsearch

Avvia tutti e tre i nodi. Non devono avviarsi in un ordine perfetto, ma guarda i log. Vuoi vedere il cluster formarsi una volta e i nodi unirsi ad esso. Se un nodo dice che non può scoprire un master, concentrati su node.name, cluster.name, discovery.seed_hosts, connettività di trasporto e impostazioni TLS/sicurezza.

Una volta che il cluster si è formato, rimuovi cluster.initial_master_nodes dalla configurazione di ogni nodo e riavvia successivamente durante una finestra pianificata se necessario. Non rimuoverlo mentre stai ancora cercando di fare il bootstrap per la prima volta.

Verificare lo stato del cluster

Da un host che può raggiungere la porta 9200:

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

Un cluster nuovo di zecca senza indici utente può mostrare verde con zero shard. I campi da controllare sono status, number_of_nodes e number_of_data_nodes.

Per una vista compatta:

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

Poi verifica l'appartenenza dei nodi:

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

Dovresti vedere tutti e tre i nodi. Un nodo avrà il marcatore di master eletto. Tutti e tre dovrebbero mostrare i ruoli che ti aspetti.

Creare un indice di test con repliche

Crea un indice di test per confermare il posizionamento degli shard:

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
    }
  }'

Controlla gli shard:

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

Con tre shard primari e una replica, dovresti vedere sei copie di shard distribuite tra i nodi. Elasticsearch eviterà di posizionare una replica sullo stesso nodo del suo primario.

Se il cluster è giallo, chiedi perché:

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

Le cause comuni sono nodi dati eleggibili insufficienti, watermark del disco, allocazione disabilitata o regole di consapevolezza dell'allocazione che non corrispondono ai tuoi attributi del nodo.

Testare il comportamento in caso di guasto di un nodo

In un test non di produzione, ferma un nodo:

sudo systemctl stop elasticsearch

Controlla lo stato da un altro nodo:

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

Il cluster dovrebbe ancora avere un master perché due dei tre nodi eleggibili come master rimangono. A seconda dei tempi, della rilocazione degli shard e del posizionamento delle repliche, lo stato può essere verde o giallo mentre Elasticsearch reagisce. Avvia di nuovo il nodo e osserva il recupero:

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

Questo test vale la pena farlo prima che il cluster diventi importante. Ti insegna come appare un recupero normale, così un incidente reale è meno sorprendente.

Alcune linee guida di produzione

Abilita e comprendi la sicurezza per la tua versione di Elasticsearch. Non esporre un'API HTTP non autenticata a Internet o a una rete interna ampia.

Fai snapshot prima di dipendere dal cluster. Le repliche proteggono dalla perdita di nodi; gli snapshot proteggono da cancellazione, corruzione ed errori operativi.

Monitora l'uso del disco, la pressione dell'heap JVM, il numero di nodi, lo stato del cluster, i task in sospeso e il successo degli snapshot. Un cluster a tre nodi è resiliente solo se ha capacità sufficiente per recuperare.

Mantieni modesto il numero di shard. Molti piccoli shard creano overhead. Un cluster base può essere sopraffatto da migliaia di piccoli indici anche quando il volume di dati non è grande.

Infine, documenta le impostazioni di bootstrap e rimuovi cluster.initial_master_nodes dopo la formazione. La maggior parte dei problemi di configurazione a tre nodi deriva da piccole discrepanze: nomi di nodi che non corrispondono ai nomi di bootstrap, porte di trasporto bloccate, directory dati riutilizzate da vecchi cluster o assunzioni sui valori predefiniti di sicurezza. Controlla quelli prima di modificare impostazioni più esotiche.

Note sulla sicurezza per le release attuali di Elasticsearch

Molte installazioni moderne di Elasticsearch abilitano le funzionalità di sicurezza durante la configurazione. Ciò significa che le chiamate HTTP possono richiedere HTTPS, un certificato CA e credenziali. Se il tuo cluster è stato configurato automaticamente con TLS, un controllo dello stato potrebbe assomigliare più a questo:

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

Non disabilitare la sicurezza solo per far funzionare un comando del tutorial. Invece, adatta gli esempi ai tuoi percorsi dei certificati e account di servizio. Per la produzione, crea utenti nominati o chiavi API con i privilegi di cui hanno bisogno invece di usare il superutente integrato per il lavoro quotidiano.

Il TLS di trasporto può anche influenzare l'adesione dei nodi. Se i nodi non possono unirsi e i log menzionano fiducia del certificato, mancata corrispondenza SAN, fallimento dell'handshake o errori di trasporto remoto, controlla i certificati prima di modificare le impostazioni di scoperta. Una lista perfetta di discovery.seed_hosts non aiuterà i nodi che si respingono a vicenda durante l'handshake TLS.

Fallimenti comuni all'avvio

Se i nodi non formano un cluster, controlla prima le cose semplici.

cluster.name deve corrispondere su tutti i nodi. Un nodo con un nome cluster diverso non si unirà solo perché appare nella lista degli host seed.

node.name deve corrispondere ai valori usati in cluster.initial_master_nodes durante il primo bootstrap. Se la configurazione dice node-1 ma il bootstrap elenca es-node-1, la scoperta può bloccarsi.

La porta di trasporto deve essere raggiungibile tra i nodi. L'accesso HTTP su 9200 non è sufficiente. Usa nc, ispezione dei gruppi di sicurezza o catture di pacchetti se necessario.

Le directory dei dati non devono contenere metadati di un vecchio cluster a meno che tu non intenda riunirti a quel cluster esatto. Riutilizzare un disco da un test precedente può produrre errori confusi sugli UUID del cluster o bootstrap non sicuro.

I controlli di memoria e bootstrap contano quando ci si associa a un indirizzo non di loopback. Elasticsearch può applicare controlli per descrittori di file, memoria virtuale, blocco della memoria e configurazione della scoperta. Leggi il log di avvio piuttosto che riprovare ciecamente.

Dopo che il cluster funziona

Crea un repository di snapshot prima che il cluster porti dati importanti. Le repliche non sono backup. Una cattiva cancellazione, errore di mapping o bug dell'applicazione si replicherà rapidamente su ogni copia.

Registra i nomi dei nodi, IP, ruoli, percorsi dati, posizioni dei certificati e cronologia del bootstrap nel tuo runbook. Durante un'interruzione, nessuno vuole fare reverse-engineering per sapere se node-2 dovrebbe essere eleggibile come master.

Imposta avvisi per perdita di nodi, stato rosso, stato giallo prolungato, watermark del disco, pressione dell'heap JVM, snapshot falliti ed elezioni frequenti del master. Un cluster a tre nodi ti dà spazio per sopravvivere a un guasto, ma solo se lo noti e lo ripari prima del secondo guasto.

Pianifica la capacità tenendo conto del recupero. Se ogni nodo funziona con un uso del disco molto alto, perdere un nodo può lasciare troppo poco spazio per la ricostruzione delle repliche. I cluster sani hanno bisogno di capacità di riserva, non solo spazio sufficiente per i primari di oggi.

Pratica di riavvio progressivo

Pratica un riavvio progressivo prima di averne bisogno per un aggiornamento del pacchetto. Riavvia un nodo, attendi che si riunisca, conferma lo stato e il recupero, poi passa al nodo successivo. Non riavviare tutti e tre i nodi contemporaneamente a meno che tu non stia intenzionalmente facendo un arresto completo del cluster.

Una sequenza semplice è:

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 il cluster ha shard grandi, considera se l'allocazione ritardata dovrebbe essere regolata prima dei riavvii pianificati. L'obiettivo è evitare la ricostruzione non necessaria delle repliche quando un nodo tornerà tra pochi minuti. Dopo la manutenzione, verifica che l'allocazione sia abilitata e che le impostazioni temporanee siano rimosse.

Testa anche il comportamento del client. Le applicazioni dovrebbero usare più di un endpoint Elasticsearch o un load balancer che rimuove i nodi guasti. Un cluster a tre nodi aiuta solo se i client possono raggiungere i nodi sani rimanenti quando un nodo è giù.

Un'ultima abitudine aiuta: mantieni una copia del elasticsearch.yml finale per ogni nodo nella gestione della configurazione. Le modifiche manuali fatte durante la configurazione tendono a divergere, e la divergenza è esattamente ciò che rende la sostituzione del nodo successivo più difficile del necessario.