Ich stelle fest…

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.

DRDB, OCFS2, EVMS, CLVM, GNDB, schlag-mich-tot

Hab ich ein Schlagwort vergessen? Macht nichts. Bin eh schon verwirrt genug. Ich habe bisher mit Clustern so rein garnichts zu tun gehabt. Doch bei Xen würde es sich natürlich anbieten, dies im Kurs mit aufzunehmen.
Also dachte ich mir: »Denny« sagte ich »Bau Dir dochmal einen Xen Cluster und schreibe dann eine Anleitung«. Soweit kein Problem, dachte ich. Gibt ja schon zu genüge (zumeist) englische Varianten davon. Nun habe ich mir im Vmware zwei normale SLES10sp1 Kisten installiert. Darin läuft erfolgreich ein DRDB mit zwei Nodes. Die SLES Kisten sollen nämlich dann den Storage bereitstellen, den dann zwei andere Rechner einbinden, um dort die Xen Images ablegen zu können.

So, jetzt bin ich mir aber im nächsten Schritt nicht sicher. Packe ich da jetzt das OCFS2 drauf? Im ersten Schritt will ich nur dafür sorgen, dass der Speicher redundant bleibt. Im Zweiten kommen dann zwei Debian Rechner, mit Xen 3.2 (wovor es mich schon graust, wenn ich an die ganzen Module denke, die mit rein sollen), die dann das OCFS2 einbinden. Damit könnte ich schonmal einer SLES10 Kiste das Licht ausknipsen, ohne dass dies eine Auswirkung auf laufende Xen Gäste haben sollte. Dann kommt noch heartbeat dazu, der dafür sorgt, dass wen ein Xen Dom0 Rechner ausfällt, die Gäste auf der Anderen wieder gestartet werden. Sehe ich doch richtig so, oder?

Derzeit habe ich zwei Anleitungen, die ich verfolge:

http://xenamo.sourceforge.net/
http://wiki.xensource.com/xenwiki/EVMS-HAwSAN-SLES10

Aber die finde ich ein wenig verwirrend, da nie so recht klar wird, wann ich was von was benötige. ….