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.