Elasticsearch Shard-Zuweisungsprobleme: Ursachen und Lösungen

Elasticsearch-Cluster sind auf Ausfallsicherheit und hohe Verfügbarkeit ausgelegt und verlassen sich stark auf die ordnungsgemäße Verteilung und Zuweisung von Shards auf Knoten. Wenn ein Shard es versäumt, von einem Zustand UNASSIGNED (nicht zugewiesen) oder INACTIVE (inaktiv) zu einem aktiven Primär- oder Replikat-Shard zu wechseln, ändert sich der Cluster-Health-Indikator oft auf Gelb oder Rot. Zu verstehen, warum Shards nicht zugewiesen werden, ist entscheidend für die Aufrechterhaltung einer gesunden, performanten und verfügbaren Suchmaschine.

Dieser Leitfaden untersucht eingehend die häufigsten Ursachen für Fehler bei der Shard-Zuweisung – von unzureichenden Cluster-Ressourcen bis hin zu falsch konfigurierten Einstellungen – und bietet umsetzbare, praktische Lösungen zur Behebung dieser Probleme, um sicherzustellen, dass Ihre Daten ordnungsgemäß indiziert und durchsuchbar sind.

Verständnis der Shard-Zustände und Zuweisung

Vor der Fehlerbehebung ist es wichtig zu wissen, was Elasticsearch zu tun versucht. Shards sind die grundlegende Einheit der Verteilung in Elasticsearch. Sie können in verschiedenen Zuständen existieren:

STARTED: Der Shard ist aktiv und bedient Anfragen (Primär oder Replikat).
RELOCATING: Der Shard wird von einem Knoten auf einen anderen verschoben (während des Rebalancings oder bei Knotenhinzufügung/-entfernung).
INITIALIZING: Ein neuer Replikat-Shard wird vom Primär-Shard erstellt.
UNASSIGNED: Der Shard existiert in den Metadaten des Cluster-Zustands, ist aber keinem Knoten zugewiesen, oft weil der erforderliche Knoten nicht verfügbar ist oder Kriterien nicht erfüllt sind.

Der Cluster-Health wird durch das Vorhandensein nicht zugewiesener Shards bestimmt:

Green (Grün): Alle Primär- und Replikat-Shards sind zugewiesen.
Yellow (Gelb): Alle Primär-Shards sind zugewiesen, aber ein oder mehrere Replikat-Shards sind nicht zugewiesen.
Red (Rot): Ein oder mehrere Primär-Shards sind nicht zugewiesen (was bei einem Ausfall des Knotens, der den Primär-Shard hostet, auf Datenverlustrisiko hindeutet).

Häufige Ursachen für Fehler bei der Shard-Zuweisung

Die Shard-Zuweisung wird durch die Zuweisungsentscheidungslogik des Clusters verwaltet, die zahlreiche Faktoren überprüft, bevor ein Shard platziert wird. Ein Fehler entsteht normalerweise durch die Verletzung eines dieser Entscheidungspunkte.

1. Unzureichende Cluster-Ressourcen

Dies ist vielleicht die häufigste Ursache für Hänger bei der Zuweisung, insbesondere in dynamischen Umgebungen.

Schwellenwerte für den Speicherplatz (Disk Space Thresholds)

Elasticsearch hört automatisch auf, neue Shards (sowohl Primär- als auch Replikat-Shards) einem Knoten zuzuweisen, wenn dessen Festplattenauslastung vordefinierte Schwellenwerte überschreitet. Standardmäßig stoppt die Zuweisung bei 85 % Auslastung und verhindert die Zuweisung vollständig bei 90 %.

Standard-Schwellenwerte (Prüfen Sie elasticsearch.yml oder Cluster-Einstellungen):

Einstellung	Standardwert	Beschreibung
`cluster.routing.allocation.disk.watermark.low`	85%	Schwellenwert, bei dem der Knoten als relativ voll gilt.
`cluster.routing.allocation.disk.watermark.high`	90%	Schwellenwert, bei dem die Zuweisung zum Knoten blockiert wird.
`cluster.routing.allocation.disk.watermark.flood_stage`	95%	Die Zuweisung stoppt vollständig, und Indexierungs-/Schreibvorgänge können fehlschlagen.

Lösung: Überprüfen Sie die Festplattenauslastung auf allen Knoten und geben Sie entweder Speicherplatz frei oder fügen Sie den Knoten, die den hohen Grenzwert überschreiten, mehr Speicherplatz hinzu.

Speicher- und CPU-Auslastung (Memory and CPU Pressure)

Obwohl seltener als Speicherprobleme, kann eine anhaltend hohe Speicherauslastung oder hohe CPU-Last auf Knoten verhindern, dass neue Shards zugewiesen werden, da die Zuweisungsentscheider Knoten mit ausreichend operativem Spielraum bevorzugen.

2. Abweichung von Knotenrollen und Attributen

Moderne Elasticsearch-Bereitstellungen verwenden häufig dedizierte Master-, Ingest- oder Coordinating-Knoten. Shards werden keinen Knoten zugewiesen, die die erforderlichen Kriterien nicht erfüllen.

Abweichende Zuweisungsregeln

Wenn Sie spezifische Indexeinstellungen konfiguriert haben, die erfordern, dass Shards auf Knoten platziert werden, die mit bestimmten Attributen gekennzeichnet sind (z. B. schnelle SSDs), aber kein verfügbarer Knoten mit diesem Tag übereinstimmt, bleiben die Shards nicht zugewiesen.

Beispiel: Ein Index, der mit index.routing.allocation.require.box_type: high_io erstellt wurde, wird nur auf Knoten zugewiesen, die explizit mit dieser Einstellung konfiguriert sind.

Lösung: Überprüfen Sie die Zuweisungsregeln (allocation.require, allocation.include, allocation.exclude) für den betroffenen Index und stellen Sie sicher, dass die Knoten über die korrekten node.attr-Einstellungen verfügen.

3. Stabilität des Cluster-Zustands und Fehler bei der Primär-Zuweisung (Roter Health-Status)

Wenn Primär-Shards nicht zugewiesen sind (Cluster ist ROT), bedeutet dies, dass der Knoten, der die letzte Primärkopie enthielt, abgestürzt ist oder den Cluster verlassen hat, und kein verfügbarer Replikat-Shard zum Primär-Shard befördert werden kann.

Häufige Szenarien:
* Ein Knoten, der die einzige Primärkopie hält, stürzt unerwartet ab.
* Der Knoten, der den Primär-Shard enthält, wird explizit aus dem Cluster entfernt, bevor die Replikate erfolgreich kopiert wurden.

Lösung: Wenn der ausgefallene Knoten nicht schnell wiederhergestellt werden kann, müssen Sie möglicherweise die Zuweisung manuell erzwingen, indem Sie den Primärblock überschreiben. Dies birgt jedoch ein hohes Risiko für Datenverlust für diese spezifischen Shards.

4. Shard-Limits und Quoten

Elasticsearch legt Limits fest, um eine außer Kontrolle geratene Shard-Erstellung zu verhindern, die den Cluster destabilisieren könnte.

Maximale Shards pro Knoten

Wenn ein Knoten seine konfigurierte maximale Anzahl von Shards (cluster.routing.allocation.total_shards_per_node) erreicht hat, werden ihm keine weiteren Shards zugewiesen, selbst wenn Speicherplatz verfügbar ist.

Lösung: Erhöhen Sie das Limit total_shards_per_node (mit Vorsicht verwenden, da zu viele Shards pro Knoten die Leistung beeinträchtigen können) oder fügen Sie dem Cluster weitere Knoten hinzu, um die Last zu verteilen.

Diagnose von Zuweisungsfehlern: Die Allocation Explain API

Die Allocation Explain API ist das leistungsstärkste Werkzeug zur Diagnose, warum ein bestimmter Shard nicht zugewiesen wird. Sie simuliert den Entscheidungsprozess der Zuweisungsentscheider.

Um sie zu verwenden, benötigen Sie den Indexnamen, die Shard-Nummer und den Knoten, auf dem sich der Shard befinden sollte (falls bekannt, andernfalls lassen Sie den Knoten weg, um alle Möglichkeiten zu prüfen).

Beispielverwendung (Überprüfung von Shard 0 des Index `%s`):

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

Die Antwort zeigt jede Zuweisungsentscheidung für diesen Shard im Detail an und gibt explizit an, welche Regel verletzt wurde (z. B. „[disk exceeding high watermark on node %s]").

Auslesen der Ausgabe

Achten Sie genau auf das Feld explanation und den Abschnitt deciders. Wenn ein Entscheider false zurückgibt, erklärt die entsprechende Meldung die verletzte Einschränkung (z. B. Festplattenauslastung, Nichtübereinstimmung der Replikatanzahl oder Ausschluss von Knotenattributen).

Schritte zur Fehlerbehebung und Befehle

Wenn Sie auf den Zustand UNASSIGNED stoßen, befolgen Sie diese priorisierte Fehlerbehebungssequenz:

Schritt 1: Cluster-Health und nicht zugewiesene Shards überprüfen

Sehen Sie sich zuerst das Gesamtbild an.

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

Suchen Sie in der Ausgabe der Cat-API insbesondere nach der Spalte unassigned.reason. Diese liefert oft sofortige Hinweise (z. B. CLUSTER_RECOVERED, NODE_LEFT, INDEX_CREATED).

Schritt 2: Speicherplatz untersuchen

Wenn der Grund auf Speicherplatzmangel hindeutet, überprüfen Sie die tatsächliche Auslastung auf allen Knoten.

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

Aktion: Wenn Knoten nahe 90 % Kapazität sind, beginnen Sie sofort damit, Protokolle zu bereinigen, die Index-Aufbewahrungsdauer zu verringern oder die Festplattenkapazität dieser Knoten zu erhöhen.

Schritt 3: Allocation Explain für komplexe Fälle verwenden

Wenn die Ursache kein offensichtlicher Ressourcenengpass ist, führen Sie die oben beschriebene Allocation Explain API aus, um Konfigurationsabweichungen festzustellen.

Schritt 4: Manuelles Erzwingen der Zuweisung (Vorsichtig verwenden)

Wenn ein Primär-Shard nicht zugewiesen ist (Roter Health-Status), weil der ursprüngliche Knoten dauerhaft ausgefallen ist und Sie das Risiko akzeptieren, Daten zu verlieren, die seit der Existenz des letzten Primär-Shards geschrieben wurden, können Sie den Cluster zwingen, ein Replikat zu befördern (falls eines existiert).

Warnung: Dieser Befehl löscht den Eintrag des nicht zugewiesenen Primär-Shards dauerhaft. Verwenden Sie dies nur, wenn Sie den Knoten, der den Primär-Shard hält, nicht wiederherstellen können.

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

Schritt 5: Behebung festsitzender Replikate (Gelber Health-Status)

Wenn nur Replikate aufgrund unzureichender Knoten oder Speicherplatz nicht zugewiesen sind (Gelber Health-Status), führt die einfache Behebung der zugrunde liegenden Ressourcenbeschränkung (Hinzufügen von Knoten oder Freigeben von Speicherplatz) normalerweise dazu, dass die Replikate automatisch zugewiesen werden, sobald die Entscheider dies zulassen.

Wenn Sie ohne Hinzufügen von Ressourcen fortfahren müssen, können Sie die Replikat-Zuweisung für den Index vorübergehend deaktivieren:

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

Nach dieser Änderung sollte der Cluster-Health auf Grün wechseln (da nun null Replikate erfolgreich zugewiesen sind). Denken Sie daran, die Replikate später wieder zu aktivieren ("index.number_of_replicas": 1).

Best Practices zur Vermeidung von Zuweisungsproblemen

Überwachen Sie Speicherplatz-Wasserzeichen streng: Richten Sie Alarme basierend auf dem high-Wasserzeichen (90 %) ein, um einzugreifen, bevor die Zuweisung vollständig blockiert wird.
Wahren Sie Knotenvielfalt: Stellen Sie sicher, dass Sie genügend physische oder virtuelle Knoten haben, sodass bei Ausfall eines Knotens noch genügend verfügbare Knoten vorhanden sind, die die Attributanforderungen erfüllen, um alle Primär-Shards und erforderlichen Replikate zu hosten.
Verwenden Sie Zuweisungsbewusstsein (Allocation Awareness): Für Bereitstellungen in mehreren Zonen oder Racks konfigurieren Sie cluster.routing.allocation.awareness.attributes, um zu verhindern, dass alle Kopien eines Shards in derselben physischen Zone landen, und um Zonen-weite Ausfälle zu mindern.
Legen Sie realistische Replikatanzahlen fest: Vermeiden Sie es, die Replikatanzahl höher als die Anzahl der physischen Knoten festzulegen, die Sie aufrechterhalten können, da dies während kleiner Wartungsarbeiten garantiert zu nicht zugewiesenen Replikaten führt.

Durch proaktives Ressourcenmanagement und die Nutzung der Allocation Explain API können Administratoren schnell die Faktoren diagnostizieren und beheben, die Elasticsearch-Shards daran hindern, die optimale Zuweisung zu erreichen.