Centro di Conoscenza DevOps
Centro di Conoscenza DevOps

Problemi di Allocazione degli Shard in Elasticsearch: Cause e Soluzioni

Risolvere i problemi comuni relativi ai guasti nell'allocazione degli shard di Elasticsearch che portano a uno stato del cluster Giallo o Rosso. Questa guida spiega le cause critiche, tra cui le soglie di spazio su disco, le mancate corrispondenze degli attributi dei nodi e la perdita di shard primari. Impara a usare efficacemente l'API Allocation Explain e ad applicare comandi pratici per ripristinare la stabilità del cluster e garantire la disponibilità dei dati.

46 visualizzazioni

Problemi di Allocazione degli Shard in Elasticsearch: Cause e Soluzioni

I cluster Elasticsearch sono progettati per la resilienza e l'alta disponibilità, basandosi fortemente sulla corretta distribuzione e allocazione degli shard tra i nodi. Quando uno shard non riesce a passare da uno stato UNASSIGNED (non assegnato) o INACTIVE (inattivo) a una replica o un primario attivo, l'indicatore di salute del cluster diventa spesso giallo o rosso. Capire perché gli shard non si stanno allocando è fondamentale per mantenere un motore di ricerca sano, performante e disponibile.

Questa guida approfondisce le cause comuni dei fallimenti di allocazione degli shard—dalle risorse del cluster insufficienti alle impostazioni errate—e fornisce soluzioni pratiche e attuabili per risolvere questi problemi, assicurando che i tuoi dati siano correttamente indicizzati e ricercabili.

Comprensione degli Stati e dell'Allocazione degli Shard

Prima di procedere alla risoluzione dei problemi, è essenziale sapere cosa sta cercando di fare Elasticsearch. Gli shard sono l'unità fondamentale di distribuzione in Elasticsearch. Possono esistere in diversi stati:

  • STARTED (Avviato): Lo shard è attivo e serve le richieste (Primario o Replica).
  • RELOCATING (In Rilocazione): Lo shard è in fase di spostamento da un nodo a un altro (durante il ribilanciamento o l'aggiunta/rimozione di nodi).
  • INITIALIZING (In Inizializzazione): Una nuova replica shard viene creata dal primario.
  • UNASSIGNED (Non Assegnato): Lo shard esiste nei metadati dello stato del cluster ma non è allocato a nessun nodo, spesso perché il nodo richiesto non è disponibile o i criteri non sono soddisfatti.

La salute del cluster è determinata dalla presenza di shard non assegnati:

  • Green (Verde): Tutti gli shard primari e di replica sono allocati.
  • Yellow (Giallo): Tutti gli shard primari sono allocati, ma una o più repliche shard non sono assegnate.
  • Red (Rosso): Uno o più shard primari non sono assegnati (indicando un rischio di perdita di dati se il nodo che ospita lo shard primario fallisce).

Cause Comuni di Fallimenti nell'Allocazione degli Shard

L'allocazione degli shard è gestita dalla logica del decider di allocazione del cluster, che verifica numerosi fattori prima di piazzare uno shard. Il fallimento deriva solitamente dalla violazione di uno di questi punti decisionali.

1. Risorse del Cluster Insufficienti

Questa è forse la causa più frequente di blocchi nell'allocazione, specialmente in ambienti dinamici.

Soglie di Spazio su Disco

Elasticsearch smette automaticamente di allocare nuovi shard (sia primari che di replica) a un nodo se l'utilizzo del disco supera le soglie predefinite. Per impostazione predefinita, l'allocazione si interrompe all'85% di utilizzo e la impedisce completamente al 90%.

Soglie Predefinite (Controllare elasticsearch.yml o Impostazioni del Cluster):

Impostazione Valore Predefinito Descrizione
cluster.routing.allocation.disk.watermark.low 85% Soglia in cui il nodo è considerato relativamente pieno.
cluster.routing.allocation.disk.watermark.high 90% Soglia in cui l'allocazione al nodo è bloccata.
cluster.routing.allocation.disk.watermark.flood_stage 95% L'allocazione si interrompe completamente e le operazioni di indicizzazione/scrittura potrebbero fallire.

Soluzione: Controllare l'utilizzo del disco su tutti i nodi e liberare spazio o aggiungere più spazio su disco ai nodi che stanno superando il high watermark.

Pressione della Memoria e della CPU

Sebbene sia meno comune dei problemi di disco, l'utilizzo elevato e persistente della memoria o l'alto carico della CPU sui nodi possono impedire l'assegnazione di nuovi shard, poiché i deciders di allocazione preferiscono i nodi con sufficiente margine operativo.

2. Mancata Corrispondenza di Ruoli e Attributi del Nodo

Le moderne implementazioni di Elasticsearch utilizzano spesso nodi dedicati per master, ingest o coordinamento. Gli shard non verranno allocati a nodi che non soddisfano i criteri richiesti.

Regole di Allocazione Non Corrispondenti

Se hai configurato impostazioni di indice specifiche che richiedono che gli shard siano posizionati su nodi etichettati con determinati attributi (ad esempio, SSD veloci), ma nessun nodo disponibile corrisponde a tale etichetta, gli shard rimarranno non assegnati.

Esempio: Un indice creato con index.routing.allocation.require.box_type: high_io verrà allocato solo su nodi configurati esplicitamente con tale impostazione.

Soluzione: Verificare le regole di allocazione (allocation.require, allocation.include, allocation.exclude) per l'indice interessato e assicurarsi che i nodi posseggano le impostazioni node.attr corrette.

3. Stabilità dello Stato del Cluster e Fallimenti di Allocazione del Primario (Salute Rossa)

Se gli shard primari non sono assegnati (il cluster è ROSSO), significa che il nodo che conteneva l'ultima copia primaria è fallito o ha lasciato il cluster e nessuna replica shard disponibile può essere promossa a primario.

Scenari Comuni:
* Un nodo che contiene l'unica copia primaria si arresta in modo anomalo inaspettato.
* Il nodo contenente lo shard primario viene esplicitamente rimosso dal cluster prima che le repliche fossero copiate con successo.

Soluzione: Se il nodo fallito non può essere recuperato rapidamente, potrebbe essere necessario forzare manualmente l'allocazione ignorando il blocco primario, ma ciò comporta un alto rischio di perdita di dati per quegli specifici shard.

4. Limiti e Quote degli Shard

Elasticsearch impone limiti per prevenire una creazione incontrollata di shard che potrebbe destabilizzare il cluster.

Shard Massimi per Nodo

Se un nodo ha raggiunto il numero massimo configurato di shard (cluster.routing.allocation.total_shards_per_node), nessun ulteriore shard gli verrà assegnato, anche se lo spazio su disco è disponibile.

Soluzione: Aumentare il limite total_shards_per_node (usare cautela, poiché troppi shard per nodo possono degradare le prestazioni) o aggiungere più nodi al cluster per distribuire il carico.

Diagnosi dei Fallimenti di Allocazione: L'API Allocation Explain

L'API Allocation Explain è lo strumento più potente per diagnosticare perché uno specifico shard non viene allocato. Simula il processo decisionale dei deciders di allocazione.

Per utilizzarla, è necessario il nome dell'indice, il numero dello shard e il nodo su cui lo shard dovrebbe trovarsi (se noto, oppure omettere il nodo per verificare tutte le possibilità).

Esempio di Utilizzo (Controllo dello Shard 0 dell'Indice my_data):

GET /_cluster/allocation/explain?pretty
{
  "index": "my_data",
  "shard": 0,
  "primary": true
}

La risposta dettaglierà ogni decisione di allocazione presa per quello shard, indicando esplicitamente quale regola è stata violata (ad esempio, "[disco che supera l'high watermark sul nodo X]").

Lettura dell'Output

Prestare molta attenzione al campo explanation e alla sezione deciders. Se un decider restituisce false, il messaggio corrispondente spiega il vincolo violato (ad esempio, utilizzo del disco, mancata corrispondenza del conteggio delle repliche o esclusione dell'attributo del nodo).

Fasi di Risoluzione dei Problemi e Comandi

Quando ci si trova di fronte a uno stato UNASSIGNED, seguire questa sequenza di risoluzione dei problemi prioritizzata:

Fase 1: Controllare la Salute del Cluster e gli Shard Non Assegnati

Innanzitutto, guarda il quadro generale.

GET /_cluster/health?pretty
GET /_cat/shards?h=index,shard,prirep,state,unassigned.reason,node

Guardare specificamente la colonna unassigned.reason dall'output dell'API cat. Questo spesso fornisce indizi immediati (ad esempio, CLUSTER_RECOVERED, NODE_LEFT, INDEX_CREATED).

Fase 2: Indagare sullo Spazio su Disco

Se la ragione indica una pressione sul disco, verificare l'utilizzo effettivo su tutti i nodi.

GET /_cat/allocation?v&h=node,disk.used_percent,disk.avail,disk.total

Azione: Se i nodi sono vicini al 90% della capacità, iniziare immediatamente a cancellare i log, a ridurre la retention degli indici o ad aggiungere capacità disco a quei nodi.

Fase 3: Utilizzare Allocation Explain per Casi Complessi

Se la causa non è un'ovvia pressione delle risorse, eseguire l'API Allocation Explain come dettagliato sopra per individuare le mancate corrispondenze di configurazione.

Fase 4: Forzare Manualmente l'Allocazione (Usare con Cautela)

Se uno shard primario è UNASSIGNED (Salute Rossa) perché il nodo originale è permanentemente sparito e si accetta il rischio di perdere i dati scritti dall'ultima esistenza dello shard primario, è possibile forzare il cluster a promuovere una replica (se ne esiste una).

Attenzione: Questo comando elimina permanentemente il record dello shard primario non assegnato. Usarlo solo se non è possibile recuperare il nodo che ospita il primario.

POST /_cluster/reroute
{
  "commands": [
    {
      "allocate_stale_primary": {
        "index": "index_name",
        "shard": 0,
        "node": "node_name_with_replica",
        "accept_data_loss": true
      }
    }
  ]
}

Fase 5: Gestire le Repliche Bloccate (Salute Gialla)

Se solo le repliche non sono assegnate (Salute Gialla) a causa di nodi insufficienti o spazio su disco, la semplice correzione del vincolo di risorse sottostante (aggiungendo nodi o liberando spazio su disco) di solito farà sì che le repliche si allocino automaticamente una volta che i deciders lo consentono.

Se si deve procedere senza aggiungere risorse, è possibile disabilitare temporaneamente l'allocazione delle repliche per l'indice:

PUT /my_index/_settings
{
  "index.blocks.write": true, 
  "index.number_of_replicas": 0
}

Dopo questa modifica, la salute del cluster dovrebbe diventare Verde (poiché zero repliche sono ora allocate con successo). Ricordarsi di riattivare le repliche in seguito ("index.number_of_replicas": 1).

Best Practices per Prevenire Problemi di Allocazione

  1. Monitorare Rigorosamente gli Watermark del Disco: Impostare avvisi basati sull'high watermark (90%) per intervenire prima che l'allocazione sia completamente bloccata.
  2. Mantenere la Diversità dei Nodi: Assicurarsi di avere abbastanza nodi fisici o virtuali in modo che, se uno fallisce, ci siano ancora abbastanza nodi disponibili che soddisfino i requisiti degli attributi per ospitare tutti i primari e le repliche richieste.
  3. Utilizzare l'Allocation Awareness (Consapevolezza dell'Allocazione): Per implementazioni multi-zona o multi-rack, configurare cluster.routing.allocation.awareness.attributes per impedire che tutte le copie di uno shard finiscano sulla stessa zona fisica, mitigando interruzioni a livello di zona.
  4. Impostare Conteggi di Replica Realistici: Evitare di impostare conteggi di replica superiori al numero di nodi fisici che è possibile sostenere, poiché ciò garantirebbe repliche non assegnate durante la manutenzione minore.

Gestendo proattivamente le risorse e utilizzando l'API Allocation Explain, gli amministratori possono diagnosticare e risolvere rapidamente i fattori che impediscono agli shard di Elasticsearch di raggiungere l'allocazione ottimale.