Wie erkenne und behebe ich Cluster-Zustandsprobleme mit zu vielen Shards?

Kurzbeschreibung

Jeder Shard verbraucht für die Wartung eine gewisse Menge an CPU/JVM-Ressourcen. Wenn du zu viele Shards hast, kann es zu einer erheblichen Verschlechterung der Cluster-Leistung kommen. In einigen Fällen, in denen zu viele Shards vorhanden sind, reagiert der gesamte Cluster möglicherweise nicht mehr.

Um sicherzustellen, dass die Cluster fehlerfrei sind und erwartungsgemäß funktionieren, befolge die bewährten Methoden von OpenSearch Service.

Symptome bei zu vielen Shards

Wenn der Cluster eines oder mehrere der folgenden Symptome aufweist, führe die Lösungsschritte durch. Um zu überprüfen, ob deine Domain von zu vielen Shards betroffen ist, überprüfe die Trends in den Zustandsmetriken des Clusters im Zeitablauf.

• Mehr als 1 000 Shards pro Knoten
• Indizes mit kleinen Shards von jeweils < 10 GB
• Konsistente Knotenausfälle
• Hohe JVM/CPU-Ressourcenmetriken
• Komplikationen bei Blau- und Grün-Bereitstellungen
• Der Cluster-Status ist für den gewählten Master äußerst schwierig zu handhaben.
• T-Instance-Typen werden verwendet. Oder es werden kleinere Instance-Typen verwendet. Beispielsweise wird der Instance-Typ c5.large verwendet.

Lösung

Deine Domain-Trends überprüfen

Verwende den Zeitraum von 3/6/12/14 Monaten, um die Amazon-CloudWatch-Metriken der Domain zu überprüfen. Wenn in regelmäßigen Abständen Shard-Erstellungen stattfinden, vergrößere das Zeitfenster des Graphen. Andernfalls wirst du nicht den vollständigen Verlauf des Zustandstrends sehen. Hinweis: Du musst den Zeitraum der Metrik auf 1 Stunde ändern, damit die Metriken in den längeren Zeiträumen ordnungsgemäß geladen werden.

Folgendes passiert in einer Domain mit zu vielen Shards:

• Die Anzahl von Shards.active steigt. Wenn die Anzahl der Shards insgesamt 1 000 Shards pro Knoten überschritten hat, ist die Integrität des Clusters gefährdet, wenn der Cluster einem erhöhten Datenverkehr ausgesetzt ist. Dieses Risiko steigt, wenn der Datenverkehr von Suchanfragen über die erhöhte Anzahl von Shards erfolgt.
• Knotenausfälle treten auf, wenn die Knoten-Metrik des Clusters in der Min/Max/Avg-Statistik keine durchgezogene Linie ist. Der OpenSearch-Service-Prozess kann auf den Knoten nicht ausgeführt werden, wenn die JVM-Speicherlimits erreicht sind. Anschließend startet der verwaltete Service den Prozess automatisch neu.
• JVMMemoryPressure steigt. Die Min/Avg/Max-Werte konvergieren, wenn G1 Garbage Collection (G1GC) häufiger und weniger effektiv wird. In einem idealen Zustand oszilliert diese Metrik zwischen 0 und 75 % in einem Sägezahnmuster. Wenn der JVMMemoryPressure bei einer Verschlechterung 75 % überschreitet und der durchschnittliche Wert von JVMMemoryPressure um 75 % ansteigt, treten die ersten Auswirkungen ein. Weitere Informationen zu JVM und Garbage Collection in OpenSearch Service findest du unter Grundlegendes zu Änderungen der JVMMemoryPressure-Metrik in Amazon OpenSearch Service. Weitere Informationen findest du unter Wie behebe ich einen hohen JVM-Speicherdruck in meinem OpenSearch-Service-Cluster?
• CPUUtilization steigt. Der Cluster verwendet mehr Ressourcen und Zeit für Garbage Collections der von ihm verwalteten Shards.

Probleme mit zu vielen Shards beheben

Wähle eine der folgenden Lösungsmethoden, um das Problem mit zu vielen Shards zu beheben:

Die Anzahl der Shards reduzieren

Es ist eine bewährte Methode von OpenSearch, die Anzahl der Shards pro Knoten auf der Grundlage des verfügbaren JVM-Heap-Speichers zu begrenzen. Stelle sicher, dass du nicht mehr als 20–25 Shards pro GiB JVM-Heap hast. Im verwalteten OpenSearch-Service hat der JVM-Heap eine Größenbeschränkung von 32 GiB. Dieses Limit bedeutet, dass du maximal 640–800 Shards pro Knoten haben kannst. Es gibt ein Limit von 1 000 Shards pro Knoten, das über die Cluster-Einstellungen geändert werden kann.

Wenn Daten nicht benötigt werden, entferne ältere Indizes. Erstelle manuelle Snapshots älterer Indexdaten, bevor du sie löschst.

Beachte Folgendes, wenn rotierende Indizes mit ISM verwendet werden:

• Prüfe, ob deine Shard-Strategie die Indizes in den bewährten Shard-Größenbereich (10–50 GB) einstuft. Nehmen wir zum Beispiel an, du verwendest tägliche ISM-Indizes und standardmäßig 5:1-Sharding. Diese Praxis führt zu 10 Shards pro Tag und bis zu 300 Shards pro Monat.
• Verwende eine Indexvorlage, um die Shard-Anzahl kleinerer Tagesindizes zu reduzieren. Weitere Informationen findest du unter Index templates (Indexvorlagen) auf der OpenSearch-Website. Beachte, dass sich dies nur auf neu erstellte Indizes im Cluster auswirkt und den Clusterzustand nicht sofort verbessert.
• Verwende die Reindexierungs-OpenSearch-API, um ältere tägliche und wöchentliche Indizes zu einem monatlichen Index zu kombinieren. Weitere Informationen findest du unter Combine one or more indexes (Ein oder mehrere Indizes kombinieren) auf der OpenSearch-Website. Ändere dann den Rotationszeitraum der ISM-Indizes, um zu vermeiden, dass zu kleine Indizes erstellt werden.

Skalieren der Instance

Beachte Folgendes:

• Ein Hochskalieren oder Aufskalieren ist auf lange Sicht keine praktikable Lösung. Befolge unbedingt die bewährten Methoden von OpenSearch Services.
• Wenn du den Instance-Typ hochskalierst, steigt die Anzahl der verfügbaren Ressourcen pro Knoten und die Gesamtzahl der Shards, die der Knoten verarbeiten kann.
• Wenn du die Anzahl der Datenknoten aufskalierst, verringert sich die Anzahl der Shards pro Knoten. Diese Verringerung mildert die Auswirkungen auf die anderen Knoten.

Ähnliche Informationen

Optimize OpenSearch index shard sizes (Optimieren von OpenSearch-Index-Shard-Größen) auf der OpenSearch-Website