Für sämtliche Fencing-Methoden gilt es, die passenden Vorbereitungen zu treffen. Was in Sachen Redundanz für den normalen Pacemaker-Betrieb gilt, gilt im Fencing-Kontext um so mehr: Die einzelnen Knoten eines Clusters sollten mehrere, voneinander unabhängige Kommunikationspfade haben. Kommt DRBD zum Einsatz, ist das meist kein größeres Problem: Häufig findet sich in Zwei-Knoten-Clustern mit DRBD ein eigener Back-to-Back-Link, über den die DRBD-Kommunikation läuft. Diese Verbindung zusammen mit der "normalen" Verbindung zur Außenwelt, über die der jeweils andere Clusterknoten ebenso erreichbar ist, sorgt für ein zuverlässiges redundantes Netzwerk-Setup. Denn damit alle Kommunikationspfade sterben, müsste einerseits der Switch kaputtgehen, über den die beiden Knoten kommunizieren. Und andererseits müsste auch die direkte Netzwerkverbindung Schaden nehmen, beispielsweise weil ein Chip auf einer Netzwerkkarte versagt. Kommunikationspfade heißen im Pacemaker-Kontext Ring, folglich ist ein Setup wie das beschriebene ein Redundant Ring Setup.
Auch wenn kein DRBD zum Einsatz kommt, sollte es mehr als einen Ring geben, über den die Clusterknoten miteinander kommunizieren können. Dabei sei vor Setups gewarnt, die letztlich wieder zu einem gemeinsamen Single Point of Failure führen: Zwei Kommunikationsringe, die durch denselben Switch führen, sind Augenwischerei, denn ein Ausfall des Switches bewirkt dann den Ausfall beider Kommunikationspfade.
DRBD beherrscht wie bereits erwähnt das Fencing auf Ressourcen-Ebene. Im Falle eines Falles hat Pacemaker so die Möglichkeit, die DRBD-Resource auf einem Clusterknoten temporär unbrauchbar zu machen. Das Feature ist nützlich, um Pacemaker bei Ausfall des DRBD-Replikationslinks richtig reagieren zu lassen.
Im Normalfall wird eine DRBD-Ressource auf dem einen Knoten die Primary-Rolle haben und auf dem anderen die Secondary-Rolle. Solange der Datenaustausch funktioniert und der Disk-State der Ressource auf den Knoten
»UpToDate
«
ist – überprüfen lässt sich das über den Inhalt von
»/proc/drbd
«
– ist für DRBD die Welt in Ordnung. Bricht der DRBD-Link allerdings weg, gerät die Replikationslösung in Schwierigkeiten. Denn dass der Secondary-Knoten dann immer weiter hinterherhinkt, bemerkt er nicht. Ohne fremden Eingriff wäre es denkbar, dass zu einem späteren Zeitpunkt der Primary-Knoten ausfällt, Pacemaker dann einen Failover durchführt und anschließend mit den alten Daten des Secondary-Knotens weiterarbeitet, der sich problemlos in die Primary-Rolle schalten lässt.