Comprendere l'elezione del Master Node e i requisiti di Quorum in Elasticsearch
Elasticsearch è un sistema distribuito che si affida al coordinamento tra i nodi per mantenere una visione coerente dello stato del cluster. Al centro di questo coordinamento si trova il Master Node. Il master node è l'unica fonte di verità per i metadati del cluster, e garantirne la stabilità e la corretta elezione è fondamentale per la salute, la scalabilità e la resilienza del cluster.
Questo articolo illustra in dettaglio le responsabilità critiche del master node, spiega il moderno processo di elezione utilizzato nelle versioni recenti di Elasticsearch (7.x+) e chiarisce il concetto essenziale di quorum: il meccanismo necessario per prevenire lo scenario devastante noto come problema dello split-brain.
Il Ruolo Critico del Master Node
Mentre i nodi dati gestiscono il lavoro più pesante di indicizzazione, ricerca e archiviazione dei dati, il master node è responsabile della gestione della struttura e dei metadati dell'intero cluster. Di norma, non partecipa alle operazioni di query o indicizzazione a meno che non sia configurato anche come nodo dati.
Responsabilità del Master Node
- Gestione dello Stato del Cluster: Il master mantiene e pubblica lo stato del cluster, un modello della configurazione attuale del cluster, inclusi quali indici esistono, le mappature e le impostazioni di tali indici e la posizione di ogni shard.
- Gestione dei Nodi: Gestisce l'ingresso e l'uscita dei nodi, aggiornando di conseguenza lo stato del cluster.
- Gestione degli Indici: Creazione, eliminazione o aggiornamento degli indici.
- Allocazione degli Shard: Decide dove devono risiedere gli shard primari e di replica (allocazione iniziale e riequilibrio dopo il fallimento di un nodo).
Se il master node fallisce, il cluster non può eseguire attività amministrative o riallocare gli shard finché un nuovo master non viene eletto con successo.
Comprendere l'Elezione del Master e il Voto
In un sistema distribuito, è necessario un processo di elezione ogni volta che l'attuale master node fallisce o diventa irraggiungibile. A partire da Elasticsearch 7.0, il meccanismo di elezione è stato notevolmente semplificato e rafforzato, principalmente eliminando l'impostazione complessa discovery.zen.minimum_master_nodes e introducendo le Configurazioni di Voto autogestite.
Il Processo di Elezione (Elasticsearch 7.x+)
L'elezione del master è ora gestita automaticamente dai nodi idonei al ruolo di master, definiti nella configurazione utilizzando node.roles: [master, data], o solo node.roles: [master] per i master dedicati.
- Scoperta dei Candidati: I nodi idonei al ruolo di master comunicano tra loro per determinare l'insieme dei membri votanti attivi.
- Verifica del Quorum: I nodi verificano se possono raggiungere un quorum, ovvero la maggioranza dei nodi votanti conosciuti, per garantire il consenso.
- Selezione del Leader: Se viene stabilito un quorum, il candidato con il rango più alto (basato su un meccanismo di spareggio come l'ID dello stato del cluster) viene proposto come nuovo master.
- Voto e Conferma: La proposta viene messa ai voti e, se accettata dalla maggioranza, il nuovo master assume il controllo e pubblica il nuovo stato del cluster.
Avvio Iniziale del Cluster (Bootstrapping)
Quando si avvia un cluster completamente nuovo per la prima volta, Elasticsearch deve sapere quali nodi devono partecipare alla configurazione di voto iniziale. Questo viene gestito utilizzando l'impostazione cluster.initial_master_nodes. Questa impostazione dovrebbe essere utilizzata una sola volta durante l'avvio iniziale del cluster.
# Frammento di 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 idonei al ruolo di master utilizzati per l'avvio iniziale
cluster.initial_master_nodes: [node-1, node-2, node-3]
Suggerimento: Una volta che il cluster è in esecuzione e stabile, è consigliabile rimuovere o commentare l'impostazione
cluster.initial_master_nodesdai file di configurazione di tutti i nodi per evitare potenziali problemi se i nodi vengono riavviati successivamente in uno stato misto.
Requisiti di Quorum e Prevenzione dello Split-Brain
La ragione fondamentale dei requisiti di quorum è garantire che possa essere eletto un solo leader alla volta, 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 due o più segmenti isolati, e ciascun segmento crede di essere il master autorevole. Se ciò accade, i nodi in segmenti diversi possono accettare richieste di indicizzazione e allocare shard indipendentemente, portando a incoerenza e corruzione dei dati quando la rete alla fine si ricompone.
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 che concordino 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 stretta maggioranza, 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, non potendo eleggere un master, si interromperà e attenderà il ripristino della connettività di rete, evitando così scritture di dati sul segmento partizionato.
| Numero di Nodi Master Votanti (N) | Quorum Richiesto (N/2 + 1) |
|---|---|
| 3 | 2 |
| 5 | 3 |
| 7 | 4 |
Avviso sulla Best Practice: Distribuire sempre un numero dispari di nodi idonei al ruolo di master (ad esempio, tre o cinque). La distribuzione di 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 fallimento, come un cluster a 3 nodi, ma utilizza un server in più.
Configurazione dei Nodi Master Dedicati
Per gli ambienti di produzione, specialmente i cluster di grandi dimensioni (20+ nodi dati), è vivamente consigliato utilizzare nodi master dedicati. Ciò separa le attività ad alta intensità di risorse di ricerca/indicizzazione dai compiti amministrativi cruciali del master.
Esempio di Configurazione del Nodo (Master Dedicato)
Per configurare un nodo in modo che sia idoneo al ruolo di master ma non memorizzi dati o esegua pipeline di ingestione, utilizzare i seguenti ruoli in elasticsearch.yml:
# Nodo 1: Master Dedicato
node.name: es-master-01
node.roles: [master]
# Disabilita il traffico HTTP/Trasporto per i master puri (opzionale, ma buona pratica di sicurezza)
# http.enabled: false
# transport.bind_host: [private_ip_of_master]
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]
# Nota: Se non vengono specificati ruoli, Elasticsearch assume di default [master, data, ingest] (default pre-8.0)
Impostazioni di Scoperta del Cluster
Tutti i nodi devono essere configurati per trovare lo stesso insieme di nodi idonei al ruolo di master utilizzando l'impostazione discovery.seed_hosts. Questa impostazione elenca gli indirizzi di rete in cui Elasticsearch può tentare di contattare altri nodi per unirsi al cluster.
# Impostazione comune per tutti i nodi del cluster
discovery.seed_hosts: ["10.0.0.1:9300", "10.0.0.2:9300", "10.0.0.3:9300"]
Questo elenco deve contenere gli indirizzi dei nodi idonei al ruolo di 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, in genere entra in stato 'rosso' o 'giallo' e registra errori persistenti. Le cause comuni includono:
| Problema | Descrizione e Soluzione |
|---|---|
| Problemi di Rete | I nodi non riescono a comunicare tra loro a causa di regole del firewall, problemi di routing o elevata latenza. Assicurarsi che le porte 9200 (HTTP) e 9300 (Trasporto) siano aperte tra i nodi. |
| Discrepanza di Configurazione | cluster.name non è corretto o discovery.seed_hosts non punta ai nodi idonei al ruolo di master corretti. Verificare che tutti i nodi utilizzino impostazioni identiche. |
| Perdita di Quorum | Troppi nodi idonei al ruolo di master sono falliti contemporaneamente (ad esempio, due fallimenti in una configurazione master a 3 nodi). Potrebbe essere necessario un intervento manuale (ad esempio, utilizzando l'API api/cluster/decommission/voting_config_exclusions) per rimuovere forzatamente i nodi falliti dall'elenco dei votanti. |
| I/O del Disco | L'I/O del disco del master node è saturo, impedendogli di pubblicare rapidamente lo stato del cluster, causando timeout e ripetute elezioni. |
Controllo della Configurazione di Voto
È possibile ispezionare la configurazione di voto corrente utilizzando l'API del Cluster:
GET /_cluster/state?filter_path=metadata.cluster_coordination.voting_config_excluding_deferred
Questo output conferma quali nodi sono attualmente conteggiati ai fini del quorum, assicurando che la configurazione corrisponda agli obiettivi di tolleranza ai guasti.
Riepilogo
Il processo di elezione del master node è la spina dorsale della resilienza di un cluster Elasticsearch. Comprendendo le responsabilità del master e implementando correttamente la regola del quorum (utilizzando un numero dispari di nodi idonei al ruolo di master e garantendo il corretto cluster.initial_master_nodes durante l'avvio), gli amministratori possono prevenire in modo affidabile scenari di split-brain e mantenere un sistema distribuito altamente disponibile. Utilizzare sempre master node dedicati in produzione per isolare le attività amministrative e garantire una pubblicazione affidabile dello stato del cluster.