Risoluzione dello Stato del Cluster Rosso: Guida Passo-Passo per la Risoluzione dei Problemi di Elasticsearch

Una checklist pratica per il cluster rosso di Elasticsearch che copre primari non assegnati, spiegazione dell'allocazione, soglie del disco e perdita di nodi.

Risoluzione dello Stato del Cluster Rosso: Guida Passo-Passo per la Risoluzione dei Problemi di Elasticsearch

Lo stato del cluster rosso di Elasticsearch significa che almeno uno shard primario non è allocato. Questo è ciò che conta. Alcuni dati potrebbero non essere disponibili, le ricerche sugli indici interessati potrebbero restituire risultati parziali o fallire, e le scritture su quegli shard non possono procedere normalmente.

Il giallo è diverso: i primari sono allocati, ma uno o più repliche non lo sono. Il giallo merita comunque attenzione perché hai meno ridondanza, ma il rosso è l'incidente. Non iniziare cancellando dati o reindirizzando shard manualmente. Prima trova quale primario non è assegnato e perché Elasticsearch rifiuta di allocarlo.

Comprendere la Salute del Cluster Elasticsearch

Elasticsearch fornisce un'API Cluster Health che offre un'istantanea dello stato del cluster e dell'allocazione degli shard. Questa API è il tuo strumento principale per diagnosticare problemi di salute.

GET _cluster/health

L'output di questo comando includerà un campo status, che può essere green, yellow o red. Fornisce anche informazioni sul numero di shard attivi e non assegnati.

  • Green: Tutti gli shard primari e replica sono allocati e funzionano correttamente.
  • Yellow: Tutti gli shard primari sono allocati, ma alcuni shard replica non sono assegnati.
  • Red: Uno o più shard primari non sono assegnati, portando all'indisponibilità dei dati per quegli shard.

Usa una chiamata di salute più dettagliata quando sei in un incidente:

GET _cluster/health?level=indices

Poi elenca gli shard non assegnati:

GET _cat/shards?v&h=index,shard,prirep,state,unassigned.reason,node&s=state,index

Cause Comuni e Passi di Risoluzione dei Problemi per Stato Rosso/Giallo

Quando il tuo cluster non è green, è tempo di indagare. Ecco le ragioni più comuni per shard non assegnati e come affrontarle:

1. Spazio su Disco Insufficiente

Elasticsearch ha salvaguardie per prevenire la corruzione dei dati a causa di dischi pieni. Se un nodo esaurisce lo spazio su disco, impedirà l'allocazione di nuovi shard o il recupero di quelli esistenti.

Diagnosi:

  • Controlla l'utilizzo del disco su ogni nodo.
  • Usa l'API Cluster Allocation Explain per capire perché gli shard non sono assegnati.
GET _cluster/allocation/explain

Questa API fornirà una motivazione dettagliata, spesso indicando le soglie del disco.

Risoluzione:

  • Libera spazio su disco: Cancella indici vecchi, sposta dati su un altro livello o aggiungi capacità. Unire forzatamente gli indici attivi non è una soluzione rapida per lo spazio su disco e può aggiungere un carico I/O pesante durante un incidente.
  • Aggiungi più spazio su disco: Aumenta la capacità di archiviazione dei tuoi nodi.
  • Configura le soglie del disco: Regola cluster.routing.allocation.disk.watermark.low, high e flood_stage solo quando i valori attuali sono errati per il tuo ambiente. Alzare le soglie può guadagnare tempo, ma può anche nascondere un vero problema di capacità.

2. Nodo Uscito dal Cluster (Espulsione del Nodo)

I nodi possono lasciare il cluster a causa di problemi di rete, crash o rimozione intenzionale. Se un nodo che contiene shard (specialmente shard primari) lascia, quegli shard diventano non assegnati.

Diagnosi:

  • Controlla i log del cluster per nodi che hanno recentemente lasciato.
  • Monitora la connettività di rete tra i nodi.
  • Assicurati che tutti i nodi siano rilevabili tra loro. Controlla discovery.seed_hosts, la connettività di trasporto e i log del cluster. Non reintrodurre cluster.initial_master_nodes in un cluster già formato come soluzione generica.

Risoluzione:

  • Riavvia il nodo: Se il nodo è crashato o diventato non reattivo, prova a riavviarlo.
  • Affronta i problemi di rete: Risolvi eventuali problemi di connettività di rete tra i nodi.
  • Riaggiungi il nodo: Se il nodo è stato rimosso intenzionalmente, assicurati che sia configurato correttamente prima di rientrare nel cluster.

3. Filtri di Allocazione degli Shard e Consapevolezza

Regole di allocazione degli shard configurate in modo errato possono impedire l'assegnazione degli shard ai nodi disponibili.

Diagnosi:

  • Rivedi le tue impostazioni cluster.routing.allocation.*, in particolare i filtri cluster.routing.allocation.include, exclude e require.
  • Controlla cluster.routing.allocation.awareness.attributes se stai usando la consapevolezza di zona o rack.

Risoluzione:

  • Regola i filtri di allocazione: Modifica i filtri per permettere l'allocazione degli shard ai nodi appropriati.
  • Correggi gli attributi di consapevolezza: Assicurati che i nodi siano correttamente etichettati con attributi di consapevolezza se usati, e che le tue regole di allocazione li rispettino.

4. Spazio su Disco Insufficiente per l'Allocazione (Post-Creazione dell'Indice)

Anche se un disco non è pieno, Elasticsearch potrebbe impedire l'allocazione degli shard se prevede che il disco supererà le soglie alte dopo l'allocazione. Questo è correlato alle soglie del disco ma impatta specificamente le nuove allocazioni.

Diagnosi:

  • L'API _cluster/allocation/explain è inestimabile qui.
  • Controlla lo spazio libero disponibile rispetto alla dimensione prevista degli shard.

Risoluzione:

  • Simile al problema generale dello spazio su disco: libera spazio, aggiungi più storage o regola le soglie con cautela.

5. Dimensione dello Shard e Capacità del Nodo

Shard molto grandi o un gran numero di shard possono mettere sotto stress le risorse del nodo (CPU, memoria) e influenzare l'allocazione. Inoltre, se un nodo ha raggiunto il suo limite di shard (cluster.routing.allocation.total_shards_per_node), nuovi shard non saranno allocati ad esso.

Diagnosi:

  • Controlla le dimensioni degli shard (GET _cat/shards?v).
  • Monitora l'utilizzo delle risorse del nodo (CPU, memoria).
  • Rivedi l'impostazione cluster.routing.allocation.total_shards_per_node.

Risoluzione:

  • Riduci la pressione degli shard: Per indici futuri, regola il rollover e il conteggio degli shard in modo che gli shard rientrino in un intervallo di dimensioni gestibile. Per indici esistenti, usa reindex, shrink o split solo dopo che il cluster è abbastanza stabile per gestire il lavoro.
  • Aumenta la capacità del nodo: Aggiungi nodi più potenti o nodi con più memoria/CPU.
  • Regola il limite di shard: Se necessario e hai risorse sufficienti, aumenta cluster.routing.allocation.total_shards_per_node.

6. Problemi del Nodo Master

Un nodo master instabile può portare a problemi di allocazione degli shard. Se il master non è disponibile o non è in grado di svolgere i suoi compiti, gli shard potrebbero diventare non assegnati.

Diagnosi:

  • Controlla i log del cluster per errori o avvisi relativi al master.
  • Assicurati di avere un numero dispari di nodi eleggibili a master (tipicamente 3 o 5) per evitare scenari di split-brain.
  • Verifica che i nodi eleggibili a master possano eleggere un master.

Risoluzione:

  • Stabilizza il master: Assicurati che i nodi eleggibili a master siano sani, abbiano risorse sufficienti e siano ben connessi.
  • Controlla la cronologia di bootstrap: cluster.initial_master_nodes è solo per la prima formazione del cluster. Dopo il bootstrap, rimuovilo dalle configurazioni del nodo e risolvi l'instabilità del master attraverso log, rete di trasporto e configurazione di voto.

Risoluzione Avanzata con _cluster/allocation/explain

L'API _cluster/allocation/explain è il tuo strumento più potente per capire perché uno shard specifico non è assegnato.

Esempio:

GET _cluster/allocation/explain
{
  "index": "my-index",
  "shard": 0,
  "primary": true
}

Questo restituirà un output JSON dettagliato che spiega perché lo shard primario 0 di my-index non può essere allocato. Cerca campi come deciders che elencano le ragioni per la non assegnazione (es., DISK_THRESHOLD, NODE_LEFT, NO_VALID_SHARD_COPY).

Risoluzione dello Stato del Cluster Giallo

Uno stato giallo significa che gli shard primari sono allocati, ma le repliche no. Questo impatta principalmente la ridondanza dei dati e la tolleranza ai guasti.

Cause Comuni:

  • Nodi insufficienti: Non hai abbastanza nodi per ospitare il numero richiesto di repliche per i tuoi indici.
  • Filtri di allocazione degli shard: Simile allo stato rosso, i filtri potrebbero impedire l'allocazione delle repliche.
  • Vincoli di spazio su disco: I nodi potrebbero avere abbastanza spazio per gli shard primari ma non abbastanza per le repliche, specialmente se le soglie del disco sono attive.

Risoluzione:

  • Aggiungi più nodi: Aumenta il numero di nodi nel tuo cluster.
  • Regola il conteggio delle repliche: Riduci il numero di repliche per indice (index.number_of_replicas) se la tolleranza ai guasti non è critica per tutti gli indici.
  • Controlla le impostazioni di allocazione: Assicurati che gli shard replica possano essere allocati ai nodi disponibili.

Migliori Pratiche per Mantenere la Salute del Cluster

  • Monitora l'Utilizzo del Disco: Monitora proattivamente lo spazio su disco su tutti i nodi e imposta avvisi.
  • Dimensiona Correttamente il Tuo Cluster: Assicurati di avere abbastanza nodi e risorse per il tuo volume di dati e carico di query.
  • Gestione degli Shard: Mantieni le dimensioni degli shard entro gli intervalli raccomandati ed evita un eccesso di shard.
  • Rivedi Regolarmente la Salute del Cluster: Usa GET _cluster/health e GET _cluster/allocation/explain come parte del tuo monitoraggio di routine.
  • Testa le Modifiche: Prima di apportare modifiche significative alle impostazioni di allocazione o alle soglie del disco, testale in un ambiente di staging.

Una volta che conosci il decisore di allocazione, il percorso è solitamente chiaro. Soglia del disco significa capacità. NODE_LEFT significa recuperare o sostituire il nodo mancante. NO_VALID_SHARD_COPY significa che potresti aver bisogno di un ripristino da snapshot o di una decisione deliberata di perdita di dati utilizzando le procedure di recupero non sicure documentate di Elasticsearch. L'ultimo caso dovrebbe essere gestito lentamente, controllando prima i backup, perché il comando che porta il cluster fuori dal rosso può anche confermare la perdita permanente dei dati più recenti del primario mancante.