Der in Teil 1 aufgebauten Heartbeat-Cluster soll nun ein Aufgabe bekommen: hochverfügbarer NFS-Server mit lokalem Storage. Was sind die wichtigen Parameter dabei?
- eine gemeinsame Cluster-IP unter der die Clients die NFS-Shares mounten können
- das zu exportierende Dateisystem muß auf beiden Nodes lokal vorhanden sein
- das zu exportierende Dateisystem muß konstant zwischen den Nodes gespiegelt werden
- bei Ausfall eines Nodes muß der andere Node in der Lage sein das Dateisystem wie erwartet per NFS zu exportieren
Hier beitet sich DRBD an, Distributed Replicated Block Device, eine Technologie zur synchronen Replikation von Block Devices über das IP-Netzwerk. Pro Blech wird ein physikalisches Volume (eine Festplatte, eine RAID-Gruppe, ein USB-Stick oder sonstwas…) definiert, welches von DRBD verwaltet und synchronisiert wird. Im User-Space taucht ein neues Device auf, z.B. /dev/drbd0 und kann auf dem aktiven Node wie ein normales Device verwendet werden. Auf dem passiven Node ist das Device nicht mountbar, so lange bis mittels Heartbeat definiert wird, daß dieser Node das Dateisystem exklusiv mounten darf.
Wie funktioniert diese Replikation?
Simpel ausgedrückt: jeder Schreib-Zugriff auf das DRBD-Device macht den Umweg über den IP-Stack und damit auf den anderen Node. Jedes Bit wird also zweimal geschrieben, und erst wenn beide Maschinen die Daten korrekt auf die Platten geschoben haben, bekommt der User das entsprechende Feedback und der Schreibvorgang wird beendet.
Setup:
Auf beiden Nodes benötigen wir zwei neue Partitionen, eine für die Nutz-Daten und eine weitere für die DRBD Meta-Daten. Die Meta-Partition muß minimal 128MB groß sein, je nach Größe der Daten-Partition auch gerne größer. An “Frasier” und “Niles” habe ich der Einfachheit halber je einen USB-Stick angeschlossen und zwei Partitionen erstellt:
/dev/sdb1 mit 512MB für die Nutz-Daten/dev/sdb2 mit 256MB für die Meta-Daten
Folgendes ist auf beiden Nodes auszuführen:
root@frasier:~# apt-get install drbd8-utils
root@frasier:~# modprobe drbd
root@frasier:~# echo drbd >> /etc/modules
Die Konfiguration von DRBD wird in /etc/drbd.conf und /etc/drbd.d/* erledigt, wobei /etc/drbd.conf nur zwei include-Statements für /etc/drbd.d/* enthält und nicht weiter angepasst werden muß. Interessanter ist die Datei /etc/drbd.d/global_common.conf, wobei auch hier keine für das Beispiel notwendigen Änderungen vorzunehmen sind.
Für jede Ressource, die von DRBD verwaltet werden soll, wird eine spezielle Konfigurationsdatei in /etc/drbd.d/ angelegt und entsprechend benannt. Wegen dem include in /etc/drbd.conf muß jede Ressourcen-Datei *.res benannt werden.
/etc/drbd.d/r0.res:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
| resource r0 {
protocol C;
handlers {
pri-on-incon-degr "echo o > /proc/sysrq-trigger ; halt -f";
pri-lost-after-sb "echo o > /proc/sysrq-trigger ; halt -f";
local-io-error "echo o > /proc/sysrq-trigger ; halt -f";
}
startup {
degr-wfc-timeout 120; # 2 minutes.
}
disk {
on-io-error detach;
}
net {
}
syncer {
rate 1M;
al-extents 257;
}
on frasier {
device /dev/drbd0;
disk /dev/sdb1;
address 198.18.1.10:7788;
meta-disk /dev/sdb2[0];
}
on niles {
device /dev/drbd0;
disk /dev/sdb1;
address 198.18.1.11:7788;
meta-disk /dev/sdb2[0];
}
} |
Es wird eine Ressource r0 definiert und entsprechend konfiguriert. Die relevanten Teile der Konfiguration von oben nach unten:
1
2
3
4
5
| handlers {
pri-on-incon-degr "echo o > /proc/sysrq-trigger ; halt -f";
pri-lost-after-sb "echo o > /proc/sysrq-trigger ; halt -f";
local-io-error "echo o > /proc/sysrq-trigger ; halt -f";
} |
Was soll passieren, wenn DRBD zu starke I/O-Fehler feststellt? In diesem Beispiel ist die konsistenz der Daten vorrangig, daher schalte den Node ab und schreibe gar nichts mehr. Wer ein anderes Verhalten wünscht tausche die Befehle in den " " entsprechend aus.
1
2
3
4
| syncer {
rate 1M;
al-extents 257;
} |
Mit welcher Geschwindigkeit sollen die Daten zwischen den Nodes synchronisiert werden? Im Falle der USB-Sticks an “Frasier” und “Niles” hier nur mit maximal 1MB/s, doch falls entsprechend schnelle Links vorhanden sind (z.B. ein dedizierter Gigabit- oder 10-Gigabit-Link) wird hier ein Wert in Megabyte pro Sekunde angegeben.
1
2
3
4
5
6
| on frasier {
device /dev/drbd0;
disk /dev/sdb1;
address 198.18.1.10:7788;
meta-disk /dev/sdb2[0];
} |
Einen solchen Block gibt es pro Node einmal, hier werden die Devices und die IP-Adresse/DNS-Name des Nodes definiert. Wie oben beschrieben ist /dev/sdb1 die Partition für die Nutz-Daten und /dev/sdb2 für die Meta-Daten des DRBD reserviert.
Die Konfigurationen müssen auf allen Nodes identisch sein. Es bietet sich also an z.B. mit rsync das komplette /etc/drbd.d/ zu übertragen. Jetzt wird es Zeit das DRBD-Device zu initialisieren:
root@frasier:~# drbdadm create-md r0
root@niles:~# drbdadm create-md r0
root@frasier:~# drbdadm up all
root@niles:~# drbdadm up all
root@frasier:~# drbdsetup /dev/drbd0 primary -o
root@frasier:~# mkfs.ext3 /dev/drbd0
root@frasier:~# mkdir /data
root@niles:~# mkdir /data
root@frasier:~# mount -t ext3 /dev/drbd0 /data
Im Hintergrund hat das DRBD schon begonnen die Devices zu synchronisieren, was man mit cat /proc/drbd beobachten kann. Sobald der initiale Transfer abgeschlossen ist, wird es Zeit den zugehörigen Service zu starten. Damit ist die Konfiguration von DRBD beendet und es fehlt nur noch die Anpassung des Heartbeats.
root@frasier:~# /etc/init.d/drbd start
root@niles:~# /etc/init.d/drbd start
Sowohl die DRBD Ressource r0 als auch das Filesystem werden als Cluster-Ressource in der Datei /etc/ha.d/haresources auf beiden Nodes verankert.
/etc/ha.d/haresources:
1
2
3
4
| frasier IPaddr2::198.18.0.1/32/eth0 \
drbddisk::r0 \
Filesystem::/dev/drbd0::/data::ext3 \
nfs-kernel-server |
Auf “frasier” ist /data bereits gemountet, der NFS-Server wird mit entsprechenden Einträgen in /etc/exports direkt loslegen können. Auf “niles” läuft kein NFS-Server und /data ist ein leerer Mountpoint. Sobald “frasier” zur Wartung abgeschaltet wird oder ausfällt, wird Heartbeat auf “niles” erst das Dateisystem mounten und anschließend den NFS-Server starten. Richtig geraten, die Reihenfolge in /etc/ha.d/haresources spielt eine Rolle. 
→ Zurück zur Übersicht.
DRBD, HA, Linux, NFS
Ein active/passive HA-Cluster mit verschiedenen Cluster-Ressourcen, die immer nur auf dem aktiven Node ausgeführt werden. Alle weiteren Nodes dienen ausschließlich zu Standby Zwecken.
Ein active/active HA-Cluster, auf dem mehrere Cluster-Ressourcen auf mehreren Nodes ausgeführt werden. Im Ausfall-Moment werden die ausfallenden Ressourcen auf die übrigend Nodes verteilt. (Die Anzahl und Leistungskraft der Nodes sollte entsprechend gewählt werden, daß bei Ausfall oder Wartung eines Nodes die verbleibenden Nodes die Aufgaben erledigen können.)
