Centro di Conoscenza DevOps
Centro di Conoscenza DevOps

Risoluzione dei problemi comuni di allocazione degli shard di Elasticsearch

Impara a risolvere e risolvere i problemi comuni di allocazione degli shard di Elasticsearch. Questa guida copre l'identificazione degli shard non assegnati, la diagnosi di problemi come errori di spazio su disco, non disponibilità dei nodi e filtri di allocazione, e fornisce soluzioni pratiche e migliori pratiche per mantenere un cluster Elasticsearch sano.

27 visualizzazioni

Risoluzione dei problemi comuni di allocazione degli shard di Elasticsearch

Elasticsearch, un potente motore di ricerca e analisi distribuito, si basa fortemente sulla sua capacità di distribuire i dati su più nodi utilizzando gli shard. Quando questi shard non riescono ad allocarsi, ciò può portare a indisponibilità dei dati, errori di ricerca e un degrado della salute del cluster. Comprendere le cause comuni dei fallimenti di allocazione degli shard e sapere come diagnosticarli e risolverli è fondamentale per mantenere un ambiente Elasticsearch stabile e performante. Questo articolo ti guiderà attraverso i problemi più frequenti e fornirà passaggi attuabili per riportare i tuoi shard in uno stato assegnato.

Questa guida si concentra sulla risoluzione pratica dei problemi per ambienti di produzione Elasticsearch. Tratteremo l'identificazione degli shard non assegnati, la comprensione dei motivi comuni di fallimento come spazio su disco, regole di allocazione e problemi dei nodi, e forniremo passaggi chiari per risolvere questi problemi in modo efficiente. Padroneggiando queste tecniche, è possibile ridurre al minimo i tempi di inattività e garantire l'affidabilità del proprio cluster Elasticsearch.

Identificare gli shard non assegnati

Il primo passo nella risoluzione dei problemi è identificare quali shard non sono assegnati e perché. Elasticsearch fornisce diversi strumenti per questo:

Utilizzo dell'API Cluster Health

L'API _cluster/health fornisce una panoramica generale dello stato del tuo cluster. Cerca unassigned_shards nella risposta. Un valore diverso da zero indica un problema.

GET _cluster/health

Esempio di frammento di risposta:

{
  "cluster_name": "my-es-cluster",
  "status": "yellow",
  "timed_out": false,
  "number_of_nodes": 3,
  "number_of_data_nodes": 3,
  "active_primary_shards": 10,
  "active_shards": 20,
  "relocating_shards": 0,
  "initializing_shards": 1,
  "unassigned_shards": 1,
  "delayed_unassigned_shards": 0,
  "number_of_pending_tasks": 0,
  "max_length_search_concurrency": 1000,
  "max_length_search_size": 10000,
  "active_shards_percent_as_number": 95.45454545454545
}

In questo esempio, "status": "yellow" e "unassigned_shards": 1 indicano che c'è uno shard non assegnato. Uno stato red significa che uno o più shard primari non sono assegnati, influenzando la disponibilità dei dati. Uno stato yellow significa che gli shard di replica non sono assegnati, ma gli shard primari sono allocati, quindi i tuoi dati sono ancora ricercabili ma non completamente ridondanti.

Utilizzo dell'API Allocation Explain

Per approfondimenti sul motivo per cui uno shard specifico non è assegnato, l'API _cluster/allocation/explain è preziosa. Puoi fornire i dettagli dello shard o lasciarla analizzare lo stato del cluster.

Per ottenere una spiegazione per qualsiasi shard non assegnato:

GET _cluster/allocation/explain

Per ottenere una spiegazione per uno shard specifico (sostituisci index_name e shard_id):

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

Cause comuni e soluzioni

Diversi fattori possono portare gli shard a non essere assegnati. Ecco i più comuni e come affrontarli:

1. Spazio su disco insufficiente

Questa è probabilmente la causa più frequente di fallimenti nell'allocazione degli shard. Quando un nodo esaurisce lo spazio su disco, Elasticsearch impedisce l'allocazione di nuovi shard per evitare la corruzione dei dati e garantire la stabilità. Potrebbe anche espellere gli shard esistenti.

  • Sintomo: L'API Allocation Explain spesso segnalerà messaggi come "cannot allocate because disk usage [X%] exceeds the low watermark [Y%]" o "cannot allocate because disk usage [X%] exceeds the high watermark [Y%]".
  • Diagnosi: Controlla l'utilizzo del disco sui tuoi nodi dati. Puoi utilizzare l'API _cat/allocation per una rapida panoramica:
    bash GET _cat/allocation?v
    Cerca nodi con percentuali di utilizzo del disco elevate.
  • Soluzioni:
    • Aggiungere più spazio su disco: La soluzione più semplice è aggiungere più spazio di archiviazione ai nodi interessati o sostituire i dischi esistenti con dischi più grandi.
    • Eliminare indici non utilizzati: Identifica ed elimina gli indici vecchi o non necessari che consumano spazio su disco.
    • Regolare i watermark: È possibile regolare i watermark di utilizzo del disco (cluster.routing.allocation.disk.watermark.low, cluster.routing.allocation.disk.watermark.high, cluster.routing.allocation.disk.watermark.flood_stage) nella configurazione elasticsearch.yml o dinamicamente tramite l'API delle impostazioni del cluster. Tuttavia, si consiglia cautela quando li si regola, poiché sono progettati per proteggere il cluster. Abbassarli senza aggiungere capacità può portare a ulteriori problemi.
      json PUT _cluster/settings { "persistent": { "cluster.routing.allocation.disk.watermark.low": "85%", "cluster.routing.allocation.disk.watermark.high": "90%", "cluster.routing.allocation.disk.watermark.flood_stage": "95%" } }
    • Aggiungere più nodi: Scala orizzontalmente il tuo cluster aggiungendo più nodi dati. Questo distribuisce i dati e riduce il carico sui singoli nodi.
    • Force Merge o eliminare dati vecchi: Se hai dati time-series, considera l'utilizzo dell'API _forcemerge su indici più vecchi per ridurre il numero di segmenti (che possono liberare spazio su disco) o utilizza la gestione del ciclo di vita degli indici (ILM) per eliminare automaticamente i dati vecchi.

2. Nodo non disponibile o in riavvio

Se un nodo è spento, in riavvio o presenta problemi di rete, gli shard presenti su quel nodo diventeranno non assegnati. Se si tratta di uno shard primario, lo stato del cluster diventerà rosso.

  • Sintomo: L'API Allocation Explain indicherà che lo shard non può essere allocato perché il nodo non è disponibile o è contrassegnato come (excluded) a causa del suo spegnimento.
  • Diagnosi: Utilizza l'API _cat/nodes per verificare lo stato dei tuoi nodi. Assicurati che tutti i nodi previsti siano elencati e integri.
    bash GET _cat/nodes?v
    Controlla i log di Elasticsearch sul nodo interessato per eventuali errori o segni di arresto.
  • Soluzioni:
    • Riavviare il nodo: Se il nodo è spento, prova a riavviare il servizio Elasticsearch.
    • Risolvere i problemi di rete: Assicurati che il nodo possa comunicare con altri nodi nel cluster.
    • Controllare i log: Esamina i log di Elasticsearch per il nodo specifico per identificare la causa principale del fallimento (ad esempio, memoria esaurita, errori del disco, problemi JVM).
    • Aumentare index.unassigned.node_left.delayed_timeout: Se i nodi entrano ed escono frequentemente dal cluster (ad esempio, durante i riavvii rolling), potresti vedere che gli shard di replica diventano temporaneamente non assegnati. L'impostazione index.unassigned.node_left.delayed_timeout (predefinita 1 minuto) consente a Elasticsearch di attendere prima di contrassegnare gli shard di un nodo uscito come non assegnati, dando al nodo il tempo di riconnettersi. Aumenta questo valore se necessario, ma sii consapevole dell'impatto sui tempi di recupero.

3. Filtri di allocazione e regole di consapevolezza

Elasticsearch ti consente di controllare dove vengono allocati gli shard utilizzando varie regole di allocazione, come attributi dei nodi e anti-affinità. Se queste regole impediscono l'allocazione, gli shard possono diventare non assegnati.

  • Sintomo: L'API Allocation Explain segnalerà che l'allocazione è disabilitata per attributi specifici o che non sono disponibili nodi idonei secondo le regole configurate.
  • Diagnosi:
    • Controlla le impostazioni del tuo indice per index.routing.allocation.require.*, index.routing.allocation.include.*, index.routing.allocation.exclude.* e index.routing.allocation.total_shards_per_node.
    • Controlla le impostazioni a livello di cluster per cluster.routing.allocation.enable (ad esempio, all, primaries, new_primaries, none).
    • Verifica gli attributi dei nodi utilizzando GET _cat/nodeattrs?v.
  • Soluzioni:
    • Aggiornare le impostazioni dell'indice: Rimuovi o modifica le regole di routing dell'indice restrittive. Ad esempio, per consentire l'allocazione su qualsiasi nodo:
      json PUT my-index/_settings { "index": { "routing": { "allocation": { "require": null, "include": null, "exclude": null } } } }
    • Aggiornare le impostazioni del cluster: Abilita temporaneamente l'allocazione se era stata disabilitata:
      json PUT _cluster/settings { "persistent": { "cluster.routing.allocation.enable": "all" } }
      Ricorda di ripristinare questa impostazione se era intesa solo come temporanea.
    • Aggiornare gli attributi dei nodi: Assicurati che i tuoi nodi abbiano gli attributi attesi definiti in elasticsearch.yml (ad esempio, node.attr.zone: us-east-1) e che questi attributi siano allineati con le tue regole di allocazione. Dopo aver modificato elasticsearch.yml, i nodi devono essere riavviati affinché le modifiche abbiano effetto.

4. Dati shard corrotti (Raro)

In rari casi, i dati degli shard possono corrompersi, impedendo a Elasticsearch di avviarsi o di allocare lo shard. Questo è più comune con problemi del disco sottostante.

  • Sintomo: I log potrebbero mostrare errori relativi alla lettura dei dati degli shard o alla corruzione dell'indice. L'API Allocation Explain potrebbe non fornire una ragione chiara o potrebbe indicare un errore di lettura.
  • Diagnosi: Esamina attentamente i log di Elasticsearch sul nodo in cui lo shard dovrebbe trovarsi. Cerca errori di I/O o messaggi di corruzione dei dati.
  • Soluzioni:
    • Ripristino da snapshot: La soluzione più affidabile è ripristinare l'indice interessato (o l'intero cluster) da uno snapshot noto e funzionante. Ecco perché i backup regolari sono fondamentali.
    • Forza eliminazione dello shard (Ultima risorsa): Se non riesci a ripristinare da uno snapshot e i dati non sono critici o possono essere re-indicizzati, potrebbe essere necessario forzare l'eliminazione dello shard corrotto. Questa è un'operazione avanzata e dovrebbe essere eseguita solo quando se ne comprendono le implicazioni. Di solito è necessario arrestare il nodo interessato, rimuovere manualmente la directory dei dati dello shard e quindi riavviare il nodo. Ciò comporterà la perdita di dati per quello shard. Consulta la documentazione di Elasticsearch per la procedura esatta per la tua versione.

5. Capacità di rilocalizzazione insufficiente

Quando un nodo lascia il cluster o sorgono problemi di spazio su disco, Elasticsearch tenta di rilocalizzare gli shard su altri nodi. Se non ci sono abbastanza nodi idonei o se il cluster è già sotto carico pesante, la rilocalizzazione degli shard può bloccarsi, portando a initializing_shards o unassigned_shards.

  • Sintomo: Gli shard rimangono nello stato initializing o relocating per periodi prolungati, o i nuovi shard non riescono ad allocarsi.
  • Diagnosi: Controlla _cat/shards e _cat/allocation per vedere gli stati degli shard e l'utilizzo del disco. Monitora la salute del cluster e l'utilizzo della CPU/IO dei nodi.
  • Soluzioni:
    • Aggiungere più nodi: Aumenta la capacità del tuo cluster aggiungendo più nodi dati.
    • Liberare risorse: Risolvi eventuali colli di bottiglia delle prestazioni sui nodi esistenti (ad esempio, CPU elevata, I/O del disco lento).
    • Regolare le impostazioni di allocazione degli shard: È possibile ottimizzare impostazioni come cluster.routing.allocation.node_concurrent_recoveries (numero di shard che possono essere recuperati contemporaneamente su un nodo) e cluster.routing.allocation.node_concurrent_incoming_recoveries (numero di shard che possono essere recuperati contemporaneamente da un altro nodo). Tuttavia, fai attenzione poiché l'aumento di questi valori può aumentare lo sforzo sul cluster.

Migliori pratiche per la prevenzione

  • Monitorare lo spazio su disco: Monitora proattivamente l'utilizzo dello spazio su disco su tutti i nodi dati. Imposta avvisi quando l'utilizzo del disco supera le soglie predefinite (ad esempio, 80% o 85%).
  • Implementare la gestione del ciclo di vita degli indici (ILM): Automatizza la gestione dei dati time-series, inclusi rollover, shrinking ed eliminazione di indici vecchi. Questo aiuta a controllare l'utilizzo dello spazio su disco.
  • Snapshot regolari: Assicurati di disporre di una solida strategia di backup con snapshot regolari e automatizzati dei tuoi dati. Testa periodicamente il tuo processo di ripristino.
  • Comprendere le regole di allocazione: Pianifica e configura attentamente le regole di allocazione degli shard in base ai requisiti hardware, dati e di disponibilità.
  • Hardware adeguato: Assicurati che i tuoi nodi dispongano di CPU, RAM e capacità di I/O sufficienti per gestire il carico di lavoro e i processi di recupero degli shard.
  • Monitoraggio della salute del cluster: Controlla regolarmente la salute del tuo cluster utilizzando l'API _cluster/health e visualizzala con strumenti come Stack Monitoring di Kibana.

Conclusione

I fallimenti nell'allocazione degli shard in Elasticsearch possono essere un problema scoraggiante, ma diagnosticando sistematicamente il problema utilizzando strumenti come l'API Cluster Health e l'API Allocation Explain, e comprendendo le cause comuni come lo spazio su disco, la disponibilità dei nodi e le regole di allocazione, è possibile risolverli efficacemente. Il monitoraggio proattivo e l'adesione alle migliori pratiche, come backup regolari e ILM, sono fondamentali per prevenire questi problemi in primo luogo e garantire un cluster Elasticsearch stabile e sano.