Zwei-Knoten-Cluster - der Teufel im Detail

Hallo Habr! Ich präsentiere Ihnen die Übersetzung des Artikels "Zwei Knoten - Der Teufel steckt im Detail" von Andrew Beekhof.

Viele Menschen bevorzugen Cluster mit zwei Knoten, weil sie konzeptionell einfacher und 33% billiger erscheinen 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 zum Erstellen eines Hochverfügbarkeitssystems besteht darin, nach einzelnen Fehlerstellen zu suchen und diese zu beseitigen, die häufig als SPoF (Single Point of Failure) abgekürzt werden .

Es ist zu beachten, dass in jedem System nicht alle möglichen Ausfallrisiken ausgeschlossen werden können. Dies ergibt sich zumindest aus der Tatsache, dass ein typischer Risikoschutz die Einführung einer gewissen Redundanz ist, was zu einer Erhöhung der Komplexität des Systems und der Entstehung neuer Fehlerquellen führt. Daher gehen wir zunächst Kompromisse ein und konzentrieren uns auf Ereignisse, die sich auf einzelne Fehlerpunkte beziehen, und nicht auf Ketten verwandter und daher immer weniger wahrscheinlicher Ereignisse.

Angesichts der Kompromisse suchen wir nicht nur nach SPoF, sondern gleichen auch die Risiken und Konsequenzen aus. Daher ist die Schlussfolgerung, was kritisch ist und was nicht für jede Bereitstellung unterschiedlich sein kann.
Nicht jeder braucht alternative Stromversorger mit unabhängigen Stromleitungen. Obwohl sich Paranoia für mindestens einen Kunden ausgezahlt hat, als dessen Überwachung einen fehlerhaften Transformator feststellte. Der Kunde rief telefonisch an und versuchte, das Energieunternehmen zu warnen, bis ein defekter Transformator explodierte.

Der natürliche Ausgangspunkt ist das Vorhandensein von mehr als einem Knoten im System. Bevor das System die Dienste nach dem Fehler auf den überlebenden Knoten verschieben kann, müssen Sie im Allgemeinen sicherstellen, dass die zu verschiebenden Dienste an keinem anderen Ort aktiv sind.

Ein Cluster mit zwei Knoten hat keine Nachteile, wenn aufgrund eines Fehlers beide Knoten dieselbe statische Website bedienen. Alles ändert sich jedoch, wenn beide Parteien die Warteschlange für gemeinsam genutzte Jobs unabhängig voneinander verwalten oder unkoordinierten Schreibzugriff auf die replizierte Datenbank oder das gemeinsam genutzte Dateisystem gewähren.

Um eine Datenbeschädigung aufgrund des Ausfalls eines Knotens zu verhindern, verlassen wir uns daher auf das, was als "Dissoziation" (Fencing) bezeichnet wird.

Prinzip der Trennung


Das Prinzip der Trennung basiert auf der Frage: Kann ein konkurrierender Knoten Datenkorruption verursachen? Für den Fall, dass Datenbeschädigung ein wahrscheinliches Szenario ist, ist es eine gute Lösung, den Knoten sowohl von eingehenden Anforderungen als auch von dauerhaftem Speicher zu isolieren. Der häufigste Ansatz zum Deaktivieren ist das Deaktivieren fehlerhafter Knoten.

Es gibt zwei Kategorien von Trennmethoden, die ich direkt und indirekt nennen werde , aber sie können gleichermaßen als aktiv und passiv bezeichnet werden. Zu den direkten Methoden gehören Aktionen überlebender Peers, z. B. die Interaktion mit einem IPMI-Gerät (Intelligent Platform Management Interface - eine Schnittstelle zur Fernüberwachung und -verwaltung des physischen Status eines Servers) oder iLO (ein Serververwaltungsmechanismus ohne physischen Zugriff auf diese). Indirekte Methoden beruhen darauf, dass der ausgefallene Knoten irgendwie erkennt, dass er sich in einem fehlerhaften Zustand befindet (oder zumindest die Wiederherstellung der restlichen Mitglieder verhindert) und dem Hardware-Watchdog signalisiert, dass der ausgefallene Knoten getrennt werden muss.

Ein Quorum hilft bei direkten und indirekten Methoden.

Direkte Dissoziation


Im Falle einer direkten Dissoziation können wir ein Quorum verwenden, um Ausschlussrennen bei einem Netzwerkausfall zu verhindern.

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

Ohne Quorum gehen beide Seiten der Netzwerkfreigabe zu Recht davon aus, dass die andere Seite tot ist, und versuchen, die andere Seite zu trennen. Im schlimmsten Fall gelingt es beiden Seiten, den gesamten Cluster zu trennen. Ein alternatives Szenario ist Deathmatch, eine endlose Schleife von Knoten, die angezeigt werden, ihre Peers nicht sehen, sie neu laden und die Wiederherstellung nur für einen Neustart einleiten, wenn ihr Peer der gleichen Logik folgt.

Das Problem mit dem Ausschluss besteht darin, dass auf die am häufigsten verwendeten Geräte aufgrund derselben Fehlerereignisse, auf die wir uns bei der Wiederherstellung konzentrieren möchten, nicht mehr zugegriffen werden kann. Die meisten IPMI- und iLO-Karten werden auf den von ihnen gesteuerten Hosts installiert und verwenden standardmäßig dasselbe Netzwerk, weshalb die Zielknoten davon ausgehen, dass die anderen Knoten offline sind.

Leider werden die Funktionen des Betriebs von IPMI- und iLo-Geräten zum Zeitpunkt des Kaufs von Geräten selten berücksichtigt.

Indirekte Trennung


Ein Quorum ist auch wichtig für die Verwaltung des indirekten Ausschlusses. Wenn alles korrekt durchgeführt wird, können Überlebende durch ein Quorum davon ausgehen, dass die verlorenen Knoten nach einer bestimmten Zeit in einen sicheren Zustand übergehen.

Mit dieser Einstellung wird der Hardware-Watchdog-Timer alle N Sekunden zurückgesetzt, wenn das Quorum nicht verloren geht. Wenn der Timer (normalerweise ein Vielfaches von N) abläuft, führt das Gerät eine unansehnliche Abschaltung der Stromversorgung durch (keine Abschaltung).

Dieser Ansatz ist sehr effektiv, aber ohne Quorum gibt es nicht genügend Informationen im Cluster, um ihn zu verwalten. Es ist nicht einfach, den Unterschied zwischen einem Netzwerkausfall und einem Ausfall des Partnerhosts festzustellen. Der Grund dafür ist, dass Sie ohne die Fähigkeit, zwischen zwei Fällen zu unterscheiden, in beiden Fällen das gleiche Verhalten wählen müssen.

Das Problem bei der Auswahl eines Modus besteht darin, dass es keine Möglichkeit gibt, die Zugänglichkeit zu maximieren und Datenverlust zu verhindern.

  • Wenn Sie davon ausgehen, dass der Partnerknoten aktiv ist, aber tatsächlich ein Fehler aufgetreten ist, stoppt der Cluster unnötigerweise die Dienste, die funktionieren müssten, um den Verlust von Diensten des heruntergefallenen Partnerknotens auszugleichen.
  • Wenn Sie davon ausgehen, dass der Knoten nicht funktioniert, es sich jedoch nur um einen Netzwerkfehler handelt und der Remote-Knoten tatsächlich funktioniert, abonnieren Sie bestenfalls eine zukünftige manuelle Abstimmung der resultierenden Datensätze.

Unabhängig davon, welche Heuristik Sie verwenden, ist es trivial, einen Fehler zu erstellen, der entweder beide Seiten zum Arbeiten zwingt oder den Cluster dazu zwingt, die überlebenden Knoten zu trennen. Wenn Quorum nicht verwendet wird, wird dem Cluster eines der leistungsstärksten Tools in seinem Arsenal entzogen.

Wenn es keine andere Alternative gibt, wäre der beste Ansatz, die Zugänglichkeit zu opfern (hier verweist der Autor auf den CAP-Satz). Die hohe Verfügbarkeit beschädigter Daten hilft niemandem, und das manuelle Abgleichen verschiedener Datensätze ist ebenfalls kein Vergnügen.

Quorum


Quorum klingt großartig, oder?

Der einzige Nachteil ist, dass Sie die Verbindung zwischen N / 2 + 1 Ihrer Knoten beibehalten müssen, um sie in einem Cluster mit N Mitgliedern zu haben. Was ist in einem Cluster mit zwei Knoten nach dem Ausfall eines Knotens unmöglich?

Was uns letztendlich zu einem grundlegenden Problem mit zwei Knoten führt: Ein
Quorum ist in zwei Knotenclustern nicht sinnvoll, und ohne dieses ist es unmöglich, die Vorgehensweise, die die Zugänglichkeit maximiert und Datenverlust verhindert, zuverlässig zu bestimmen
Selbst in einem System von zwei Knoten, die durch ein Querkabel verbunden sind, ist es unmöglich, endgültig zwischen dem Trennen des Netzwerks und dem Ausfall eines anderen Knotens zu unterscheiden. Das Trennen eines Endes (dessen Wahrscheinlichkeit natürlich proportional zum Abstand zwischen den Knoten ist) reicht aus, um jede Annahme zu widerlegen, dass der Kanal gleich dem Zustand des Partnerknotens arbeitet.

Damit der Cluster aus zwei Knoten funktioniert


Manchmal kann oder will der Kunde keinen dritten Knoten kaufen, und wir sind gezwungen, nach einer Alternative zu suchen.

Option 1 - Doppelte Trennmethode


Das iLO- oder IPMI-Gerät des Knotens ist ein Fehlerpunkt, da Überlebende es im Falle eines Fehlers nicht verwenden können, um den Knoten in einen sicheren Zustand zu versetzen. In einem Cluster von 3 oder mehr Knoten können wir dies abmildern, indem wir das Quorum berechnen und den Hardware-Watchdog verwenden (ein indirekter Ausrückmechanismus, wie bereits erläutert). Bei zwei Knoten sollten stattdessen Netzwerk-Netzschalter (Stromverteilungseinheiten oder PDUs) verwendet werden.

Nach dem Fehler versucht der Überlebende zunächst, das primäre Trenngerät (integriertes iLO oder IPMI) zu kontaktieren. Wenn dies erfolgreich ist, wird die Wiederherstellung wie gewohnt fortgesetzt. Nur im Falle eines iLO / IPMI-Gerätefehlers erfolgt der Anruf an die PDU. Wenn der Anruf erfolgreich ist, kann die Wiederherstellung fortgesetzt werden.

Stellen Sie sicher, dass sich die PDU in einem anderen Netzwerk als dem Clusterverkehr befindet. Andernfalls blockiert ein einzelner Netzwerkfehler den Zugriff auf beide Isolationsgeräte und blockiert die Wiederherstellung von Diensten.

Hier fragen Sie sich vielleicht: Ist die PDU nicht ein einziger Fehlerpunkt? Worauf die Antwort natürlich lautet.

Wenn dieses Risiko für Sie erheblich ist, sind Sie nicht allein: Verbinden Sie beide Knoten mit zwei PDUs und weisen Sie die Cluster-Software an, beide beim Ein- und Ausschalten von Knoten zu verwenden. Jetzt bleibt der Cluster aktiv, wenn eine PDU ausfällt und ein zweiter Ausfall einer anderen PDU oder eines anderen IPMI-Geräts erforderlich ist, 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 komplex. Viele Unternehmen wünschen sich eine gewisse Trennung zwischen Administratoren und Anwendungsbesitzern, und sicherheitsbewusste Netzwerkadministratoren sind nicht immer begeistert davon, PDU-Zugriffsparameter an Dritte weiterzugeben.

In diesem Fall wird empfohlen, einen neutralen Dritten zu erstellen, der die Quorumberechnung ergänzen kann.

Im Falle eines Fehlers sollte der Knoten in der Lage sein, die Übertragung seines Partners oder Schiedsrichters zu sehen, um die Dienste wiederherzustellen. Der Arbiter enthält auch die Funktion zum Unterbrechen der Verbindung, wenn beide Knoten den Arbiter sehen können, sich aber nicht sehen.

Diese Option sollte in Verbindung mit einer indirekten Dissoziationsmethode verwendet werden, z. B. einem Hardware-Watchdog-Timer, der so konfiguriert ist, dass er den Computer ausschaltet, wenn er die Verbindung zu seinem Partnerknoten und dem Arbiter verliert. Somit kann der Überlebende sicher annehmen, dass sich sein Partnerknoten nach Ablauf des Hardware-Watchdog-Timers in einem sicheren Zustand befindet.

Der praktische Unterschied zwischen dem Arbiter und dem dritten Knoten besteht darin, dass der Arbiter viel weniger Ressourcen für seine Arbeit benötigt und möglicherweise mehr als einen Cluster bedienen kann.

Option 3 - Der menschliche Faktor


Der letzte Ansatz besteht darin, dass Überlebende weiterhin Dienste ausführen, die sie bereits ausgeführt haben, aber keine neuen Dienste starten, bis entweder das Problem selbst behoben ist (Netzwerkwiederherstellung, Neustart des Knotens) oder die Person nicht die Verantwortung dafür übernimmt, dies manuell zu bestätigen Die andere Seite ist tot.

Bonus Option


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

Zwei Gestelle


Stellen wir uns aus Gründen der Argumentation vor, ich hätte Sie von den Vorzügen des dritten Knotens überzeugt. Jetzt müssen wir den physischen Standort der Knoten berücksichtigen. Wenn sie im selben Rack platziert (und mit Strom versorgt) sind, stellt dies auch SPoF dar und eines, das nicht durch Hinzufügen eines zweiten Racks behoben werden kann.

Wenn dies überraschend ist, überlegen Sie, was passiert, wenn das Rack mit zwei Knoten ausfällt, und wie der überlebende Knoten zwischen diesem Fall und dem Netzwerkfehler unterscheidet.

Kurze Antwort: Dies ist nicht möglich, und wir beschäftigen uns erneut mit allen Problemen bei zwei Knoten. Oder Überlebender:

  • ignoriert das Quorum und versucht fälschlicherweise, die Wiederherstellung bei Netzwerkausfällen einzuleiten (die Möglichkeit, die Trennung abzuschließen, ist eine separate Geschichte und hängt davon ab, ob die PDUs beteiligt sind und ob sie die Stromversorgung von einem der Racks gemeinsam nutzen) oder
  • respektiert das Quorum und trennt sich vorzeitig, wenn sein Partnerknoten ausfällt

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

Zwei Rechenzentren


An diesem Punkt können Leser, die nicht mehr risikoscheu sind, in Betracht ziehen, sich von einem Unfall zu erholen. Was passiert, wenn ein Asteroid mit unseren drei Knoten, die auf drei verschiedene Racks verteilt sind, ein einzelnes Rechenzentrum betritt? Offensichtlich schlechte Dinge, aber abhängig von Ihren Anforderungen reicht das Hinzufügen eines zweiten Rechenzentrums möglicherweise nicht aus.

Wenn alles richtig gemacht wurde, bietet Ihnen das zweite Rechenzentrum (und das ist vernünftig) eine aktuelle und konsistente Kopie Ihrer Dienste und ihrer Daten. Wie in den Szenarien mit zwei Knoten und zwei Racks verfügt das System jedoch nicht über genügend Informationen, um maximale Verfügbarkeit sicherzustellen und Schäden (oder Abweichungen von Datensätzen) zu vermeiden. Selbst wenn drei Knoten (oder Racks) vorhanden sind, kann das System aufgrund ihrer Verteilung auf nur zwei Rechenzentren nicht zuverlässig die richtige Entscheidung treffen, wenn ein (jetzt viel wahrscheinlicheres) Ereignis auftritt, bei dem die beiden Seiten keine Verbindung herstellen können.

Dies bedeutet nicht, dass eine Lösung mit zwei Rechenzentren niemals passt. Unternehmen möchten häufig, dass die Mitarbeiter sich dessen bewusst sind, bevor sie beim Umzug in ein Backup-Rechenzentrum einen außergewöhnlichen Schritt unternehmen. Denken Sie daran, dass Sie, wenn Sie den Fehler automatisieren möchten, entweder ein drittes Rechenzentrum benötigen, damit das Quorum sinnvoll ist (entweder direkt oder über einen Arbiter), oder dass Sie einen Weg finden, das gesamte Rechenzentrum zuverlässig zu deaktivieren.

All Articles