Amazon OpenSearch Service für Hochverfügbarkeit konfigurieren | Amazon Web Services

Amazon OpenSearch Service für Hochverfügbarkeit konfigurieren | Amazon Web Services

Quellknoten: 2691649

Amazon OpenSearch-Dienst ist eine vollständig Open-Source-Such- und Analysemaschine, die die sichere Suche, Überwachung und Analyse von Geschäfts- und Betriebsdaten in Echtzeit für Anwendungsfälle wie Empfehlungsmaschinen, E-Commerce-Websites und Katalogsuche ermöglicht. Um in Ihrem Unternehmen erfolgreich zu sein, müssen Ihre Systeme hochverfügbar und leistungsfähig sein, Ausfallzeiten minimieren und Ausfälle vermeiden. Wenn Sie OpenSearch Service als primäres Mittel zur Überwachung Ihrer Infrastruktur verwenden, müssen Sie auch dessen Verfügbarkeit sicherstellen. Ausfallzeiten für den OpenSearch-Dienst können erhebliche Auswirkungen auf Ihre Geschäftsergebnisse haben, z. B. Umsatzeinbußen, Produktivitätsverluste, Verlust des Markenwerts und mehr.

Das Industriestandard zur Messung der Verfügbarkeit ist eine Neunerklasse. OpenSearch Service bietet 3 9 Verfügbarkeiten, wenn Sie folgen Best Practices, was bedeutet, dass weniger als 43.83 Minuten Ausfallzeit pro Monat garantiert sind. In diesem Beitrag erfahren Sie, wie Sie Ihre OpenSearch Service-Domäne für hohe Verfügbarkeit und Leistung konfigurieren können, indem Sie beim Einrichten Ihrer Domäne Best Practices und Empfehlungen befolgen.

Es gibt zwei wesentliche Elemente, die die Verfügbarkeit Ihrer Domain beeinflussen: die Ressourcennutzung Ihrer Domain, die hauptsächlich von Ihrer Arbeitslast bestimmt wird, und externe Ereignisse wie Infrastrukturausfälle. Während Ersteres durch kontinuierliche Überwachung der Leistung und Gesundheit der Domäne und entsprechende Skalierung der Domäne kontrolliert werden kann, ist Letzteres nicht möglich. Um die Auswirkungen externer Ereignisse wie einem Ausfall der Availability Zone, eines Instanz- oder Festplattenausfalls oder Netzwerkproblemen in Ihrer Domäne abzumildern, müssen Sie zusätzliche Kapazität bereitstellen, die über mehrere Availability Zones verteilt ist, und mehrere Kopien der Daten aufbewahren. Andernfalls kann es zu Leistungseinbußen, Nichtverfügbarkeit und im schlimmsten Fall zu Datenverlust kommen.

Schauen wir uns die Optionen an, die Ihnen zur Verfügung stehen, um sicherzustellen, dass die Domain verfügbar und leistungsfähig ist.

Cluster-Konfiguration

In diesem Abschnitt werden wir über verschiedene Konfigurationsoptionen sprechen, die Sie für die ordnungsgemäße Einrichtung Ihres Clusters benötigen. Dazu gehört die Angabe der Anzahl der AZ für die Bereitstellung, die Einrichtung der Master- und Datenknoten sowie die Einrichtung von Indizes und Shards.

Multi-AZ-Bereitstellung

Datenknoten sind für die Verarbeitung von Indexierungs- und Suchanfragen in Ihrer Domain verantwortlich. Durch die Bereitstellung Ihrer Datenknoten über mehrere Availability Zones hinweg wird die Verfügbarkeit Ihrer Domain verbessert, indem redundante Datenspeicherung und -verarbeitung pro Zone hinzugefügt werden. Mit einer Multi-AZ-Bereitstellung kann Ihre Domain auch dann verfügbar bleiben, wenn eine vollständige Availability Zone nicht mehr verfügbar ist. Für Produktions-Workloads: AWS empfiehlt die Verwendung von drei Availability Zones für Ihre Domäne. Verwenden Sie zwei Availability Zones für Regionen, die nur zwei unterstützen, um die Verfügbarkeit zu verbessern. Dadurch wird sichergestellt, dass Ihre Domain im Falle eines Single-AZ-Ausfalls verfügbar ist.

Dedizierter Cluster-Manager (Masterknoten)

AWS empfiehlt die Verwendung von drei dedizierten Cluster-Manager-Knoten (CM). für alle Produktionsaufgaben. CM-Knoten verfolgen den Zustand des Clusters, den Status und Standort seiner Indizes und Shards, die Zuordnung für alle Indizes und die Verfügbarkeit seiner Datenknoten und verwalten eine Liste der in Bearbeitung befindlichen Aufgaben auf Clusterebene. Ohne dedizierte CM-Knoten verwendet der Cluster Datenknoten, was den Cluster anfällig für Arbeitslastanforderungen macht. Sie sollten die CM-Knoten anhand der Größe der Aufgabe dimensionieren – in erster Linie anhand der Anzahl der Datenknoten, der Indizes und der Shards. OpenSearch Service stellt CM-Knoten immer in drei Availability Zones bereit, wenn dies von der Region unterstützt wird (zwei in einer Availability Zone und einer in anderen Availability Zones, wenn Regionen nur zwei Availability Zones haben). Bei einer laufenden Domäne fungiert nur einer der drei CM-Knoten als gewählter Leiter. Die anderen beiden CM-Knoten nehmen an einer Wahl teil, wenn der gewählte CM-Knoten ausfällt.

Die folgende Tabelle zeigt die Empfehlungen von AWS zur CM-Größe. CM-Knoten funktionieren basierend auf der Anzahl der Knoten, Indizes, Shards und Zuordnungen. Je mehr Arbeit, desto mehr Rechenleistung und Arbeitsspeicher benötigen Sie, um den Clusterstatus zu halten und damit zu arbeiten.

Instanzanzahl RAM-Größe des Cluster-Manager-Knotens Maximal unterstützte Shard-Anzahl Empfohlener minimaler dedizierter Cluster-Manager-Instanztyp
1-10 8 GiB 10,000 m5.large.search oder m6g.large.search
11-30 16 GiB 30,000 c5.2xlarge.search oder c6g.2xlarge.search
31-75 32 GiB 40,000 c5.4xlarge.search oder c6g.4xlarge.search
76. - 125 64 GiB 75,000 r5.2xlarge.search oder r6g.2xlarge.search
126. - 200 128 GiB 75,000 r5.4xlarge.search oder r6g.4xlarge.search

Indizes und Shards

Indizes sind ein logisches Konstrukt, das eine Sammlung von Dokumenten enthält. Sie partitionieren Ihren Index für die Parallelverarbeitung, indem Sie eine primäre Shard-Anzahl angeben, wobei Shards eine physische Einheit zum Speichern und Verarbeiten von Daten darstellen. Im OpenSearch Service kann ein Shard entweder ein primärer Shard oder ein Replikat-Shard sein. Sie verwenden Replikate aus Gründen der Haltbarkeit – wenn der primäre Shard verloren geht, stuft OpenSearch Service eines der Replikate zum primären Shard hoch – und zur Verbesserung des Suchdurchsatzes. OpenSearch Service stellt sicher, dass die primären und Replikat-Shards auf verschiedenen Knoten und in verschiedenen Availability Zones platziert werden, wenn sie in mehr als einer Availability Zone bereitgestellt werden. Für eine hohe Verfügbarkeit empfiehlt AWS die Konfiguration von mindestens zwei Replikaten für jeden Index in einem Drei-Zonen-Setup, um Leistungs- und Verfügbarkeitsunterbrechungen zu vermeiden. Wenn in einem Multi-AZ-Setup ein Knoten ausfällt oder im schlimmsten Fall eine Availability Zone ausfällt, verfügen Sie immer noch über eine Kopie der Daten.

Clusterüberwachung und -verwaltung

Wie bereits erwähnt, ist die Auswahl Ihrer Konfiguration auf der Grundlage von Best Practices nur die halbe Miete. Wir müssen außerdem die Ressourcennutzung und -leistung kontinuierlich überwachen, um festzustellen, ob die Domäne skaliert werden muss. Eine unzureichend bereitgestellte oder überausgelastete Domäne kann zu Leistungseinbußen und schließlich zur Nichtverfügbarkeit führen.

CPU-Auslastung

Sie nutzen die CPU in Ihrer Domäne, um Ihre Arbeitslast auszuführen. Als allgemeine Regel sollten Sie eine durchschnittliche CPU-Auslastung von 60 % für jeden Datenknoten anstreben, mit Spitzenwerten bei 80 % und kleine Spitzen bis 100 % tolerieren. Wenn Sie die Verfügbarkeit berücksichtigen und insbesondere die Nichtverfügbarkeit einer vollständigen Zone berücksichtigen, gibt es zwei Szenarios. Wenn Sie über zwei Verfügbarkeitszonen verfügen, verarbeitet jede Zone 50 % des Datenverkehrs. Wenn eine Zone nicht mehr verfügbar ist, übernimmt die andere Zone den gesamten Datenverkehr, wodurch sich die CPU-Auslastung verdoppelt. In diesem Fall müssen Sie in jeder Zone eine durchschnittliche CPU-Auslastung von etwa 30–40 % erreichen, um die Verfügbarkeit aufrechtzuerhalten. Wenn Sie drei Availability Zones betreiben, nimmt jede Zone 33 % des Datenverkehrs auf. Wenn eine Zone nicht mehr verfügbar ist, erhält jede andere Zone etwa 17 % Traffic. In diesem Fall sollten Sie eine durchschnittliche CPU-Auslastung von 50–60 % anstreben.

Speicherauslastung

OpenSearch Service unterstützt zwei Arten der Garbage Collection. Die erste ist die G1 Garbage Collection (G1GC), die von OpenSearch Service-Knoten verwendet wird, powered by AWS Graviton 2. Der zweite ist Concurrent Mark Sweep (CMS), der von allen Knoten verwendet wird, die von anderen Prozessoren angetrieben werden. Vom gesamten einem Knoten zugewiesenen Speicher ist die Hälfte (bis zu 32 GB) dem Java-Heap zugewiesen, und der Rest des Speichers wird von anderen Betriebssystemaufgaben, dem Dateisystem-Cache usw. verwendet. Um die Verfügbarkeit einer Domäne aufrechtzuerhalten, empfehlen wir, die maximale JVM-Auslastung bei etwa 80 % in CMS und 95 % in G1GC zu halten. Alles, was darüber hinausgeht, würde sich auf die Verfügbarkeit Ihrer Domain auswirken und Ihren Cluster beeinträchtigen. Wir empfehlen außerdem, die automatische Optimierung zu aktivieren, die die Speichernutzung aktiv überwacht und den Garbage Collector auslöst.

Speicherauslastung

OpenSearch Service veröffentlicht mehrere Richtlinien für Größe von Domains. Damit Sie die richtige Speichermenge für Ihre Anforderungen ermitteln können, stellen wir Ihnen eine empirische Formel zur Verfügung. Es ist jedoch wichtig, die Speichererschöpfung im Laufe der Zeit und Änderungen der Arbeitslasteigenschaften im Auge zu behalten. Um sicherzustellen, dass der Domäne nicht der Speicherplatz ausgeht und sie weiterhin Daten indizieren kann, sollten Sie eine Konfiguration vornehmen Amazon CloudWatch Alarme und überwachen Sie Ihren freien Speicherplatz.

AWS empfiehlt außerdem die Auswahl einer primären Shard-Anzahl, damit jeder Shard innerhalb eines optimalen Größenbands liegt. Sie können die optimale Shard-Größe durch Proof-of-Concept-Tests mit Ihren Daten und Ihrem Datenverkehr ermitteln. Als Richtlinie verwenden wir Primär-Shard-Größen von 10–30 GB für Suchanwendungsfälle und 45–50 GB Primär-Shard-Größen für Protokollanalyse-Anwendungsfälle. Da Shards die Worker in Ihrer Domäne sind, sind sie direkt für die Verteilung der Arbeitslast auf die Datenknoten verantwortlich. Wenn Ihre Shards zu groß sind, kann es zu einer Belastung Ihres Java-Heaps durch große Aggregationen, schlechtere Abfrageleistung und schlechtere Leistung bei Aufgaben auf Clusterebene wie Shard-Neuverteilung, Snapshots und Hot-to-Warm-Migrationen kommen. Wenn Ihre Shards zu klein sind, können sie den Java-Heap-Speicher der Domäne überlasten, die Abfrageleistung durch übermäßige interne Vernetzung verschlechtern und Aufgaben auf Clusterebene verlangsamen. Wir empfehlen außerdem, die Anzahl der Shards pro Knoten proportional zum verfügbaren Heap zu halten (die Hälfte des RAM der Instanz bis zu 32 GB) – 25 Shards pro GB Java-Heap. Dies ergibt eine praktische Grenze von 1,000 Shards auf jedem Datenknoten in Ihrer Domäne.

Zusammenfassung

In diesem Beitrag haben Sie verschiedene Tipps und Tricks zum Einrichten einer hochverfügbaren Domäne mit OpenSearch Service kennengelernt, die Ihnen dabei hilft, die Leistung und Verfügbarkeit des OpenSearch Service aufrechtzuerhalten, indem Sie ihn über drei Availability Zones ausführen.

Seien Sie gespannt auf eine Reihe von Beiträgen, die sich auf die verschiedenen Features und Funktionalitäten von OpenSearch Service konzentrieren. Wenn Sie Feedback zu diesem Beitrag haben, senden Sie es im Kommentarbereich. Wenn Sie Fragen zu diesem Beitrag haben, starten Sie einen neuen Thread OpenSearch Service-Forum oder über Kontakt AWS-Support.


Über die Autoren

Rohin Bhargava ist Senior Product Manager im Amazon OpenSearch Service-Team. Seine Leidenschaft bei AWS ist es, Kunden dabei zu helfen, die richtige Mischung aus AWS-Services zu finden, um ihre Geschäftsziele zu erreichen.

Prashant Agrawal ist Senior Search Specialist Solutions Architect beim Amazon OpenSearch Service. Er arbeitet eng mit Kunden zusammen, um ihnen bei der Migration ihrer Workloads in die Cloud zu helfen, und hilft bestehenden Kunden bei der Feinabstimmung ihrer Cluster, um eine bessere Leistung zu erzielen und Kosten zu sparen. Bevor er zu AWS kam, half er verschiedenen Kunden, OpenSearch und Elasticsearch für ihre Such- und Protokollanalyse-Anwendungsfälle zu verwenden. Wenn er nicht arbeitet, reist er oft und erkundet neue Orte. Kurz gesagt, er macht gerne Eat → Travel → Repeat.

Zeitstempel:

Mehr von AWS Big Data