Debugging

Die möglichen Probleme mit einem Dateisystem sind sehr zahlreich. Die erhöhte Komplexität von Cluster-Dateisystemen macht das natürlich nicht einfacher. Aus OCFS2-Sicht kann es bei drei verschiedenen Schichten haken: an der Dateisystemstruktur auf der Platte, der Cluster-Konfiguration und/oder der Cluster-Infrastruktur. Zu Letzterer zählen der Netzwerkstack für Heartbeat, die Cluster-Kommunikation und eventuell auch der Zugriff auf den Datenträger. Außerdem sind hier die Probleme auf Fibre-Channel- und iSCSI-Ebene anzusiedeln.

Probleme in der Cluster-Infrastruktur untersucht der Admin wie gewöhnliche Netzwerk-, FC- oder iSCSI-Probleme. Ist die Cluster-Konfiguration nicht auf allen Knoten identisch, kann es ebenfalls zu Schwierigkeiten kommen. Der Admin kann hier mit »vi« , »scp« und »md5sum« der Sache auf den Grund gehen und das Problem lösen. Alternativ – vorausgesetzt die Cluster-Infrastruktur steht – synchronisiert ein Update der Konfiguration via »ocfs2console« die Cluster-Konfiguration auf allen Rechnern.

Es kann helfen, das problematische OCFS2-Volume komplett offline zu nehmen, also abzuhängen, und den Cluster-Service über »/etc/init.d/o2cb restart« auf allen Rechnern neu zu starten. Der Admin kann mit Hilfe von »tunefs.ocfs2« das Dateisystem sogar in eine Art Single-User-Mode setzen. Dafür setzt er den Mount-Typ von »cluster« auf »local« . Danach kann nur ein einzelner Rechner das Dateisystem mounten – und dies sogar ohne den Cluster-Stack.

Bei allen Aktionen muss dem Administrator bewusst sein, dass das Dateisystem von mehr als einem Rechner gemountet sein kann. Bestimmte Aktionen, etwa mit »tunefs.ocfs2« , funktionieren nicht, wenn ein weiterer Rechner auf das Dateisystem zugreift. Im Beispiel von Listing 6 versucht der Anwender das Label zu ändern. Der Vorgang schlägt fehl, obwohl das Dateisystem (auf diesem Rechner) offline ist. Dann hilft das Kommando »mounted.ocfs2« weiter. Es sieht im Header des OCFS2 nach, auf welchen Rechnern das Dateisystem online ist.

Die wichtigsten Daten über die Dateisystemstruktur befinden sich im Superblock. Wie andere Linux-Dateisysteme legt auch OCFS2 Sicherungskopien des Superblocks an. Das Konzept der OCFS2-Entwickler ist allerdings etwas ungewohnt: OCFS2 legt maximal sechs Kopien an und diese an nicht konfigurierbaren Offsets: 1 GByte, 4 GByte, 16 GByte, 64 GByte, 256 GByte und 1 TByte. Konsequenterweise haben OCFS2-Volumes kleiner als 1GByte keine (!) Kopie des Superblocks. Fairerweises sagt »mkfs.ocfs2« dies aber beim Anlegen des Dateisystems. Der Admin muss Ausschau nach der Zeile »Writing backup superblock: ...« halten. Ein netter Nebeneffekt der statischen Backup-Superblocks ist: Der Admin kann sie beim Filesystem-Check nach Nummern referenzieren. Im Beispiel von Listing 7 ist der primäre Superblock beschädigt, der Mount und ein simpler »fsck.ocfs2« funktionieren daher nicht. Mit Hilfe des ersten Backups gelingt aber die Wiederherstellung.

Radio Eriwan

Im Prinzip ist es recht einfach, einen OCFS2-Cluster-aufzusetzen. Die Software ist für eine Reihe von Linux-Distributionen verfügbar, also macht schon die Installation keine großen Schwierigkeiten. Da OCFS2 mit iSCSI genauso funktioniert wie mit Fibre Channel, stellt auch die Hardware-Seite kein unlösbares Problem dar. Das Setup des Cluster-Framework ist recht einfach und sogar mit einfachen Tools wie »vi« zu bewerkstelligen.

OCFS2 bringt keine ausgeklügelten Fencing-Technologien wie andere Cluster-Dateisysteme mit. Das ist oft aber auch gar nicht nötig. Auch das Fehlen eines Cluster-fähigen Volumenmanagers erleichtert dem Anwender den Einstieg in die OCFS2-Welt. Durch die Einfachheit und geringe Komplexität im Vergleich zu anderen Cluster-Dateisystemen ist OCFS2 mehr als einen Blick wert.