Elasticsearch Master-Knoten-Wahl und Quorum-Anforderungen verstehen

Elasticsearch ist ein verteiltes System, das auf der Koordination zwischen Knoten basiert, um eine konsistente Ansicht des Cluster-Status aufrechtzuerhalten. Im Mittelpunkt dieser Koordination steht der Master-Knoten. Der Master-Knoten ist die einzige Quelle der Wahrheit für Cluster-Metadaten, und die Gewährleistung seiner Stabilität und einer korrekten Wahl ist von größter Bedeutung für die Cluster-Gesundheit, Skalierbarkeit und Ausfallsicherheit.

Dieser Artikel beschreibt die kritischen Verantwortlichkeiten des Master-Knotens, erklärt den modernen Wahlprozess, der in neueren Elasticsearch-Versionen (7.x+) verwendet wird, und verdeutlicht das wesentliche Konzept des Quorums – den Mechanismus, der notwendig ist, um das verheerende Szenario, bekannt als Split-Brain-Problem, zu verhindern.

Die kritische Rolle des Master-Knotens

Während Datenknoten die Hauptarbeit des Indexierens, Suchens und Speicherns von Daten übernehmen, ist der Master-Knoten 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 Master-Knotens

Cluster-Status-Verwaltung: Der Master verwaltet und veröffentlicht den Cluster-Status – einen Bauplan der aktuellen Cluster-Konfiguration, einschließlich der vorhandenen Indizes, der Mappings und Einstellungen für diese Indizes sowie des Speicherorts jedes Shards.
Knotenverwaltung: Handhabung des Beitritts und Verlassens von Knoten, Aktualisierung des Cluster-Status entsprechend.
Index-Verwaltung: Erstellen, Löschen oder Aktualisieren von Indizes.
Shard-Zuweisung: Entscheidung, wo primäre und Replik-Shards gespeichert werden sollen (anfängliche Zuweisung und Neuausgleich nach Knotenausfall).

Fällt der Master-Knoten aus, kann der Cluster keine administrativen Aufgaben ausführen oder Shards neu zuweisen, bis ein neuer Master erfolgreich gewählt wurde.

Master-Wahl und Abstimmung verstehen

In einem verteilten System ist ein Wahlprozess erforderlich, sobald der aktuelle Master-Knoten 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 nun automatisch von den Master-fähigen Knoten gehandhabt, die in der Konfiguration über node.roles: [master, data] oder nur node.roles: [master] für dedizierte Master definiert sind.

Kandidaten-Entdeckung: Master-fähige Knoten kommunizieren, um den Satz aktiver stimmberechtigter Mitglieder zu bestimmen.
Quorum-Prüfung: Knoten überprüfen, ob sie ein Quorum – eine Mehrheit der bekannten Abstimmungsknoten – erreichen können, um Konsens sicherzustellen.
Anführer-Auswahl: Wenn ein Quorum etabliert ist, wird der höchstrangige Kandidat (basierend auf einem Tie-Breaking-Mechanismus wie der Cluster-Status-ID) als neuer Master vorgeschlagen.
Abstimmung und Bestätigung: Über den Vorschlag wird abgestimmt, und wenn er von der Mehrheit angenommen wird, übernimmt der neue Master die Kontrolle und veröffentlicht den neuen Cluster-Status.

Erstes 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 einmal während des ersten Starts des Clusters verwendet werden.

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

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

Tipp: Sobald der Cluster läuft und stabil ist, sollten Sie die Einstellung cluster.initial_master_nodes aus den Konfigurationsdateien aller Knoten entfernen oder auskommentieren, um potenzielle Probleme zu vermeiden, falls Knoten später in einem gemischten Zustand neu gestartet werden.

Quorum-Anforderungen und Split-Brain-Verhinderung

Der grundlegende Grund für Quorum-Anforderungen ist, zu garantieren, dass jederzeit nur ein Anführer 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 zwei oder mehr isolierte Segmente aufteilt und jedes Segment glaubt, der autoritative Master zu sein. Geschieht dies, können Knoten in verschiedenen Segmenten unabhängig Indexierungsanfragen annehmen und Shards zuweisen, was zu Dateninkonsistenz und -korruption führt, wenn das Netzwerk schließlich wiederhergestellt ist.

Die Quorum-Regel (Mehrheitskonsens)

Um Split-Brain zu verhindern, erzwingt Elasticsearch eine Mehrheitskonsensregel, die eine Mindestanzahl von abstimmenden Knoten erfordert, um einer Änderung des Cluster-Status zuzustimmen. Dieses Minimum ist das Quorum, berechnet als:

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

Indem eine strikte Mehrheit erforderlich ist, 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 Datenschreibvorgänge in das partitionierte Segment vermieden werden.

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

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

Dedizierte Master-Knoten konfigurieren

Für Produktionsumgebungen, insbesondere große Cluster (20+ Datenknoten), wird dringend empfohlen, dedizierte Master-Knoten zu verwenden. Dies trennt die ressourcenintensiven Aufgaben des Suchens/Indexierens von den entscheidenden administrativen Pflichten des Masters.

Beispiel für die Knotenkonfiguration (Dedizierter Master)

Um einen Knoten als Master-fähig zu konfigurieren, der aber keine Daten speichert oder Ingest-Pipelines ausführt, verwenden Sie die folgenden Rollen in elasticsearch.yml:

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

# HTTP-/Transport-Traffic für reine Master deaktivieren (optional, aber gute Sicherheitspraxis)
# http.enabled: false 
# transport.bind_host: [private_ip_of_master]

Beispiel für die Knotenkonfiguration (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]

# Hinweis: Wenn keine Rollen angegeben sind, verwendet Elasticsearch standardmäßig [master, data, ingest] (Standard vor 8.0)

Cluster-Erkennungseinstellungen

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

# Allgemeine 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 Master-fä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 oder hoher Latenz nicht miteinander kommunizieren. Stellen Sie sicher, dass die Ports 9200 (HTTP) und 9300 (Transport) zwischen den Knoten geöffnet sind.
Konfigurationskonflikt	`cluster.name` ist falsch oder `discovery.seed_hosts` zeigt nicht auf die richtigen Master-fähigen Knoten. Überprüfen Sie, ob alle Knoten identische Einstellungen verwenden.
Quorum-Verlust	Zu viele Master-fähige Knoten sind gleichzeitig ausgefallen (z. B. zwei Ausfälle in einem 3-Knoten-Master-Setup). Manuelles Eingreifen (z. B. mithilfe der API `api/cluster/decommission/voting_config_exclusions`) kann erforderlich sein, um fehlerhafte Knoten zwangsweise aus der Abstimmungsliste zu entfernen.
Festplatten-E/A	Die Festplatten-E/A des Master-Knotens ist gesättigt, was ihn daran hindert, den Cluster-Status schnell zu veröffentlichen, was zu Timeouts und wiederholten Wahlen führt.

Überprüfung der Abstimmungskonfiguration

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

GET /_cluster/state?filter_path=metadata.cluster_coordination.voting_config_excluding_deferred

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

Zusammenfassung

Der Master-Knoten-Wahlprozess ist das Rückgrat der Ausfallsicherheit eines Elasticsearch-Clusters. Durch das Verständnis der Verantwortlichkeiten des Masters und die korrekte Implementierung der Quorum-Regel (Verwendung einer ungeraden Anzahl von Master-fähigen Knoten und Sicherstellung korrekter cluster.initial_master_nodes während des Bootstraps) können Administratoren Split-Brain-Szenarien zuverlässig verhindern und ein hochverfügbares verteiltes System aufrechterhalten. Verwenden Sie in der Produktion immer dedizierte Master-Knoten, um administrative Aufgaben zu isolieren und eine zuverlässige Veröffentlichung des Cluster-Status zu gewährleisten.