Warum hat mein Amazon OpenSearch Service-Cluster einen roten oder gelben Status?

Kurzbeschreibung

Die Registerkarte Überwachung in Ihrer OpenSearch Service-Konsole zeigt den Status des Index mit der geringsten Fehlerrate in Ihrem Cluster an. Ein Clusterstatus, der einen roten Status anzeigt, bedeutet nicht, dass Ihr Cluster ausgefallen ist. Dieser Status gibt an, dass mindestens ein primärer Shard und seine Replikate keinem Knoten zugewiesen sind. Wenn Ihr Clusterstatus einen gelben Status anzeigt, werden die primären Shards für alle Indizes den Knoten in Ihrem Cluster zugewiesen. Ein oder mehrere Replikat-Shards werden jedoch keinem der Knoten zugewiesen.

Hinweis: Konfigurieren Sie Ihre Domain erst neu, wenn Sie den roten Clusterstatus behoben haben. Wenn Sie versuchen, Ihre Domain neu zu konfigurieren, obwohl sie sich in einem roten Clusterstatus befindet, könnte sie im Status „In Bearbeitung“ stecken bleiben. Weitere Informationen zu Clustern die im Status „Verarbeitung“ feststecken, finden Sie unter Warum ist meine OpenSearch Service-Domain im Status „Verarbeitung“ hängen geblieben?

Ihr Cluster kann aus den folgenden Gründen einen roten Status annehmen:

• Ausfälle mehrerer Datenknoten
• Einen korrupten oder roten Shard für einen Index verwenden
• Hoher JVM-Speicherdruck oder hohe CPU-Auslastung
• Niedriger Festplattenspeicher oder Festplattenversatz
• Keine Replikat-Shards für den nicht zugewiesenen Shard

Hinweis: In einigen Fällen können Sie Ihren roten Cluster-Status möglicherweise beheben, indem Sie den Index aus einem automatisierten Snapshot löschen und dann wiederherstellen.

Ihr Cluster kann aus den folgenden Gründen einen gelben Gesundheitsstatus annehmen:

• Erstellung eines neuen Indexes
• Nicht genügend Knoten für die Zuordnung zu den Shards oder Disk Skew
• Hoher JVM-Speicherdruck
• Ausfall eines einzelnen Knotens
• Die maximale Anzahl von Wiederholungsversuchen bei der Shard-Zuweisung wurde überschritten
• Die Anzahl der Replikat-Shards ist höher als die Anzahl der Datenknoten
• Kontinuierlicher Einsatz in Blau oder Grün aufgrund der Verlagerung von Datensplittern

Hinweis: Wenn sich Ihr gelber Cluster-Status nicht von selbst löst, können Sie den Status lösen, indem Sie die Indexeinstellungen aktualisieren oder die nicht zugewiesenen Shards manuell umleiten. Wenn sich Ihr gelber Cluster-Status nicht von selbst löst, identifizieren Sie die Grundursache und beheben Sie diese. Um zu verhindern, dass der Clusterstatus gelb ist, wenden Sie die bewährten Methoden zur Cluster health best practices (Clustergesundheit) an.

Behebung

Identifizieren Sie den Grund für Ihre nicht zugewiesenen Shards

Gehen Sie wie folgt vor, um die nicht zugewiesenen Shards zu identifizieren:

1.Listet den nicht zugewiesenen Shard auf:

$ curl -XGET 'domain-endpoint/_cat/shards?h=index,shard,prirep,state,unassigned.reason' | grep UNASSIGNED

2.Rufen Sie die Details ab, warum der Shard nicht zugewiesen wurde:

$ curl -XGET 'domain-endpoint/_cluster/allocation/explain?pretty' -H 'Content-Type:application/json' -d'
{
     "index": "<index name>",
     "shard": <shardId>,
     "primary": <true or false>
}

3.(Optional) Löschen Sie bei einem roten Cluster-Status die besorgniserregenden Indizes und identifizieren und beheben Sie die Grundursache:

curl -XDELETE 'domain-endpoint/<index names>'

Identifizieren Sie dann die verfügbaren Snapshots und stellen Sie Ihre Indizes anhand eines Snapshots wieder her:

curl -XGET 'domain-endpoint/_snapshot?pretty'

Bei gelbem Clusterstatus sollten Sie die Hauptursache beheben, sodass Ihre Shards zugewiesen werden.

Fehlerbehebung bei Ihrem roten oder gelben Clusterstatus

Nicht genügend Knoten, um sie den Shards zuzuweisen

Ein Replikat-Shard wird nicht demselben Knoten zugewiesen wie sein primärer Shard. Ein Einzelknoten-Cluster mit Replikat-Shards wird immer mit einem gelben Clusterstatus initialisiert. Cluster mit einem Knoten werden auf diese Weise initialisiert, da es keine anderen verfügbaren Knoten gibt, denen OpenSearch Service ein Replikat zuweisen kann.

Es gibt auch ein Standardlimit von „1.000“ für die Einstellung cluster.max_shards\ _per_node für OpenSearch Service Versionen 7.x und höher. Es hat sich bewährt, die Einstellung cluster.max_shards_per_node auf dem Standardwert „1000" zu belassen. Wenn Sie Shard-Zuweisungsfilter einrichten, um zu kontrollieren, wie OpenSearch Service Shards zuweist, kann die Zuweisung des Shard aufgehoben werden, weil nicht genügend gefilterte Knoten vorhanden sind. Um diesen Knotenmangel zu verhindern, erhöhen Sie die Anzahl Ihrer Knoten. Stellen Sie sicher, dass die Anzahl der Replikate für jeden primären Shard geringer ist als die Anzahl der Datenknoten. Sie können auch die Anzahl der Replikat-Shards reduzieren. Weitere Informationen finden Sie unter Größe von OpenSearch Service-Domänen und Entmystifizierung der OpenSearch Service-Shard-Zuweisung.

Niedriger Festplattenspeicher oder Festplattenversatz

Wenn nicht genügend Festplattenspeicher zur Verfügung steht, kann Ihr Cluster einen roten oder gelben Integritätsstatus annehmen. Es muss genügend Speicherplatz für Shards vorhanden sein, bevor OpenSearch Service die Shards verteilt.

Verwenden Sie die folgende Syntax, um zu überprüfen, wie viel Speicherplatz für jeden Knoten in Ihrem Cluster verfügbar ist:

$ curl domain-endpoint/_cat/allocation?v

Weitere Informationen zu Speicherplatzproblemen finden Sie unter Wie behebe ich geringen Speicherplatz in meiner OpenSearch Service-Domain?

Ein starker Festplattenversatz kann bei einigen Datenknoten auch zu Problemen mit wenig Speicherplatz führen. Wenn Sie beschließen, Shards neu zuzuweisen, kann es sein, dass die Zuordnung der Shards während der Shard-Verteilung aufgehoben wird. Informationen zur Behebung dieses Problems finden Sie unter Wie stelle ich die ungleichmäßige Shard-Verteilung in meinem OpenSearch Service-Cluster wieder her?

Die festplattenbasierten Shard-Zuweisungseinstellungen können auch dazu führen, dass Shards nicht zugewiesen werden. Wenn die Metrik cluster.routing.allocation.disk.watermark.low beispielsweise auf 50 GB festgelegt ist, muss die angegebene Menge an Festplattenspeicher für die Shard-Zuweisung verfügbar sein.

Verwenden Sie die folgende Syntax, um die aktuellen Einstellungen für die festplattenbasierte Shard-Zuweisung zu überprüfen:

$ curl -XGET domain-endpoint/_cluster/settings?include_defaults=true&flat_settings=true

Um Ihre Speicherplatzprobleme zu lösen, sollten Sie die folgenden Ansätze in Betracht ziehen:

• Löschen Sie alle unerwünschten Indizes für gelbe und rote Cluster.
• Rote Indizes für rote Cluster löschen
• Erhöhen Sie die EBS-Lautstärke.
• Fügen Sie weitere Datenknoten hinzu.

Hinweis: Vermeiden Sie es, Konfigurationsänderungen an Ihrem Cluster vorzunehmen, wenn dieser einen roten Integritätsstatus aufweist. Wenn Sie versuchen, Ihre Domain neu zu konfigurieren, obwohl sie sich in einem roten Clusterstatus befindet, könnte sie im Status „In Bearbeitung“ stecken bleiben.

Hoher JVM-Speicherdruck

Jede Shard-Zuweisung verwendet CPU, Heap-Speicherplatz sowie Festplatten- und Netzwerkressourcen. Konstant hoher JVM-Speicherdruck kann zu einer fehlgeschlagenen Shard-Zuweisung führen. Wenn der JVM-Speicherdruck beispielsweise 95% übersteigt, wird ein übergeordneter Schutzschalter des Speichers ausgelöst. Der Zuweisungs-Thread wird dann storniert, sodass Shards nicht zugewiesen werden.

Um dieses Problem zu beheben, reduzieren Sie zunächst den JVM-Speicherdruck. Nachdem die Belastung Ihres JVM-Speichers reduziert wurde, sollten Sie die folgenden zusätzlichen Tipps beachten, um Ihren Cluster wieder in einen grünen Zustand zu versetzen:

• Erhöhen Sie den Standardwert für die Wiederholung von Shards von „5“ oder höher.
• Deaktiviere und aktiviere den Replica-Shard.
• Versuchen Sie es manuell erneut mit den nicht zugewiesenen Shards.

Beispiel-API zur Erhöhung des Wiederholungswerts:

PUT <index-name>/_settings
{
 "index.allocation.max_retries" : <value>
}

Weitere Informationen zur Reduzierung Ihres JVM-Speicherdrucks finden Sie unter Wie behebe ich einen hohen JVM-Speicherdruck in meinem OpenSearch Service-Cluster?

Ausfall des Knotens

Wenn in Ihrem Cluster ein Knotenausfall auftritt, wird die Zuweisung von Shards, die einem Knoten zugewiesen sind, aufgehoben. Wenn für einen bestimmten Index keine Replikat-Shards verfügbar sind, kann selbst ein Ausfall eines einzelnen Knotens zu einem roten Integritätsstatus führen. Zwei Replikat-Shards und eine Multi-AZ-Bereitstellung schützen Ihren Cluster vor Datenverlust bei einem Hardwareausfall.

Wenn all Ihre Indizes über einen Replikat-Shard verfügen, kann ein Ausfall eines einzelnen Knotens dazu führen, dass Ihr Cluster vorübergehend in einen gelben Integritätsstatus wechselt. Wenn Ihr Cluster vorübergehend einen gelben Integritätsstatus annimmt, wird OpenSearch Service automatisch wiederhergestellt, sobald der Knoten wieder fehlerfrei ist. Oder der OpenSearch Service wird wiederhergestellt, wenn Shards einem neuen Knoten zugewiesen werden.

Sie können Knotenausfälle bestätigen, indem Sie Ihre Amazon CloudWatch-Metriken überprüfen. Weitere Informationen zur Identifizierung eines Knotenausfalls finden Sie unter Ausgefallene Clusterknoten.

Hinweis: Es empfiehlt sich auch, jedem Index einen Replikat-Shard zuzuweisen oder dedizierte primäre Knoten zu verwenden und die Zonenerkennung zu aktivieren. Weitere Informationen findest du auf der Elasticsearch-Website unter Umgang mit Fehlern.

Die maximale Anzahl von Wiederholungsversuchen wurde überschritten

In OpenSearch Service darf Ihr Cluster das maximale Zeitlimit (5.000 ms) oder die Anzahl der Wiederholungsversuche (5) für die Shard-Zuweisung nicht überschreiten. Wenn Ihr Cluster die maximalen Schwellenwerte erreicht hat, müssen Sie manuell eine Shard-Zuweisung auslösen. Um manuell eine Shard-Zuweisung auszulösen, deaktivieren Sie die Replikat-Shards für Ihre Indizes und reaktivieren Sie sie erneut.

Eine Konfigurationsänderung in Ihrem Cluster kann auch die Shard-Zuweisung auslösen. Weitere Informationen zur Shard-Allokation findest du auf der Elasticsearch-Website unter Jeder Shard verdient ein Zuhause.

Hinweis: Es ist keine bewährte Methode, die Shard-Zuweisung manuell auszulösen, wenn Ihr Cluster eine hohe Arbeitslast hat. Wenn Sie alle Ihre Replikate aus einem Index entfernen, darf sich der Index nur auf primäre Shards stützen. Wenn ein Knoten ausfällt, wechselt Ihr Cluster in einen roten Integritätsstatus, da die primären Shards nicht zugewiesen sind.

Um einen Replikat-Shard zu deaktivieren, aktualisieren Sie den Wert für number_of_replicas auf „0":

$ curl -XPUT 'domain-endpoint/<indexname>/_settings' -H 'Content-Type: application/json' -d'
{
     "index" : {
          "number_of_replicas" : 0
     }
}

Stellen Sie außerdem sicher, dass die Einstellung index.auto_expand_replicas auf „false“ gesetzt ist. Wenn Ihr Cluster wieder in einen grünen Status zurückkehrt, können Sie den Wert index.number_of_replicas auf den gewünschten Wert zurücksetzen, um die Zuweisung von Replica-Shards auszulösen. Wenn die Shard-Zuweisung erfolgreich ist, wechselt Ihr Cluster in einen grünen Integritätsstatus.

Bewährte Verfahren zur Clustergesundheit

Beachten Sie die folgenden bewährten Methoden, um Ihren gelben oder roten Clusterstatus zu beheben:

• Legen Sie einen empfohlenen Amazon CloudWatch-Alarm für AutomatedSnapshotFailure fest. Mit dem Alarm können Sie sicherstellen, dass Sie über einen Snapshot verfügen, mit dem Sie Ihre Indizes wiederherstellen können, sobald Ihr Cluster in einen roten Status wechselt.
• Wenn Ihr Cluster einer anhaltend hohen Arbeitslast ausgesetzt ist, skalieren Sie Ihren Cluster. Weitere Informationen zur Skalierung Ihres Clusters finden Sie unter Wie kann ich eine OpenSearch Service-Domain skalieren?
• Überwachen Sie Ihre Festplattenauslastung, den JVM-Speicherdruck und die CPU-Auslastung und stellen Sie sicher, dass sie die festgelegten Schwellenwerte nicht überschreiten. Weitere Informationen finden Sie unter Empfohlene CloudWatch-Alarme und Cluster-Metriken.
• Stellen Sie sicher, dass alle primären Shards über Replikat-Shards verfügen, um sich vor Knotenausfällen zu schützen.

Weitere Informationen finden Sie unter Bewährte Methoden für den Betrieb von Amazon OpenSearch Service.