Ein Cluster aus zwei Knoten – der Teufel steckt im Detail

Hallo, Habr! Ich präsentiere Ihnen eine Übersetzung des Artikels. «Zwei Knoten – Der Teufel steckt im Detail» Autor Andrew Beekhof.

Viele Menschen ziehen Cluster mit zwei Knoten vor, weil sie konzeptionell einfacher erscheinen und zudem 33 % kostengünstiger sind als ihre drei-knotigen Geschwister. Obwohl es durchaus möglich ist, einen guten Cluster aus zwei Knoten zu erstellen, wird in den meisten Fällen, aufgrund nicht berücksichtigter Szenarien, eine solche Konfiguration eine Vielzahl von weniger offensichtlichen Problemen verursachen.

Der erste Schritt bei der Schaffung eines Hochverfügbarkeitssystems besteht darin, Einzelpunkte des Ausfalls zu identifizieren und zu beseitigen, die oft kurz als SPoF (single point of failure) bezeichnet werden.

Es ist wichtig zu beachten, dass es in jedem System unmöglich ist, alle möglichen Ausfallrisiken zu eliminate. Das ergibt sich zumindest aus der Tatsache, dass der typische Schutz vor Risiko die Einführung einer gewissen Redundanz umfasst, was die Komplexität des Systems erhöht und neue Ausfallpunkte schafft. Daher gehen wir von Anfang an einen Kompromiss ein und konzentrieren uns auf Ereignisse, die mit Einzelpunkten des Ausfalls verbunden sind, und nicht auf Ketten von zusammenhängenden und folglich immer weniger wahrscheinlichen Ereignissen.

Unter Berücksichtigung der Kompromisse suchen wir nicht nur nach SPoF, sondern wägen auch Risiken und Konsequenzen ab, sodass die Schlussfolgerung darüber, was kritisch und was nicht ist, je nach Bereitstellung unterschiedlich ausfallen kann.

Nicht jeder benötigt alternative Stromversorger mit unabhängigen Stromleitungen. Obwohl Paranoia sich für mindestens einen Kunden ausgezahlt hat, als ihre Überwachung einen defekten Transformator entdeckte. Der Kunde rief an, um das Energiewerk zu warnen, bis der defekte Transformator explodierte.

Ein natürlicher Ausgangspunkt ist, dass im System mehr als ein Knoten vorhanden ist. Bevor das System jedoch die Dienste auf den nach einem Ausfall verbleibenden Knoten verschieben kann, muss im Allgemeinen sichergestellt werden, dass die zu verschiebenden Dienste an keinem anderen Ort aktiv sind.

Ein Cluster mit zwei Knoten hat keine Nachteile, wenn im Falle eines Ausfalls beide Knoten dieselbe statische Website bedienen. Alles ändert sich jedoch, wenn beide Seiten unabhängig eine gemeinsame Warteschlange von Aufgaben verwalten oder unkoordinierten Schreibzugriff auf eine replizierte Datenbank oder ein gemeinsames Dateisystem gewähren.

Um Datenbeschädigungen durch den Ausfall eines Knotens zu verhindern, verlassen wir uns auf das, was man nennt „Abgrenzung“ (Fencing).

Das Prinzip der Abgrenzung

Das Prinzip der Abgrenzung basiert auf der Frage: Kann ein konkurrierender Knoten Datenbeschädigungen verursachen? Wenn das Risiko einer Datenbeschädigung ein wahrscheinliches Szenario ist, ist eine Isolation des Knotens von eingehenden Anfragen sowie von persistentem Speicher eine gute Lösung. Der am häufigsten angewandte Ansatz zur Abgrenzung besteht darin, fehlerhafte Knoten abzuschalten.

Es gibt zwei Kategorien von Abgrenzungsmethoden, die ich erwähnen möchte: direkte und indirekte, aber ebenso können sie genannt werden aktive und passive. Direkte Methoden umfassen Maßnahmen von überlebenden Peer-Knoten, wie das Interagieren mit einem IPMI-Gerät (Intelligent Platform Management Interface – Schnittstelle zur Fernüberwachung und Verwaltung des physischen Zustands eines Servers) oder iLO (Managementmechanismus für Server ohne physischen Zugang), während indirekte Methoden auf einen ausgefallenen Knoten angewiesen sind, um auf irgendeine Weise zu erkennen, dass er sich in einem fehlerhaften Zustand befindet (oder zumindest die anderen Mitglieder bei der Wiederherstellung stört) und Signale zu senden hardware watchdog um den Ausfall des fehlerhaften Knotens zu melden.

Quorum hilft sowohl bei der Anwendung direkter als auch indirekter Methoden.

Direkte Abgrenzung

Im Falle der direkten Abgrenzung können wir ein Quorum nutzen, um Wettrennen bei der Abgrenzung im Falle eines Netzwerkfehlers zu verhindern.

Mit dem Konzept des Quorums hat das System genügend Informationen (auch ohne Verbindung zu seinen Partnern), sodass die Knoten automatisch wissen, ob sie eine Abgrenzung und / oder Wiederherstellung einleiten sollen.

Ohne Quorum nehmen beide Seiten der Netzwerkpartition zu Recht an, dass die andere Seite tot ist, und werden versuchen, den anderen abzugrenzen. Im schlimmsten Fall gelingt es beiden Seiten, den gesamten Cluster abzuschalten. Ein alternatives Szenario ist der Deathmatch, ein endloser Zyklus von Knoten, die erscheinen, ihre Peers nicht sehen, sie neu starten und die Wiederherstellung einleiten, nur um neu zu starten, wenn ihr Peer nach demselben Prinzip agiert.

Das Problem der Abgrenzung besteht darin, dass die am häufigsten verwendeten Geräte aufgrund derselben Ausfallereignisse, auf die wir uns für die Wiederherstellung konzentrieren möchten, nicht verfügbar werden. Die meisten IPMI- und iLO-Karten sind auf den Hosts installiert, die sie steuern, und verwenden standardmäßig dasselbe Netzwerk, was dazu führt, dass die Zielknoten annehmen, dass die anderen Knoten offline sind.

Leider werden die Besonderheiten der Funktionsweise von IPMI- und iLo-Geräten beim Kauf von Hardware selten berücksichtigt.

Indirekte Abgrenzung

Ein Quorum ist auch wichtig für die Verwaltung indirekter Abgrenzungen; wenn alles richtig gemacht wird, kann das Quorum den Überlebenden ermöglichen anzunehmen, dass die verlorenen Knoten nach einer gewissen Zeit in einen sicheren Zustand übergehen.

Bei dieser Konfiguration wird der Hardware-Watchdog-Timer alle N Sekunden zurückgesetzt, wenn kein Quorum verloren geht. Wenn der Timer (normalerweise mehrere Vielfache von N) abläuft, führt das Gerät eine unfreundliche Abschaltung (keine Shutdown) durch.

Dieser Ansatz ist sehr effektiv, aber ohne ein Quorum zur Verwaltung gibt es nicht genügend Informationen innerhalb des Clusters. Es ist nicht einfach, den Unterschied zwischen einem Netzwerkabbruch und einem Ausfall des Partnerknotens zu erkennen. Der Grund, warum dies von Bedeutung ist, besteht darin, dass Sie ohne die Möglichkeit, die beiden Fälle zu unterscheiden, gezwungen sind, im beiden Fällen das gleiche Verhalten zu wählen.

Das Problem bei der Wahl eines Modus besteht darin, dass es keinen Handlungsansatz gibt, der die Verfügbarkeit maximiert und den Datenverlust verhindert.

• Wenn Sie entscheiden, anzunehmen, dass der Partnerknoten aktiv ist, es sich aber tatsächlich um einen Ausfall handelt, stoppt der Cluster unnötig Dienste, die zur Kompensation des Ausfalls des Partnerknotens hätten laufen sollen.
• Wenn Sie annehmen, dass der Knoten nicht funktioniert, es sich aber nur um einen Netzwerkfehler handelte und der entfernte Knoten tatsächlich funktionsfähig ist, dann abonnieren Sie im besten Fall zukünftige manuelle Abstimmungen der resultierenden Datensätze.

Unabhängig von der verwendeten Heuristik ist es trivial, einen Ausfall zu erzeugen, der entweder beide Seiten zum Laufen bringt oder den Cluster zwingt, überlebende Knoten abzuschalten. Das Nichtverwendung eines Quorums beraubt den Cluster tatsächlich eines der mächtigsten Werkzeuge in seinem Arsenal.

Wenn es keine andere Alternative gibt, ist der beste Ansatz, die Verfügbarkeit zu opfern (hier verweist der Autor auf das CAP-Theorem). Hohe Verfügbarkeit beschädigter Daten hilft niemandem, und das manuelle Abgleichen verschiedener Datensätze macht auch keinen Spaß.

Quorum

Quorum hört sich doch gut an, oder?

Der einzige Nachteil ist, dass für einen Cluster mit N Mitgliedern eine Verbindung zwischen N / 2 + 1 Ihrer Knoten bestehen muss. Das ist in einem Cluster mit zwei Knoten nach dem Ausfall eines Knotens unmöglich.

Das bringt uns letztendlich zu einem grundlegenden Problem bei zwei Knoten:
Quorum macht in zweiknotigen Clustern keinen Sinn, und ohne das ist es unmöglich, zuverlässig zu bestimmen, welche Maßnahmen die Verfügbarkeit maximieren und Datenverluste verhindern.
Selbst in einem System mit zwei Knoten, die durch ein Cross-Kabel verbunden sind, ist es unmöglich, endgültig zwischen einem Netzwerkabbruch und dem Ausfall eines anderen Knotens zu unterscheiden. Ein Abbruch an einem Ende (dessen Wahrscheinlichkeit definitiv proportional zur Entfernung zwischen den Knoten ist) reicht aus, um jede Annahme zu widerlegen, dass die Funktionalität des Kanals dem Zustand des Partnerknotens entspricht.

Einen Cluster aus zwei Knoten zum Laufen bringen

Manchmal kann der Kunde einen dritten Knoten nicht kaufen oder möchte das nicht, und wir müssen nach einer Alternative suchen.

Option 1 – Duplizierungsmethode zur Abgrenzung

Das iLO- oder IPMI-Gerät eines Knotens stellt einen Single Point of Failure dar, denn im Falle eines Ausfalls können die verbleibenden Knoten es nicht verwenden, um den Knoten in einen sicheren Zustand zu versetzen. In einem Cluster mit 3 oder mehr Knoten können wir dies durch Berechnung des Quorums und den Einsatz eines Hardware-Watchdogs mildern (ein Mechanismus der indirekten Abgrenzung, wie zuvor besprochen). Bei zwei Knoten müssen wir stattdessen Netzschalter (Power Distribution Units oder PDUs) verwenden.

Nach einem Ausfall versucht der überlebende Knoten zunächst, eine Verbindung zum Hauptabgrenzungsgerät (integriertes iLO oder IPMI) herzustellen. Wenn dies erfolgreich ist, wird die Wiederherstellung wie gewohnt fortgesetzt. Nur im Fall eines Ausfalls des iLO-/IPMI-Geräts wird die PDU kontaktiert, und wenn der Kontakt erfolgreich ist, kann die Wiederherstellung fortgesetzt werden.

Stellen Sie sicher, dass Sie das PDU in ein Netzwerk einfügen, das von dem Cluster-Traffic getrennt ist, da sonst ein einzelner Netzwerkfehler den Zugriff sowohl auf die Aufteilungseinrichtungen als auch auf die Wiederherstellung der Dienste blockiert.

Hier können Sie fragen – ist das PDU-Gerät nicht der einzige Ausfallpunkt? Die Antwort lautet – natürlich ist es das.

Wenn dieses Risiko für Sie erheblich ist – Sie sind nicht allein: Schließen Sie beide Knoten an zwei PDUs an und weisen Sie der Cluster-Software an, beide beim Ein- und Ausschalten der Knoten zu verwenden. Jetzt bleibt der Cluster aktiv, wenn ein PDU ausfällt, und um die Wiederherstellung zu blockieren, ist ein zweiter Ausfall entweder eines anderen PDUs oder des IPMI-Geräts erforderlich.

Option 2 – Hinzufügen eines Schiedsrichters

In einigen Szenarien, obwohl technisch die Methode der doppelten Aufteilung möglich ist, ist sie politisch kompliziert. Viele Unternehmen ziehen eine klare Trennung zwischen Administratoren und Anwendungsbesitzern vor, und sicherheitsbewusste Netzwerkadministratoren sind nicht immer begeistert davon, jemandem den Zugriff auf das PDU zu ermöglichen.

In diesem Fall wird als empfohlene Alternative die Schaffung einer neutralen dritten Partei empfohlen, die die Berechnung des Quorums ergänzen kann.

Im Falle eines Ausfalls sollte der Knoten in der Lage sein, den Kanal seines Partners oder Schiedsrichters zu sehen, um die Dienste wiederherzustellen. Der Schiedsrichter enthält auch eine Funktion zum Trennen der Verbindung, wenn beide Knoten den Schiedsrichter sehen können, sich aber nicht gegenseitig sehen.

Diese Option sollte in Kombination mit einem indirekten Aufteilungsverfahren verwendet werden, wie einem Hardware-Watchdog-Timer, der so eingestellt ist, dass er die Maschine ausschaltet, wenn sie die Verbindung zu ihrem Partnerknoten und Schiedsrichter verliert. So kann der Überlebende mit ausreichender Sicherheit annehmen, dass sein Partnerknoten nach Ablauf des Hardware-Watchdog-Timers in einem sicheren Zustand sein wird.

Der praktische Unterschied zwischen einem Schiedsrichter und einem dritten Knoten besteht darin, dass der Schiedsrichter viel weniger Ressourcen für seine Funktion benötigt und potenziell mehrere Cluster bedienen kann.

Option 3 – Menschlicher Faktor

Der letzte Ansatz besteht darin, dass die Überlebenden weiterhin die Dienste ausführen, die sie bereits leisten, jedoch keine neuen starten, bis entweder das Problem von selbst behoben ist (Netzwerkwiederherstellung, Neustart des Knotens) oder jemand die Verantwortung für die manuelle Bestätigung übernimmt, dass die andere Partei tot ist.

Bonusoption

Habe ich bereits erwähnt, dass Sie einen dritten Knoten hinzufügen können?

Zwei Racks

Um der Argumentation willen, stellen wir uns vor, ich hätte Sie von den Vorteilen eines dritten Knotens überzeugt. Nun müssen wir die physische Anordnung der Knoten betrachten. Wenn sie (und die Stromversorgung) im selben Rack untergebracht sind, stellt dies ebenfalls einen SPoF dar, und das kann nicht einfach gelöst werden, indem ein zweites Rack hinzugefügt wird.

Wenn das erstaunlich ist, denken Sie daran, was passiert, wenn das Rack mit zwei Knoten ausfällt und wie der überlebende Knoten diesen Fall von einem Netzwerkfehler unterscheiden kann.

Die kurze Antwort: Das ist unmöglich, und wir haben wieder mit all den Problemen im Zusammenhang mit zwei Knoten zu tun. Entweder der Überlebende:

• ignoriert das Quorum und versucht fälschlicherweise, die Wiederherstellung während Netzwerkunterbrechungen zu initiieren (die Möglichkeit, eine Trennung zu beenden, ist eine separate Geschichte und hängt davon ab, ob der PDU beteiligt ist und ob sie die Leistung mit einem der Racks teilen), oder
• respektiert das Quorum und schaltet sich vorzeitig aus, wenn sein Partnerknoten ausfällt.

In jedem Fall sind zwei Racks nicht besser als eines, und die Knoten sollten entweder unabhängige Stromquellen erhalten oder auf drei (oder mehr, je nachdem, wie viele Knoten Sie haben) Racks verteilt werden.

Zwei Rechenzentren

Zu diesem Zeitpunkt könnten Leser, die nicht mehr risikobereit sind, über die Notfallwiederherstellung nachdenken. Was passiert, wenn ein Asteroid in ein Rechenzentrum mit unseren drei Knoten, die auf drei verschiedenen Racks verteilt sind, einschlägt? Offensichtlich schlechte Dinge, aber je nach Ihren Bedürfnissen könnte das Hinzufügen eines zweiten Rechenzentrums nicht ausreichend sein.

Wenn alles richtig gemacht wird, bietet das zweite Rechenzentrum Ihnen (und das ist vernünftig) eine aktuelle und konsistente Kopie Ihrer Dienste und deren Daten. Doch wie in Szenarien mit zwei Knoten und zwei Racks fehlen dem System die Informationen, um maximale Verfügbarkeit zu gewährleisten und Schäden (oder Abweichungen in den Datensätzen) zu verhindern. Selbst bei drei Knoten (oder Racks) lässt deren Verteilung auf nur zwei Rechenzentren das System unfähig zurück, zuverlässig die richtige Entscheidung im Falle eines (jetzt deutlich wahrscheinlicheren) Ereignisses zu treffen, das keine der beiden Seiten zuordnen kann.

Das bedeutet nicht, dass eine Lösung mit zwei Rechenzentren niemals geeignet ist. Unternehmen möchten häufig, dass jemand informiert ist, bevor ein außergewöhnlicher Schritt unternommen wird, um zu einem Backup-Rechenzentrum überzugehen. Denken Sie nur daran, dass, wenn Sie einen Ausfall automatisieren möchten, Sie entweder ein drittes Rechenzentrum benötigen, damit ein Quorum sinnvoll ist (direkt oder über einen Schiedsrichter), oder Sie einen Weg finden müssen, ein ganzes Rechenzentrum zuverlässig abzuschalten.

Quelle: habr.com