Fehlerbehebung bei häufigen Split-Brain-Szenarien in Elasticsearch-Clustern

Split Brain ist der Elasticsearch-Fehler, über den Leute sprechen, weil es sich dramatisch anhört, aber die nützliche Frage ist praktischer: Können mehr als ein Teil des Clusters gleichzeitig Entscheidungen auf Master-Ebene treffen? Moderne Elasticsearch-Versionen sind darauf ausgelegt, dies durch mehrheitsbasierte Cluster-Koordination zu verhindern. Ältere Cluster, insbesondere solche vor Version 7.0 mit einer schlechten discovery.zen.minimum_master_nodes-Einstellung, waren leichter falsch zu konfigurieren.

Dieser Artikel trennt daher zwei Situationen, die oft vermischt werden. Ein echter Split Brain bedeutet, dass unabhängige Partitionen jeweils einen Master wählen oder behalten können. Ein Master-Wahl-Ausfall bedeutet, dass der Cluster keinen Master wählen kann, weil er keine Mehrheit hat. Ersteres riskiert widersprüchliche Cluster-Zustände und Dateninkonsistenzen. Letzteres ist schmerzhaft, aber normalerweise der sicherere Fehlermodus.

Wie Split Brain aussieht

In einem gesunden Cluster verwaltet ein gewählter Master den Cluster-Zustand: Indexerstellung, Shard-Allokationsentscheidungen, Mappings, Knotenmitgliedschaft und ähnliche Metadaten. Datenknoten können Lese- und Schreibvorgänge verarbeiten, aber der Cluster hängt dennoch von einer einzigen Master-Sicht der Welt ab.

Ein Split-Brain-Szenario tritt auf, wenn Netzwerkpartitionen oder schlechte Discovery-Einstellungen dazu führen, dass zwei Gruppen von Knoten sich so verhalten, als ob jede Gruppe der echte Cluster wäre. Eine Seite könnte Schreibvorgänge auf einen Index akzeptieren, während die andere Seite andere Schreibvorgänge akzeptiert. Wenn die Konnektivität zurückkehrt, kann Elasticsearch nicht einfach zwei widersprüchliche Verläufe wie eine Textdatei zusammenführen.

In modernem Elasticsearch sollte eine Partition, die keine Mehrheit der master-fähigen Knoten hat, keinen Master wählen. Das bedeutet, dass einige Knoten möglicherweise nicht verfügbar werden, anstatt einen konkurrierenden Cluster zu bilden. Das ist das Verhalten, das Sie wünschen.

Die Version ist wichtig

Für Elasticsearch 6.x und älter war die wichtigste Einstellung:

discovery.zen.minimum_master_nodes: 2

Die Regel war die Mehrheit der master-fähigen Knoten: (N / 2) + 1, abgerundet bei Integer-Division vor dem Hinzufügen von eins. Bei drei master-fähigen Knoten setzen Sie es auf 2. Bei fünf setzen Sie es auf 3. Wenn Sie es in einem Drei-Knoten-Cluster auf 1 setzen, wird Split Brain möglich.

Für Elasticsearch 7.x und später ist discovery.zen.minimum_master_nodes verschwunden. Die Cluster-Koordination hat sich geändert, und Elasticsearch verwaltet die Voting-Konfiguration. Neue Cluster benötigen dennoch korrektes Bootstrapping mit cluster.initial_master_nodes, aber diese Einstellung ist nur für die erste Clusterbildung. Nachdem der Cluster gebildet ist, entfernen Sie sie aus der Konfiguration.

"Reparieren" Sie einen modernen Cluster nicht, indem Sie alte discovery.zen-Einstellungen hinzufügen. Sie sind nicht mehr die Kontrollebene.

Häufige Ursachen

Der häufigste Auslöser ist eine Netzwerkpartition zwischen master-fähigen Knoten. In Cloud-Begriffen könnte das eine Sicherheitsgruppenänderung, eine schlechte Routingtabelle, eine Netzwerk-ACL, ein Problem auf Zone-Ebene oder eine Firewall-Regel sein, die den Transport-Port 9300 blockiert. In Bare-Metal-Umgebungen könnte es ein Switch-, VLAN-, DNS-, MTU- oder Paketverlustproblem sein.

Eine weitere Ursache ist der Betrieb von zu wenigen master-fähigen Knoten. Zwei master-fähige Knoten sind ungünstig, weil es nach einem Ausfall keine saubere Mehrheit gibt. Ein Produktionscluster verwendet normalerweise drei dedizierte master-fähige Knoten oder drei Knoten mit gemischten Rollen in einer kleinen Bereitstellung.

Eine dritte Ursache sind veraltete oder wiederverwendete Datenverzeichnisse. Wenn Sie VMs klonen oder Festplatten von alten Clustern wiederverwenden, können Knoten Cluster-Metadaten mit sich führen, die Sie nicht beabsichtigt haben. Dies kann zu verwirrenden Join-Fehlern und im schlimmsten Fall zur versehentlichen Bildung eines separaten Clusters führen.

Schließlich kann die manuelle Wiederherstellung unter Druck das Problem verschlimmern. Das Neustarten zufälliger Knoten, das Löschen von Datenpfaden oder das Erzwingen unsicherer Allokation, bevor Sie wissen, welche Partition autoritativ ist, kann einen behebbaren Vorfall in Datenverlust verwandeln.

Erste Überprüfungen während eines Vorfalls

Beginnen Sie damit, jeden erreichbaren Knoten zu fragen, was er denkt:

curl -s "http://KNOTEN:9200/_cat/master?v"
curl -s "http://KNOTEN:9200/_cat/nodes?v&h=ip,name,roles,master,node.role"
curl -s "http://KNOTEN:9200/_cluster/health?pretty"

Führen Sie diese nach Möglichkeit gegen mehr als einen Knoten aus. Wenn verschiedene Knoten unterschiedliche Master oder unterschiedliche Knotenmitgliedschaften melden, haben Sie es möglicherweise mit einem partitionierten Cluster oder isolierten Knoten zu tun.

Überprüfen Sie die Logs auf master-fähigen Knoten auf Nachrichten über Wahlen, Joins, Trennungen und Publikationsfehler. Nützliche Suchbegriffe sind master not discovered, elected-as-master, node-left, node-join, publication, connect_transport_exception und handshake.

Testen Sie dann die Transport-Konnektivität, nicht nur HTTP:

nc -vz knoten-1.beispiel.intern 9300
nc -vz knoten-2.beispiel.intern 9300
nc -vz knoten-3.beispiel.intern 9300

Führen Sie diese Tests von Knoten zu Knoten durch. Ein Load Balancer oder Bastion-Host, der den HTTP-Port 9200 erreicht, sagt Ihnen sehr wenig darüber aus, ob Elasticsearch-Knoten über 9300 einen Cluster bilden können.

Überprüfen Sie die Discovery- und Bootstrap-Konfiguration

Unter Elasticsearch 7.x und später überprüfen Sie diese Einstellungen:

cluster.name: mein-cluster
discovery.seed_hosts:
  - knoten-1:9300
  - knoten-2:9300
  - knoten-3:9300

Nur für einen brandneuen Cluster:

cluster.initial_master_nodes:
  - knoten-1
  - knoten-2
  - knoten-3

Die Bootstrap-Namen müssen mit node.name übereinstimmen. Nachdem der Cluster gebildet ist, entfernen Sie cluster.initial_master_nodes von allen Knoten.

Unter Elasticsearch 6.x und älter überprüfen Sie:

discovery.zen.minimum_master_nodes: 2

für einen Cluster mit drei master-fähigen Knoten. Bestätigen Sie auch, dass alle master-fähigen Knoten konsistente Discovery-Hosts und Cluster-Namen haben.

Wiederherstellungsprinzipien

Wenn Sie einen echten Split Brain vermuten, hören Sie auf, Änderungen über die Cluster-API vorzunehmen, bis Sie wissen, welche Seite autoritativ ist. Die sicherste Wiederherstellung folgt normalerweise dieser Reihenfolge:

1. Beweise sichern: Sammeln Sie Logs, Knotenlisten, Master-Ansichten und Index-Health von jeder Partition.
2. Stellen Sie die Netzwerkkonnektivität wieder her oder isolieren Sie absichtlich die schlechte Seite.
3. Wählen Sie die autoritative Partition basierend auf Mehrheit, aktuellsten gültigen Daten und geschäftlichen Auswirkungen.
4. Stoppen Sie Elasticsearch auf Knoten, die nicht als unabhängige Partition fortgesetzt werden sollen.
5. Bringen Sie die Knoten nacheinander zurück und überprüfen Sie, ob sie dem autoritativen Cluster beitreten.
6. Stellen Sie fehlende Daten aus Snapshots wieder her, wenn eine Primär-Shard-Historie verloren oder inkonsistent ist.

Löschen Sie keine Translog-Verzeichnisse als routinemäßige Split-Brain-Behebung. Das ist gefährlicher Rat. Translogs sind Teil der Elasticsearch-Wiederherstellung. Das manuelle Entfernen von Dateien unter dem Datenpfad kann zu Datenverlust führen und sollte nur mit versionsspezifischer Anleitung von Elastic-Support oder nachdem Sie den Verlust akzeptiert und einen Wiederaufbauplan haben, durchgeführt werden.

Wenn zwei Partitionen unabhängig voneinander Schreibvorgänge akzeptiert haben, gibt es möglicherweise keine perfekte automatische Zusammenführung. Möglicherweise müssen Sie aus einem Snapshot wiederherstellen, aus Quellsystemen neu indizieren, Anwendungslogs wiedergeben oder die Daten einer Seite als autoritativ auswählen.

Ein realistisches Beispiel

Stellen Sie sich einen Drei-Knoten-Cluster über drei private Subnetze vor. Eine Firewall-Änderung blockiert versehentlich den Transportverkehr zwischen Knoten 1 und den Knoten 2 und 3. Knoten 2 und 3 sehen sich noch, also behalten oder wählen sie einen Master. Knoten 1 kann keine Mehrheit sehen. In einem modernen, korrekt konfigurierten Cluster sollte Knoten 1 keinen konkurrierenden Master allein bilden. Clients, die Knoten 1 verwenden, können ausfallen, aber der Cluster vermeidet widersprüchliche Master.

Stellen Sie sich nun einen alten 6.x-Cluster mit drei master-fähigen Knoten und discovery.zen.minimum_master_nodes: 1 vor. Knoten 1 kann sich selbst wählen, während Knoten 2 und 3 einen anderen Master wählen. Das ist das klassische Split-Brain-Risiko. Die Behebung besteht nicht nur darin, das Netzwerk wieder zu verbinden. Sie müssen auch die Quorum-Konfiguration korrigieren und entscheiden, wie mit allen auf der falschen Seite akzeptierten Schreibvorgängen umgegangen werden soll.

Prävention

Verwenden Sie drei master-fähige Knoten für kleine und mittlere Cluster. Machen Sie sie für größere Cluster zu dedizierten Master-Knoten, damit Such- und Indizierungslast die Cluster-Koordination nicht beeinträchtigt.

Halten Sie master-fähige Knoten in zuverlässigen Netzwerken mit geringem Paketverlust. Das Verteilen von Knoten über Zonen kann die Verfügbarkeit verbessern, aber nur, wenn das Netzwerk zwischen den Zonen zuverlässig ist und das Quorum-Design immer noch sinnvoll ist.

Überwachen Sie Master-Änderungen. Eine Master-Wahl während geplanter Wartungsarbeiten ist normal. Häufige Wahlen während des normalen Verkehrs sind ein Warnsignal.

Überwachen Sie die Transport-Konnektivität und nicht nur die HTTP-Verfügbarkeit. Ein Knoten kann auf 9200 antworten und dennoch nicht korrekt am Cluster teilnehmen, wenn der Transportverkehr blockiert ist.

Erstellen Sie regelmäßig Snapshots und testen Sie Wiederherstellungen. Replikate schützen Sie nicht vor einem versehentlichen Löschen, beschädigten Daten oder widersprüchlichen Schreibvorgängen während eines schwerwiegenden Vorfalls.

Seien Sie vorsichtig mit Bootstrap-Einstellungen. Auf modernen Clustern ist cluster.initial_master_nodes keine alltägliche Discovery-Einstellung. Verwenden Sie es, um einen neuen Cluster zu erstellen, und entfernen Sie es dann.

Die beste Split-Brain-Wiederherstellung ist die, die Sie nie brauchen: mehrheitsbasierte Master-Fähigkeit, korrekte versionsspezifische Discovery-Einstellungen, langweilige Netzwerkregeln und ein getesteter Snapshot-Plan.

Wie man Split Brain von einer normalen Wahl unterscheidet

Eine Master-Wahl ist nicht automatisch ein Split Brain. Während eines Rolling-Restarts, Netzwerk-Flaps oder Master-Knoten-Ausfalls kann Elasticsearch einen neuen Master wählen. Wenn der Cluster einen autoritativen Master behält und der alte Master zurücktritt, ist das normales verteiltes Systemverhalten.

Warnsignale sind unterschiedliche Ansichten von verschiedenen Knoten. Wenn Knoten A sich selbst als Master meldet, während Knoten B Knoten C als Master meldet, stoppen Sie und untersuchen Sie. Wenn zwei Gruppen von Knoten beide Cluster-Zustandsänderungen akzeptieren, während sie getrennt sind, haben Sie eine viel ernstere Situation als eine kurze Wahl.

Beobachten Sie auch das Client-Verhalten. Clients, die an einen isolierten Knoten gebunden sind, können Fehler sehen, selbst während die Mehrheitsseite gesund ist. Das bedeutet nicht, dass der Mehrheitscluster defekt ist. Es kann bedeuten, dass Ihre Client-Verbindungsstrategie oder Ihr Load Balancer immer noch Datenverkehr an einen Knoten sendet, der nicht teilnehmen kann.

Load Balancer und Client-Routing

Die Elasticsearch-Transport-Discovery ist nicht dasselbe wie das HTTP-Routing des Clients. Platzieren Sie die Master-Discovery nicht hinter einem generischen HTTP-Load-Balancer und erwarten Sie, dass dies die Cluster-Mitgliedschaft löst. Knoten benötigen Transport-Konnektivität zueinander.

Verwenden Sie für Clients mehrere HTTP-Endpunkte oder einen Load Balancer, der ungesunde Knoten schnell entfernt. Ein Knoten, der seinen Master verloren hat, kann dennoch kurzzeitig einen lauschenden Prozess haben, aber er ist kein gutes Ziel für Schreibvorgänge. Health Checks sollten aussagekräftiger sein als "Port 9200 ist offen".

Ein praktischer HTTP-Health-Check könnte die Cluster-Health lokal abfragen und Knoten ablehnen, die keinen entdeckten Master haben. Der genaue Ansatz hängt von Ihrem Client und Ihrer Infrastruktur ab, aber das Prinzip ist einfach: Senden Sie keine Schreibvorgänge mehr an isolierte Knoten.

Bereinigung nach dem Vorfall

Nachdem der Cluster stabil ist, vergleichen Sie die Index-Health, Dokumentenzahlen und anwendungsseitige Source-of-Truth-Zahlen. Wenn die Möglichkeit bestand, dass Schreibvorgänge auf verschiedenen Partitionen gelandet sind, kann die Elasticsearch-Health allein nicht beweisen, dass die Daten semantisch korrekt sind.

Überprüfen Sie den Zeitplan. Welcher Knoten hat zuerst die Konnektivität verloren? Welcher Knoten war vor dem Ereignis der Master? Haben Clients weiter geschrieben? Waren Snapshots aktuell? Haben Alarme ausgelöst, bevor Benutzer es bemerkt haben? Diese Details bestimmen, ob Sie nur eine Netzwerkbehebung oder einen Datenabgleichsplan benötigen.

Planen Sie für ältere Cluster die Versions- und Discovery-Einstellungsarbeiten. Wenn Sie immer noch eine Version ausführen, die von discovery.zen.minimum_master_nodes abhängt, stellen Sie sicher, dass sie heute korrekt ist, und planen Sie dann einen Upgrade-Pfad. Split-Brain-Prävention ist kein einmaliger Runbook-Schritt; sie ist Teil des Cluster-Lifecycle-Managements.

Konfigurationsänderungen, die Sie während der Panik vermeiden sollten

Ändern Sie nicht cluster.name, um Knoten zum Beitritt zu bewegen. Das erzeugt ein anderes Problem der Cluster-Identität.

Löschen Sie keine Datenpfade, es sei denn, Sie verwerfen absichtlich die lokalen Shard-Kopien des Knotens und haben bestätigt, dass der Cluster gültige Kopien an anderer Stelle oder Snapshots verfügbar hat.

Fügen Sie cluster.initial_master_nodes nicht wieder zu einem bestehenden modernen Cluster als allgemeine Neustartbehebung hinzu. Diese Einstellung ist für das anfängliche Bootstrapping, nicht für die routinemäßige Discovery.

Senken Sie nicht quorumartige Schutzmaßnahmen auf alten Clustern, um die Verfügbarkeit wiederherzustellen. Das Schreibbarmachen einer Minderheitspartition mag sich wie ein Fortschritt anfühlen, aber genau das macht widersprüchliche Master möglich.

Entwerfen für ungünstige Ausfallbereiche

Drei master-fähige Knoten funktionieren am besten, wenn kein einzelnes Infrastrukturereignis zwei von ihnen entfernen kann. In einer Cloud-Region mit drei Zonen ist ein master-fähiger Knoten pro Zone ein übliches Muster. In einer Umgebung mit zwei Zonen ist die Platzierung schwieriger, da eine Zone zwei Stimmen enthalten kann. Wenn diese größere Zone ausfällt, kann die verbleibende einzelne Stimme nicht sicher einen Master wählen. Das ist nicht Elasticsearch, das zerbrechlich ist; das ist Mehrheitsmathematik.

Lösen Sie dies nicht, indem Sie eine gerade Anzahl von Voting-Knoten hinzufügen, ohne die Fehlermodi durchzudenken. Vier master-fähige Knoten erfordern immer noch eine Mehrheit, und eine Zwei-Zwei-Partition kann nicht sicher eine Seite wählen. Dedizierte reine Voting-Knoten können in einigen Designs helfen, aber das Prinzip bleibt gleich: Der Cluster benötigt eine zuverlässige Mehrheit, um Cluster-Zustandsentscheidungen zu treffen.

Schreiben Sie dies in den Architekturnotizen nieder. Während eines Ausfalls fragen die Leute oft, warum der überlebende Knoten oder die überlebende Zone nicht einfach weiter Schreibvorgänge bedienen kann. Die Antwort sollte vor dem Vorfall klar sein: Das Akzeptieren von Schreibvorgängen ohne Mehrheit riskiert widersprüchliche Verläufe.