Comprensione dell'elezione del nodo master e dei requisiti di quorum in Elasticsearch

Il quorum del nodo master di Elasticsearch determina se il tuo cluster può eleggere in sicurezza un leader, pubblicare modifiche allo stato del cluster ed evitare che due lati disconnessi dello stesso cluster prendano decisioni diverse.

Il master eletto non rende le ricerche più veloci da solo. Coordina il cluster. Quando le elezioni sono instabili, i sintomi possono apparire sparsi: la creazione di indici si blocca, l'allocazione degli shard si ferma, Kibana riporta stati di salute mutevoli e i log ripetono messaggi su un master non trovato.

Il Ruolo Critico del Nodo Master

Mentre i nodi dati gestiscono il lavoro pesante di indicizzazione, ricerca e archiviazione dei dati, il nodo master è responsabile della gestione della struttura e dei metadati dell'intero cluster. Di solito non partecipa alle operazioni di query o indicizzazione a meno che non sia configurato anche come nodo dati.

Responsabilità del Nodo Master

1. Gestione dello Stato del Cluster: Il master mantiene e pubblica lo stato del cluster—un progetto della configurazione attuale del cluster, inclusi quali indici esistono, le mappature e le impostazioni per quegli indici, e la posizione di ogni shard.
2. Gestione dei Nodi: Gestione dell'ingresso e dell'uscita dei nodi, aggiornando di conseguenza lo stato del cluster.
3. Gestione degli Indici: Creazione, eliminazione o aggiornamento degli indici.
4. Allocazione degli Shard: Decisione su dove dovrebbero risiedere gli shard primari e di replica (allocazione iniziale e ribilanciamento dopo un guasto del nodo).

Se il master eletto fallisce, il cluster sospende il lavoro solo del master fino a quando un altro master non viene eletto. Le ricerche esistenti possono continuare per gli shard disponibili, ma la creazione di indici, gli aggiornamenti delle mappature e le decisioni di allocazione dipendono da una coordinazione stabile del master.

Comprensione dell'elezione del Master e del Voto

In un sistema distribuito, è necessario un processo di elezione ogni volta che il nodo master corrente fallisce o diventa irraggiungibile. Da Elasticsearch 7.0, il meccanismo di elezione è stato significativamente semplificato e rafforzato, principalmente attraverso l'eliminazione della complessa impostazione discovery.zen.minimum_master_nodes e l'introduzione di Configurazioni di Voto autogestite.

Il Processo di Elezione (Elasticsearch 7.x+)

L'elezione del master è ora gestita automaticamente dai nodi eleggibili come master, che sono definiti nella configurazione usando node.roles: [master, data], o solo node.roles: [master] per master dedicati.

1. Scoperta dei Candidati: I nodi eleggibili come master comunicano per determinare l'insieme dei membri votanti attivi.
2. Controllo del Quorum: I nodi controllano se possono raggiungere un quorum—una maggioranza dei nodi votanti conosciuti—per garantire il consenso.
3. Selezione del Leader: Se viene stabilito un quorum, il sottosistema di coordinamento di Elasticsearch seleziona un master secondo le sue regole interne di elezione.
4. Voto e Impegno: La proposta viene votata e, se accettata dalla maggioranza, il nuovo master prende il controllo e pubblica il nuovo stato del cluster.

Bootstrap Iniziale del Cluster

Quando si avvia un nuovo cluster per la prima volta, Elasticsearch ha bisogno di sapere quali nodi dovrebbero partecipare alla configurazione di voto iniziale. Questo viene gestito usando l'impostazione cluster.initial_master_nodes. Questa impostazione dovrebbe essere usata solo una volta durante l'avvio iniziale del cluster.

# snippet elasticsearch.yml per la configurazione iniziale
cluster.name: my-production-cluster
node.name: node-1
node.roles: [master, data]

# Elenca i nomi di tutti i nodi eleggibili come master usati per il bootstrap iniziale
cluster.initial_master_nodes: [node-1, node-2, node-3]

Consiglio: Una volta che il cluster si è formato, rimuovi cluster.initial_master_nodes da ogni nodo. Lasciarlo in posizione può essere pericoloso durante riavvii successivi perché questa impostazione è destinata solo al primo bootstrap di un nuovo cluster.

Requisiti di Quorum e Prevenzione dello Split-Brain

La ragione fondamentale dei requisiti di quorum è garantire che solo un leader possa essere eletto in qualsiasi momento, prevenendo così il problema dello split-brain.

Cos'è lo Split-Brain?

Lo split-brain si verifica quando una partizione di rete divide il cluster in segmenti isolati, e più di un segmento crede di avere il master autorevole. Se ciò accade, lati diversi possono accettare modifiche contrastanti allo stato del cluster, che è esattamente ciò che il quorum è progettato per prevenire.

La Regola del Quorum (Consenso di Maggioranza)

Per prevenire lo split-brain, Elasticsearch impone una regola di consenso di maggioranza, richiedendo un numero minimo di nodi votanti per concordare su qualsiasi modifica dello stato del cluster. Questo minimo è il quorum, calcolato come:

$$\text{Quorum} = \lfloor (\text{Numero di Nodi Votanti} / 2) \rfloor + 1$$

Richiedendo una maggioranza stretta, se la rete si partiziona, solo il lato più grande (che detiene la maggioranza) può raggiungere il quorum e continuare a operare. Il lato più piccolo, incapace di eleggere un master, si fermerà e aspetterà che la connettività di rete venga ripristinata, evitando così scritture di dati nel segmento partizionato.

Numero di Nodi Master Votanti (N)	Quorum Richiesto (N/2 + 1)
3	2
5	3
7	4

Avvertenza sulle Buone Pratiche: Distribuisci sempre un numero dispari di nodi eleggibili come master (ad esempio, tre o cinque). Distribuire un numero pari (ad esempio, quattro) offre la stessa tolleranza ai guasti del numero dispari precedente (tre), ma richiede più risorse. Ad esempio, un cluster di voto a 4 nodi richiede 3 voti (N/2+1), il che significa che può tollerare solo un guasto, come un cluster a 3 nodi, ma utilizza un server extra.

Configurazione di Nodi Master Dedicati

Per ambienti di produzione, tre nodi eleggibili come master dedicati sono la base comune. Questo separa il carico di ricerca e indicizzazione dal lavoro di coordinamento. I piccoli cluster di sviluppo possono eseguire ruoli misti, ma un cluster che conta non dovrebbe permettere a un picco di aggregazione pesante o di ingest di affamare il master eletto.

Esempio di Configurazione del Nodo (Master Dedicato)

Per configurare un nodo come eleggibile come master ma non memorizzare dati o eseguire pipeline di ingest, usa i seguenti ruoli in elasticsearch.yml:

# Nodo 1: Master Dedicato
node.name: es-master-01
node.roles: [master]

# Associa il trasporto a una rete privata e limita l'accesso con firewall/gruppi di sicurezza.
# network.host: 10.0.0.1

Esempio di Configurazione del Nodo (Nodo Dati Dedicato)

Al contrario, un nodo dati dedicato dovrebbe essere impedito di partecipare al processo di elezione del master:

# Nodo 4: Nodo Dati Dedicato
node.name: es-data-04
node.roles: [data]

# Se non vengono specificati ruoli, Elasticsearch assegna il set di ruoli predefinito per quella versione.

Impostazioni di Scoperta del Cluster

Tutti i nodi devono essere configurati per trovare lo stesso insieme di nodi eleggibili come master usando l'impostazione discovery.seed_hosts. Questa impostazione elenca gli indirizzi di rete dove Elasticsearch può tentare di contattare altri nodi per unirsi al cluster.

# Impostazione comune per tutti i nodi nel cluster
discovery.seed_hosts: ["10.0.0.1:9300", "10.0.0.2:9300", "10.0.0.3:9300"]

Questa lista dovrebbe contenere gli indirizzi dei nodi eleggibili come master (es-master-01, es-master-02, es-master-03, ecc.).

Risoluzione dei Problemi di Elezione

Se il cluster non riesce a eleggere un master, entra tipicamente in uno stato 'rosso' o 'giallo' e registra errori persistenti. Le cause comuni includono:

Problema	Descrizione e Soluzione
Problemi di Rete	I nodi non possono comunicare a causa di regole del firewall, problemi di routing, problemi DNS o alta latenza. La porta di trasporto, comunemente 9300, deve essere raggiungibile tra i nodi. HTTP, comunemente 9200, è per l'accesso client/API e non è il canale di elezione.
Disallineamento di Configurazione	cluster.name è errato o discovery.seed_hosts non punta ai nodi eleggibili come master corretti. Verifica che tutti i nodi utilizzino impostazioni identiche.
Perdita di Quorum	Troppi nodi votanti sono falliti contemporaneamente, come due guasti in una configurazione a tre master. Se i nodi mancanti sono spariti permanentemente, usa l'API di esclusione della configurazione di voto con attenzione e solo dopo aver confermato la modalità di guasto.
I/O del Disco	L'I/O del disco del nodo master è saturo, impedendogli di pubblicare rapidamente lo stato del cluster, portando a timeout ed elezioni ripetute.

Controllo della Configurazione di Voto

Puoi ispezionare la configurazione di voto corrente usando l'API del Cluster:

GET /_cluster/state?filter_path=metadata.cluster_coordination

Questo output conferma quali nodi sono attualmente conteggiati per il quorum, assicurando che la tua configurazione corrisponda ai tuoi obiettivi di tolleranza ai guasti.

Il modello di produzione più sicuro è noioso: tre nodi eleggibili come master dedicati in domini di guasto separati, rete di trasporto stabile, seed hosts corretti e cluster.initial_master_nodes usato solo una volta. Quando le elezioni falliscono, resisti all'impulso di riavviare tutti i nodi contemporaneamente. Leggi i log, conferma quali nodi eleggibili come master possono vedersi l'un l'altro, e fai una modifica controllata alla volta.