Mit OpenSearch Clusterperformancegröße suchen

Bei der Skalierung und Bestimmung der Kapazität eines OpenSearch-Clusters müssen Kosten und Performance ausgeglichen werden. Mehrere Faktoren beeinflussen sowohl Performance- als auch Größenentscheidungen und machen es unerlässlich, Daten zu diesen Aspekten zu sammeln, um Ihren Kapazitätsplanungsprozess zu optimieren.

Sie können diese Faktoren in die folgenden Kategorien gruppieren: Anwendungsfallspezifische, datenbezogene und ressourcenbezogene Überlegungen.

• Anwendungsfallspezifisch: Diese Faktoren sind der beabsichtigte Zweck des OpenSearch-Deployments. Wird das Cluster beispielsweise für die Loganalyse oder -beobachtbarkeit verwendet, was in der Regel eine höhere Anzahl von Schreibvorgängen im Vergleich zu Lesevorgängen beinhaltet? Oder wird es für die Anwendungssuche verwendet, bei der Daten einmal geschrieben und oft gelesen werden? Oder soll das Cluster ressourcenintensive Workloads für maschinelles Lernen unterstützen? Wenn Sie Ihren Anwendungsfall verstehen, können Sie die erforderliche Lese- und Schreiblatenz und den erforderlichen Durchsatz, Abfragemuster und die zu optimierenden Abfragetypen wie Filter, Aggregationen oder einfache Suchen bestimmen.
• Datenbezogen: Dieser Faktor umfasst das zu speichernde Datenvolumen, den Datentyp (strukturiert oder unstrukturiert), die Dokumentgröße, die Kardinalität, Feldtypen und die Definition von Feldzuordnungen. Außerdem tragen der verwendete Komprimierungscodec sowie die Größe und Anzahl der Indizes, Shards und Replikate zur Gesamtgröße und Performance des Clusters bei.
• Ressourcenbezogen: Diese Faktoren beinhalten die Konfiguration und die Anzahl der Knoten im Cluster, einschließlich Cluster Manager-Knoten, Datenknoten und Dashboard-Knoten. Diese Ressourcen wirken sich direkt auf die Fähigkeit des Clusters aus, die definierte Workload zu verarbeiten und die beste Performance sicherzustellen.

Obwohl die Kapazitätsplanung zunächst überwältigend erscheinen kann, wird sie überschaubarer, wenn Sie experimentieren und Bedenken inkrementell ansprechen. Der Schlüssel besteht darin, mit einer ersten Schätzung zu beginnen, die auf bewährten Best Practices basiert, kontinuierlich zu bewerten, ob Ihre Key Performance Indicators (KPIs) erfüllt werden, und zu iterieren, bis Sie das ideale Gleichgewicht zwischen Kosten und Leistung erreichen. Die folgenden Schritte beschreiben den Kapazitätsplanungsprozess:

1. Schätzen Sie Speicheranforderungen.
2. Definieren Sie die Sharding-Strategie.
3. Schätzen Sie die Datenknotenkonfiguration.
4. Schätzen Sie die Cluster Manager-Knotenkonfiguration.
5. Schätzen Sie die Dashboard-Knotenkonfiguration.
6. Testen Sie das Cluster, und iterieren Sie.

In diesem Abschnitt können Sie die besprochenen Prinzipien auf eine realistische Übung zur Clustergröße anwenden. Angenommen, Sie haben einen Anwendungsfall für Loganalysen, in dem Sie Daten über mehrere Indizes in einem OpenSearch-Cluster mit einer Rate von 10 GB pro Tag aufnehmen. Ihr Ziel ist es, die Daten für maximal 90 Tage aufzubewahren, danach können Sie sie sicher verwerfen.

Die Datenaufnahme kann je nach Anwendungsfall entweder in Batches oder kontinuierlich erfolgen. In vielen Anwendungssuch- und Business-Intelligence-Szenarios werden Daten während Batchprozessen in Massen geladen und dann für verschiedene Vorgänge wie Filtern, Aggregation und Suche abgefragt. Diese Arten von Indizes gelten als langlebig, und ihre Speicheranforderungen können in der Regel durch die Analyse der Quelldaten geschätzt werden, die sich selten ändern.

Für andere Anwendungsfälle wie Loganalysen, Zeitreihenanalysen und die Überwachung von realen Benutzern werden Daten kontinuierlich in das Cluster aufgenommen, wobei Indizes nach Erreichen einer bestimmten Größe oder eines bestimmten Zeitschwellenwerts verschoben werden. Für diese Indextypen ist es wichtig, das Datenvolumen zu berechnen, das über einen bestimmten Zeitraum aufgenommen wurde, und dann mit dem erforderlichen Aufbewahrungszeitraum zu multiplizieren, um den Speicherbedarf abzuschätzen.

Neben dem gesamten Datenvolumen, das aufgenommen wird, beeinflussen mehrere andere Faktoren die erforderliche Speichermenge:

• Aufbewahrungszeitraum (r): Die Dauer, für die Daten im Cluster aufbewahrt werden, bestimmt die maximale Datenmenge, die zu einem bestimmten Zeitpunkt gespeichert wird. Mit dieser Abbildung können Sie die Kapazität des Clusters schätzen, um das Worst-Case-Szenario zu bewältigen, bei dem die größte Datenmenge vorhanden ist, und eine ideale Performance auch unter Spitzenspeicherbedingungen sicherstellen.
• Replikatanzahl (rc): Jedes Replikat ist eine exakte Kopie seines primären Shards und dient sowohl zu Zuverlässigkeits- als auch zu Performancezwecken. Um Datenverlust zu vermeiden, empfehlen wir, mindestens ein Replikat zu verwenden, das die Standardeinstellung für jeden Index ist. Wenn Ihr Anwendungsfall hohe Lese-Volumes umfasst, kann es sinnvoll sein, mehr als ein Replikat zu konfigurieren. Dadurch können mehrere Replikat-Shards nebenläufige Suchabfragen verarbeiten, wodurch die Last verteilt und die Abfrageperformance verbessert wird.
• Komprimierungsverhältnis (cr): Die auf dem Datenträger gespeicherten Daten sind nicht identisch mit dem aufgenommenen Raw-Daten-Volume. Stattdessen ist sie aufgrund der während des Indexierungsprozesses angewendeten Komprimierung normalerweise kleiner. OpenSearch unterstützt verschiedene Komprimierungscodecs, die jeweils einen anderen Kompromiss zwischen Komprimierungsverhältnis und Performance bieten. Sie können den am besten geeigneten Codec für Ihren Anwendungsfall während der Indexerstellung auswählen.

  Das erreichte Komprimierungsverhältnis hängt von mehreren Faktoren ab, darunter der Datentyp (strukturiert vs. unstrukturiert), die Anzahl der wiederholten oder leeren Feldwerte, die Datenkardinalität und die Gesamtgröße der Daten. Eine angemessene Startannahme für die Komprimierung liegt typischerweise zwischen 25% und 40%. Beispielsweise würden 10 GB Raw-Daten zwischen 6 GB (cr=1,67) und 7,5 GB (cr=1,33) auf der Festplatte belegen. Es ist jedoch wichtig, diese Annahme mit tatsächlichen Tests für Ihren spezifischen Anwendungsfall zu validieren.

• OpenSearch Indexierungs-Overhead (o1): OpenSearch verursacht bis zu 10% Speicher-Overhead für die Indexierung von Rohdaten. Nach der Indexierung können Sie die API /_cat/indices?v zusammen mit dem Wert pri.store.size verwenden, um den genauen Wert im Istwert zu berechnen.
• OpenSearch Service Overhead (o2): OpenSearch reserviert für Segmentzusammenführungen, Logs und andere interne Vorgänge bis zu 20% des Speicherplatzes auf jeder Instanz mit einem Maximum von 20 GB.
• Betriebssystem-Overhead (o3): Standardmäßig reserviert Linux 5% des Dateisystems für den Root-Benutzer, um sicherzustellen, dass kritische Systemprozesse wie Logging und temporäre Dateierstellung weiterhin funktionieren, wenn der Datenträger fast voll ist. Dieser reservierte Speicherplatz hilft auch bei der Systemwiederherstellung und verhindert die Datenträgerfragmentierung, sodass Betriebsunterbrechungen vermieden werden.
• Puffer zur Berücksichtigung der Fehlermarge (b): Es wird empfohlen, einen 5-10%-Puffer hinzuzufügen, um menschliche Fehler und zu optimistische Annahmen zu berücksichtigen, da die Shard-Anzahl nach der Definition eines Index nicht geändert werden kann. Sie können diesen Puffer später anpassen oder entfernen, wenn Sie die tatsächlichen Nutzungsdaten erfassen.
• Formula:

  Required Storage = Source Data * r * (1 + rc) * (1/cr) * (1 + o1) * (1/1-o2) * (1/1-o3) * (1+b)

  Die Anwendung dieser Formel auf die Beispielübung führt zu Folgendem:

  • Quelldaten = 10 GB pro Tag
  • r = 90, unter Berücksichtigung der Aufbewahrungsfrist von 90 Tagen
  • rc = 1, wenn man bedenkt, dass wir 1 Replikat wollen
  • cr = 1,33, wenn man bedenkt, dass wir ein Kompressionsverhältnis von 25% erreichen
  • o1 = 0,1 (10% Indizierungs-Overhead)
  • o2 = 0,2 (20% Service-Overhead)
  • o3 = 0,05 (5% Overhead des Betriebssystems)
  • b = 0,1 (10% Fehlerpuffer)
  • Erforderlicher Speicher = 10 * 90 * 2 * 0,75 * 1,1 * 1/0,8 * 1/0,95 * 1,1 = 2150 GB = 2,2 TB (gerundet)

Nachdem Sie Ihre Speicheranforderungen festgelegt haben, besteht der nächste Schritt darin, Ihre Sharding-Strategie zu definieren. Dazu gehört die Bestimmung der Größe, Anzahl und Verteilung Ihrer Shards. OpenSearch-Shards sind unabhängige Partitionen Ihrer Indexdaten, die darauf ausgelegt sind, Daten auf Clusterknoten zu verteilen, um eine hohe Performance und Fehlertoleranz sicherzustellen.

Es gibt zwei Arten von Shards: Primär- und Replikat. Ein primärer Shard ist die autoritative Kopie einer Datenpartition und verarbeitet Lese- und Schreibvorgänge. Im Gegensatz dazu ist ein Replikat-Shard eine exakte Kopie des primären Shards und wird ausschließlich für Lesevorgänge verwendet. Alle Schreibanforderungen werden zuerst an das primäre Shard weitergeleitet. Danach werden die Daten auf die Replikat-Shards repliziert.

OpenSearch weist sowohl Primär- als auch Replikat-Shards automatisch Knoten zu, um sicherzustellen, dass Primär-Shards so gleichmäßig wie möglich verteilt werden und dass Primär- und Replikat-Shards nicht auf demselben Knoten platziert werden. Beispiel: Ein Index mit drei primären und je einem Replikat-Shard ergibt sechs Shards insgesamt – drei primäre und drei Replikat-Shards. In dieser Konfiguration wird jede Schreibanforderung von zwei Shards (einem primären und einem Replikat) verarbeitet, während Leseanforderungen von einer beliebigen Kombination aus Primär- und Replikat-Shards verarbeitet werden können, was Redundanz und Load Balancing ermöglicht.

Nachdem Sie Ihre Speicheranforderungen festgelegt und die Größe und Anzahl der Shards festgelegt haben, können Sie Hardwareentscheidungen treffen. Während die Hardwareanforderungen je nach Workload variieren können, finden Sie hier einige allgemeine Empfehlungen.

Um die Clusterstabilität und -performance zu verbessern, empfehlen wir die Verwendung dedizierter Cluster Manager-Knoten. Diese Knoten entlasten kritische Verwaltungsaufgaben von den Datenknoten, sodass sie sich ausschließlich auf die Datenspeicherung und Abfrageverarbeitung konzentrieren können. Cluster Manager-Knoten speichern keine Daten und verarbeiten keine Datenuploadanforderungen. Stattdessen verwalten sie den Gesamtzustand und den Status des Clusters. Sie verfolgen alle Knoten im Cluster, überwachen die Anzahl der Indizes und überwachen die Shard-Verteilung für jeden Index.

Managerknoten verwalten Routinginformationen, aktualisieren den Clusterstatus bei Änderungen (z.B. Indizes erstellen oder Knoten hinzufügen/entfernen) und replizieren Statusaktualisierungen auf allen Knoten. Außerdem senden sie Taktüberwachungssignale, um den Zustand und die Verfügbarkeit von Datenknoten zu überwachen und sicherzustellen, dass das Cluster betriebsbereit bleibt.

Es wird empfohlen, mindestens drei Cluster Manager-Knoten zu verwenden, um eine optimale Zuverlässigkeit zu gewährleisten. Nur einen Managerknoten zu haben, ist riskant, da das Cluster bei einem Ausfall dieses Knotens nicht mehr verfügbar sein könnte. Außerdem ist die Verwendung einer geraden Anzahl von Managerknoten nicht ideal, da sie verhindert, dass das Cluster das erforderliche Quorum bildet, um im Fehlerfall einen neuen Manager zu wählen. Drei Managerknoten stellen bei einem Ausfall zwei Backupknoten bereit und stellen ein Quorum für die Auswahl eines neuen Managers sicher.

Die Erhöhung der Anzahl der Manager-Knoten in ungeraden Schritten (5, 7 usw.) kann die Fehlertoleranz erhöhen, sodass das Cluster mehr Manager-Knotenausfällen standhalten kann, während es betriebsbereit bleibt. Das Hinzufügen von mehr als drei Manager-Knoten ist jedoch übertrieben und sollte nur für außergewöhnlich große Cluster oder spezielle Anwendungsfälle nach eingehender Analyse berücksichtigt werden.

Obwohl dedizierte Cluster Manager-Knoten Such- und Abfrageanforderungen nicht verarbeiten, sind ihre Ressourcenanforderungen eng an die Anzahl der Datenknoten, Indizes und Shards gebunden, die sie verwalten müssen. Die folgende Richtlinie kann als Ausgangspunkt dienen:

• 4 vCPU und 8 GB Arbeitsspeicher: Bis zu 16
• 8 vCPU und 16 GB Arbeitsspeicher: Von 17 bis 32
• 8 vCPU und 32 GB Arbeitsspeicher: Von 33–64
• 16 vCPU und 64 GB Arbeitsspeicher: Von 65 bis 128

Da wir fünf Datenknoten haben, können wir mit drei Cluster Manager-Knoten beginnen, die jeweils 4 vCPU und 8 GB Arbeitsspeicher haben.

Dashboard-Knoten sind der einfachste Knotentyp, da sie Daten nicht direkt lokal indexieren oder durchsuchen und minimale Speicheranforderungen haben. Diese Knoten fungieren hauptsächlich als API-Server, stellen Anforderungen an das Cluster aus und verarbeiten Daten-I/O. Die wichtigsten Ressourcen, die für Dashboard-Knoten erforderlich sind, sind CPU und Speicher, die von der Anzahl der gleichzeitigen Dashboard-Anforderungen abhängen.

Obwohl es üblich ist, einen einzelnen Dashboard-Knoten in kleineren oder sogar Produktionsclustern zu verwenden, empfehlen wir für die High Availability-(HA-)Dashboardanwendung OpenSearch, mindestens zwei Knoten zu verwenden. Ein guter Ausgangspunkt ist, je nach Ihren HA-Anforderungen einen oder zwei Dashboard-Knoten bereitzustellen. Weisen Sie bei Szenarios mit niedrigem Durchsatz 4 vCPUs und 8 GB Arbeitsspeicher pro Knoten zu. Bei Szenarios mit hohem Durchsatz weisen Sie 8 vCPUs und 16 GB Arbeitsspeicher pro Knoten zu. Überwachen Sie nach dem Deployment die CPU-Auslastung und den JVM-Druck, um Ressourcen basierend auf der tatsächlichen Performance zu optimieren.

Da Ihre Loganalyseanwendung hauptsächlich von einer begrenzten Anzahl von Experten für Ursachenanalyse, Debugging und gelegentliche Überprüfung und Berichterstellung verwendet wird, können Sie mit einem einzelnen Dashboard-Knoten beginnen, der 8 vCPUs und 16 GB Arbeitsspeicher enthält. Anschließend können Sie die Ressourcen anpassen (entweder vertikal oder horizontal skalieren) basierend auf Nutzungsmustern und der Performance dieser anfänglichen Konfiguration.

Führen Sie die folgenden Tests aus, und passen Sie die Konfiguration nach Bedarf an:

• Produktionsähnliche Testdaten verwenden: Stellen Sie sicher, dass Ihre Testdaten die Produktionsdaten, die in das Cluster aufgenommen werden, genau widerspiegeln. Dazu gehört der Abgleich der Struktur von Dokumenten (Felder, Datentypen usw.) und ihrer Größe mit dem, was in der Produktion verwendet wird.
• Real-World Load simulieren: Führen Sie Leistungstests unter realen Bedingungen durch. Erstellen Sie zunächst ein kleines Cluster, das die erwartete Last simuliert, und extrapolieren Sie dann die Ergebnisse, um die Performance größerer Cluster zu schätzen. Ihre Testdaten sollten ein beträchtliches Volumen (in GB) aufweisen, um die Last genau widerzuspiegeln.
• Schlüsselmetriken überwachen und analysieren: Überwachen Sie kontinuierlich kritische Metriken wie CPU-Auslastung, JVM-Druck, Datenträgernutzung, Such- und Indexierungslatenz, Such- und Indexierungsraten und allgemeine Verfügbarkeit. Passen Sie die Clusterkonfiguration nach Bedarf an, um die gewünschten KPIs zu erfüllen.
• Kontinuierliches Monitoring in der Produktion: Eine kontinuierliche Überwachung Ihres Produktionsclusters ist unerlässlich. Prüfen Sie diese KPIs regelmäßig, und ergreifen Sie Korrekturmaßnahmen, wenn die Performance von den erwarteten Schwellenwerten abweicht. Sich nur auf einmalige Tests zu verlassen, bevor Sie live gehen, reicht nicht aus. Kontinuierliche Validierung ist entscheidend für die Aufrechterhaltung der besten Performance.

Für die Skalierung eines OpenSearch-Clusters ist ein durchdachter Ansatz erforderlich, der Performance und Kosten ausgleicht, Faktoren wie Anwendungsfall, Datenvolumen und Ressourcenzuweisung berücksichtigt. Dieses Thema enthält wichtige Anleitungen, Best Practices und Daumenregeln für den Einstieg in die Kapazitätsplanung. Durch die Befolgung eines strukturierten Prozesses und die Iteration basierend auf Leistungstests können Sie sicherstellen, dass Ihr Cluster sowohl für Effizienz als auch Skalierbarkeit optimiert ist. Regelmäßige Überwachung und Änderungen als Reaktion auf reale Belastungen sind für die Aufrechterhaltung der Spitzenleistung unerlässlich. Die optimale Clusterkonfiguration entwickelt sich weiter, wenn Sie Erkenntnisse aus Ihren spezifischen Workload- und Nutzungsmustern gewinnen.