Dimensionierung von Amazon OpenSearch Service-Domains

Es gibt keine perfekte Methode zur Dimensionierung von Amazon OpenSearch Service-Domains. Wenn Sie jedoch mit einem Verständnis Ihrer Speicheranforderungen, des Services und OpenSearch selbst beginnen, können Sie eine fundierte erste Schätzung Ihres Hardwarebedarfs vornehmen. Diese Schätzung kann als Ausgangspunkt für den wichtigsten Aspekt der Dimensionierung von Domains dienen: Tests mit repräsentativen Workloads und Überwachung ihrer Leistung.

Berechnung der Speicheranforderungen

Die meisten OpenSearch Workloads lassen sich in eine von zwei großen Kategorien einteilen:

• Langlebiger Index: Sie schreiben Code, der Daten in einem oder mehreren Indizes verarbeitet und diese OpenSearch Indizes dann regelmäßig aktualisiert, wenn sich die Quelldaten ändern. Einige allgemeine Beispiele sind Suchen auf Websites, in Dokumenten und für e-Commerce-Zwecke.

• Rolling-Indizes: Daten fließen kontinuierlich in einen Satz temporärer Indizes mit einem Indizierungszeitraum und einem Aufbewahrungsfenster (z. B. einen Satz täglicher Indizes, der zwei Wochen lang aufbewahrt wird). Einige allgemeine Beispiele sind Protokollanalyse, Zeitreihenverarbeitung und Clickstream-Analyse.

Für langlebige Index-Workloads können Sie die Quelldaten auf dem Datenträger untersuchen und einfach bestimmen, wie viel Speicherplatz dafür benötigt wird. Wenn die Daten aus mehreren Quellen stammen, addieren Sie diese Quellen einfach.

Für Rolling-Indizes können Sie die während eines repräsentativen Zeitraums generierten Datenmenge mit dem Aufbewahrungszeitraum multiplizieren. Wenn Sie beispielsweise 200 MiB Protokolldaten pro Stunde generieren, sind das 4,7 GiB pro Tag, also 66 GiB Daten zu jedem Zeitpunkt, wenn Sie einen Aufbewahrungszeitraum von zwei Wochen verwenden.

Die Größe Ihrer Datenquelle ist jedoch nur ein Aspekt Ihrer Speicheranforderungen. Außerdem müssen Sie Folgendes berücksichtigen:

• Anzahl der Replikate Jedes Replikat ist eine vollständige Kopie des primären Shards. Die Speichergröße des Indexes gibt die Größe an, die der Primär- und der Replikat-Shard einnehmen. Standardmäßig hat jeder OpenSearch Index ein Replikat. Wir empfehlen, mindestens eines zu verwenden, um sich gegen Datenverlust zu schützen. Replikate können auch die Suchleistung verbessern. Wenn Sie einen hohen Workload haben, können Sie in Betracht ziehen, mehrere zu erstellen. Verwenden Sie PUT /my-index/_settings, um die number_of_replicas-Einstellung für Ihren Index zu aktualisieren.

• OpenSearch Indizierungsaufwand: Die Größe eines Indexes auf der Festplatte variiert. Die Gesamtgröße der Quelldaten plus Index beträgt oft 110 % der Quelle, wobei der Index bis zu 10 % der Quelldaten ausmacht. Nachdem Sie Ihre Daten indexiert haben, können Sie den pri.store.size Wert _cat/indices?v API und verwenden, um den genauen Overhead zu berechnen. _cat/allocation?vbietet auch eine nützliche Zusammenfassung.

• Für das Betriebssystem reservierter Speicherplatz: Standardmäßig reserviert Linux 5 % des Dateisystems für den root-Benutzer für kritische Prozesse, zur Systemwiederherstellung und zum Schutz vor Problemen mit der Festplattenfragmentierung.

• OpenSearch Serviceaufwand: Der OpenSearch Service reserviert 20% des Speicherplatzes jeder Instanz (bis zu 20 GiB) für Segmentzusammenführungen, Protokolle und andere interne Operationen.

  Aufgrund dieses Höchstwerts von 20 GiB kann die Gesamtmenge an reserviertem Speicherplatz stark variieren und hängt von der Anzahl der Instances in Ihrer Domain ab. Beispiel: Eine Domain kann drei m6g.xlarge.search-Instances haben, mit jeweils 500 GiB Speicherplatz, also insgesamt 1,46 TiB. In diesem Fall beträgt der gesamte reservierte Speicherplatz nur 60 GiB. Eine andere Domain kann 10 m3.medium.search-Instances haben, mit jeweils 100 GiB Speicherplatz, also insgesamt 0,98 TiB. Hier beträgt der gesamte reservierte Speicherplatz 200 GiB, auch wenn die erste Domain 50 % größer ist.

  In der folgenden Formel wenden wir eine „Worst-Case“-Schätzung für den Zusatzaufwand an. Diese Schätzung beinhaltet zusätzlichen freien Speicherplatz, um die Auswirkungen von Knotenausfällen und Ausfällen der Availability Zone zu minimieren.

Wenn Sie insgesamt jederzeit 66 GiB Quelldaten haben und ein Replikat verwenden wollen, liegt Ihr minimaler Speicherbedarf nahe 66 * 2 * 1,1/0,95/0,8 = 191 GiB. Sie können diese Berechnung wie folgt verallgemeinern:

Quelldaten * (1 + Anzahl von Replikaten) * (1 + Indexierungsaufwand)/(1 — reservierter Linux-Speicherplatz)/(1 — OpenSearch Serviceaufwand) = Mindestspeicherbedarf

Sie können diese vereinfachte Version verwenden:

Quelldaten * (1 + Anzahl der Replikate) * 1,45 = Mindestspeicheranforderung

Unzureichender Speicherplatz ist eine der häufigsten Ursachen für Clusterinstabilität. Sie sollten also die Zahlen überprüfen, wenn Sie Instance-Typen, Instance-Anzahlen und Speicher-Volumes auswählen.

Es gibt weitere Überlegungen zum Speicher.

• Wenn Ihre Mindestspeicheranforderungen 1 PB überschreiten, lesen Sie nach unter Petabyte-Größe in Amazon OpenSearch Service.

• Wenn Sie Rolling-Indizes haben und eine Hot-Warm-Architektur verwenden wollen, lesen Sie UltraWarm Speicher für Amazon OpenSearch Service.

Auswahl der Anzahl der Shards

Nachdem Sie die Speicheranforderungen kennen, können Sie über Ihre Indizierungsstrategie nachdenken. Standardmäßig ist in OpenSearch Service jeder Index in fünf primäre Shards und ein Replikat (insgesamt 10 Shards) unterteilt. Dieses Verhalten unterscheidet sich von Open Source OpenSearch, bei dem standardmäßig ein primärer und ein Replikat-Shard verwendet werden. Da Sie die Anzahl der primären Shards für einen vorhandenen Index nicht leicht ändern können, sollten Sie die Anzahl der Shards festlegen, bevor Sie Ihr erstes Dokument indizieren.

Das übergeordnete Ziel bei der Auswahl der Shard-Anzahl ist es, einen Index gleichmäßig über alle Knoten im Cluster zu verteilen. Diese Shards sollten jedoch nicht zu groß oder zu zahlreich sein. Als allgemeine Richtlinie gilt, dass die Shard-Größe bei Workloads, bei denen die Suchlatenz ein wichtiges Leistungsziel ist, zwischen 10 und 30 GiB und bei schreibintensiven Workloads wie der Protokollanalyse zwischen 30 und 50 GiB liegen sollte.

Große Shards können die Wiederherstellung OpenSearch nach einem Ausfall erschweren. Da jedoch jede Shard eine gewisse Menge an Speicher beansprucht, können zu viele kleine Shards zu Leistungsproblemen CPU und Speicherproblemen führen. Mit anderen Worten, Shards sollten klein genug sein, dass die zugrunde liegende OpenSearch Service-Instanz sie verarbeiten kann, aber nicht so klein, dass sie die Hardware unnötig belasten.

Angenommen, Sie haben 66 GiB Daten. Sie gehen nicht davon aus, dass diese Anzahl mit der Zeit zunimmt, und Sie möchten Ihre Shards mit je 30 GiB beibehalten. Die Anzahl der Shards sollte deshalb ca. 66 * 1,1/30 = 3 betragen. Sie können diese Berechnung wie folgt verallgemeinern:

(Datenquelle + Wachstumspotenzial) * (1 + Indizierungsaufwand)/Gewünschte Shard-Größe = Ungefähre Anzahl der primären Shards

Diese Gleichung hilft Daten-Wachstum im Laufe der Zeit auszugleichen. Wenn Sie davon ausgehen, dass sich dieselben 66 GiB Daten innerhalb des nächsten Jahres vervierfachen, ist die ungefähre Anzahl der Shards (66 + 198) * 1,1 / 30 = 10. Beachten Sie jedoch, dass Sie diese zusätzlichen 198 GiB Daten noch nicht haben. Stellen Sie sicher, dass bei dieser Vorbereitung für die future nicht unnötig kleine Scherben entstehen, die in der CPU Gegenwart riesige Mengen an Speicherplatz verbrauchen. In diesem Fall sind 66 * 1,1/10 Shards = 7,26 GiB pro Shard, was zusätzliche Ressourcen verbraucht und unterhalb des empfohlenen Größenbereichs liegt. Sie könnten eher den middle-of-the-road Ansatz von sechs Shards in Betracht ziehen, sodass Sie heute 12-GiB-Shards und in future 48-GiB-Shards haben werden. Auch hier könnten Sie bevorzugen, mit drei Shards zu beginnen und Ihre Daten neu zu indizieren, wenn die Shards über 50 GiB zunehmen.

Ein weitaus weniger häufiges Problem ist die Begrenzung der Shard-Anzahl pro Knoten. Wenn Sie Ihre Shards entsprechend dimensionieren, geht Ihnen in der Regel schon lange vor Erreichen dieser Grenze der Datenträger-Speicherplatz aus. Beispielsweise verfügt eine m6g.large.search-Instance über eine maximale Datenträgergröße von 512 GiB. Wenn Sie unter 80 % der Datenträgernutzung bleiben und die Größe Ihrer Shards bei 20 GiB liegt, können ungefähr 20 Shards untergebracht werden. Elasticsearch 7. x und höher sowie alle Versionen von OpenSearch haben ein Limit von 1.000 Shards pro Knoten. Um die maximalen Shards pro Knoten anzupassen, konfigurieren Sie die cluster.max_shards_per_node-Einstellung. Ein Beispiel finden Sie unter Cluster-Einstellungen.

Durch eine angemessene Dimensionierung der Shards bleiben Sie fast immer unter dieser Grenze, Sie können jedoch auch die Anzahl der Shards pro GiB des Java-Heaps prüfen. Auf einem vorgegebenen Knoten sollten Sie nicht mehr als 25 Shards pro GB des Java-Heaps haben. Eine m5.large.search-Instance verfügt bspw. über einen 4-GiB-Heap, sodass jeder Knoten nicht mehr als 100 Shards haben sollte. Bei dieser Anzahl an Shards ist jeder Shard etwa 5 GiB groß, was weit unter unserer Empfehlung liegt.

Auswählen von Instance-Typen und Tests

Nachdem Sie Ihre Speicheranforderungen berechnet und die Anzahl der benötigten Shards ausgewählt haben, können Sie Hardware-Entscheidungen treffen. Hardware-Anforderungen variieren je nach Workload erheblich. Wir können jedoch einige grundlegende Empfehlungen bieten.

Im Allgemeinen entsprechen die Speicherlimits für jeden Instance-Typ der Menge CPU und dem Arbeitsspeicher, den Sie möglicherweise für geringe Workloads benötigen. Eine m6g.large.search Instance hat beispielsweise eine maximale EBS Volumegröße von 512 GiB, 2 CPU V-Kerne und 8 GiB Arbeitsspeicher. Wenn Ihr Cluster viele Shards hat, aufwändige Aggregationen ausführt, Dokumente häufig aktualisiert oder eine große Anzahl von Abfragen verarbeitet, sind diese Ressourcen möglicherweise für Ihre Anforderungen nicht ausreichend. Wenn Ihr Cluster in eine dieser Kategorien fällt, versuchen Sie, mit einer Konfiguration zu beginnen, die eher 2 CPU V-Cores und 8 GiB Arbeitsspeicher pro 100 GiB Ihres Speicherbedarfs entspricht.

Tipp

Eine Zusammenfassung der Hardwareressourcen, die jedem Instance-Typ zugewiesen sind, finden Sie unter Amazon OpenSearch Service-Preise.

Dennoch sind auch diese Ressourcen möglicherweise nicht ausreichend. Einige OpenSearch Benutzer berichten, dass sie ein Vielfaches dieser Ressourcen benötigen, um ihre Anforderungen zu erfüllen. Um die richtige Hardware für Ihre Workloads zu finden, müssen Sie eine fundierte erste Einschätzung vornehmen, mit repräsentativen Workloads testen, anpassen und erneut testen.

Schritt 1: Machen Sie einen ersten Schätzwert

Zu Beginn empfehlen wir mindestens drei Knoten, um mögliche OpenSearch Probleme zu vermeiden, wie z. B. einen Split-Brain-Status (wenn ein Kommunikationsausfall dazu führt, dass ein Cluster zwei Master-Knoten hat). Wenn Sie drei dedizierte Hauptknoten haben, empfehlen wir immer noch mindestens zwei Datenknoten für die Replikation.

Schritt 2: Berechnen Sie den Speicherbedarf pro Knoten

Wenn Sie eine Speicheranforderung von 184 GiB haben und die empfohlene Mindestanzahl von drei Knoten, verwenden Sie die Gleichung 184/3 = 61 GiB, um den Speicherplatz zu ermitteln, die jeder Knoten benötigt. In diesem Beispiel könnten Sie drei m6g.large.search Instances auswählen, von denen jede ein EBS 90-GiB-Speichervolumen verwendet, sodass Sie über ein Sicherheitsnetz und einen gewissen Spielraum für Wachstum im Laufe der Zeit verfügen. Diese Konfiguration bietet 6 CPU V-Kerne und 24 GiB Arbeitsspeicher, sodass sie für leichtere Workloads geeignet ist.

Als größer ausgelegtes Beispiel nehmen Sie etwa eine Speicheranforderung von 14 TiB (14.336 GiB) Speicher und einen hohen Workload an. In diesem Fall könnten Sie den Test mit 2 * 144 = 288 CPU V-Kernen und 8 * 144 = 1152 GiB Arbeitsspeicher beginnen. Diese Zahlen funktionieren für etwa 18 i3.4xlarge.search-Instances. Wenn Sie den schnellen, lokalen Speicher nicht benötigen, können Sie auch 18 r6g.4xlarge.search Instances testen, die jeweils ein EBS 1-TiB-Speichervolume verwenden.

Informationen zu Clustern mit Hunderten von Terabytes an Daten finden Sie unter Petabyte-Größe in Amazon OpenSearch Service.

Schritt 3: Führen Sie repräsentative Tests durch

Nach der Konfiguration des Clusters können Sie Ihre Indizes anhand der zuvor berechneten Anzahl von Shards hinzufügen, einige repräsentative Client-Tests anhand eines realistischen Datensatzes durchführen und CloudWatch Metriken überwachen, um zu sehen, wie der Cluster mit der Arbeitslast umgeht.

Schritt 4: Erfolg oder Iterieren

Wenn die Leistung Ihren Anforderungen entspricht, die Tests erfolgreich sind und die CloudWatch Metriken normal sind, ist der Cluster einsatzbereit. Denken Sie daran, CloudWatch Alarme einzurichten, um eine ungesunde Ressourcennutzung zu erkennen.

Wenn die Leistung nicht akzeptabel ist, Tests fehlschlagen oder CPUUtilization oder JVMMemoryPressure hoch sind, müssen Sie möglicherweise einen anderen Instance-Typ wählen (oder Instances hinzufügen) und die Tests fortsetzen. Wenn Sie Instances hinzufügen, OpenSearch wird die Verteilung der Shards im Cluster automatisch ausgeglichen.

Da es einfacher ist, die überschüssige Kapazität in einem überlasteten Cluster als das Defizit in einem zu wenig ausgelasteten Cluster zu messen, empfehlen wir, mit einem Cluster zu beginnen, der größer ist als der, den Sie wahrscheinlich benötigen werden. Testen und skalieren Sie anschließend abwärts zu einem effizienten Cluster, der über die zusätzlichen Ressourcen verfügt, um einen stabilen Betrieb in Zeiten erhöhter Aktivität sicherzustellen.

Produktions-Cluster oder Cluster mit komplexen Zuständen profitieren von dedizierten Hauptknoten, die die Leistung und Cluster-Zuverlässigkeit verbessern.