Das Pacemaker-Setup abschließen

Damit ist die DRBD-Konfiguration in Pacemaker ebenso vorhanden wie die Konfiguration der virtuellen Maschine. Es gilt noch, die beiden Ressourcen miteinander so zu verbinden, dass sie stets auf dem gleichen Host laufen. Das geht mit einem Colocation- und einem Order-Constraint. Angenommen, die DRBD-Master-Slave-Ressource hieße »ms_drbd_VirtDom1« und die Resource für die VM selbst hieße »res_VirtDom1« , wäre ein passendes Setup dieses:

colocation c_virtdom1_on_drbd inf: res_VirtDom1 ms_drbd_VirtDom1:Master order o_drbd_before_virtdom1 inf: ms_drbd_VirtDom1:promote res_VirtDom1:start

Damit ist die virtuelle Maschine vollständig in Pacemaker integriert. Ob das Setup funktioniert, testen Admins, indem sie einen der beiden Knoten in den Standby-Modus setzen – idealerweise den, auf dem die VM gerade läuft – und nachvollziehen, ob die Maschine auf dem anderen Knoten gestartet wird ( Abbildung 4 ).

Abbildung 4: Dieser Cluster ist für den Betrieb dreier virtueller Maschinen eingerichtet und funktioniert wie gewünscht.

Live-Migration

Die verwendeten Komponenten dieses Setups bringen ab Werk alles mit, was es für Live-Migration braucht. Damit DRBD selbst diese Aufgabe erfüllen kann, sind im Vergleich zum Standard-Setup aber kleine Änderungen der Ressource zu erledigen. Denn damit Live-Migration funktionieren kann, muss DRBD sich im Dual-Primary-Modus befinden ( Abbildung 5 ). Unter normalen Umständen ist unbedingt davon abzuraten, DRBD im Dual-Primary-Modus zu betreiben. Ein Tech-Guide von LINBIT [1] , verfasst vom Autor dieses Artikels, listet die Nachteile dieses Setups auf. Im konkreten Beispiel führt an einer Lösung, in der die DRBD-Ressource auf beiden Seiten im Dual-Primary-Mode und damit beschreibbar ist, aber kein Weg vorbei. Denn für die Live-Migration muss KVM zumindest zwischenzeitlich auf beiden Seiten schreibend auf das Device zugreifen können. Eine vollständige Ressourcen-Konfiguration für diesen Einsatzzweck finden Sie in Listing 3 . Die außergewöhnlichen Teile sind hervorgehoben. Zusätzlich zu den Änderungen an der DRBD-Ressource ist auch die Regel für die Master-Slave-Ressource in Pacemaker zu ändern:

resource VirtDom1 {
volume 0 { device /dev/ drbd0; disk /dev/ system/ r0; meta-disk internal; }
net { after-sb-0pri discard-zero-changes; after-sb-1pri discard-secondary; after-sb-2pri disconnect; allow-two-primaries; }
on alice { address 192.168.0.1:7899; }
on bob { address 192.168.0.1:7899; } }

Abbildung 5: Live-Migration setzt voraus, dass die DRBD-Ressource wie hier zu sehen auf beiden Knoten im Primary-Modus läuft.

ms ms_drbd_VirtDom1 res_drbd_VirtDom1  meta master-max="<C>2<C>" master-node-max="1" clone-max="2" clone-node-max="1"  notify="true"

Schließlich ist für die VirtualDomain-Ressource in Pacemaker noch ein Meta-Parameter zu setzen. Diese komplette Zeile heißt »allow-migrate= "true"« und wird in die vorhandene Konfiguration eingefügt.

Nach diesen Änderungen ist das DRBD auf beiden Seiten des Clusters permanent primär. Der »crm resource migrate« -Befehl tut dann für die jeweilige virtuelle Maschine das Nötige. Aber Achtung: Der Befehl »migrate« tut nichts anderes, als in der CIB einen negativen Location-Constraint für den Host zu setzen, auf dem die Ressource bis zum Befehl gelaufen ist. Solange dieser Constraint in der CIB steht, kann die Ressource auf dem Ursprungsknoten deshalb nicht mehr gestartet werden. Mittels »crm configure edit« lässt sich der Constraint aber beseitigen; alternativ hilft auch »crm resource unmigrate« .