Hey Habr! Ich präsentiere Ihnen die Übersetzung des Artikels von Andrew Beekhof.
Viele Menschen bevorzugen Cluster mit zwei Knoten, weil sie konzeptionell einfacher erscheinen und außerdem 33 % günstiger sind als ihre Gegenstücke mit drei Knoten. Obwohl es durchaus möglich ist, einen guten Cluster aus zwei Knoten zusammenzustellen, führt eine solche Konfiguration in den meisten Fällen aufgrund nicht berücksichtigter Szenarien zu vielen nicht offensichtlichen Problemen.
Der erste Schritt bei der Erstellung eines Hochverfügbarkeitssystems besteht darin, einzelne Fehlerquellen, oft auch als „Points of Failure“ bezeichnet, zu finden und zu beseitigen SPoF (der Punkt des Versagens).
Es ist zu bedenken, dass es unmöglich ist, alle möglichen Ausfallrisiken eines Systems auszuschließen. Dies ist auf die Tatsache zurückzuführen, dass eine typische Risikoabwehr darin besteht, eine gewisse Redundanz einzuführen, was zu einer erhöhten Systemkomplexität und der Entstehung neuer Fehlerquellen führt. Deshalb gehen wir zunächst einen Kompromiss ein und konzentrieren uns auf Ereignisse, die mit einzelnen Fehlerquellen verbunden sind, und nicht auf Ketten zusammengehöriger und daher zunehmend unwahrscheinlicherer Ereignisse.
Angesichts der Kompromisse suchen wir nicht nur nach SPoF, sondern gleichen auch Risiken und Konsequenzen ab, wodurch die Schlussfolgerung darüber, was kritisch ist und was nicht, bei jedem Einsatz unterschiedlich sein kann.
Nicht jeder braucht alternative Stromlieferanten mit unabhängigen Stromleitungen. Allerdings zahlte sich die Paranoia für mindestens einen Kunden aus, als bei der Überwachung ein defekter Transformator entdeckt wurde. Der Kunde versuchte per Telefon, das Energieversorgungsunternehmen zu alarmieren, bis der defekte Transformator explodierte.
Ein natürlicher Ausgangspunkt besteht darin, mehr als einen Knoten im System zu haben. Bevor das System jedoch nach einem Ausfall Dienste auf den verbleibenden Knoten verschieben kann, muss es im Allgemeinen sicherstellen, dass die verschobenen Dienste nicht an anderer Stelle aktiv sind.
Ein Zwei-Knoten-Cluster hat keine Nachteile, wenn ein Fehler dazu führt, dass beide Knoten dieselbe statische Website bedienen. Die Dinge ändern sich jedoch, wenn das Ergebnis dazu führt, dass beide Parteien unabhängig voneinander eine gemeinsame Jobwarteschlange verwalten oder unkoordinierten Schreibzugriff auf eine replizierte Datenbank oder ein gemeinsames Dateisystem gewähren.
Um eine Datenbeschädigung infolge eines Ausfalls eines einzelnen Knotens zu verhindern, verlassen wir uns daher auf etwas namens "Dissoziation" (Fechten).
Das Prinzip der Dissoziation
Im Mittelpunkt des Dissoziationsprinzips steht die Frage: Kann ein konkurrierender Knoten Datenkorruption verursachen? Falls eine Datenbeschädigung ein wahrscheinliches Szenario ist, wäre es eine gute Lösung, den Knoten sowohl von eingehenden Anforderungen als auch vom dauerhaften Speicher zu isolieren. Der gebräuchlichste Ansatz zur Trennung besteht darin, die fehlerhaften Knoten zu trennen.
Es gibt zwei Kategorien von Dissoziationsmethoden, die ich nennen werde gerade и indirekt, aber sie können gleichermaßen aufgerufen werden aktiv и passiv. Direkte Methoden umfassen Aktionen seitens überlebender Peers, wie z. B. die Interaktion mit einem IPMI-Gerät (Intelligent Platform Management Interface) oder iLO-Gerät (ein Mechanismus zur Verwaltung von Servern bei fehlendem physischen Zugriff auf sie), während indirekte Methoden auf dem ausgefallenen Gerät basieren Knoten, um irgendwie zu erkennen, dass er sich in einem ungesunden Zustand befindet (oder zumindest die Wiederherstellung anderer Mitglieder zu verhindern) und zu signalisieren über die Notwendigkeit, den ausgefallenen Knoten zu trennen.
Quorum hilft sowohl bei der Verwendung direkter als auch indirekter Methoden.
Direkte Dissoziation
Im Falle einer direkten Dissoziation können wir das Quorum nutzen, um Dissoziationsrennen im Falle eines Netzwerkausfalls zu verhindern.
Mit dem Quorum-Konzept sind genügend Informationen im System vorhanden (auch ohne Verbindung zu seinen Peers), damit Knoten automatisch wissen, ob sie eine Dissoziation und/oder Wiederherstellung einleiten sollen.
Ohne ein Quorum gehen beide Seiten einer Netzwerkspaltung zu Recht davon aus, dass der andere tot ist, und werden versuchen, den anderen zu distanzieren. Im schlimmsten Fall gelingt es beiden Parteien, den gesamten Cluster herunterzufahren. Ein alternatives Szenario ist ein Deathmatch, eine Endlosschleife von Knoten, die auftauchen, ihre Peers nicht sehen, sie neu starten und die Wiederherstellung einleiten, nur um neu zu starten, wenn ihr Peer der gleichen Logik folgt.
Das Problem bei der Trennung besteht darin, dass die am häufigsten verwendeten Geräte aufgrund derselben Fehlerereignisse, auf die wir bei der Wiederherstellung abzielen möchten, nicht mehr verfügbar sind. Die meisten IPMI- und iLO-Karten sind auf den von ihnen gesteuerten Hosts installiert und nutzen standardmäßig dasselbe Netzwerk, was dazu führt, dass die Zielhosts glauben, dass andere Hosts offline sind.
Leider werden die Betriebsfunktionen von IPMI- und iLo-Geräten beim Gerätekauf selten berücksichtigt.
Indirekte Dissoziation
Das Quorum ist auch für die Verwaltung der indirekten Trennung wichtig. Wenn es richtig durchgeführt wird, kann das Quorum den Überlebenden die Annahme ermöglichen, dass verlorene Knoten nach einer bestimmten Zeitspanne in einen sicheren Zustand übergehen.
Bei dieser Konfiguration wird der Hardware-Watchdog-Timer alle N Sekunden zurückgesetzt, wenn das Quorum nicht verloren geht. Wenn der Timer (normalerweise mehrere Vielfache von N) abläuft, führt das Gerät einen unvorhergesehenen Ausschaltvorgang durch (kein Herunterfahren).
Dieser Ansatz ist sehr effektiv, aber ohne ein Quorum stehen im Cluster nicht genügend Informationen zur Verfügung, um ihn zu verwalten. Es ist nicht einfach, den Unterschied zwischen einem Netzwerkausfall und einem Ausfall eines Peer-Knotens zu erkennen. Der Grund dafür ist, dass Sie ohne die Möglichkeit, zwischen den beiden Fällen zu unterscheiden, gezwungen sind, in beiden Fällen das gleiche Verhalten zu wählen.
Das Problem bei der Auswahl eines Modus besteht darin, dass es keine Vorgehensweise gibt, die die Verfügbarkeit maximiert und Datenverluste verhindert.
- Wenn Sie davon ausgehen, dass ein Peer-Knoten aktiv ist, aber tatsächlich ausfällt, stoppt der Cluster unnötigerweise laufende Dienste, um den Verlust von Diensten vom ausgefallenen Peer-Knoten auszugleichen.
- Wenn Sie davon ausgehen, dass ein Knoten ausgefallen ist, es sich aber nur um einen Netzwerkfehler handelte und der Remote-Knoten tatsächlich funktionsfähig ist, dann melden Sie sich bestenfalls für einen zukünftigen manuellen Abgleich der resultierenden Datensätze an.
Unabhängig davon, welche Heuristik Sie verwenden, ist es trivial, einen Fehler zu erzeugen, der entweder zum Ausfall beider Seiten führt oder dazu führt, dass der Cluster die überlebenden Knoten herunterfährt. Wenn das Quorum nicht genutzt wird, wird dem Cluster tatsächlich eines der leistungsstärksten Werkzeuge in seinem Arsenal entzogen.
Wenn es keine andere Alternative gibt, besteht der beste Ansatz darin, die Verfügbarkeit zu opfern (hier bezieht sich der Autor auf das CAP-Theorem). Eine hohe Verfügbarkeit beschädigter Daten hilft niemandem, und der manuelle Abgleich verschiedener Datensätze macht auch keinen Spaß.
Quorum
Quorum klingt großartig, oder?
Der einzige Nachteil besteht darin, dass Sie für einen Cluster mit N Mitgliedern eine Verbindung zwischen N/2+1 Ihrer verbleibenden Knoten benötigen. Was in einem Cluster mit zwei Knoten nicht möglich ist, nachdem ein Knoten ausgefallen ist.
Was uns letztendlich zum Grundproblem mit zwei Knoten bringt:
Quorum macht in Clustern mit zwei Knoten keinen Sinn, und ohne es ist es unmöglich, zuverlässig die Vorgehensweise zu bestimmen, die die Verfügbarkeit maximiert und Datenverluste verhindert
Selbst in einem System aus zwei Knoten, die über ein Crossover-Kabel verbunden sind, ist es unmöglich, eindeutig zwischen einem Netzwerkausfall und einem Ausfall des anderen Knotens zu unterscheiden. Der Ausfall eines Endes (dessen Wahrscheinlichkeit natürlich proportional zum Abstand zwischen den Knoten ist) reicht aus, um jede Annahme zu widerlegen, dass der Zustand der Verbindung dem Zustand des Partnerknotens entspricht.
Damit ein Cluster mit zwei Knoten funktioniert
Manchmal kann oder will der Kunde keinen dritten Knoten erwerben und wir sind gezwungen, nach einer Alternative zu suchen.
Option 1 – Doppelte Dissoziationsmethode
Das iLO- oder IPMI-Gerät eines Knotens stellt einen Fehlerpunkt dar, da Überlebende es bei einem Ausfall nicht verwenden können, um den Knoten in einen sicheren Zustand zu versetzen. In einem Cluster mit 3 oder mehr Knoten können wir dies abmildern, indem wir das Quorum berechnen und einen Hardware-Watchdog verwenden (einen indirekten Trennungsmechanismus, wie zuvor erläutert). Im Falle von zwei Knoten müssen wir stattdessen Netzwerk-Stromverteilungseinheiten (PDUs) verwenden.
Nach einem Fehler versucht der Überlebende zunächst, Kontakt zum primären Trennungsgerät (eingebettetes iLO oder IPMI) aufzunehmen. Wenn dies erfolgreich ist, wird die Wiederherstellung wie gewohnt fortgesetzt. Nur wenn das iLO/IPMI-Gerät ausfällt, wird auf die PDU zugegriffen; wenn der Zugriff erfolgreich ist, kann die Wiederherstellung fortgesetzt werden.
Achten Sie darauf, die PDU in einem anderen Netzwerk als den Cluster-Verkehr zu platzieren, da sonst ein einzelner Netzwerkausfall den Zugriff auf beide Trennungsgeräte und die Wiederherstellung von Diensten blockiert.
Hier fragen Sie sich vielleicht: Ist die PDU ein Single Point of Failure? Darauf lautet die Antwort natürlich.
Wenn dieses Risiko für Sie erheblich ist, sind Sie nicht allein: Schließen Sie beide Knoten an zwei PDUs an und weisen Sie die Clustering-Software an, beim Ein- und Ausschalten der Knoten beide zu verwenden. Der Cluster bleibt jetzt aktiv, wenn eine PDU ausfällt, und ein zweiter Ausfall der anderen PDU oder des IPMI-Geräts ist erforderlich, um die Wiederherstellung zu blockieren.
Option 2 – Hinzufügen eines Schiedsrichters
In einigen Szenarien ist die Methode der doppelten Trennung zwar technisch möglich, aber politisch schwierig. Viele Unternehmen wünschen sich eine gewisse Trennung zwischen Administratoren und Anwendungseigentümern, und sicherheitsbewusste Netzwerkadministratoren sind nicht immer begeistert davon, PDU-Zugriffseinstellungen mit anderen zu teilen.
In diesem Fall besteht die empfohlene Alternative darin, einen neutralen Dritten zu schaffen, der die Quorumsberechnung ergänzen kann.
Im Falle eines Ausfalls muss ein Knoten in der Lage sein, die Funkwellen seines Peers oder Arbiters zu sehen, um Dienste wiederherzustellen. Der Arbiter enthält auch eine Trennfunktion, wenn beide Knoten den Arbiter sehen können, sich aber nicht sehen können.
Diese Option muss in Verbindung mit einer indirekten Trennungsmethode verwendet werden, z. B. einem Hardware-Watchdog-Timer, der so konfiguriert ist, dass er eine Maschine abschaltet, wenn sie die Verbindung zu ihrem Peer- und Arbiter-Knoten verliert. Daher kann ein Überlebender vernünftigerweise davon ausgehen, dass sich sein Peer-Knoten nach Ablauf des Hardware-Watchdog-Timers in einem sicheren Zustand befindet.
Der praktische Unterschied zwischen einem Arbiter und einem dritten Knoten besteht darin, dass ein Arbiter für den Betrieb weitaus weniger Ressourcen benötigt und möglicherweise mehr als einen Cluster bedienen kann.
Option 3 – Menschlicher Faktor
Der letzte Ansatz besteht darin, dass Überlebende weiterhin die Dienste ausführen, die sie bereits ausgeführt haben, aber keine neuen starten, bis sich entweder das Problem von selbst löst (Netzwerkwiederherstellung, Knotenneustart) oder eine Person die Verantwortung dafür übernimmt, manuell zu bestätigen, dass die andere Seite tot ist.
Bonusoption
Habe ich erwähnt, dass Sie einen dritten Knoten hinzufügen können?
Zwei Gestelle
Nehmen wir der Argumentation halber an, dass ich Sie von den Vorzügen des dritten Knotens überzeugt habe. Jetzt müssen wir uns mit der physischen Anordnung der Knoten befassen. Wenn sie im selben Rack untergebracht (und mit Strom versorgt) sind, handelt es sich ebenfalls um SPoF, der nicht durch das Hinzufügen eines zweiten Racks gelöst werden kann.
Wenn dies überraschend ist, überlegen Sie, was passieren würde, wenn ein Rack mit zwei Knoten ausfällt, und wie der überlebende Knoten zwischen diesem und einem Netzwerkausfall unterscheiden würde.
Die kurze Antwort lautet: Das ist nicht möglich, und wieder haben wir es mit allen Problemen im Zwei-Knoten-Fall zu tun. Oder Überlebender:
- ignoriert das Quorum und versucht fälschlicherweise, bei Netzwerkausfällen eine Wiederherstellung einzuleiten (die Fähigkeit zur vollständigen Trennung ist eine andere Geschichte und hängt davon ab, ob die PDU beteiligt ist und ob sie den Strom mit einem der Racks teilen), oder
- respektiert das Quorum und trennt sich vorzeitig, wenn sein Peer-Knoten ausfällt
In jedem Fall sind zwei Racks nicht besser als eins, und die Knoten müssen entweder eine unabhängige Stromversorgung erhalten oder auf drei (oder mehr, je nachdem, wie viele Knoten Sie haben) Racks verteilt sein.
Zwei Rechenzentren
An dieser Stelle möchten Leser, die nicht mehr risikoscheu sind, möglicherweise über eine Notfallwiederherstellung nachdenken. Was passiert, wenn ein Asteroid dasselbe Rechenzentrum trifft und unsere drei Knoten auf drei verschiedene Racks verteilt sind? Offensichtlich schlechte Dinge, aber je nach Ihren Anforderungen reicht das Hinzufügen eines zweiten Rechenzentrums möglicherweise nicht aus.
Wenn es richtig gemacht wird, stellt Ihnen das zweite Rechenzentrum (und das vernünftigerweise) eine aktuelle und konsistente Kopie Ihrer Dienste und deren Daten zur Verfügung. Allerdings sind, wie in Zwei-Knoten- und Zwei-Rack-Szenarien, nicht genügend Informationen im System vorhanden, um maximale Verfügbarkeit sicherzustellen und Korruption (oder Datensatzdiskrepanzen) zu verhindern. Selbst bei drei Knoten (oder Racks) ist das System aufgrund der Verteilung auf nur zwei Rechenzentren nicht in der Lage, zuverlässig die richtige Entscheidung zu treffen, wenn ein (jetzt viel wahrscheinlicheres) Ereignis eintritt, über das beide Parteien nicht kommunizieren können.
Dies bedeutet nicht, dass eine Lösung mit zwei Rechenzentren niemals geeignet ist. Unternehmen möchten oft, dass eine Person darüber Bescheid weiß, bevor sie den außergewöhnlichen Schritt wagt und in ein Backup-Rechenzentrum umzieht. Bedenken Sie jedoch, dass Sie, wenn Sie den Ausfall automatisieren möchten, entweder ein drittes Rechenzentrum benötigen, damit das Quorum sinnvoll ist (entweder direkt oder über einen Schiedsrichter), oder dass Sie eine Möglichkeit finden, die gesamten Daten zuverlässig herunterzufahren Center.
Source: habr.com