Warum DRBD im Pacemaker-Cluster deaktivieren?

In der DRBD-Dokumentation (im Abschnitt Integrieren von DRBD in Pacemaker-Cluster ) wird empfohlen, DRBD in einem Pacemaker-Cluster zu deaktivieren:

Wenn Sie den DRBD-OCF-Ressourcenagenten verwenden, wird empfohlen, das Starten, Herunterfahren, Heraufstufen und Herabstufen von DRBD ausschließlich auf den OCF-Ressourcenagenten zu verschieben. Das bedeutet, dass Sie das DRBD-Init-Skript deaktivieren sollten : chkconfig drbd off.

Unter systemd würde dies betragen systemctl disable drbd.service.

Kann die Aktivierung von DRBD trotz dieser Empfehlung schaden? Die Idee wäre, DRBD zu aktivieren, aber Corosync und Pacemaker zu deaktivieren, damit ein Clusterknoten nach dem Ausfall und Neustart weiterhin DRBD-synchronisierte Daten empfängt, ansonsten aber "passiv" bleibt. Dies sollte ermöglichen, dass der ausgefallene Knoten analysiert wird, bevor er wieder in den Cluster eintreten kann. In der Zwischenzeit werden jedoch weiterhin Live-Daten auf beiden Clusterknoten gespeichert. Was ist die Begründung für die Empfehlung, die diese Begründung überwiegen würde?

Die Absicht, den DRBD-Dienst auf Betriebssystemebene zu deaktivieren, besteht darin, dass alles vom Schrittmacher gesteuert wird. Wenn zwei Dienste (z. B. PCMK und Ihr Betriebssystem) versuchen, zu starten / zu stoppen / zu fördern / herabzustufen usw., riskieren Sie Split-Brains. In einer kontrollierten Clusterumgebung sollte alles von Ihrem Cluster-Ressourcenmanager, in diesem Fall dem Schrittmacher, verwaltet werden, um Verwechslungen zwischen den Clusterknoten zu vermeiden. In einem Fall von Split-Brain oder ähnlichem wird Ihr CRM entweder STONITH oder Zaun oder das konfigurierte Quorum auf den anderen Knoten verwenden, um es aufzulösen.

Bei Verwendung eines Cluster-Ressourcenmanagers sollte jede Ressource vom Ressourcenmanager gesteuert werden. Jede Ressource, die außerhalb des Cluster-Ressourcenmanagers aktiviert / deaktiviert wird, kann sowohl für den Administrator als auch für den Ressourcenmanager selbst zu Verwirrung führen.

Es gibt bereits zwei Antworten, die deutlich machen, dass dies eine schlechte Idee ist und warum, aber vielleicht helfen einige Details, wie es für Sie schief gehen könnte und wie Sie Pacemaker verwenden können, um diese Probleme anzugehen, Sie und / oder andere davon zu überzeugen Dinge nicht so machen.

Zunächst protokolliert Pacemaker Ressourcenfehler und berücksichtigt diese. Die Standardfehleranzahl für eine Ressource, bevor sie von einem Knoten "gesperrt" wird, beträgt drei innerhalb des Zeitfensters für das Zeitlimit für Ressourcenfehler, das standardmäßig nie abläuft. Wenn Ihre DRBD-Ressource (oder eine andere Ressource) dreimal hintereinander ausfällt, wird sie von ihrem derzeit aktiven Knoten gesperrt, indem eine starke (unendliche) "negative Standortbeschränkung" verwendet wird. Dies bedeutet, dass die Ressource überall ausgeführt werden kann, ABER sein derzeit aktiver Knoten. Sobald diese Regel vorhanden ist, wird die Ressource entweder an einen anderen Ort verschoben, wenn dies möglich ist, oder sie wird angehalten, bis ihre Fehler behoben sind.

Sie sehen also, dass Pacemaker dazu gebracht werden kann, diese Fehler selbstständig zu behandeln.

Sie müssen verstehen, was Pacemaker ist und wie es sich verhält, um zu verstehen, warum die Verwaltung von Ressourcen, die den Status außerhalb von Pacemaker erzwingen, schlecht ist. Schrittmacher ist ein endliches Staatssystem. Es hängt davon ab, dass Sie die vollständige Kontrolle über die von ihm verwalteten Ressourcen haben, damit diese ordnungsgemäß nach Fehlern wiederhergestellt werden können und die Ressourcen entweder dort gestoppt oder gestartet werden, wo sie sein sollten.

Stellen Sie sich eine einfache Ressource vor, die jeweils nur auf einem Knoten ausgeführt werden sollte, damit sie nicht zu "Split-Brain" wird und ein divergierendes Dataset erstellt - fast das Schlimmste, was passieren kann, da dies mit ziemlicher Sicherheit entweder Datenverlust verursacht oder erfordert große Aufmerksamkeit des Bedieners, um Datenverlust zu vermeiden.

Pacemaker steuert diese Ressource und startet eine Instanz der Software auf dem Knoten "Able". Ein wohlmeinender Administrator stellt fest, dass der Dienst auf Able gestartet wurde, die systemd-Einheitendatei jedoch "deaktiviert" ist. Dieser Administrator aktiviert die Gerätedatei, sodass der Dienst beim Neustart "zurückkommt", ohne zu wissen, dass Pacemaker dies bereits erledigt. Die systemd-Einheitendatei ist so konfiguriert, dass die Ressource bei einem Fehler neu gestartet wird, so wie es viele sind.

Sobald Pacemaker versucht, diese Ressource von Able auf den zweiten Knoten im Cluster "Baker" zu migrieren, tritt bei der Ressource ein Stoppfehler auf, da der Dienst beendet wurde, aber irgendwie noch am Leben ist und wir uns mitten in einer Zombie-Apokalypse befinden. Da die Ressource nicht gestoppt werden kann, kann sie auf Baker nicht gestartet werden, ohne dass ein Split-Brain-Zustand auftritt. Die Ressource wechselt zwischen gestoppt und gestartet, während systemd und Pacemaker um die Kontrolle kämpfen. Schließlich "gibt" Pacemaker die Ressource auf und versetzt sie in den "nicht verwalteten Modus", was bedeutet, dass für diese Ressource keine Start- oder Stoppvorgänge ausgeführt werden.

In diesem Szenario gewann Systemd, weil es "dümmer und beharrlicher" war als Pacemaker. Dies ist für einen Administrator, der mit dem Verhalten von Pacemaker und Systemd nicht vertraut ist, äußerst schwierig zu verstehen, da es einfach so aussieht, als würde Pacemaker überall versagen - wenn es in Wirklichkeit genau das tut, was es unter den gegebenen Bedingungen tun soll zur Hand.

Bedenken Sie auch, dass das obige Szenario das bestmögliche Ende für diese Bedingung hatte. Bei dem geringsten Infrastrukturausfall wäre der Cluster mit dieser auf beiden Knoten aktiven Ressource zu einem Split-Brain geworden.

Abgesehen davon würde das Fechten über STONTIH verhindern, dass der Cluster in diesem Szenario zu einem Split-Brain wird, aber STONITH ist ein letzter Ausweg für die Clusterstabilität, während die oben genannte Bedingung ihn als fast ersten Ausweg darstellen würde. Und wie immer MÜSSEN Sie STONITH, um einen Cluster produktionsbereit zu machen.