Problemi di allocazione degli shard in Elasticsearch: cause e soluzioni

I problemi di allocazione degli shard in Elasticsearch si manifestano solitamente con uno stato del cluster giallo o rosso. Il giallo indica che gli shard primari sono assegnati ma almeno una replica non lo è. Il rosso significa che almeno uno shard primario non è assegnato, quindi alcuni dati potrebbero non essere disponibili fino al ripristino.

Questa guida mostra come individuare il blocco di allocazione, leggere l'output dell'API Allocation Explain e scegliere la soluzione meno rischiosa. L'obiettivo è ripristinare l'allocazione senza aggravare la perdita di dati.

Comprensione degli stati degli shard e della salute del cluster

Gli shard sono l'unità che Elasticsearch posiziona tra i nodi dati. Possono esistere in diversi stati:

• STARTED: Lo shard è attivo e serve le richieste.
• RELOCATING: Lo shard si sta spostando da un nodo all'altro.
• INITIALIZING: Lo shard è in fase di creazione o ripristino.
• UNASSIGNED: Lo shard esiste nei metadati del cluster ma non è allocato su un nodo.

La salute del cluster segue questi stati degli shard:

• Verde: Tutti gli shard primari e le repliche sono allocati.
• Giallo: Tutti gli shard primari sono allocati, ma una o più repliche non sono assegnate.
• Rosso: Uno o più shard primari non sono assegnati. Le ricerche potrebbero restituire risultati parziali o fallire per gli indici interessati e le scritture su tali indici potrebbero fallire.

Cause comuni dei fallimenti di allocazione degli shard

Elasticsearch utilizza i decisori di allocazione prima di posizionare uno shard. Una singola decisione NO può mantenere uno shard non assegnato.

Soglie del disco

La pressione del disco è una delle cause più comuni. Elasticsearch utilizza soglie del disco per evitare di riempire un nodo. Una volta che un nodo supera la soglia bassa o alta, le decisioni di allocazione diventano più restrittive. Alla soglia di flood-stage, Elasticsearch può aggiungere un blocco di sola lettura agli indici interessati per proteggere il nodo dall'esaurimento del disco.

Impostazione	Default comune	Effetto
cluster.routing.allocation.disk.watermark.low	85%	Evita di allocare ulteriori shard su nodi al di sopra di questa soglia.
cluster.routing.allocation.disk.watermark.high	90%	Tenta di spostare gli shard via ed evita di posizionare shard sul nodo.
cluster.routing.allocation.disk.watermark.flood_stage	95%	Può bloccare le scritture sugli indici interessati.

Conferma le impostazioni effettive del tuo cluster prima di modificare qualsiasi cosa:

GET /_cluster/settings?include_defaults=true&filter_path=**.disk.watermark*

Quindi controlla l'utilizzo del disco del nodo:

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

Libera spazio, aggiungi disco, aggiungi nodi dati, elimina indici vecchi o riduci la pressione delle repliche. Se è stato impostato un blocco di flood-stage, rimuovilo solo dopo aver risolto la pressione del disco:

PUT /my_index/_settings
{
  "index.blocks.read_only_allow_delete": null
}

Ruoli dei nodi e filtri di allocazione

Gli shard degli indici vengono allocati solo su nodi con un ruolo dati e filtri di allocazione corrispondenti. Se utilizzi attributi dei nodi per tier hot/warm, rack, zone o tipi di storage, un errore di battitura può bloccare gli shard.

Ad esempio, un indice con index.routing.allocation.require.box_type: high_io verrà allocato solo su nodi configurati con node.attr.box_type: high_io.

Controlla i filtri degli indici e gli attributi dei nodi:

GET /my_index/_settings?filter_path=*.settings.index.routing.allocation
GET /_cat/nodeattrs?v
GET /_cat/nodes?v&h=name,roles,disk.used_percent

Correggi l'impostazione dell'indice o aggiungi un nodo dati idoneo. Non rimuovere la consapevolezza di allocazione con leggerezza in cluster multi-zona; potrebbe posizionare tutte le copie di uno shard nello stesso dominio di guasto.

Shard primari mancanti

Se uno shard primario non è assegnato, il nodo che conteneva il primario attivo potrebbe essere scomparso, l'indice potrebbe essere stato appena ripristinato o le regole di allocazione potrebbero bloccare ogni nodo idoneo. Non presumere che i dati siano persi finché l'API Allocation Explain non ti dice perché Elasticsearch non può allocare lo shard.

Scenari comuni includono:

• Un nodo che conteneva l'unica copia primaria valida è andato in crash.
• I filtri di allocazione escludono ogni nodo dati che potrebbe ospitare il primario.
• Un ripristino da snapshot o la creazione di un indice è in attesa di nodi idonei.
• Esiste una copia obsoleta dello shard, ma Elasticsearch non la promuoverà senza l'accettazione esplicita della perdita di dati.

Prima prova a recuperare il nodo mancante, ripristina uno snapshot o correggi il blocco di allocazione. Utilizza l'allocazione forzata del primario solo quando capisci quale copia è obsoleta o quando hai accettato la perdita di dati per quello shard.

Limiti degli shard

Anche i limiti di shard per nodo possono bloccare l'allocazione. Le impostazioni comuni includono index.routing.allocation.total_shards_per_node e cluster.routing.allocation.total_shards_per_node.

Controlla questi limiti:

GET /_cluster/settings?include_defaults=true&filter_path=**.total_shards_per_node
GET /my_index/_settings?filter_path=*.settings.index.routing.allocation.total_shards_per_node

Aggiungi nodi, riduci il numero di repliche, consolida gli indici piccoli o aumenta cautamente il limite pertinente. Troppi shard per nodo possono aumentare la pressione sull'heap e rallentare le operazioni sullo stato del cluster.

Diagnostica con l'API Allocation Explain

L'API Allocation Explain è il miglior strumento per rispondere alla domanda "perché questo shard non si sta allocando?"

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

Per lasciare che Elasticsearch scelga uno shard attualmente non assegnato, chiama l'API senza corpo:

GET /_cluster/allocation/explain?pretty

Leggi prima questi campi:

• can_allocate: La risposta di alto livello.
• allocate_explanation: Il riepilogo in inglese semplice.
• node_allocation_decisions: Decisioni per nodo.
• deciders: La regola esatta che ha restituito NO o THROTTLE.

Una decisione NO è il blocco. Una decisione THROTTLE di solito significa che Elasticsearch può allocare lo shard ma sta limitando il lavoro di recupero concorrente.

Sequenza di risoluzione dei problemi sicura

Inizia in modo ampio, poi restringi.

1. Controlla la salute del cluster e gli shard non assegnati

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

Guarda unassigned.reason. Valori come NODE_LEFT, INDEX_CREATED, CLUSTER_RECOVERED o ALLOCATION_FAILED ti dicono dove guardare dopo.

2. Controlla il disco e l'idoneità del nodo

GET /_cat/allocation?v&h=node,disk.used_percent,disk.avail,disk.total
GET /_cat/nodes?v&h=name,roles,heap.percent,ram.percent,cpu,disk.used_percent

Se i nodi sono vicini alla soglia alta, risolvi la pressione del disco prima di modificare le impostazioni di allocazione.

3. Esegui Allocation Explain

Utilizza l'indice interessato, il numero dello shard e il flag primario/replica. L'output dovrebbe nominare l'impostazione, la condizione del nodo o il decisore che blocca l'allocazione.

4. Evita reroute rischiosi finché non conosci la causa

I comandi di reroute manuali sono per casi di recupero specifici. Non sono una soluzione generale per la pressione del disco, filtri errati o troppe repliche.

Se una copia primaria obsoleta è l'unico percorso di recupero pratico, il comando si presenta così:

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

accept_data_loss: true è richiesto per un motivo. Usalo solo dopo aver controllato gli snapshot, tentato di recuperare il nodo mancante e confermato quale nodo contiene la copia obsoleta.

5. Gestisci la salute gialla separatamente

Se solo le repliche non sono assegnate, il cluster può ancora servire i dati primari. Risolvi prima il vincolo di risorse sottostante. L'aggiunta di un nodo dati, la pulizia del disco o la correzione dei filtri di allocazione di solito consentono a Elasticsearch di assegnare le repliche automaticamente.

Se devi operare temporaneamente senza repliche, riduci il numero di repliche per l'indice interessato:

PUT /my_index/_settings
{
  "index.number_of_replicas": 0
}

Questo può far diventare la salute verde perché Elasticsearch non si aspetta più copie di replica per quell'indice. Riduce anche la disponibilità, quindi reimposta le repliche al valore desiderato dopo aver aggiunto capacità o risolto l'allocazione.

Prevenire i problemi di allocazione

• Invia avvisi prima che i nodi superino la soglia alta del disco.
• Mantieni abbastanza nodi dati disponibili per il numero di repliche e le regole di consapevolezza di allocazione.
• Utilizza conteggi di shard adatti al tuo heap, volume di dati e obiettivi di recupero.
• Rivedi i template degli indici in modo che i nuovi indici non ereditino conteggi di replica o filtri di allocazione errati.
• Testa la sostituzione dei nodi e le procedure di ripristino da snapshot prima di un incidente.

Conclusione

Il percorso più sicuro è semplice: identifica lo shard non assegnato, esegui Allocation Explain, correggi il decisore che dice NO ed evita l'allocazione forzata a meno che tu non abbia accettato il compromesso della perdita di dati.