Verständnis der Elasticsearch-Masterknoten-Wahl und Quorumsanforderungen

Das Quorum des Elasticsearch-Masterknotens entscheidet, ob Ihr Cluster sicher einen Leader wählen, Cluster-Zustandsänderungen veröffentlichen und vermeiden kann, dass zwei getrennte Seiten desselben Clusters unterschiedliche Entscheidungen treffen.

Der gewählte Master beschleunigt nicht selbst die Suche. Er koordiniert den Cluster. Wenn Wahlen instabil sind, können die Symptome verstreut wirken: Indexerstellung hängt, Shard-Zuordnung stoppt, Kibana meldet wechselnde Gesundheitszustände und Logs wiederholen Nachrichten darüber, dass ein Master nicht gefunden wird.

Die kritische Rolle des Masterknotens

Während Datenknoten die schweren Aufgaben des Indexierens, Suchens und Speicherns von Daten übernehmen, ist der Masterknoten für die Verwaltung der Struktur und Metadaten des gesamten Clusters verantwortlich. Er nimmt normalerweise nicht an Abfrage- oder Indexierungsoperationen teil, es sei denn, er ist auch als Datenknoten konfiguriert.

Verantwortlichkeiten des Masterknotens

1. Cluster-Zustandsverwaltung: Der Master verwaltet und veröffentlicht den Cluster-Zustand—einen Bauplan der aktuellen Konfiguration des Clusters, einschließlich der vorhandenen Indizes, der Zuordnungen und Einstellungen für diese Indizes sowie des Standorts jedes Shards.
2. Knotenverwaltung: Behandlung des Beitritts und Verlassens von Knoten, Aktualisierung des Cluster-Zustands entsprechend.
3. Indexverwaltung: Erstellen, Löschen oder Aktualisieren von Indizes.
4. Shard-Zuordnung: Entscheiden, wo primäre und Replikat-Shards platziert werden sollen (anfängliche Zuordnung und Neuausgleich nach Knotenausfall).

Wenn der gewählte Master ausfällt, pausiert der Cluster die Master-Arbeit, bis ein anderer Master gewählt wird. Bestehende Suchvorgänge können für verfügbare Shards fortgesetzt werden, aber Indexerstellung, Mapping-Updates und Zuordnungsentscheidungen hängen von einer stabilen Master-Koordination ab.

Verständnis der Master-Wahl und Abstimmung

In einem verteilten System ist ein Wahlprozess erforderlich, wenn der aktuelle Masterknoten ausfällt oder unerreichbar wird. Seit Elasticsearch 7.0 wurde der Wahlmechanismus erheblich vereinfacht und gehärtet, hauptsächlich durch die Eliminierung der komplexen Einstellung discovery.zen.minimum_master_nodes und die Einführung von selbstverwalteten Abstimmungskonfigurationen.

Der Wahlprozess (Elasticsearch 7.x+)

Die Master-Wahl wird jetzt automatisch von den masterfähigen Knoten durchgeführt, die in der Konfiguration mit node.roles: [master, data] oder nur node.roles: [master] für dedizierte Master definiert sind.

1. Kandidatenentdeckung: Masterfähige Knoten kommunizieren, um die Menge der aktiven Abstimmungsteilnehmer zu bestimmen.
2. Quorum-Prüfung: Knoten prüfen, ob sie ein Quorum—eine Mehrheit der bekannten Abstimmungsknoten—erreichen können, um Konsens sicherzustellen.
3. Leader-Auswahl: Wenn ein Quorum hergestellt ist, wählt das Koordinationssubsystem von Elasticsearch gemäß seinen internen Wahlregeln einen Master aus.
4. Abstimmung und Bestätigung: Der Vorschlag wird zur Abstimmung gestellt, und wenn er von der Mehrheit angenommen wird, übernimmt der neue Master die Kontrolle und veröffentlicht den neuen Cluster-Zustand.

Initiales Cluster-Bootstrapping

Beim erstmaligen Starten eines brandneuen Clusters muss Elasticsearch wissen, welche Knoten an der anfänglichen Abstimmungskonfiguration teilnehmen sollen. Dies wird mit der Einstellung cluster.initial_master_nodes gehandhabt. Diese Einstellung sollte nur einmalig beim ersten Start des Clusters verwendet werden.

# elasticsearch.yml Ausschnitt für die initiale Einrichtung
cluster.name: my-production-cluster
node.name: node-1
node.roles: [master, data]

# Liste der Namen aller masterfähigen Knoten, die für das initiale Bootstrap verwendet werden
cluster.initial_master_nodes: [node-1, node-2, node-3]

Tipp: Sobald der Cluster gebildet wurde, entfernen Sie cluster.initial_master_nodes von jedem Knoten. Das Belassen kann bei späteren Neustarts gefährlich sein, da diese Einstellung nur für das erste Bootstrap eines brandneuen Clusters gedacht ist.

Quorumsanforderungen und Split-Brain-Prävention

Der grundlegende Grund für Quorumsanforderungen ist die Garantie, dass zu jeder Zeit nur ein Leader gewählt werden kann, wodurch das Split-Brain-Problem verhindert wird.

Was ist Split-Brain?

Split-Brain tritt auf, wenn eine Netzwerkpartition den Cluster in isolierte Segmente teilt und mehr als ein Segment glaubt, den autoritativen Master zu haben. Wenn das passiert, können verschiedene Seiten widersprüchliche Cluster-Zustandsänderungen akzeptieren, was genau das ist, was das Quorum verhindern soll.

Die Quorum-Regel (Mehrheitskonsens)

Um Split-Brain zu verhindern, erzwingt Elasticsearch eine Mehrheitskonsensregel, die eine Mindestanzahl von Abstimmungsknoten erfordert, die jeder Cluster-Zustandsänderung zustimmen müssen. Dieses Minimum ist das Quorum, berechnet als:

$$\text{Quorum} = \lfloor (\text{Anzahl der Abstimmungsknoten} / 2) \rfloor + 1$$

Durch die Anforderung einer strikten Mehrheit kann bei einer Netzwerkpartition nur die größere Seite (die die Mehrheit besitzt) das Quorum erreichen und weiterarbeiten. Die kleinere Seite, die keinen Master wählen kann, wird anhalten und auf die Wiederherstellung der Netzwerkverbindung warten, wodurch Datenvermeidungen in das partitionierte Segment vermieden werden.

Anzahl der abstimmenden Masterknoten (N)	Erforderliches Quorum (N/2 + 1)
3	2
5	3
7	4

Best Practice Warnung: Stellen Sie immer eine ungerade Anzahl von masterfähigen Knoten bereit (z.B. drei oder fünf). Die Bereitstellung einer geraden Anzahl (z.B. vier) bietet die gleiche Fehlertoleranz wie die vorhergehende ungerade Anzahl (drei), erfordert aber mehr Ressourcen. Zum Beispiel benötigt ein 4-Knoten-Abstimmungscluster 3 Stimmen (N/2+1), was bedeutet, dass er nur einen Ausfall tolerieren kann, genau wie ein 3-Knoten-Cluster, aber einen zusätzlichen Server verwendet.

Konfiguration dedizierter Masterknoten

Für Produktionsumgebungen sind drei dedizierte masterfähige Knoten die übliche Basislinie. Dies trennt Such- und Indexierungslast von der Koordinationsarbeit. Kleine Entwicklungsumgebungen können gemischte Rollen ausführen, aber ein Cluster, der wichtig ist, sollte nicht zulassen, dass eine schwere Aggregation oder ein Ingest-Anstieg den gewählten Master aushungert.

Knotenkonfigurationsbeispiel (Dedizierter Master)

Um einen Knoten als masterfähig zu konfigurieren, aber keine Daten zu speichern oder Ingest-Pipelines auszuführen, verwenden Sie die folgenden Rollen in elasticsearch.yml:

# Knoten 1: Dedizierter Master
node.name: es-master-01
node.roles: [master]

# Binden Sie den Transport an ein privates Netzwerk und beschränken Sie den Zugriff mit Firewalls/Sicherheitsgruppen.
# network.host: 10.0.0.1

Knotenkonfigurationsbeispiel (Dedizierter Datenknoten)

Umgekehrt sollte ein dedizierter Datenknoten daran gehindert werden, am Master-Wahlprozess teilzunehmen:

# Knoten 4: Dedizierter Datenknoten
node.name: es-data-04
node.roles: [data]

# Wenn keine Rollen angegeben sind, weist Elasticsearch den Standard-Rollensatz für diese Version zu.

Cluster-Erkennungseinstellungen

Alle Knoten müssen so konfiguriert sein, dass sie denselben Satz von masterfähigen Knoten mit der Einstellung discovery.seed_hosts finden. Diese Einstellung listet die Netzwerkadressen auf, unter denen Elasticsearch versuchen kann, andere Knoten zu kontaktieren, um dem Cluster beizutreten.

# Gemeinsame Einstellung für alle Knoten im Cluster
discovery.seed_hosts: ["10.0.0.1:9300", "10.0.0.2:9300", "10.0.0.3:9300"]

Diese Liste sollte die Adressen der masterfähigen Knoten enthalten (es-master-01, es-master-02, es-master-03, usw.).

Fehlerbehebung bei Wahlproblemen

Wenn der Cluster keinen Master wählen kann, geht er typischerweise in einen 'roten' oder 'gelben' Zustand über und protokolliert dauerhafte Fehler. Häufige Ursachen sind:

Problem	Beschreibung & Lösung
Netzwerkprobleme	Knoten können aufgrund von Firewall-Regeln, Routing-Problemen, DNS-Problemen oder hoher Latenz nicht kommunizieren. Der Transport-Port, normalerweise 9300, muss zwischen Knoten erreichbar sein. HTTP, normalerweise 9200, ist für Client/API-Zugriff und nicht der Wahlkanal.
Konfigurationskonflikt	cluster.name ist falsch oder discovery.seed_hosts zeigt nicht auf die richtigen masterfähigen Knoten. Überprüfen Sie, ob alle Knoten identische Einstellungen verwenden.
Quorum-Verlust	Zu viele Abstimmungsknoten sind gleichzeitig ausgefallen, z.B. zwei Ausfälle in einer Drei-Master-Einrichtung. Wenn die fehlenden Knoten dauerhaft weg sind, verwenden Sie die API für Abstimmungskonfigurationsausschlüsse vorsichtig und nur nach Bestätigung des Fehlermodus.
Festplatten-I/O	Die Festplatten-I/O des Masterknotens ist gesättigt, was ihn daran hindert, den Cluster-Zustand schnell zu veröffentlichen, was zu Timeouts und wiederholten Wahlen führt.

Überprüfen der Abstimmungskonfiguration

Sie können die aktuelle Abstimmungskonfiguration mit der Cluster-API überprüfen:

GET /_cluster/state?filter_path=metadata.cluster_coordination

Diese Ausgabe bestätigt, welche Knoten derzeit zum Quorum gezählt werden, und stellt sicher, dass Ihre Konfiguration Ihren Fehlertoleranzzielen entspricht.

Das sicherste Produktionsmuster ist langweilig: drei dedizierte masterfähige Knoten in separaten Ausfallbereichen, stabiles Transportnetzwerk, korrekte Seed-Hosts und cluster.initial_master_nodes nur einmal verwendet. Wenn Wahlen fehlschlagen, widerstehen Sie dem Drang, alle Knoten auf einmal neu zu starten. Lesen Sie die Logs, bestätigen Sie, welche masterfähigen Knoten sich gegenseitig sehen können, und nehmen Sie jeweils eine kontrollierte Änderung vor.