Risoluzione dei Problemi Comuni di Split-Brain nei Cluster Elasticsearch

Lo split brain è il guasto di Elasticsearch di cui si parla perché suona drammatico, ma la domanda utile è più pratica: più di una parte del cluster può prendere decisioni a livello di master contemporaneamente? Le versioni moderne di Elasticsearch sono progettate per prevenirlo attraverso il coordinamento del cluster basato sulla maggioranza. I cluster più vecchi, specialmente quelli pre-7.0 con un'impostazione discovery.zen.minimum_master_nodes errata, erano più facili da configurare male.

Quindi questo articolo separa due situazioni che spesso vengono confuse. Un vero split brain significa che partizioni indipendenti possono ciascuna eleggere o mantenere un master. Un'interruzione dell'elezione del master significa che il cluster non può eleggere un master perché non ha una maggioranza. Il primo rischia uno stato del cluster conflittuale e un'incoerenza dei dati. Il secondo è doloroso, ma di solito è la modalità di guasto più sicura.

Che aspetto ha lo split brain

In un cluster sano, un master eletto gestisce lo stato del cluster: creazione di indici, decisioni di allocazione degli shard, mapping, appartenenza dei nodi e metadati simili. I nodi dati possono gestire letture e scritture, ma il cluster dipende ancora da una singola visione del master del mondo.

Uno scenario di split brain si verifica quando partizioni di rete o impostazioni di discovery errate permettono a due gruppi di nodi di comportarsi come se ogni gruppo fosse il vero cluster. Un lato potrebbe accettare scritture su un indice mentre l'altro lato accetta scritture diverse. Quando la connettività ritorna, Elasticsearch non può semplicemente unire due storie contrastanti come un file di testo.

In Elasticsearch moderno, se una partizione non ha una maggioranza di nodi eleggibili come master, non dovrebbe eleggere un master. Ciò significa che alcuni nodi potrebbero diventare non disponibili invece di formare un cluster concorrente. Questo è il comportamento che desideri.

La versione è importante

Per Elasticsearch 6.x e versioni precedenti, l'impostazione chiave era:

discovery.zen.minimum_master_nodes: 2

La regola era la maggioranza dei nodi eleggibili come master: (N / 2) + 1, arrotondato per difetto nella divisione intera prima di aggiungere uno. Con tre nodi eleggibili come master, impostalo a 2. Con cinque, impostalo a 3. Impostarlo a 1 in un cluster a tre nodi rendeva possibile lo split brain.

Per Elasticsearch 7.x e versioni successive, discovery.zen.minimum_master_nodes è scomparso. Il coordinamento del cluster è cambiato ed Elasticsearch gestisce la configurazione di voto. I nuovi cluster hanno ancora bisogno di un bootstrap corretto con cluster.initial_master_nodes, ma quell'impostazione è solo per la prima formazione del cluster. Dopo che il cluster si è formato, rimuovila dalla configurazione.

Non "risolvere" un cluster moderno aggiungendo vecchie impostazioni discovery.zen. Non sono più il piano di controllo.

Cause comuni

Il trigger più comune è una partizione di rete tra nodi eleggibili come master. In termini cloud, potrebbe essere una modifica al gruppo di sicurezza, una tabella di routing errata, un ACL di rete, un problema a livello di zona o una regola del firewall che blocca la porta di trasporto 9300. In ambienti bare metal, potrebbe essere un problema di switch, VLAN, DNS, MTU o perdita di pacchetti.

Un'altra causa è l'esecuzione di un numero troppo basso di nodi eleggibili come master. Due nodi eleggibili come master sono scomodi perché non c'è una maggioranza netta dopo che uno fallisce. Un cluster di produzione normalmente utilizza tre nodi dedicati eleggibili come master, o tre nodi con ruoli misti in una piccola implementazione.

Una terza causa sono le directory dati obsolete o riutilizzate. Se cloni VM o riutilizzi dischi da vecchi cluster, i nodi potrebbero portare metadati del cluster che non intendevi. Ciò può portare a confusi fallimenti di join e, nei casi peggiori, alla formazione accidentale di un cluster separato.

Infine, il ripristino manuale sotto pressione può peggiorare il problema. Riavviare nodi casuali, cancellare i percorsi dei dati o forzare un'allocazione non sicura prima di sapere quale partizione è autorevole può trasformare un incidente recuperabile in una perdita di dati.

Primi controlli durante un incidente

Inizia chiedendo a ogni nodo raggiungibile cosa pensa:

curl -s "http://NODO:9200/_cat/master?v"
curl -s "http://NODO:9200/_cat/nodes?v&h=ip,name,roles,master,node.role"
curl -s "http://NODO:9200/_cluster/health?pretty"

Esegui questi comandi su più di un nodo se possibile. Se nodi diversi riportano master diversi o appartenenze a nodi diverse, potresti avere a che fare con un cluster partizionato o nodi isolati.

Controlla i log sui nodi eleggibili come master per messaggi su elezioni, join, disconnessioni e fallimenti di pubblicazione. Termini di ricerca utili includono master not discovered, elected-as-master, node-left, node-join, publication, connect_transport_exception e handshake.

Quindi testa la connettività di trasporto, non solo HTTP:

nc -vz node-1.example.internal 9300
nc -vz node-2.example.internal 9300
nc -vz node-3.example.internal 9300

Esegui questi test da nodo a nodo. Un bilanciatore di carico o un bastion che raggiunge la porta HTTP 9200 ti dice molto poco sul fatto che i nodi Elasticsearch possano formare un cluster su 9300.

Controlla la configurazione di discovery e bootstrap

Su Elasticsearch 7.x e versioni successive, ispeziona queste impostazioni:

cluster.name: my-cluster
discovery.seed_hosts:
  - node-1:9300
  - node-2:9300
  - node-3:9300

Solo per un cluster nuovo di zecca:

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

I nomi di bootstrap devono corrispondere a node.name. Dopo che il cluster si è formato, rimuovi cluster.initial_master_nodes da tutti i nodi.

Su Elasticsearch 6.x e versioni precedenti, controlla:

discovery.zen.minimum_master_nodes: 2

per un cluster a tre nodi eleggibili come master. Conferma anche che tutti i nodi eleggibili come master abbiano host di discovery e nomi di cluster coerenti.

Principi di ripristino

Se sospetti un vero split brain, smetti di apportare modifiche tramite l'API del cluster finché non sai quale lato è autorevole. Il ripristino più sicuro di solito segue questo ordine:

1. Conserva le prove: raccogli log, elenchi di nodi, viste del master e salute degli indici da ciascuna partizione.
2. Ripristina la connettività di rete o isola intenzionalmente il lato sbagliato.
3. Scegli la partizione autorevole in base alla maggioranza, ai dati validi più recenti e all'impatto aziendale.
4. Ferma Elasticsearch sui nodi che non dovrebbero continuare come partizione indipendente.
5. Riporta i nodi uno alla volta e verifica che si uniscano al cluster autorevole.
6. Ripristina i dati mancanti dagli snapshot se qualche cronologia di shard primario è persa o incoerente.

Non eliminare le directory translog come soluzione di routine per lo split brain. Questo è un consiglio pericoloso. I translog fanno parte del ripristino di Elasticsearch. Rimuovere manualmente i file sotto il percorso dei dati può causare perdita di dati e dovrebbe essere fatto solo con una guida specifica per versione dal supporto Elastic o dopo aver accettato la perdita e avere un piano di ricostruzione.

Se due partizioni hanno accettato scritture indipendentemente, potrebbe non esserci una perfetta unione automatica. Potrebbe essere necessario ripristinare da snapshot, reindicizzare dai sistemi sorgente, riprodurre i log dell'applicazione o scegliere i dati di un lato come autorevoli.

Un esempio realistico

Immagina un cluster a tre nodi attraverso tre sottoreti private. Una modifica al firewall blocca accidentalmente il traffico di trasporto tra il nodo 1 e i nodi 2 e 3. I nodi 2 e 3 si vedono ancora, quindi mantengono o eleggono un master. Il nodo 1 non può vedere una maggioranza. In un cluster moderno e correttamente configurato, il nodo 1 non dovrebbe formare un master concorrente da solo. I client che utilizzano il nodo 1 potrebbero fallire, ma il cluster evita master conflittuali.

Ora immagina un vecchio cluster 6.x con tre nodi eleggibili come master e discovery.zen.minimum_master_nodes: 1. Il nodo 1 può eleggere se stesso, mentre i nodi 2 e 3 eleggono un altro master. Questo è il classico rischio di split brain. La soluzione non è solo riconnettere la rete. Devi anche correggere la configurazione del quorum e decidere come gestire eventuali scritture accettate sul lato sbagliato.

Prevenzione

Usa tre nodi eleggibili come master per cluster piccoli e medi. Per cluster più grandi, rendili nodi master dedicati in modo che il carico di ricerca e indicizzazione non interferisca con il coordinamento del cluster.

Mantieni i nodi eleggibili come master su reti affidabili con bassa perdita di pacchetti. Distribuire i nodi tra le zone può aiutare la disponibilità, ma solo se la rete tra le zone è affidabile e il design del quorum ha ancora senso.

Monitora i cambiamenti del master. Un'elezione del master durante la manutenzione programmata è normale. Elezioni frequenti durante il traffico normale sono un segnale di avvertimento.

Monitora la connettività di trasporto e non solo il tempo di attività HTTP. Un nodo può rispondere su 9200 e ancora non partecipare correttamente al cluster se il traffico di trasporto è bloccato.

Esegui snapshot regolarmente e testa i ripristini. Le repliche non ti proteggono da una cancellazione errata, dati corrotti o scritture conflittuali durante un incidente grave.

Fai attenzione con le impostazioni di bootstrap. Sui cluster moderni, cluster.initial_master_nodes non è un'impostazione di discovery quotidiana. Usalo per creare un nuovo cluster, poi rimuovilo.

Il miglior ripristino dello split brain è quello di cui non hai mai bisogno: eleggibilità del master basata sulla maggioranza, impostazioni di discovery corrette per la versione, regole di rete noiose e un piano di snapshot testato.

Come distinguere lo split brain da un'elezione normale

Un'elezione del master non è automaticamente uno split brain. Durante un riavvio progressivo, un flap di rete o un guasto del nodo master, Elasticsearch può eleggere un nuovo master. Se il cluster mantiene un master autorevole e il vecchio master si dimette, questo è un comportamento normale di un sistema distribuito.

I segnali di avvertimento sono viste diverse da nodi diversi. Se il nodo A si segnala come master mentre il nodo B segnala il nodo C come master, fermati e indaga. Se due gruppi di nodi accettano entrambi cambiamenti di stato del cluster mentre sono disconnessi, hai una situazione molto più grave di una breve elezione.

Osserva anche il comportamento del client. I client ancorati a un nodo isolato potrebbero vedere fallimenti anche mentre il lato di maggioranza è sano. Ciò non significa che il cluster di maggioranza sia rotto. Potrebbe significare che la tua strategia di connessione client o il bilanciatore di carico stanno ancora inviando traffico a un nodo che non può partecipare.

Bilanciatori di carico e routing client

Il discovery di trasporto di Elasticsearch non è la stessa cosa del routing client HTTP. Non mettere il discovery del master dietro un bilanciatore di carico HTTP generico e aspettarti che risolva l'appartenenza al cluster. I nodi hanno bisogno di connettività di trasporto tra loro.

Per i client, usa più endpoint HTTP o un bilanciatore di carico che rimuova rapidamente i nodi non sani. Un nodo che ha perso il suo master potrebbe ancora avere un processo in ascolto per un breve periodo, ma non è un buon target per le scritture. I controlli di salute dovrebbero essere più significativi di "la porta 9200 è aperta".

Un controllo di salute HTTP pratico potrebbe interrogare la salute del cluster localmente e rifiutare i nodi che non hanno un master scoperto. L'approccio esatto dipende dal tuo client e dall'infrastruttura, ma il principio è semplice: non continuare a inviare scritture a nodi isolati.

Pulizia post-incidente

Dopo che il cluster è stabile, confronta la salute degli indici, i conteggi dei documenti e i conteggi della fonte di verità a livello di applicazione. Se c'era la possibilità che le scritture finissero su partizioni diverse, la sola salute di Elasticsearch non può provare che i dati siano semanticamente corretti.

Rivedi la sequenza temporale. Quale nodo ha perso la connettività per primo? Quale nodo era master prima dell'evento? I client hanno continuato a scrivere? Gli snapshot erano aggiornati? Gli avvisi sono scattati prima che gli utenti se ne accorgessero? Questi dettagli determinano se hai bisogno solo di una correzione di rete o di un piano di riconciliazione dei dati.

Per i cluster più vecchi, programma il lavoro sulla versione e sulle impostazioni di discovery. Se stai ancora eseguendo una versione che dipende da discovery.zen.minimum_master_nodes, assicurati che sia corretta oggi, poi pianifica un percorso di aggiornamento. La prevenzione dello split brain non è un passaggio runbook una tantum; fa parte della gestione del ciclo di vita del cluster.

Modifiche alla configurazione da evitare durante il panico

Non cambiare cluster.name per far unire i nodi. Questo crea un diverso problema di identità del cluster.

Non cancellare i percorsi dei dati a meno che tu non stia intenzionalmente scartando le copie locali degli shard del nodo e abbia confermato che il cluster ha copie valide altrove o snapshot disponibili.

Non aggiungere cluster.initial_master_nodes di nuovo a un cluster moderno esistente come soluzione generale di riavvio. Questa impostazione è per il bootstrap iniziale, non per il discovery di routine.

Non abbassare le protezioni di tipo quorum sui vecchi cluster per ripristinare la disponibilità. Rendere scrivibile una partizione di minoranza può sembrare un progresso, ma è esattamente come diventano possibili master conflittuali.

Progettare per domini di guasto scomodi

Tre nodi eleggibili come master funzionano meglio quando nessun singolo evento infrastrutturale può rimuoverne due. In una regione cloud a tre zone, un nodo eleggibile come master per zona è un modello comune. In un ambiente a due zone, il posizionamento è più difficile perché una zona può contenere due voti. Se quella zona più grande fallisce, il singolo voto rimanente non può eleggere un master in sicurezza. Questo non è Elasticsearch fragile; è matematica di maggioranza.

Non risolvere questo aggiungendo un numero pari di nodi votanti senza pensare alle modalità di guasto. Quattro nodi eleggibili come master richiedono ancora una maggioranza, e una partizione due-due non può scegliere un lato in sicurezza. I nodi dedicati solo al voto possono aiutare in alcuni progetti, ma il principio rimane lo stesso: il cluster ha bisogno di una maggioranza affidabile per prendere decisioni sullo stato del cluster.

Scrivilo nelle note di architettura. Durante un'interruzione, le persone spesso chiedono perché il nodo sopravvissuto o la zona sopravvissuta non può semplicemente continuare a servire le scritture. La risposta dovrebbe essere chiara prima dell'incidente: accettare scritture senza una maggioranza rischia una storia conflittuale.