Dedizierte Masterknoten in Amazon OpenSearch Service - OpenSearch Amazon-Dienst

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Dedizierte Masterknoten in Amazon OpenSearch Service

Amazon OpenSearch Service verwendet dedizierte Master-Knoten, um die Cluster-Stabilität zu erhöhen. Ein dedizierter Hauptknoten führt Cluster-Verwaltungsaufgaben aus, jedoch keine Daten hält oder auf Daten-Upload-Anforderungen reagiert. Diese Auslagerung von Cluster-Verwaltungsaufgaben erhöht die Stabilität Ihrer Domain. Wie bei allen anderen Knotentypen zahlen Sie einen Stundensatz für jeden dedizierten Hauptknoten.

Dedizierte Hauptknoten führten die folgenden Cluster-Verwaltungsaufgaben aus:

  • Nachverfolgung aller Knoten im Cluster

  • Nachverfolgung der Indexanzahl im Cluster

  • Nachverfolgung der Anzahl der Shards, die zu jedem Index gehören

  • Pflege der Routing-Informationen für Knoten im Cluster

  • Aktualisierung des Cluster-Status nach Statusänderungen, z. B. dem Erstellen eines Index und dem Hinzufügen oder Entfernen von Knoten im Cluster

  • Replikation von Änderungen am Cluster-Status über alle Knoten im Cluster hinweg

  • Überwachung der Integrität aller Cluster-Knoten, indem Funktionsmeldungen gesendet werden, also periodische Signale, die die Verfügbarkeit der Datenknoten im Cluster überwachen

Die folgende Abbildung zeigt eine OpenSearch Service-Domain mit 10 Instanzen. Sieben der Instances sind Datenknoten und drei sind dedizierte Hauptknoten. Nur einer der dedizierten Hauptknoten ist aktiv. Die beiden grauen dedizierte Hauptknoten sind als Sicherung vorgesehen, falls der aktive dedizierte Hauptknoten ausfällt. Alle Daten-Upload-Anforderungen werden von den sieben Datenknoten bedient und alle Cluster-Verwaltungsaufgaben werden vom aktiven dedizierten Hauptknoten übernommen.

Anzahl der dedizierten Hauptknoten auswählen

Wir empfehlen, Multi-AZ mit Standby zu verwenden, wodurch jeder OpenSearch Produktions-Servicedomäne drei dedizierte Masterknoten hinzugefügt werden. Wenn Sie mit Multi-AZ ohne Standby oder Single-AZ bereitstellen, empfehlen wir dennoch drei dedizierte Masterknoten. Wählen Sie niemals eine gerade Anzahl an dedizierten Hauptknoten. Berücksichtigen Sie bei der Auswahl der Anzahl dedizierter Hauptknoten Folgendes:

  • Ein dedizierter Master-Knoten ist vom OpenSearch Service ausdrücklich verboten, da Sie für den Fall eines Fehlers kein Backup haben. Sie erhalten eine Validierungsausnahme, wenn Sie versuchen, eine Domain mit nur einem dedizierten Hauptknoten zu erstellen.

  • Wenn Sie zwei dedizierte Hauptknoten haben, verfügt Ihr Cluster nicht über das erforderliche Knoten-Quorum für die Wahl eines neuen Hauptknotens bei einem Ausfall.

    Ein Quorum ist die Anzahl der dedizierten Hauptknoten / 2 + 1 (abgerundet auf die nächste ganze Zahl). In diesem Fall: 2/2 + 1 = 2. Da ein dedizierter Hauptknoten ausgefallen ist und nur ein Backup vorhanden ist, verfügt der Cluster nicht über ein Quorum und kann keinen neuen Hauptknoten wählen.

  • Drei dedizierte Hauptknoten, die empfohlene Anzahl, bieten zwei Backup-Knoten für den Fall eines Hauptknotenausfalls, und das erforderliche Quorum (2) für die Wahl eines neuen Hauptknotens.

  • Vier dedizierte Hauptknoten bieten gegenüber dreien keine Vorteile und können Probleme verursachen, wenn Sie mehrere Availability Zones verwenden.

    • Wenn ein Hauptknoten ausfällt, haben Sie das Quorum (3), um einen neuen Hauptknoten zu wählen. Wenn zwei Knoten ausfallen, verlieren Sie dieses Quorum, genau wie bei drei dedizierten Hauptknoten.

    • In einer Konfiguration mit drei Availability Zonen verfügen zwei AZs über einen dedizierten Hauptknoten und eine AZ über zwei. Wenn diese AZ eine Störung hat, haben die verbleibenden beiden AZs nicht das erforderliche Quorum (3), um einen neuen Hauptknoten zu wählen.

  • Fünf dedizierte Hauptknoten funktionieren ebenso wie drei und ermöglichen Ihnen, zwei Knoten zu verlieren und ein Quorum zu behalten. Da jedoch nur ein dedizierter Hauptknoten zu einem bestimmten Zeitpunkt aktiv ist, bedeutet diese Konfiguration, dass vier Leerlaufknoten bezahlt werden müssen. Nach Ansicht vieler Kunden ist ein derartiger Failover-Schutz übertrieben.

Wenn ein Cluster über eine gerade Anzahl von Knoten verfügt, die als Master in Frage kommen, OpenSearch und Elasticsearch-Versionen 7. x und später ignorieren einen Knoten, sodass die Abstimmungskonfiguration immer eine ungerade Zahl ist. In diesem Fall sind vier dedizierte Hauptknoten im Wesentlichen mit drei (und zwei mit einem) äquivalent.

Anmerkung

Wenn Ihr Cluster nicht über das erforderliche Quorum für die Wahl eines neuen Hauptknotens verfügt, schlagen Schreib- und Leseanforderungen an den Cluster fehl. Dieses Verhalten unterscheidet sich von der OpenSearch Standardeinstellung.

Auswählen von Instance-Typen für dedizierte Hauptknoten

Obwohl dedizierte Master-Knoten keine Such- und Abfrageanfragen verarbeiten, korreliert ihre Größe stark mit der Instanzgröße und der Anzahl der Instances, Indizes und Shards, die sie verwalten können. Für Produktionscluster empfehlen wir mindestens die folgenden Instance-Typen für dedizierte Master-Knoten.

Diese Empfehlungen basieren auf typischen Workloads und können je nach Ihren Anforderungen variieren. Cluster mit vielen Shards oder Feldzuordnungen profitieren von größeren Instance-Typen. Überwachen Sie die Metriken dedizierter Hauptknoten, um zu sehen, ob Sie einen größeren Instance-Typ verwenden müssen.

Instance-Anzahl

Hauptknoten-RAM-Größe Maximal unterstützte Shard-Anzahl

Empfohlenes Minimum für den dedizierten Hauptknoten-Instance-Typ

1–10

8 GiB 10 K

m5.large.search oder m6g.large.search

11–30

16 GiB 30 K

c5.2xlarge.search oder c6g.2xlarge.search

31–75 32 GiB 40 000

r5.xlarge.search oder r6g.xlarge.search

76 – 125 64 GiB 75 K

r5.2xlarge.search oder r6g.2xlarge.search

126 – 200

128 GiB 75 K

r5.4xlarge.search oder r6g.4xlarge.search