Projekt »Virtueller hochverfügbarer Linux-Server«, Teil 8
DRBD, KVM und Heartbeat
DRBD
In Version 8 hat sich in DRBD die Konfigurationsdatei leicht geändert. Auch die Tools haben an manchen Stellen eine andere Syntax. Zuerst benötigen wir aber die Konfigurationsdatei. Diese enthält Definitionen global und common sowie eine Definition pro Ressource (DRBD-Gerät). Der Abschnitt common vereinfacht die Konfiguration erheblich, da er für alle DRBD-Geräte gilt. Mit einem Gerät vm100 und unter Weglassen von Kommentaren und Leerzeilen kann die Datei so aussehen:
/etc/drbd.conf
global {
usage-count no;
}
common {
protocol C;
handlers {
pri-on-incon-degr "halt -f";
pri-lost-after-sb "halt -f";
}
syncer { rate 50M; }
startup {
wfc-timeout 60;
degr-wfc-timeout 60;
}
disk { on-io-error detach; }
net {
after-sb-0pri disconnect;
after-sb-1pri disconnect;
after-sb-2pri disconnect;
}
}
resource vm100 {
on erdbeere {
device /dev/drbd0;
disk /dev/mapper/vg0-vm100;
address 192.168.2.1:7780;
meta-disk internal;
}
on himbeere {
device /dev/drbd0;
disk /dev/mapper/vg0-vm100;
address 192.168.2.2:7780;
meta-disk internal;
}
}
Diese Datei muss auf beiden Rechnern immer identisch sein! Jetzt können wir auf beiden Servern das Gerät initialisieren:
drbdadm create-md vm100 drbdadm up vm100
Nur auf einem von beiden dürfen wir das folgende Kommando ausführen. Damit bestimmen wir diesen Rechner zum primären Knoten für diese Ressource.
drbdadm -- --overwrite-data-of-peer primary vm100
Nun haben wir das Blockgerät /dev/drbd0, das wir auf dem Primärrechner mit fdisk formatieren und dann eine virtuelle Maschine (VM) damit starten könnten. Oder wir starten die virtuelle Maschine direkt und erledigen die Partitionierung innerhalb - so würde man vorgehen, wenn man eine Distribution in der VM installieren würde.
Doch statt /dev/drbd0 direkt zu verwenden, entschied ich mich dafür, dieses Gerät mit xfs zu formatieren, dann eine Datei mit nahezu der gleichen Größe wie das Dateisystem anzulegen und diese Datei der VM als Festplatten-Image zur Verfügung zu stellen. Dies hört sich kompliziert an und es dauert auch eine Weile, wenn das Dateisystem groß ist, doch könnte es flexibler sein. Beide Methoden sind möglich und es bleibt noch zu messen, welche Auswirkungen dies auf die Geschwindigkeit hat.
Infolgedessen verwendete ich folgende Kommandos, um das Dateisystem anzulegen und anschließend die Datei in diesem Dateisystem zu erstellen:
mkfs.xfs /dev/drbd0 mkdir -p /mnt/vm100 mount /dev/drbd0 /mnt/vm100 dd if=/dev/zero of=/mnt/vm100/vm100.image bs=1024k
Der letzte Befehl ist derjenige, der so lange dauert. Sei's drum. Man könnte zwar sehr schnell eine Datei mit Löchern (sparse file) anlegen, aber dann müssen die Löcher zur Laufzeit gefüllt werden, was vermutlich viel Leistung kostet.
Nun können wir eine erste Geschwindigkeitsmessung dieser Partition durchführen. hdparm liefert nur 20 MB/s als Ergebnis, doch habe ich mittlerweile festgestellt, dass die Werte von hdparm auf LVM-Partitionen nicht brauchbar sind. Messen wir lieber mit Bonnie++:
Version 1.03 ------Sequential Output------ --Sequential Input- --Random- -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP himbeere 512M 47149 96 145830 83 58398 44 41366 78 121283 43 341.5 2 ------Sequential Create------ --------Random Create-------- -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 16 3534 95 +++++ +++ 4017 98 3683 96 +++++ +++ 3431 97
145 MB/s ist doch schon ganz ordentlich, auch wenn die drei Platten zusammen auf 210 MB/s kommen könnten. Bei dieser Messung wurde aber noch nichts repliziert, weil der zweite Rechner noch nicht konfiguriert war.
