Dimensionierung

Mithilfe der Größenbestimmung können Sie den richtigen Instance-Typ, die Anzahl der Datenknoten und die Speicheranforderungen für Ihre Zielumgebung ermitteln. Wir empfehlen, dass Sie die Größe zuerst nach dem Speicher und dann nach festlegen CPUs. Wenn du Elasticsearch oder bereits verwendest OpenSearch, bleibt die Größe im Allgemeinen gleich. Sie müssen jedoch den Instanztyp identifizieren, der Ihrer aktuellen Umgebung entspricht. Um die richtige Größe zu ermitteln, empfehlen wir die Verwendung der folgenden Richtlinien.

Speicher

Die Dimensionierung Ihres Clusters beginnt mit der Definition der Speicheranforderungen. Identifizieren Sie den Rohspeicher, den Sie für Ihren Cluster benötigen. Dies wird anhand der Daten ermittelt, die von Ihrem Quellsystem generiert wurden (z. B. Server, die Protokolle generieren, oder die Rohgröße des Produktkatalogs). Nachdem Sie ermittelt haben, wie viele Rohdaten Sie haben, verwenden Sie die folgende Formel, um den Speicherbedarf zu berechnen. Sie können das Ergebnis dann als Ausgangspunkt für Ihren PoC verwenden.

storage needed = (daily source data in bytes × 1.45) (number_of_replicas + 1) × number of days retained

Die Formel berücksichtigt Folgendes:

• Die Größe eines Indexes auf der Festplatte variiert, ist jedoch häufig um 10 Prozent größer als die Quelldaten.

• Der Betriebssystem-Overhead von 5 Prozent ist Linux für die Systemwiederherstellung und den Schutz vor Problemen mit der Festplattendefragmentierung vorbehalten.

• OpenSearch reserviert 20 Prozent des Speicherplatzes jeder Instanz für Segmentzusammenführungen, Protokolle und andere interne Operationen.

• Wir empfehlen, 10 Prozent zusätzlichen Speicherplatz vorzuhalten, um die Auswirkungen von Knotenausfällen und Ausfällen in der Availability Zone zu minimieren.

Zusammengenommen erfordern diese Gemeinkosten und Reservierungen 45 Prozent zusätzlichen Speicherplatz, basierend auf den tatsächlichen Rohdaten in der Quelle. Aus diesem Grund multiplizieren Sie die Quelldaten mit 1,45. Als Nächstes multiplizieren Sie dies mit der Anzahl der Datenkopien (z. B. eine Primärkopie plus der Anzahl der Replikate, die Sie verwenden werden). Die Anzahl der Replikate hängt von Ihren Anforderungen an Stabilität und Durchsatz ab. Für einen durchschnittlichen Anwendungsfall beginnen Sie mit einem primären und einem Replikat. Multiplizieren Sie abschließend mit der Anzahl der Tage, an denen Sie Daten auf einer Hot-Storage-Tier aufbewahren möchten.

Amazon OpenSearch Service bietet Warm-, Warm- und Kaltlagerstufen. Die Warm-Speicherstufe verwendet UltraWarm Speicher. UltraWarm bietet eine kostengünstige Möglichkeit, große Mengen schreibgeschützter Daten auf Amazon OpenSearch Service zu speichern. Standarddatenknoten verwenden Hot-Storage in Form von Instance-Speichern oder Amazon Elastic Block Store (Amazon EBS) -Volumes, die an jeden Knoten angehängt sind. Hot Storage bietet die schnellstmögliche Leistung für die Indizierung und Suche nach neuen Daten. UltraWarm Knoten verwenden Amazon Simple Storage Service (Amazon S3) als Speicher und als ausgeklügelte Caching-Lösung zur Verbesserung der Leistung. Für Indizes, in die Sie nicht aktiv schreiben oder die Sie seltener abfragen und die nicht dieselben Leistungsanforderungen haben, UltraWarm bietet dies deutlich niedrigere Kosten pro GiB an Daten. Weitere Informationen UltraWarm dazu finden Sie in der AWS-Dokumentation.

Wenn Sie eine OpenSearch Service-Domain erstellen und Hot-Storage verwenden, müssen Sie möglicherweise die EBS-Volume-Größe definieren. Das hängt von Ihrer Wahl des Instanztyps für die Datenknoten ab. Sie können dieselbe Formel für den Speicherbedarf verwenden, um die Volume-Größe für Amazon EBS-gestützte Instances zu bestimmen. Wir empfehlen die Verwendung von GP3-Volumes für T3-, R5-, R6G-, M5-, M5g-, C5- und C6g-Instance-Familien der neuesten Generation. Mithilfe von Amazon EBS-GP3-Volumes können Sie Leistung unabhängig von der Speicherkapazität bereitstellen. Amazon EBS-GP3-Volumes bieten auch eine bessere Basisleistung bei 9,6 Prozent niedrigeren Kosten pro GB als bestehende GP2-Volumes im Service. OpenSearch Mit gp3 erhalten Sie außerdem mehr Speicherplatz in den Instance-Familien R5, R6g, M5 und M6g, was Ihnen helfen kann, Ihre Kosten weiter zu optimieren. Sie können EBS-Volumes bis zum unterstützten Kontingent erstellen. Weitere Informationen zu Kontingenten finden Sie unter Amazon OpenSearch Service-Kontingente.

Für Datenknoten mit NVM Express (NVMe) -Laufwerken, wie z. B. i3- und r6gd-Instances, ist die Volume-Größe festgelegt, sodass EBS-Volumes keine Option sind.

Anzahl der Knoten und Instanztypen

Die Anzahl der Knoten basiert auf der Anzahl der Knoten, die für den Betrieb Ihres Workloads CPUs erforderlich sind. Die Anzahl von CPUs basiert auf der Anzahl der Shards. Ein Index in OpenSearch besteht aus mehreren Shards. Wenn Sie einen Index erstellen, geben Sie die Anzahl der Shards für den Index an. Daher müssen Sie Folgendes tun:

1. Berechnen Sie die Gesamtzahl der Shards, die Sie in der Domain speichern möchten.

2. Ermitteln Sie die CPU.

3. Finden Sie den kostengünstigsten Knotentyp und die Anzahl, die Ihnen die erforderliche Anzahl von CPUs und Speicherplatz bietet.

Dies ist normalerweise ein Ausgangspunkt. Führen Sie Tests durch, um festzustellen, ob die geschätzte Größe Ihren funktionalen und nichtfunktionalen Anforderungen entspricht.

Festlegung der Indexierungsstrategie und der Anzahl der Shards

Nachdem Sie die Speicheranforderungen kennen, können Sie entscheiden, wie viele Indizes Sie benötigen, und die Anzahl der Shards für jeden Index ermitteln. Im Allgemeinen verfügen Suchanwendungsfälle über einen oder mehrere Indizes, von denen jeder eine durchsuchbare Entität oder einen Katalog darstellt. Für Anwendungsfälle mit Protokollanalysen kann ein Index eine tägliche oder wöchentliche Protokolldatei darstellen. Nachdem Sie die Anzahl der Indizes festgelegt haben, beginnen Sie mit der folgenden Skalierung und legen Sie die entsprechende Anzahl der Shards fest:

• Anwendungsfälle für die Suche — 10—30 GB/Shard

• Anwendungsfälle für Protokollanalysen — 50 GB/Shard

Sie können das Gesamtvolumen der Daten in einem einzelnen Index durch die Shard-Größe teilen, die Sie in Ihrem Anwendungsfall anstreben. Dadurch erhalten Sie die Anzahl der Shards für den Index. Wenn Sie die Gesamtzahl der Shards ermitteln, können Sie die richtigen Instance-Typen finden, die zu Ihrer Arbeitslast passen. Die Shards sollten nicht zu groß oder zu zahlreich sein. Große Shards können die Wiederherstellung OpenSearch nach einem Ausfall erschweren. Da jedoch jeder Shard eine gewisse Menge an CPU und Arbeitsspeicher beansprucht, können zu viele kleine Shards zu Leistungsproblemen und Fehlern führen. out-of-memory Darüber hinaus kann ein Ungleichgewicht bei der Zuweisung von Shards zu Datenknoten zu Verzerrungen führen. Wenn Sie Indizes mit mehreren Shards haben, versuchen Sie, die Anzahl der Shards auf ein gerades Vielfaches der Anzahl der Datenknoten einzustellen. Dies sorgt dafür, dass Shards gleichmäßig über Datenknoten verteilt sind, und verhindert heiße Knoten. Wenn Sie beispielsweise 12 primäre Shards haben, sollte Ihre Datenknotenanzahl 2, 3, 4, 6 oder 12 betragen. Die Shard-Anzahl ist jedoch zweitrangig gegenüber der Shard-Größe; Wenn Sie über 5 GiB an Daten verfügen, sollten Sie dennoch einen einzelnen Shard verwenden. Eine gleichmäßige Verteilung der Anzahl der Replikat-Shards in der Availability Zone trägt ebenfalls zur Verbesserung der Ausfallsicherheit bei.

CPU-Auslastung

Im nächsten Schritt müssen Sie ermitteln, wie viele CPUs Sie für Ihren Workload benötigen. Wir empfehlen, mit einer CPU-Anzahl zu beginnen, die 1,5 mal so hoch ist wie die Anzahl Ihrer aktiven Shards. Ein aktiver Shard ist ein beliebiger Shard für einen Index, der umfangreiche Schreibvorgänge empfängt. Verwenden Sie die Anzahl der primären Shards, um die aktiven Shards für Indizes zu ermitteln, die umfangreiche Lese- oder Schreibanforderungen erhalten. Für Protokollanalysen ist in der Regel nur der aktuelle Index aktiv. Für Suchanwendungsfälle werden alle primären Shards als aktive Shards betrachtet. Wir empfehlen zwar 1,5 CPUs pro aktivem Shard, dies hängt jedoch stark von der Arbeitslast ab. Achten Sie darauf, die CPU-Auslastung zu testen und zu überwachen und entsprechend zu skalieren.

Eine bewährte Methode zur Aufrechterhaltung Ihrer CPU-Auslastung besteht darin, sicherzustellen, dass die OpenSearch Dienstdomäne über genügend Ressourcen verfügt, um ihre Aufgaben zu erfüllen. Ein Cluster mit konstant hoher CPU-Auslastung kann die Clusterstabilität beeinträchtigen. Wenn Ihr Cluster überlastet ist, blockiert OpenSearch Service eingehende Anfragen, was zu Ablehnungen von Anfragen führt. Dies dient dazu, die Domain vor einem Ausfall zu schützen. Die allgemeinen Richtlinien für die CPU-Auslastung liegen bei durchschnittlich 60 Prozent und bei einer maximalen CPU-Auslastung von 80 Prozent. Gelegentliche Spitzenwerte von 100 Prozent sind immer noch akzeptabel und erfordern möglicherweise keine Skalierung oder Neukonfiguration.

Instance-Typen

Amazon OpenSearch Service bietet Ihnen die Wahl zwischen verschiedenen Instance-Typen. Sie können die Instance-Typen auswählen, die am besten zu Ihrem Anwendungsfall passen. Amazon OpenSearch Service unterstützt die Instance-Familien R, C, M, T und I. Sie wählen eine Instance-Familie basierend auf der Arbeitslast aus: speicheroptimiert, rechenoptimiert oder gemischt. Nachdem Sie eine Instance-Familie identifiziert haben, wählen Sie den Instance-Typ der neuesten Generation. Im Allgemeinen empfehlen wir Graviton und spätere Generationen, da sie darauf ausgelegt sind, im Vergleich zu Instances der vorherigen Generation eine verbesserte Leistung bei geringeren Kosten zu bieten.

Basierend auf verschiedenen Tests, die für Anwendungsfälle zur Protokollanalyse und Suche durchgeführt wurden, empfehlen wir Folgendes:

• Für Anwendungsfälle der Protokollanalyse besteht eine allgemeine Richtlinie darin, mit der R-Familie von Graviton-Instanzen für Datenknoten zu beginnen. Wir empfehlen Ihnen, Tests durchzuführen, Benchmarks für Ihre Anforderungen festzulegen und die passende Instance-Größe für Ihren Workload zu ermitteln.

• Für Suchanwendungsfälle empfehlen wir die Verwendung von Graviton-Instances der R- und C-Familie für Datenknoten, da Suchanwendungsfälle im Vergleich zu Log-Analytics-Anwendungsfällen mehr CPU erfordern. Für kleinere Workloads können Sie Graviton-Instances der M-Familie sowohl für die Suche als auch für Protokolle verwenden. Instances der I-Familie bieten NVMe Laufwerke und werden von Kunden mit schnellen Indizierungen und Suchanforderungen mit niedriger Latenz verwendet.

Der Cluster besteht aus Datenknoten und Cluster-Manager-Knoten. Obwohl dedizierte Master-Knoten keine Such- und Abfrageanfragen verarbeiten, korreliert ihre Größe stark mit der Instanzgröße und der Anzahl der Instanzen, Indizes und Shards, die sie verwalten können. Die AWS-Dokumentation enthält eine Matrix, in der der Mindesttyp einer dedizierten Cluster-Manager-Instanz empfohlen wird.

AWS bietet allgemeine (M6g), rechenoptimierte (C6g) und speicheroptimierte (R6g und R6gd) für Amazon OpenSearch Service Version 7.9 oder höher, die auf AWS Graviton2-Prozessoren basieren. Diese Instances werden mit kundenspezifischem Silizium erstellt, das von Amazon entworfen wurde. Es handelt sich um von Amazon entwickelte Hardware- und Softwareinnovationen, die die Bereitstellung effizienter, flexibler und sicherer Cloud-Dienste mit isolierter Mehrmandantenfähigkeit, privaten Netzwerken und schnellem lokalen Speicher ermöglichen.

Die Graviton2-Instance-Familie reduziert die Latenz bei der Indexierung um bis zu 50 Prozent und verbessert die Abfrageleistung um bis zu 30 Prozent im Vergleich zu den im OpenSearch Service verfügbaren Intel-basierten Instances der vorherigen Generation (M5, C5, R5).