Hallo, Habr! Ich präsentiere Ihnen die Übersetzung des Artikels Autor Andrew Beekhof.
Viele Menschen ziehen Cluster mit zwei Knoten vor, da sie konzeptionell einfacher erscheinen und zudem 33 % günstiger sind als ihre dreiknotenartigen Kollegen. Obwohl es durchaus möglich ist, ein gutes Cluster aus zwei Knoten zu erstellen, führt diese Konfiguration in den meisten Fällen aufgrund unberücksichtigter Szenarien zu einer Vielzahl von unvorhersehbaren Problemen.
Der erste Schritt zum Aufbau eines hochverfügbaren Systems besteht darin, einzelne Fehlerpunkte zu identifizieren und zu beseitigen, die häufig 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 eliminieren. Dies ergibt sich zumindest aus der Tatsache, dass typischerweise der Schutz vor Risiko durch die Einführung gewisser Redundanzen erfolgt, was zu einer erhöhten Systemkomplexität und der Entstehung neuer Fehlerpunkte führt. Daher gehen wir von Anfang an einen Kompromiss ein und konzentrieren uns auf Ereignisse, die mit einzelnen Fehlerpunkten verbunden sind, anstatt auf Ketten verbundener und folglich immer unwahrscheinlicherer Ereignisse.
Bei der Berücksichtigung von Kompromissen suchen wir nicht nur nach SPoF, sondern wägen auch Risiken und Konsequenzen ab. Daraus ergibt sich, dass das, was kritisch ist und was nicht, je nach Deployment unterschiedlich sein kann.
Nicht jeder benötigt alternative Stromanbieter mit unabhängigen Stromleitungen. Während Paranoia sich für mindestens einen Kunden rentiert hat, als deren Überwachung einen defekten Transformator entdeckte. Der Kunde rief an, um das Energieunternehmen zu warnen, bis der defekte Transformator explodierte.
Ein natürlicher Ausgangspunkt ist, dass das System mehr als einen Knoten hat. Bevor das System jedoch Dienste auf den verbleibenden Knoten nach einem Ausfall verschieben kann, muss in der Regel sichergestellt werden, dass die zu verschiebenden Dienste nicht an anderer Stelle aktiv sind.
Ein zwei Knoten Cluster hat keine Nachteile, wenn beide Knoten im Falle eines Ausfalls dieselbe statische Webseite bedienen. Doch alles ändert sich, wenn beide Seiten unabhängig eine gemeinsame Aufgabenwarteschlange verwalten oder unkoordinierten Schreibzugriff auf eine replizierte Datenbank oder ein gemeinsames Dateisystem gewähren.
Um Datenbeschädigungen durch den Ausfall eines Knotens zu vermeiden, verlassen wir uns auf das, was als «Abgrenzung» (fencing) bezeichnet wird.
Das Prinzip der Abgrenzung
Das Prinzip der Abgrenzung basiert auf der Frage: Kann ein konkurrierender Knoten Datenbeschädigungen verursachen? Wenn Datenbeschädigung ein wahrscheinliches Szenario darstellt, ist eine Isolation des Knotens sowohl von eingehenden Anfragen als auch von persistentem Speicher eine gute Lösung. Der gängigste Ansatz zur Abgrenzung besteht darin, defekte Knoten abzuschalten.
Es gibt zwei Kategorien von Abgrenzungsmethoden, die ich als direkt und indirekt, aber auch gleichermaßen als aktiv und passiv bezeichnet werden können.. Direkte Methoden umfassen Maßnahmen seitens der überlebenden Peer-Knoten, wie die Interaktion mit IPMI (Intelligent Platform Management Interface – eine Schnittstelle zum Fernüberwachen und Verwalten des physischen Zustands eines Servers) oder iLO (Management-Mechanismus für Server unter Bedingungen ohne physischen Zugriff), während indirekte Methoden auf den ausgefallenen Knoten angewiesen sind, um in irgendeiner Weise zu erkennen, dass er sich in einem ungültigen Zustand befindet (oder zumindest den Wiederherstellungsprozess anderer Mitglieder behindert) und ein Signal zu senden. zum Abschalten des ausgefallenen Knotens.
Quorum, hilfreich bei der Verwendung sowohl direkter als auch indirekter Methoden.
Direkte Abgrenzung
Bei der direkten Abgrenzung können wir ein Quorum nutzen, um Abgrenzungsrennen im Falle eines Netzwerkausfalls zu verhindern.
Mit dem Konzept des Quorums hat das System genügend Informationen (auch ohne Verbindung zu seinen Partnern), damit die Knoten automatisch wissen, ob sie eine Abgrenzung und/oder Wiederherstellung einleiten sollen.
Ohne ein Quorum gehen beide Seiten der Netzwerksegmentierung fälschlicherweise davon aus, dass die andere Seite offline ist, und versuchen, sich voneinander abzutrennen. Im schlimmsten Fall gelingt es beiden Seiten, den gesamten Cluster abzuschalten. Ein alternatives Szenario ist ein Deathmatch, ein endloser Zyklus von Knoten, die erscheinen, ihre Peers nicht sehen, sie neu starten und eine Wiederherstellung initiieren, nur um sich erneut neu zu starten, wenn ihr Peer dasselbe Prinzip durchläuft.
Das Problem mit der Abtrennung besteht darin, dass die häufigsten Geräte aufgrund derselben Ausfallereignisse, auf die wir uns zur Wiederherstellung stützen möchten, nicht mehr verfügbar sind. Die meisten IPMI- und iLO-Karten sind auf Hosts installiert, die sie verwalten, und verwenden standardmäßig dasselbe Netzwerk, was dazu führt, dass die Zielknoten annehmen, dass die anderen Knoten offline sind.
Leider werden die Besonderheiten des Betriebs von IPMI- und iLo-Geräten selten zum Zeitpunkt des Kaufs der Hardware berücksichtigt.
Indirekte Abtrennung
Das Quorum ist auch wichtig für das Management indirekter Abgrenzungen. Wenn alles richtig gemacht wird, kann das Quorum den Überlebenden ermöglichen anzunehmen, dass verlorene Knoten nach einer bestimmten Zeit in einen sicheren Zustand übergehen.
Bei dieser Einstellung wird der Hardware-Überwachungs-Timer alle N Sekunden zurückgesetzt, solange das Quorum nicht verloren geht. Wenn der Timer (normalerweise ein Vielfaches von N) abläuft, erfolgt eine ungraceful Abschaltung des Geräts (nicht ein Shutdown).
Dieser Ansatz ist sehr effektiv, aber ohne Quorum fehlen die notwendigen Informationen innerhalb des Clusters für dessen Verwaltung. Es ist nicht einfach zu unterscheiden, ob ein Netzwerk ausgefallen ist oder ob ein Partnerknoten ausgefallen ist. Der Grund, warum das wichtig ist, liegt darin, dass Sie ohne die Möglichkeit, die beiden Fälle zu unterscheiden, gezwungen sind, in beiden Fällen dasselbe Verhalten zu wählen.
Das Problem bei der Wahl eines einzelnen Modus besteht darin, dass es keinen Handlungsansatz gibt, der die Verfügbarkeit maximiert und den Datenverlust verhindert.
- Wenn Sie annehmen, dass der Partnerknoten aktiv ist, es aber tatsächlich zu einem Ausfall gekommen ist, wird der Cluster übermäßig Dienste stoppen, die zur Kompensation des Ausfalls des Partnerknotens hätten arbeiten sollen.
- Wenn Sie annehmen, dass der Knoten nicht funktioniert, es jedoch nur ein Netzwerkfehler war und der entfernte Knoten tatsächlich funktioniert, dann stimmen Sie im besten Fall einer zukünftigen manuellen Überprüfung der resultierenden Datensätze zu.
Unabhängig davon, welche Heuristik Sie verwenden, ist es trivial, einen Fehler zu erzeugen, der entweder beide Seiten in Betrieb hält oder den Cluster zwingt, überlebende Knoten herunterzufahren. Die Nichtnutzung eines Quorums beraubt den Cluster tatsächlich eines seiner mächtigsten Werkzeuge.
Wenn es keine andere Alternative gibt, ist der beste Ansatz, die Verfügbarkeit aufzugeben (hier verweist der Autor auf das CAP-Theorem). Hohe Verfügbarkeit fehlerhafter Daten hilft niemandem, und eine manuelle Überprüfung verschiedener Datensätze ist ebenfalls nicht erfreulich.
Quorum
Quorum klingt gut, oder?
Der einzige Nachteil besteht darin, dass, um ihn in einem Cluster mit N Knoten zu haben, eine Verbindung zwischen N / 2 + 1 Ihrer Knoten bestehen bleiben muss. Dies ist in einem Cluster mit zwei Knoten nach einem Ausfall eines Knotens nicht möglich.
Das führt uns letztendlich zu einem grundlegenden Problem bei zwei Knoten:
Das Quorum hat in Zwei-Knoten-Clustern keinen Sinn, und ohne es ist es unmöglich, den besten Handlungsverlauf zuverlässig zu bestimmen, um die Verfügbarkeit zu maximieren und Datenverlust zu 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. Das Trennen eines Endes (dessen Wahrscheinlichkeit zweifellos proportional zur Entfernung zwischen den Knoten ist) reicht aus, um jede Annahme zu widerlegen, dass die Verfügbarkeit des Kanals mit der Gesundheit des Partnerknotens übereinstimmt.
Einen Cluster aus zwei Knoten zum Laufen bringen
Manchmal kann oder möchte der Kunde keinen dritten Knoten dazukaufen, und wir müssen nach Alternativen suchen.
Option 1 – Duplizierende Fehlerisolationsmethode
Das iLO- oder IPMI-Gerät eines Knotens stellt einen Ausfallpunkt dar, da, im Falle eines Fehlers, die verbleibenden Knoten nicht in der Lage sind, ihn in einen sicheren Zustand zu versetzen. In einem Cluster aus drei oder mehr Knoten können wir dies durch die Berechnung des Quorums und die Verwendung eines Hardware-Watchdogs abmildern (ein indirekter Trennmechanismus, wie zuvor besprochen). Bei zwei Knoten müssen wir stattdessen Netzwechselstromverteilungseinheiten (Power Distribution Units oder PDUs) verwenden.
Nach einem Ausfall versucht der überlebende Knoten zuerst, mit dem Haupttrenngerät (integriertes iLO oder IPMI) zu kommunizieren. Wenn dies gelingt, läuft die Wiederherstellung wie gewohnt weiter. Nur im Falle eines Ausfalls des iLO/IPMI-Geräts wird der PDU kontaktiert, und wenn dieser Kontakt erfolgreich ist, kann die Wiederherstellung fortgesetzt werden.
Stellen Sie sicher, dass der PDU sich in einem von dem Cluster-Traffic verschiedenen Netzwerk befindet, da sonst ein einzelner Netzwerkfehler den Zugriff auf sowohl die Trenngeräte als auch die Wiederherstellung der Dienste blockiert.
Hier könnten Sie fragen – ist das PDU-Gerät nicht ein einzelner Ausfallpunkt? Darauf lautet die Antwort – natürlich ist es das.
Wenn dieses Risiko für Sie von Bedeutung ist, sind Sie nicht allein: Schließen Sie beide Knoten an zwei PDUs an und geben Sie der Cluster-Software an, beide beim Hoch- und Herunterfahren der Knoten zu verwenden. Dadurch bleibt der Cluster aktiv, selbst wenn ein PDU ausfällt, und für eine Wiederherstellung ist ein zusätzlicher Ausfall entweder des anderen PDUs oder des IPMI-Geräts erforderlich.
Option 2 – Hinzufügen eines Schiedsrichters
In manchen Szenarien, obwohl technisch möglich, ist die Methode der doppelten Abschottung politisch komplex. Viele Unternehmen legen Wert auf eine klare Trennung zwischen Administratoren und Anwendungsbesitzern, und Sicherheitsbewusste Netzwerkadministratoren sind nicht immer begeistert davon, dass jemand anderen Zugang zu den PDU-Einstellungen erhält.
In diesem Fall wird empfohlen, eine neutrale dritte Partei zu schaffen, die zur Quorum-Berechnung beiträgt.
Im Falle eines Ausfalls muss der Knoten in der Lage sein, den Partner oder den Schiedsrichter zu sehen, um die Dienste wiederherzustellen. Der Schiedsrichter beinhaltet auch eine Verbindungstrennfunktion, falls beide Knoten den Schiedsrichter sehen können, aber sich gegenseitig nicht sehen.
Diese Option sollte in Kombination mit einer indirekten Trennung verwendet werden, wie beispielsweise einem Hardware-Überwachungstimer, 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-Überwachungstimers in einem sicheren Zustand ist.
Der praktische Unterschied zwischen einem Schiedsrichter und einem dritten Knoten besteht darin, dass der Schiedsrichter deutlich weniger Ressourcen benötigt und potenziell mehr als ein Cluster bedienen kann.
Option 3 – Menschlicher Faktor
Der letzte Ansatz besteht darin, dass die Überlebenden weiterhin alle Dienste ausführen, die sie bereits durchgeführt haben, jedoch keine neuen Dienste 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 Seite tot ist.
Bonusoption
Habe ich bereits erwähnt, dass Sie einen dritten Knoten hinzufügen können?
Zwei Ständer
Um das Argument zu verdeutlichen, nehmen wir an, ich habe Sie von den Vorteilen des dritten Knotens überzeugt. Nun müssen wir die physische Standortwahl der Knoten betrachten. Wenn sie in derselben Rack untergebracht sind (und mit Strom versorgt werden), stellt das ebenfalls einen SPoF dar, den man nicht einfach durch Hinzufügen eines zweiten Racks lösen kann.
Wenn das überraschen klingt, denken Sie daran, was passiert, wenn das Rack mit den beiden Knoten ausfällt und wie der überlebende Knoten diesen Zustand von einem Netzwerkfehler unterscheiden wird.
Die kurze Antwort: Das ist unmöglich, und wir haben wieder mit all den Problemen zu kämpfen, die mit zwei Knoten verbunden sind. Entweder der Überlebende:
- ignoriert das Quorum und versucht fälschlicherweise, die Wiederherstellung während eines Netzwerkfehlers in Gang zu setzen (die Möglichkeit eines Split-Brain ist eine andere Geschichte und hängt davon ab, ob der PDU eingebunden ist und ob sie die Stromversorgung mit einem der Racks teilen), oder
- achtet auf das Quorum und schaltet sich vorzeitig ab, 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
An diesem Punkt könnten Leser, die nicht mehr risikofreudig sind, über Disaster Recovery nachdenken. Was passiert, wenn ein Asteroid in ein Rechenzentrum einschlägt, während unsere drei Knoten auf drei verschiedene Racks verteilt sind? Offensichtlich nichts Gutes, aber je nach Ihren Anforderungen könnte die Hinzufügung eines zweiten Rechenzentrums nicht ausreichen.
Wenn alles richtig gemacht wird, stellt das zweite Rechenzentrum Ihnen (und das ist sinnvoll) eine aktuelle und konsistente Kopie Ihrer Dienste und deren Daten zur Verfügung. Allerdings, wie in Szenarien mit zwei Knoten und zwei Racks, fehlt es dem System an Informationen, um maximale Verfügbarkeit zu gewährleisten und Beschädigungen (oder Abweichungen in Datensätzen) zu vermeiden. Selbst wenn drei Knoten (oder Racks) vorhanden sind, lässt deren Verteilung nur auf zwei Rechenzentren das System nicht in der Lage, zuverlässig die richtige Entscheidung im Falle eines (jetzt viel wahrscheinlicheren) Ereignisses zu treffen, das beide Seiten nicht miteinander verbinden können.
Das bedeutet nicht, dass eine Lösung mit zwei Rechenzentren niemals geeignet ist. Unternehmen möchten häufig, dass jemand informiert ist, bevor sie den außergewöhnlichen Schritt des Übergangs zu einem Backup-Rechenzentrum unternehmen. Beachten Sie einfach, dass Sie, wenn Sie einen Ausfall automatisieren möchten, entweder ein drittes Rechenzentrum benötigen, damit das Quorum Sinn macht (entweder direkt oder über einen Schiedsrichter), oder dass Sie einen Weg finden müssen, um das gesamte Rechenzentrum zuverlässig abzuschalten.
Quelle: habr.com
