Cluster bauen macht kein Spaß. Allein wie unterschiedlich schon die Ansätze und Umsetzungen letzten Endes sind, kann einen ganz schön verwirren.
Durch das Lesen der Doku, versteht meiner einer allerdings mehr und mehr, wo was gebraucht wird. Im Falle meines Planes, Xen Hoch verfügbar zu »konstruieren«, stellen sich da diverse Probleme. Zum einen müssen alle Dom0 Rechner auf den gleichen Storage Poolzugreifen können, und zwar sowohl lesen, als auch schreibend(!). Dies ließe sich z.B. mittels NFS bewerkstelligen, allerdings passen NFS und Geschwindigkeit nicht wirklich zusammen. Des weiteren benötigt es eine Software, die dafür sorgt, dass die nötigen Schritte eingeleitet werden, bei einem Ausfall. Im Falle von Xen bedeutet dies, das ausgefallene DomUs auf anderen Dom0s hochgefahren werden.
ein weiteres Problem besteht im Storage selbst: dieser muss ebenfalls redundant sein. Nun gibt es da eine (an für sich) tolle Software: drbd. Diese Sofware synchronisiert Blockgeräte über ein Netzwerk hinweg. Anders formuliert, wenn sich auf Rechner1 ein Bit ändert, wandert dieses Bit auch auf Rechner 2. Also im Grunde nichts anderes, als ein Spiegel. Das Problem hierbei: nur einer lässt sich zur Laufzeit verwenden. Würde man auf beiden Rechnern diesen Datenträger einhängen (welcher über ein Dateisystem verfügt), würde dieses zielsicher zerlegt werden. Um dem vorzubeugen, unterbindet »drbd« dies, und lässt es nur zu, wenn der Primäre Spiegel nicht verfügbar ist. Wir lernen also, es gibt »primary« und »secondary«.
Das hilft uns allerdings nicht viel, denn wir möchten ja, zeitgleichen Zugriff auf dieses Blockgerät. Nun gibt es ab drbd 8.0.x die Möglichkeit, beide Spiegel auf »primary« zu setzen. Das versetzt uns in die Lage, auf beides Rechnern, diesen Datenträger einzubinden. Die Problematik was das Dateisystem angeht, wurde damit allerdings nicht entschärft, und hier kommt ein Clusterdateisystem zum Einsatz. Dieses regelt den syncronen Zugriff auf ein und die selben Datenstrukturen und verhindert, dass zwei Zugriffe von unterschiedlichen Rechnern, zur selben Zeit auf die selben Daten schreiben und damit ein inkonsistentes Dateisystem produzieren. Und genau hier hänge ich nun schon seit drei Tagen. Soviel zur Theorie.
Mir gelang es zwar, »drbd« aufzusetzen, aber bei dem mounten des Oracle Cluster Filesystems Version 2, gibt es nur eine Fehlermeldung. Dabei spielt es keine Rolle, ob als Linux ein SLES10sp1 werkelt, oder ein Debian Etch. Stellt sich also die Frage: wo liegt das Problem? Was »drbd« und »ocfs« gibt es zu hauf widersprüchliche Aussagen, die sehr an Voodoo grenzen und für meinen Geschmack nichts ist, was ich produktiv einsetzen wollte (nichts desto trotz, gibt es sie). Warte ich mal die Antwort von der »drbd« Mailingliste ab. Eventuelle werde ich daraus schlauer … ansonsten bleibt nur noch ocfs durch »gfs« zu ersetzen, was in der Komplexität noch ein Stück höher liegt …
Update
Von: Florian Haas (LINBIT Information Technologies GmbH)
An: drbd-user@lists.linbit.com
OCFS2 had a bug that prevented it from working correctly with DRBD. That
filesystem bug was fixed by our own Phil Reisner and is included in kernel
version 2.6.21 and up. Etch is on 2.6.18, SLES 10 is on a patched 2.6.16;
I’m not sure whether they backported Phil’s 2.6.21 fix to that.