KVM Hochverfügbarkeits-Cluster mit 2 Nodes (Debian 9)

Autor: Silvester Langen

Für wen ist das Howto geeignet?

Dieses Howto richtet sich an interessierte Linuxfreunde mit fortgeschrittenem Kenntnisstand. Basics wie die Einrichtung der Netzwerkkarte, Vergabe einer IP oder mounten eines Dateisystems sollte hinreichend bekannt sein, da sie hier nicht erklärt werden. Ebenso sollte der User in der Lage sein auftretende Probleme selbsttätig zu lösen, falls das System nicht so reagiert wie erwartet.

Was genau ist ein Cluster?

Bei einem Cluster handelt es sich um einen Zusammenschluss mehrerer, jedoch mindestens zwei Server (Nodes). Die bekanntesten Möglichkeiten sind das Failover- und das Load-balancing-Cluster. Das Hochverfügbarkeits-Cluster (Failover-Cluster) ist dafür ausgelegt im Falle eines Ausfalls eines Knotenrechners (Node) einen anderen, quasi auf den Ausfall wartenden Server einzusetzen, um den Dienst aufrechtzuerhalten. Und dann gibt es noch das Lastenverteilungs-Cluster (Load balancing Cluster), was zur Lastenverteilung verwendet wird. Dabei werden zwei oder mehr Server zu einem Cluster zusammengefasst, wobei alle Server Primärsysteme sind und den selben Dienst anbieten. Eintreffende Anfragen werden vom Cluster-Management gerecht auf die einzelnen Nodes aufgeteilt, um die Last gleichmäßig auf das Cluster zu verteilen. Somit wird eine Überlastung eines einzelnen Knotenrechners verhindert.

Was genau wollen wir machen?

Wir möchten uns einen Hochverfügbarkeits-Cluster mit zwei Nodes bauen. Der Dienst, der aufrechterhalten bleiben soll ist die Bereitstellung und Aufrechterhaltung des Betriebes einer virtuellen Maschine. Etwas konkreter: Wir installieren KVM auf beiden Servern (Nodes) und sorgen dafür, dass bei einem Ausfall des Primärserver der Sekundärserver den Job übernimmt und die VM weiter betreibt. Damit die VM immer auf dem zweiten Server aktuell ist, nutzen wir DRBD, um sie auf den zweiten Server zu replizieren und somit immer einen Live-Zustand zu haben.

Wir installieren und konfigurieren dafür folgende Software:

• DRBD
• LVM
• KVM
• Pacemaker/Corosync

1. Systemvoraussetzungen

Ich setze voraus, dass wir bereits zwei funktionierende jungfräuliche Server mit einer frischen Debian Stretch Installation haben. Die Systeme sind aktualisiert und können sich gegenseitig anpingen. Außerdem müssen sie sich im selben Netzwerk befinden. In meiner Testumgebung habe ich die IPs 192.168.2.170 und 192.168.2.171 für die Server Node1 und Node2 gewählt. Eine gemeinsame Cluster-IP ist in diesem Fall nicht notwendig, da sie zur virtuellen Maschine gehört.

Außerdem brauchen wir auf der Festplatte noch einige GB Platz für eine eigene Partition, die wir später replizieren wollen. Oder besser noch eine ganze Festplatte. Die Vorgehensweise für die Replikation ist aber die gleiche, keine Sorge. Die Kapazität sollte auf beiden Servern möglichst gleich sein. In meiner Testumgebung hab ich einfach eine weitere Festplatte hinzugefügt (sdb)

2. Das System ein bisschen vorbereiten

Im ersten Schritt sorgen wir dafür, dass beide Server sich gegenseitig mit Namen kennen. Diesen Schritt auf beiden Servern ausführen:

#vi /etc/hosts

# Hosts File
192.168.2.170 node1.myserver.tld node1
192.168.2.171 node2.myserver.tld node2

3. DRBD

DRBD steht für Distributed Replicated Block Device. Es ist ein Kernelmodul mit einem Managementprogramm, was uns die Bedienung ermöglich. DRBD ist ein Mechanismus, der es uns möglich macht Block Devices (bspw. Festplatten) live über das Netzwerk zu spiegeln. Ein Raid-1, wenn man so will. In der Regel verwendet man es für Hochverfügbarkeit – so wie wir es jetzt nun einsetzen wollen.

Wir setzen hier eine Minimalkonfiguration ein, die funktioniert. „Fine Tuning“ kann man später immer noch vornehmen. Für den Produktiveinsatz ohnehin unerlässlich.

Außerdem ist es eine Master/Slave Konfiguration. Das bedeutet, dass ein Node der Master ist und alles repliziert wird, was auf seinem Blockdevice geschieht. Das andere Node ist der Slave und quasi nur der Empfänger, der immer eine Live-Kopie der Daten hat. Die Rollen können natürlich jederzeit getauscht werden, was für ein Failover-Cluster natürlich wichtig ist.

3.1 DRBD installieren und konfigurieren

Nun installieren wird DRBD. Ebenfalls wieder auf beiden Servern.

apt-get install drbd8-utils -y

Nach der Installation muss die Datei /etc/drbd.d/r0.res mit folgendem Inhalt angelegt werden. Sollten eure Hostnamen von meinen abweisen (bspw. server01 statt node1), dann unbedingt in der r0.res berücksichtigen. Ebenfalls die Partitionen und IPs der Hosts.

resource r0 {
on node1 {
device    /dev/drbd0;
disk      /dev/sdb1;
address   192.168.2.170:7789;
meta-disk internal;
}
on node2 {
device    /dev/drbd0;
disk      /dev/sdb1;
address   192.168.2.171:7789;
meta-disk internal;
}
}

3.2 Die Ressource aktivieren

Nach dem wir die Konfigurationsdatei geschrieben haben, können wir nun DRBD anweisen eine Ressource zu erstellen und diese dann zu aktivieren. Die ersten beiden Zeilen sind auf beiden Servern auszuführen. Die anderen beiden auf dem jeweiligen Server.

drbdadm create-md r0
drbdadm up r0
drbdadm primary –force r0

Diese vier Zeilen im Detail:
– Die erste Zeile erstellt eine Ressource „r0“ und nutzt die Einstellungen, die wir zuvor in der drbd.conf festgelegt haben (IP der Nodes, welche Festplatten verwendet werden etc.)
– Die zweite Zeile besagt, dass die Ressource „r0“ gestartet werden soll.
– Die dritte Zeile weist DRBD an, dass Node1 nun der Master ist.

Mit Eingabe der oben stehenden Zeilen sollte DRBD nun mit der Synchronisierung beginnen. Das kann man sich mit folgendem Befehl anschauen, der sich mit Strg+C abbrechen lässt.

watch cat /proc/drbd

Die Ausgabe sollte dann folgende Fortschrittanzeige ergeben:

version: 8.4.7 (api:1/proto:86-101)
srcversion: 0904DF2CCF7283ACE07D07A
0: cs:SyncTarget ro:Secondary/Primary ds:Inconsistent/UpToDate C r—–
ns:0 nr:11784 dw:11784 dr:0 al:8 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:10472576
[>………………..] sync’ed:  0.2% (10224/10236)M
finish: 1:12:43 speed: 2,356 (2,356) want: 4,200 K/sec

Wer das so hat, der hat alles richtig gemacht. Steht da irgendwo etwas von WFConnection (waiting for connection), dann sind beide Nodes noch nicht miteinander verbunden und er kann die Synchronisierung nicht beginnen. Da hilft, wenn man man die Verbindung auf beiden Nodes kurz kappt und dann neu aufbaut:

drbdadm disconnect r0
drbdadm connect r0

3.3 Manuelles Umschalten der Ressourcen

Dieser Step ist nur etwas Spielerei, um sich das DRBD und seine Tätigkeiten näher zu bringen. Es kann problemlos übersprungen werden. Aber es würde keine Schmerzen bereiten, wenn man es noch nicht kennt und einfach mal testen möchte. 🙂

In /dev/ gibt es nun ein neues Blockdevice, welches auf sdb bzw. sdb1 aufgesetzt ist. Ein Blick in „lsblk“ würde es aufzeigen. Das neue Blockdevice heißt nun drbd0 und ist ab jetzt verwendbar. Man kann es mit fdisk (cfdisk)  partitionieren oder direkt formatieren. So, wie man es will. Es ist danach mountbar und kann es normal wie jede andere Festplatte verwenden.

Das geht natürlich aber immer nur auf dem Node, der gerade Master ist. Der Slave kann dieses Blockdevice (drbd0) nicht mounten. Das System würde es sofort ablehnen. Bevor man also versucht den Node zwischen Master und Slave hin- und herzuschalten, muss man also Sorge dafür tragen, dass dieses Blockdevice (/dev/drbd0) keinen Falls gemountet ist. Wenn man der Anleitung bis hier her gefolgt ist und noch keine eigenen Spielereien gestartet hat, dann sollte das der Fall auch sein.

Eigentlich müsste nach den Zeilen von oben Node1 der Master und Node2 der Slave sein. Das können wir uns aber noch mal genauer anschauen mit (Abbruch mit Strg+C):

cat /proc/drbd

Der Node, der Master ist muss zum Slave gemacht werden. Und erst danach den Slave zum Master machen.

drbdadm secondary r0 drbdadm primary r0

Nun sollte es möglich sein auf dem Node2 (vorher war er Slave – jetzt Master) das Dateisystem von drbd0 zu mounten.

4. KVM

KVM steht für kernel-based Virtual Machine und basiert auf QEMU. Seit 2006 wurde es veröffentlich und ist seit Kernelversion 2.6.20 im Kernel enthalten. Seit 2008 gehört es Red Hat. Damit KVM betrieben werden kann ist eine CPU von Nöten, die Intel VT bzw. AMD-V unterstützt. Sollte die CPU nicht eine dieser beiden Virtualisierungserweiterungen besitzen so ist der Betrieb von KVM nicht möglich.

4.1 Installation

Tatsächlich ist die Installation und Konfiguration von KVM sehr leicht und geht schnell umzusetzen. Ich gehe jetzt davon aus, dass der Zustand Node1 = Master und Node2 = Slave wiederhergestellt worden ist. Mit folgender Zeile ist KVM zu installieren. Natürlich auf beiden Servern.

apt-get -y install qemu-kvm libvirt-daemon libvirt-daemon-system virtinst bridge-utils

Das war schon die Installation. Es braucht wenige Platz und ist leicht zu installieren. 🙂

4.2 Die Bridge erstellen

Wir müssen für KVM eine Bridge erstellen über die alle Netzwerkverbindung abgewickelt wird. Auch die Verbindung vom KVM-Wirt selbst (eth0) wird darüber laufen. Wir öffnen die Datei „interfaces“ und verändern sie nach folgendem Vorbild. Selbstverständlich ist die Netzwerkkonfiguration anzugleichen und das bitte auf beiden Servern.

# Auf Node1

auto eth0
iface eth0 inet manual

iface br0 inet static
address 192.168.2.170
network 192.168.2.0
netmask 255.255.255.0
broadcast 192.168.2.255
gateway 192.168.2.254
dns-nameservers 8.8.8.8
bridge_ports eth0
bridge_stp off
auto br0

# Auf Node2

auto eth0
iface eth0 inet manual

iface br0 inet static
address 192.168.2.171
network 192.168.2.0
netmask 255.255.255.0
broadcast 192.168.2.255
gateway 192.168.2.254
dns-nameservers 8.8.8.8
bridge_ports eth0
bridge_stp off
auto br0

Wie man hier sieht bekommt br0 die Netzwerkkonfiguration während eth0 nur noch auf manual gesetzt wird.

4.2 Das replizierte Laufwerk mounten

Im Moment ist das so, dass wir noch keine virtuelle Maschine haben. Das ist auch gut so, denn wir brauchen noch einen Step bis wir sie installieren können. Das Laufwerk oder Partition, was wir mit DRBD replizieren, muss noch in das Standartverzeichnis gemountet werden, sodass alle darin erstellten virtuellen Maschinen ab dem Moment zum Node2 repliziert werden. Das Standartverzeichnis für die VMs ist /var/lib/libvirt/images/. Falls noch nicht geschehen, so muss /dev/drbd0 mit einem Dateisystem formatiert und danach gemountet werden.

mkfs.ext4 /dev/drbd0
mount /dev/drbd0 /var/lib/libvirt/images

Ein df -h zeigt uns das gemountete replizierte Blockdevice an. Schaut zufriedenstellend aus. 🙂

4.2 Eine virtuelle Maschine erstellen

Ich zeige hier zwei Wege, wie man eine VM erstellen kann. Die herkömmliche Variante per Konsole und dann eine bequeme Möglichkeit per GUI. Egal womit wir die VM installieren wollen. Ein ISO auf dem Server wäre nicht schlecht. Dazu besucht man die Debian-Seite und sucht sich dort ein passendes Image aus, was man sich bspw. mit wget ziehen kann. Wer als VM CentOS möchte, der nimmt eben das oder oder oder. Es darf auch ein Windows ISO sein. Ich bevorzuge hier aber ein Debian 9, weil ich bereits ISOs dazu habe und speichere sie unter:

/var/lib/libvirt/ISOs/

Das Verzeichnis „ISOs“ habe ich vorher selbst angelegt, da es standartmäßig nicht existiert.

Per Konsole:
Eine VM kann mit einfachen Konsolenbefehlen installiert werden.

virt-install –name myvm01 –ram 1024 –disk path=/var/lib/libvirt/images/vm01.img,size=10 –vcpus 2 –os-type linux –os-variant debian9 –network bridge=br0 –graphics none –console pty,target_type=serial –cdrom=/var/lib/libvirt/ISOs/Debian9.iso –extra-args ‚console=ttyS0,115200n8 serial‘

Per GUI:

Ein Kinderspiel, wenn man es erst einmal gemacht hat. Da ich nur selten direkt am Server stehe und meist alles via SSH erledige, muss ich mir mein Virtual Machine Manager (VMM) per SSH auf meinen Arbeitsrechner holen. Wer das Glück hat und direkt an dem Server arbeiten kann, der installiert sich einfach schnell mit einem apt-get sein Paket virt-manager und kann es lokal starten. Wer es so machen muss wie ich befolgt die kommenden Schritte:

1. Xming herunterladen und installieren.
2. Putty starten
2.1 Den Hostnamen oder IP angeben
2.2 Links in der Leiste unter Connection das SSH erweitern
2.3 Dort X11 klicken und den Haken bei Enable X11 forwarding setzen.
2.4 Zurück zu Session und dort die Verbindung öffnen. Putty startet ganz normal wie immer.
3. apt-get install virt-manager
4. Ganz einfach virt-manager in Putty eingeben. Xming übernimmt den Rest und stellt die GUI parat.

Egal, ob per GUI oder Konsole. Die virtuelle Maschine wird debian9 heißen und die Konfigurationsdatei heißt automatisch debian9.xml. Das erst mal nur zur Kenntnisname, denn diese Information brauchen wir ganz am Schluss noch mal. Außerdem vergebe ich der VM die IP 192.168.2.199.

4.3 Konfigurationsdatei der VM übertragen

Nun haben wir dafür gesorgt, dass die virtuelle Festplatte der VM auf dem zweiten Server (Node2) immer in aktueller Form zur Verfügung steht. Das reicht aber noch nicht ganz, denn ohne Datei, die erst mal die Hardware und Einstellungen der VM definiert, kann diese VM nicht gestartet werden. Jetzt gibt es zwei Möglichkeiten:

• Wir kopieren immer die Datei vom Node1 aus /etc/libvirt/qemu/ heraus und rüber zu Node2 in das gleiche Verzeichnis.
• Wir replizieren das Verzeichnis /etc/libvirt/qemu von Node1 auf Node2.

Nun ist also die Konfigurationsdatei auf dem anderen Server. Das reicht so aber noch nicht. Nun müssen wir KVM die virtuelle Maschine bekannt machen. Danach schauen wir uns an, ob sie nun als VM erkannt wird und dass sie offline ist. Das geht mit einer Zeile:

virsh define /etc/libvirt/qemu/debian9.xml
virsh list –all

Der Schalter „list“ alleine reicht leider nicht aus. Man würde nur bereits laufende VMs sehen. Ein „–all“ muss dazu, um auch die ausgeschalteten VMs angezeigt zu bekommen.

Die zweite Möglichkeit ist vor allem interessant, wenn man immer wieder wechselnde (neue) VMs hat und keine Lust die .xml-Datei jedes mal zu kopieren. Für unseren Demonstrationszweck reicht mir eine Kopie. Wie das mit der Replikation funktioniert steht weiter oben beschrieben.

Jetzt haben wir einen Punkt erreicht, der einigen Usern schon mehr als reichen würde. Die Umschaltung im Falle des Falles könnte man auch per Hand machen…. ja… könnte… Nachts um 3… ? …!!! Es gibt Dinge auf die man wirklich gut verzichten kann. Und wann passiert noch mal der Ausfall?

• am Wochenende
• in der Nacht!
• oder kurz vor Feierabend

Das ist quasi ein ungeschriebenes Gesetz. 😉

5. Pacemaker/Corosync

Natürlich will man Nachts um 3 nicht an die Konsole und einen manuellen Switchover machen müssen, weil sich ein Server verabschiedet hat. Das müssen wir also noch hinbekommen, dass die Systeme das selbst feststellen und dann die Umschaltung auf den anderen Clusternode vornehmen. Dafür ist Pacemaker und Corosync zuständig. Bevor wir bei Pacemaker und Corosync ins Detail gehen installieren wir es vorher mit einem:

apt-get install libqb0 fence-agents pacemaker corosync pacemaker-cli-utils crmsh

Natürlich wieder auf beiden Servern installieren. Wer noch Jessie verwendet, der muss auf die Backports zurückgreifen, da die Entwickler damals den „Einsendeschluss“ verpasst haben und Pacemaker somit nicht Bestandteil von Jessie war. Mit Stretch ist diese Info aber wieder obsolet. Pacemaker ist in Stretch wieder enthalten.

5.1 Was ist Pacemaker und Corosync?

Die Corosync Cluster Engine stellt in Verbindung mit einigen anderen Softwarekomponenten, eine Überwachungsfunktion zur Verfügung und ist Dank Pacemaker befähigt Dienste wie MySQL-Datenbankserver, Apache, DRBD, Samba und viele andere zu starten und anzuhalten. Pacemaker und Corosync wird oft in einem Atemzug genannt, da beide sich sehr gut ergänzen. Die Installation und Konfiguration über Paketmanager wie Apt, Yum usw. ist leicht zu bewerkstelligen.

5.2 Konfiguration von Corosync

Da wir die Pakete bereits installiert haben können wir sofort mit der Konfiguration loslegen. Dazu öffnen wir die Konfigurationsdatei /etc/corosync/corosync.conf und füllen sie mit folgendem Inhalt. Der bestehende Inhalt kann problemlos gelöscht werden. Diese Aktion wieder auf beiden Servern durchführen.

totem {
version: 2
token: 3000
token_retransmits_before_loss_const: 10
clear_node_high_bit: yes
crypto_cipher: none
crypto_hash: none
transport: udpu
interface {
ringnumber: 0
bindnetaddr: 192.168.2.0
}
}
logging {
to_logfile: yes
logfile: /var/log/corosync/corosync.log
debug: off
timestamp: on
logger_subsys {
subsys: QUORUM
debug: off
}
}
quorum {
provider: corosync_votequorum
two_node: 1
wait_for_all: 1
}
nodelist {
node{
ring0_addr: 192.168.2.170
}
node{
ring0_addr: 192.168.2.171
}
}

Nun müssen wir dafür sorgen, dass für Corosync ein authkey generiert wird. Das ist immer so eine sportliche Sache. Das lässt sich in drei Schritten erledigen, wenn es ein wirklich sicherer Key sein soll. Der Authkey wird dabei nur auf einem Server generiert und danach auf den anderen Server rüberkopiert.

1. corosync-keygen ausführen
2. zweites Terminal öffnen und einen Editor starten
3. brutal viel Zeichen (Copy/paste von irgendwoher) x-fach dort reinpasten
4. so lange bis corosync-keygen sagt, dass er genug hat.

Alternativ kann man eine nicht ganz so sichere, aber wie ich finde immer noch sicher genug, Methode verwenden in dem man corosync-keygen -l (ein kleines „L“) ausführt. Es werden sich dann einfach zufällige Zeichen aus dem Random Data Source geholt. Ob nun die 4-stufige Prozedur oder der Einzeiler: Beide erzeugen eine Datei /etc/corosync/authkey. Jetzt müssen wir die Datei nur noch von Node1 zu Node2 kopieren und das lösen wir mit scp.

scp /etc/corosync/authkey root@node2:/etc/corosync/authkey

Jetzt Corosync und danach Pacemaker neu starten

service corosync start
service pacemaker start

Wenn alles richtig gelaufen ist, dann wird man, wenn man den Status von Corosync abruft feststellen, dass beide Knoten miteinander verbunden sind und als „online“ geführt werden. Die Eingabe von crm status sollte folgende Ausgabe zu Tage bringen.

Stack: corosync
Current DC: node2 (version 1.1.16-94ff4df) – partition with quorum
Last updated: Wed Aug 16 21:59:12 2017
Last change: Wed Aug 16 21:59:11 2017 by hacluster via crmd on node2

2 nodes configured
0 resources configured

Online: [ node1 node2 ]

No resources

5.3 Konfiguration von Pacemaker

Tatsächlich sind wir schon bald fertig mit unserem Cluster. Es fehlt nur noch die Konfiguration von Pacemaker. Schließlich wollen wir, dass er für uns die Resourcen umschaltet. Irgendwie müssen wir ihm verständlich machen welcher Node welche Dienste laufen hat und wie die Reihenfolge der Dienste ist, die gestartet werden müssen. Es bringt nichts zu versuchen die VM zu starten, wenn DRBD nicht auf „primary“ steht und das Dateisystem nicht gemountet ist. Das regeln wird in Pacemaker mit dem Cluster Resource Manager „crm“.

Wir öffnen nun das Command Line Interface (CLI) von CRM mit einer einfachen Eingabe in die Konsole:

crm configure

Nun sollte folgende Ausgabe zurückgegeben werden, die anzeigt, dass man sich innerhalb von CRM befindet:

crm(live) #

Das CLI ist interaktiv und man kann sich innerhalb dessen bewegen. Ein „ls“ zeigt uns die Möglichkeiten. Um die Konfiguration zu erreichen tippen wir innerhalb des CLI einfach ein: „configure“. Wir wechseln also innerhalb des CLI in den Konfigurationsbereich. Dort offenbart und ein weiteres „ls“ weitere Möglichkeiten, um damit zu arbeiten. Ein „quit“ entlässt uns aus dem CLI.

Das Schöne an CRM ist, dass wir auch direkt von der Konsole aus arbeiten können, wenn wir die Bereiche bereits kennen, die wir „betreten“ wollen. So reicht ein einfaches „crm configure“ uns zum gleichen Ziel zu kommen. Kurz noch mal zur Erinnerung an eine Passage weiter oben: Die virtuelle Maschine heißt bei mir debian9. Sollte eure einen anderen Namen haben so ist dieser unten in der Konfiguration von Pacemaker in der 6. Zeile ziemlich mittig anzupassen, da sonst Pacemaker versucht eine VM zu starten, die KVM aber nicht kennt.

Beginnen wir also die Konfiguration von Pacemaker. Die nachfolgenden Zeilen sind Zeile für Zeile am besten per Copy/Paste in den Server zu übertragen.

property stonith-enabled=false
property no-quorum-policy=ignore

primitive drbd_res ocf:linbit:drbd params drbd_resource=r0 op monitor interval=29s role=Master op monitor interval=31s role=Slave
primitive fs_kvm_res ocf:heartbeat:Filesystem params device=“/dev/drbd0″ directory=“/var/lib/libvirt/images“ fstype=“ext4″ op start interval=“0″ timeout=“60″ op stop interval=“0″ timeout=“120″
primitive res_virtdom_debian9 ocf:heartbeat:VirtualDomain params config=“/etc/libvirt/qemu/debian9.xml“ force_stop=“false“ op monitor interval=“30s“ timeout=“90s“ op start interval=“0″ timeout=“90s“ op stop interval=“0″ timeout=“5min“

ms ms_drbd drbd_res meta master-node-max=“1″ clone-max=“2″ clone-node-max=“1″ globally-unique=“false“ notify=“true“ target-role=“Master“
location drbd_on_node1 ms_drbd rule role=“master“ 100: #uname eq node1
group lvm_grp fs_kvm_res res_virtdom_debian9
colocation apache-deps inf: ms_drbd:Master lvm_grp
order app_on_drbd inf: ms_drbd:promote lvm_grp:start

commit

Nach dem „commit“ gibt CRM drei Warnungen raus. Die darf man ignorieren. Nun geben wir in der Konsole wieder „crm status“ ein und erhalten folgende Ausgabe:

root@server01:~# crm status
Stack: corosync
Current DC: server01 (version 1.1.16-94ff4df) – partition with quorum
Last updated: Thu Aug 17 08:38:18 2017
Last change: Thu Aug 17 08:38:08 2017 by root via crm_resource on server01

2 nodes configured
4 resources configured

Online: [ node1 node2 ]

Full list of resources:

Master/Slave Set: ms_drbd [drbd_res]
Masters: [ node1 ]
Slaves: [ node2 ]
Resource Group: lvm_grp
fs_kvm_res (ocf::heartbeat:Filesystem):    Started node1
res_virtdom_debian9        (ocf::heartbeat:VirtualDomain): Started node1

Bei genauerer Betrachtung ziehen wir also folgende Informationen für uns heraus:

1. Es sind 2 Nodes konfiguriert
2. Es sind 4 Resourcen konfiguriert
3. beide Nodes sind Online
4. Node1 ist Master
5. Node2 ist Slave
6. Das Filesystem ist auf Node1 gestartet (drbd0 primary und ext4 gemountet)
7. Die virtuelle Maschine ist auf Node1 gestartet.

5.4 Ausgiebig testen

5.4.1 Grundsteine für die Tests

Jetzt behauptet also Pacemaker, dass die VM auf Node1 gestartet ist. Das wollen wir natürlich mal ausprobieren. Wir starten also den Virt-Manager auf Node1 (siehe weiter oben, falls vergessen wie…) und öffnen uns darin die VM, um darin arbeiten zu können. Aha! Die VM scheint zu laufen. Der erste Test ist quasi abgeschlossen. 😉 Nun lassen wir uns die konfigurierte IP-Adresse der VM anzeigen. Wer mag, der installiert sich noch einen Apache2 Server und lässt sich per Browser die Defaultseite der VM anzeigen.

5.4.2 Genauere Beobachtungen im Failoverfall

Nun wollen wir doch sehen was Pacemaker & Co so machen, wenn es zum Ausfall von Node1 kommt. Damit wir uns das richtig schön anschauen können, schlage ich folgendes vor: Auf Node2 öffnen wir 4 zusätzliche Terminals (Putty), um alles gleichzeitig beobachten zu können. Pro Terminal öffnen wir wiederum ein Programm was uns ein Element unseres Systems zeigt wie es arbeitet. Ich gebe also das Terminal an und dahinter den Befehl Zwecks Beobachtung, den man einfach dort eingibt.

Terminal 1 -> „watch crm status“
Terminal 2 -> „watch cat /proc/drbd“
Terminal 3 -> „watch virsh list –all“
Ein „ping 192.168.2.199“ von einem unbeteiligten anderen Rechner aus. Bei Windows bekommt man den Dauerping mit -t.

Nun schalte ich Node1 einfach ab. Richtig den Schalter aus und simuliere damit einen Hardwaredefekt.

Ich erwarte nun folgende Dinge:

Terminal 1 zeigt mir den Ausfall (offline) von Node1 und dann den Wechsel der Dienst auf Node2.
Terminal 2 zeigt mir den Wechsel von „secondary/primary“ nach „primary/secondary“.
Terminal 3 zeigt mir, dass debian9 erst „shut off“ ist und dann „running“.
Der Ping zeigt mir ein kurzes Hängen nach dem ich Node1 ausgeschaltet habe bis die VM vollständig auf Node2 läuft.

Auch das sollte super funktioniert haben. Die VM ist also ausgefallen, weil Node1 kaputt ist. Node2 merkt das und startet alle nötigen Resourcen der Reihe nach bis letztendlich die VM wieder läuft.

5.4.3 Genauere Beobachtungen im Failbackfall

So, nun ist das aber so: Node1 ist ja ausgeschaltet. Node2 läuft und arbeitet. Genauer gesagt: die VM arbeitet und bietet ihre Dienste an. Es kommen Daten hinzu, werden gelöscht und verändert. Node1 merkt davon natürlich nichts. Sein Datenbestand ist asynchron zu Node2 und veraltet. Wir haben im Moment also eine Split Brain Situation. Was müsste nun geschehen, wenn Node1 wieder online kommt?

Wir öffnen 2 neue Terminals auf Node2:

Terminal 1 -> „watch crm status“
Terminal 2 -> „watch cat /proc/drbd“

Nun schalte ich Node1 wieder ein und lasse ihn hochfahren.

Ich erwarte nun folgende Dinge:

Terminal 1 zeigt mir, dass Node1 wieder online ist.
Terminal 2 zeigt mir einen Synchronisierungsvorgang.

Dabei erhält Node1 nun den aktuellen Datenbestand von Node2. Eine Umschaltung von Node2 auf Node1 findet aber nicht statt. Muss auch nicht, denn es spielt gar keine Rolle auf welchem Node die VM ausgeführt wird.

6. Weitere Gedanken

Wir haben einen guten Anfang für ein Hochverfügbarkeits-Cluster gebaut. Für den Produktivbetrieb in unternehmerischem Sinne reicht das so noch nicht ganz aus. Die Replikation von DRBD müsste beispielsweise über eine gesonderte Netzwerkverbindung stattfinden. Außerdem sollte man mehr als zwei Nodes betreiben, damit der einzelne Node für sich feststellen kann, ob er vom Cluster getrennt wurde und somit offline gehen muss. Und, und, und…

Ich hoffe es hat bei euch so funktioniert wie bei mir. Zeitgleich zum schreiben des HowTos habe ich die ganze Prozedur in meiner Testumgebung durchgespielt. Falls es noch Ergänzungen gibt oder ein Fehler entdeckt wurde, so bitte ich um entsprechende Kommentare bzw. eine Mail (silvester * familielangen.de) an mich. Vielen Dank für euer Interesse und viel Spaß mit dem Cluster. 😉