Fehlerbehebung bei häufigen Elasticsearch Shard-Zuweisungsfehlern

Elasticsearch, eine leistungsstarke verteilte Such- und Analyse-Engine, basiert stark auf seiner Fähigkeit, Daten mithilfe von Shards über mehrere Knoten zu verteilen. Wenn diese Shards nicht zugewiesen werden können, kann dies zu Dateninkonsistenzen, Suchfehlern und einem verschlechterten Cluster-Zustand führen. Das Verständnis der häufigsten Ursachen von Shard-Zuweisungsfehlern und das Wissen, wie diese diagnostiziert und behoben werden können, ist entscheidend für die Aufrechterhaltung einer stabilen und leistungsfähigen Elasticsearch-Umgebung. Dieser Artikel führt Sie durch die häufigsten Probleme und bietet umsetzbare Schritte, um Ihre Shards wieder in einen zugewiesenen Zustand zu versetzen.

Dieser Leitfaden konzentriert sich auf die praktische Fehlerbehebung für Elasticsearch-Produktionsumgebungen. Wir behandeln die Identifizierung nicht zugewiesener Shards, das Verständnis häufiger Fehlerursachen wie Speicherplatz, Zuweisungsregeln und Knotenprobleme und bieten klare Schritte zur effizienten Behebung dieser Probleme. Durch die Beherrschung dieser Techniken können Sie Ausfallzeiten minimieren und die Zuverlässigkeit Ihres Elasticsearch-Clusters gewährleisten.

Identifizierung nicht zugewiesener Shards

Der erste Schritt bei der Fehlerbehebung ist die Identifizierung, welche Shards nicht zugewiesen sind und warum. Elasticsearch bietet hierfür mehrere Tools:

Verwendung der Cluster Health API

Die _cluster/health-API bietet einen Überblick auf hoher Ebene über den Status Ihres Clusters. Suchen Sie in der Antwort nach unassigned_shards. Ein Wert ungleich Null weist auf ein Problem hin.

GET _cluster/health

Beispiel für eine Antwort (Auszug):

{
  "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 diesem Beispiel weisen "status": "yellow" und "unassigned_shards": 1 darauf hin, dass ein Shard nicht zugewiesen ist. Ein red-Status bedeutet, dass ein oder mehrere primäre Shards nicht zugewiesen sind, was die Datenverfügbarkeit beeinträchtigt. Ein yellow-Status bedeutet, dass Replik-Shards nicht zugewiesen sind, primäre Shards jedoch zugewiesen sind, sodass Ihre Daten weiterhin durchsuchbar, aber nicht vollständig redundant sind.

Verwendung der Allocation Explain API

Für detaillierte Einblicke, warum ein bestimmter Shard nicht zugewiesen ist, ist die _cluster/allocation/explain-API von unschätzbarem Wert. Sie können Shard-Details angeben oder den Cluster-Zustand analysieren lassen.

Um eine Erklärung für einen beliebigen nicht zugewiesenen Shard zu erhalten:

GET _cluster/allocation/explain

Um eine Erklärung für einen bestimmten Shard zu erhalten (ersetzen Sie index_name und shard_id):

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

Häufige Ursachen und Lösungen

Mehrere Faktoren können dazu führen, dass Shards nicht zugewiesen werden. Hier sind die häufigsten und wie Sie sie beheben können:

1. Unzureichender Speicherplatz

Dies ist wohl die häufigste Ursache für Shard-Zuweisungsfehler. Wenn einem Knoten der Speicherplatz ausgeht, verhindert Elasticsearch, dass neue Shards auf diesem zugewiesen werden, um Datenkorruption zu vermeiden und die Stabilität zu gewährleisten. Es kann auch vorhandene Shards entfernen.

Symptom: Die Allocation Explain API meldet häufig Nachrichten wie "cannot allocate because disk usage [X%] exceeds the low watermark [Y%]" oder "cannot allocate because disk usage [X%] exceeds the high watermark [Y%]".
Diagnose: Überprüfen Sie die Festplattennutzung auf Ihren Datenknoten. Sie können die _cat/allocation-API für einen schnellen Überblick verwenden:
bash GET _cat/allocation?v
Suchen Sie nach Knoten mit hohen prozentualen Festplattennutzungen.
Lösungen:
- Mehr Speicherplatz hinzufügen: Die einfachste Lösung ist, den betroffenen Knoten mehr Speicherplatz hinzuzufügen oder vorhandene Festplatten durch größere zu ersetzen.
- Nicht verwendete Indizes löschen: Identifizieren und löschen Sie alte oder unnötige Indizes, die Speicherplatz verbrauchen.
- Wasserzeichen anpassen: Sie können die Festplattennutzungs-Wasserzeichen (cluster.routing.allocation.disk.watermark.low, cluster.routing.allocation.disk.watermark.high, cluster.routing.allocation.disk.watermark.flood_stage) in Ihrer elasticsearch.yml-Konfiguration oder dynamisch über die Cluster-Einstellungen-API anpassen. Vorsicht ist jedoch geboten, wenn Sie diese anpassen, da sie zum Schutz Ihres Clusters entwickelt wurden. Eine Senkung ohne Kapazitätserweiterung kann zu weiteren Problemen führen.
  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%" } }
- Weitere Knoten hinzufügen: Skalieren Sie Ihren Cluster durch Hinzufügen weiterer Datenknoten. Dies verteilt die Daten und reduziert die Last auf einzelne Knoten.
- Zwangsvereinigung oder Löschen alter Daten: Wenn Sie Zeitreihendaten haben, ziehen Sie die Verwendung der _forcemerge-API für ältere Indizes in Betracht, um die Anzahl der Segmente zu reduzieren (was Speicherplatz freigeben kann), oder verwenden Sie Index Lifecycle Management (ILM), um alte Daten automatisch zu löschen.

2. Knoten nicht verfügbar oder wird neu gestartet

Wenn ein Knoten ausgefallen ist, neu gestartet wird oder Netzwerkprobleme aufweist, werden alle auf diesem Knoten befindlichen Shards nicht zugewiesen. Handelt es sich um einen primären Shard, wechselt der Cluster-Status zu „rot“.

Symptom: Die Allocation Explain API wird anzeigen, dass der Shard nicht zugewiesen werden kann, da der Knoten nicht verfügbar ist oder aufgrund seines Ausfalls als (excluded) markiert ist.
Diagnose: Verwenden Sie die _cat/nodes-API, um den Status Ihrer Knoten zu überprüfen. Stellen Sie sicher, dass alle erwarteten Knoten aufgeführt und fehlerfrei sind.
bash GET _cat/nodes?v
Überprüfen Sie die Elasticsearch-Protokolle auf dem betroffenen Knoten auf Fehler oder Anzeichen eines Herunterfahrens.
Lösungen:
- Knoten neu starten: Wenn der Knoten ausgefallen ist, versuchen Sie, den Elasticsearch-Dienst neu zu starten.
- Netzwerkprobleme beheben: Stellen Sie sicher, dass der Knoten mit anderen Knoten im Cluster kommunizieren kann.
- Protokolle überprüfen: Untersuchen Sie die Elasticsearch-Protokolle für den spezifischen Knoten, um die Grundursache des Fehlers zu ermitteln (z. B. fehlender Speicher, Festplattenfehler, JVM-Probleme).
- index.unassigned.node_left.delayed_timeout erhöhen: Wenn Knoten häufig dem Cluster beitreten und ihn verlassen (z. B. während Rolling Restarts), können Replik-Shards vorübergehend nicht zugewiesen werden. Die Einstellung index.unassigned.node_left.delayed_timeout (Standard 1 Minute) ermöglicht es Elasticsearch, zu warten, bevor Shards auf einem abgetrennten Knoten als nicht zugewiesen markiert werden, wodurch dem Knoten Zeit zum Wiederbeitritt gegeben wird. Erhöhen Sie diesen Wert bei Bedarf, beachten Sie jedoch die Auswirkungen auf die Wiederherstellungszeit.

3. Zuweisungsfilterung und Awareness-Regeln

Elasticsearch ermöglicht Ihnen, die Zuweisung von Shards mithilfe verschiedener Zuweisungsregeln zu steuern, wie z. B. Knotenattribute und Anti-Affinitäten. Wenn diese Regeln die Zuweisung verhindern, können Shards nicht zugewiesen werden.

Symptom: Die Allocation Explain API wird melden, dass die Zuweisung für bestimmte Attribute deaktiviert ist oder dass gemäß den konfigurierten Regeln keine geeigneten Knoten verfügbar sind.
Diagnose:
- Überprüfen Sie Ihre Indexeinstellungen auf index.routing.allocation.require.*, index.routing.allocation.include.*, index.routing.allocation.exclude.* und index.routing.allocation.total_shards_per_node.
- Überprüfen Sie Ihre Cluster-Einstellungen auf cluster.routing.allocation.enable (z. B. all, primaries, new_primaries, none).
- Überprüfen Sie Knotenattribute mit GET _cat/nodeattrs?v.
Lösungen:
- Index-Einstellungen aktualisieren: Entfernen oder passen Sie restriktive Index-Routing-Regeln an. Zum Beispiel, um die Zuweisung zu jedem Knoten zu erlauben:
  json PUT my-index/_settings { "index": { "routing": { "allocation": { "require": null, "include": null, "exclude": null } } } }
- Cluster-Einstellungen aktualisieren: Aktivieren Sie die Zuweisung vorübergehend, falls sie deaktiviert war:
  json PUT _cluster/settings { "persistent": { "cluster.routing.allocation.enable": "all" } }
  Denken Sie daran, diese Einstellung rückgängig zu machen, wenn sie nur vorübergehend sein sollte.
- Knotenattribute aktualisieren: Stellen Sie sicher, dass Ihre Knoten die erwarteten Attribute in elasticsearch.yml definiert haben (z. B. node.attr.zone: us-east-1) und dass diese Attribute mit Ihren Zuweisungsregeln übereinstimmen. Nach einer Änderung der elasticsearch.yml müssen die Knoten neu gestartet werden, damit die Änderungen wirksam werden.

4. Beschädigte Shard-Daten (selten)

In seltenen Fällen können Shard-Daten korrumpiert werden, was Elasticsearch daran hindert, den Shard zu starten oder zuzuweisen. Dies ist häufiger bei zugrunde liegenden Festplattenproblemen der Fall.

Symptom: Protokolle könnten Fehler im Zusammenhang mit dem Lesen von Shard-Daten oder Indexkorruption zeigen. Die Allocation Explain API gibt möglicherweise keinen klaren Grund an oder weist auf einen Lesefehler hin.
Diagnose: Überprüfen Sie die Elasticsearch-Protokolle auf dem Knoten genau, auf dem der Shard erwartet wird. Suchen Sie nach E/A-Fehlern oder Nachrichten über Datenkorruption.
Lösungen:
- Aus Snapshot wiederherstellen: Die zuverlässigste Lösung ist die Wiederherstellung des betroffenen Index (oder des gesamten Clusters) aus einem bekannten guten Snapshot. Deshalb sind regelmäßige Backups entscheidend.
- Shard zwangsweise löschen (letztes Mittel): Wenn Sie nicht aus einem Snapshot wiederherstellen können und die Daten nicht kritisch sind oder neu indiziert werden können, müssen Sie möglicherweise den beschädigten Shard zwangsweise löschen. Dies ist ein fortgeschrittener Vorgang und sollte nur durchgeführt werden, wenn Sie die Auswirkungen verstehen. Sie müssen in der Regel den betroffenen Knoten stoppen, das Shard-Datenverzeichnis manuell entfernen und dann den Knoten neu starten. Dies führt zu Datenverlust für diesen Shard. Konsultieren Sie die Elasticsearch-Dokumentation für das genaue Verfahren für Ihre Version.

5. Unzureichende Relocation-Kapazität

Wenn ein Knoten den Cluster verlässt oder Probleme mit dem Speicherplatz auftreten, versucht Elasticsearch, Shards auf andere Knoten zu verschieben. Wenn nicht genügend geeignete Knoten vorhanden sind oder der Cluster bereits stark ausgelastet ist, kann die Shard-Relocation ins Stocken geraten, was zu initializing_shards oder unassigned_shards führt.

Symptom: Shards verbleiben für längere Zeit im Status initializing oder relocating, oder neue Shards können nicht zugewiesen werden.
Diagnose: Überprüfen Sie _cat/shards und _cat/allocation, um Shard-Status und Speicherplatznutzung zu sehen. Überwachen Sie den Cluster-Zustand und die CPU-/E/A-Auslastung der Knoten.
Lösungen:
- Weitere Knoten hinzufügen: Erhöhen Sie die Kapazität Ihres Clusters durch Hinzufügen weiterer Datenknoten.
- Ressourcen freigeben: Beheben Sie Leistungsengpässe auf vorhandenen Knoten (z. B. hohe CPU-Auslastung, langsame Festplatten-E/A).
- Shard-Zuweisungseinstellungen anpassen: Sie können Einstellungen wie cluster.routing.allocation.node_concurrent_recoveries (Anzahl der Shards, die gleichzeitig auf einem Knoten wiederhergestellt werden können) und cluster.routing.allocation.node_concurrent_incoming_recoveries (Anzahl der Shards, die gleichzeitig von einem anderen Knoten wiederhergestellt werden können) anpassen. Seien Sie jedoch vorsichtig, da eine Erhöhung dieser Werte den Cluster stärker belasten kann.

Best Practices zur Vorbeugung

Speicherplatz überwachen: Überwachen Sie proaktiv die Festplattennutzung auf allen Datenknoten. Richten Sie Warnmeldungen ein, wenn die Festplattennutzung vordefinierte Schwellenwerte überschreitet (z. B. 80 % oder 85 %).
Index Lifecycle Management (ILM) implementieren: Automatisieren Sie die Verwaltung von Zeitreihendaten, einschließlich des Rollens, Schrumpfens und Löschens alter Indizes. Dies hilft, den Speicherplatzverbrauch zu kontrollieren.
Regelmäßige Snapshots: Stellen Sie sicher, dass Sie eine robuste Backup-Strategie mit regelmäßigen, automatisierten Snapshots Ihrer Daten haben. Testen Sie Ihren Wiederherstellungsprozess regelmäßig.
Zuweisungsregeln verstehen: Planen und konfigurieren Sie die Shard-Zuweisungsregeln sorgfältig basierend auf Ihrer Hardware, Daten und Verfügbarkeitsanforderungen.
Angemessene Hardware: Stellen Sie sicher, dass Ihre Knoten über ausreichende CPU-, RAM- und E/A-Kapazitäten verfügen, um die Arbeitslast und Shard-Wiederherstellungsprozesse zu bewältigen.
Cluster-Gesundheitsüberwachung: Überprüfen Sie regelmäßig die Gesundheit Ihres Clusters mithilfe der _cluster/health-API und visualisieren Sie diese mit Tools wie Kibana's Stack Monitoring.

Fazit

Shard-Zuweisungsfehler in Elasticsearch können ein beängstigendes Problem sein, aber durch die systematische Diagnose des Problems mithilfe von Tools wie der Cluster Health API und der Allocation Explain API und das Verständnis häufiger Ursachen wie Speicherplatz, Knotenverfügbarkeit und Zuweisungsregeln können Sie diese effektiv beheben. Proaktive Überwachung und die Einhaltung bewährter Verfahren, wie regelmäßige Backups und ILM, sind der Schlüssel zur Vermeidung dieser Probleme von vornherein und zur Gewährleistung eines stabilen, gesunden Elasticsearch-Clusters.