Nochmal: Erfahrungen mit verteilten Dateisystemen
Hallo,
ich hatte schon mal am 07.11.2012 ein Mail in diese Liste zum Thema
geschrieben.
Mittlerweile habe ich einige Tests durchgeführt.
Ausgangssituation:
2 Server sollen für Virtualisierung (KVM) genutzt werden. Jeder Server soll
alle Daten vorhalten so dass bei einem Hardware-Ausfall die VMs relativ einfach
von einer Maschine auf die andere umgezogen werden können. Die beiden Server
sind via 10 GE verbunden.
Auf jedem Server läuft Debian/Wheezy mit Kernel 3.8.12 aus Sid. Ich habe vier
VMs installiert, jede hat eine eigene DRBD-Ressource (Primary-Secondary
Betrieb). Das funktioniert alles prächtig. Die VM kann den Server (ich sage
dazu mal Dom0 auch wenn ich kein Xen verwende) wechseln, bisher habe ich sie
brav angehalten, den primary im DRBD geändert und dann wieder auf der anderen
Dom0 hochgefahren (VM einfrieren und RAM transferien muss ich noch testen).
Soweit war das auch nicht schwierig.
Was ich aber gerne haben möchte ich dass sich die VMs die Daten (/home) teilen.
Ich könnte jetzt einfach auf beiden Dom0's eine neue DRBD-Ressource anlegen,
ext4 formatieren und dann auf *einer* der Dom0's mounten und per NFS drauf zu
greifen. Aber ich finde das eigentlich blöd - ich möchte gerne von beiden
Maschinen aus auf die Datei zugreifen können.
Getestet habe ich:
- GlusterFS
geht, Perfomance ist unterirdisch
- ceph
scheint nicht wirklich stable zu sein, ist mir böse abgeschmiert und trotz
großer Mühen konnte ich die Daten nicht retten
- ocfs2
da bin ich gerade dran
Zu ocfs2 hatte ich folgende Ideen:
1. DRBD auf beiden Dom0's, das device wird raw über KVM in die DomU's
durchgereicht
2. DRBD auf beiden Dom0's, ocfs2 wird in den Dom0's gemounted und über NFS frei
gegeben
zu 1:
Habe ich mit verschiedenen Kernel-Versionen getestet. Sobald ich mit bonnie
Last auf das FS gebe dauert es max. 30 Sekunden bis das drbd aus dem Tritt
kommt:
May 6 14:50:55 adler kernel: [ 4672.053033] d-con r0: BAD! BarrierAck #9985 received, expected #9983!
May 6 14:50:55 adler kernel: [ 4672.053164] d-con r0: peer( Primary -> Unknown ) conn( Connected -> ProtocolError ) pdsk( UpToDate -> DUnknown )
Danach haben wir eine split brain Situation die man nur noch händisch
reparieren kann (und auf einer Dom0 muss ich dann die Daten des DRBD wegwerfen
lassen).
Leider habe ich keine Idee warum das passiert.
zu 2:
Habe ich vor allem mit Kernel 3.8.12 getest. Bonnie läuft einige Minuten, dann
hängt alles. Nach 120 Sekunden kommt:
May 15 16:41:38 adler kernel: [ 724.387144] INFO: task jbd2/drbd0-36:4780 blocked for more than 120 seconds.
Dabei werden dann auch keine Daten mehr auf die block devices geschrieben oder
übers Netzwerk übertragen. Die Dom0's kann ich dann nur noch mit "echo b >
/proc/sysrq-trigger" neu starten, jeder normale reboot/shutdown Versuch
scheitert.
Testweise habe ich auf das DRBD device nur ein ext4 gemacht
(Primary/Secondary), auf nur einer Dom0 gemounted und dann alle vier DomUs über
NFS darauf zugreifen lassen. Das geht einwandfrei und mit super Performance.
Ich bin im Moment etwas ratlos wo die Probleme liegen und wie man das zum
Laufen bekommt. Über jede Erfahrung, Idee oder Rat wäre ich dankbar.
Viele Grüße
Meinhard
Reply to: