Cluster-Dateisystem OCFS2 einfach gemacht

Sollen zwei oder mehr Recher auf ein und denselben Datenbestand zugreifen, gibt es bei Linux- und Unix-Systemen mehrere konkurrierende Ansätze. Einen Überblick über verschiedene Technologien gibt der Kasten "Shared Filesystems". Dieser Artikel nimmt das Oracle Cluster File System 2 (OCFS2, [1]) unter die Lupe, das – wie der Name schon andeutet – vor allem für Cluster-Setups mehrerer Server geeignet ist.

Wer ein auf Shared Disks basierendes Cluster-Dateisystem aufsetzen will, muss zunächst ein paar Dinge beachten. Als Erstes muss der Administrator das Grundgerüst eines Clusters aufbauen. Dazu gehören die Informationen, welche Rechner zum Cluster gehören, ihre Erreichbarkeit per TCP/IP und der Name des Clusters. Im Falle von OCFS2 leistet dies eine einzelne Ascii-Datei, die in Listing 1 zu sehen ist.

Die zweite zu lösende Aufgabe bei Cluster-Dateisystemen ist der kontrollierte und geordnete Zugriff auf die Daten, zum Beispiel mit File Locking, das Konflikte vermeiden soll. Der Distributed Lock Manager (DLM) sorgt bei OCFS2 dafür, dass keine Inkonsistenzen im Dateisystem auftreten. Eine extra Konfiguration ist nicht nötig – das Initialisieren des OCFS2-Clusters startet auch den DLM. Aber das beste File Locking nützt nichts, wenn der schreibende Rechner außer Kontrolle gerät. Dann hilft nur, dem Rechner das Schreiben zu verwehren, also das so genannte Fencing. OCFS2 ist hier recht einfach gestrickt und beherrscht nur Self-Fencing: Stellt ein Knoten fest, dass er nicht mehr sauber in den Cluster integriert ist, schließt er sich selbst durch eine Kernel-Panic aus. Wie das DLM setzt auch Self-Fencing bei OCFS2 keine besondere Konfiguration voraus. Steht die Cluster-Konfiguration und ist auf alle beteiligten Knoten verteilt, ist die Hauptarbeit für ein funktionierendes OCFS2 also bereits getan. Dann ist alles ganz einfach: Cluster starten, gegebenenfalls OCFS2 anlegen, das Dateisystem mounten und fertig.

Abbildung 2: Unspektakulär: Der OCFS2-Mountvorgang

Erste Schritte

Wie erwähnt ist OCFS2 ein auf Shared Disks basierendes Cluster-Dateisystem. Die Bandbreite von Techniken, die eine "geteilte" Platte bereitstellen, reicht vom teuren SAN via Fibre Channel über iSCSI bis zum kostengünstigen DRBD [6]. In diesem Artikel kommen iSCSI und NDAS (Network Direct Attached Storage) zum Einsatz. Die zweite Zutat zum OCFS2-Setup sind Rechner mit OCFS2-fähigem Betriebssystem. Am besten eignen sich Oracles Enterprise Linux, Suse Linux Enterprise Server, Open Suse, Red Hat Enterprise Linux und Fedora.

Die Softwaresuite für OCFS2 besteht aus den Paketen »ocfs2-tools« , »ocfs2console« (Abbildung 1) und den Kernelmodulen »ocfs2-`uname -r`« . Mit »ocfs2console« erhält der Admin eine grafische Oberfläche, um die Cluster-Konfiguration anzulegen und auf die beteiligten Knoten zu verteilen. Dies ist aber auch ebenso gut mit »vi« und »scp« möglich. Tabelle 1 listet auf, welche Aktionen das grafische Frontend zulässt und welchen Kommandozeilen-Tools dies entspricht. Ist die Cluster-Konfiguration angelegt, startet »/etc/init.d/o2cb online« das Subsystem (Listing 2). Das Init-Skript lädt die Kernelmodule und stellt ein paar Defaultwerte für Heartbeat und Fencing ein.

Abbildung 1: Cluster-Konfiguration mit dem GUI-Tool ocfs2console.

Läuft das OCFS2-Grundgerüst, kann der Administrator das Cluster-Dateisystem anlegen. Im einfachsten Fall erledigt dies »mkfs.ocfs2 Gerätedatei« (Listing 3). Die Manpage zu »mkfs.ocfs« listet mögliche Optionen auf, die wichtigsten von ihnen sind in Tabelle 2 zu finden.

Ist das Dateisystem angelegt, muss der Administrator es mounten. Das Mount-Kommando funktioniert analog zu ungeclusterten Dateisystemen. Beim Ein- wie auch beim Aushängen von OCFS2-Volumes ist mit einer kurzen Verzögerung zu rechnen: Beim Einhängen muss sich der ausführende Rechner beim Distributed Lock-Manager (DLM) anmelden. Analog löst der DLM beim Umount gehaltene Locks auf oder verwaltet sie über die verbliebenen Rechner.

Keine Panik

Die Dokumentation verweist auf verschiedene Optionen, die der Admin beim Mounten verwenden kann. Stellt OCFS2 einen Fehler in der Datenstruktur fest, schaltet es per Default auf Nur-Lesen um. In bestimmten Situationen kann aber ein Reboot zur Bereinigung der Situation besser sein. Das übernimmt die Mountoption »errors=panic« . Ebenfalls interessant ist die Option »commit=Sekunden« . Der Standardwert ist 5 und er bedeutet, dass OCFS2 alle 5 Sekunden die Daten auf die Platte schreibt. Im Falle eines Crash hat man – dank Journaling – ein konsistentes Dateisystem und höchstens die Arbeit der letzten 5 Sekunden verloren. In die gleiche Richtung geht die Mountoption, die den Umgang mit den Daten beim Journaling festgelegt. Mit der neusten Version schreibt OCFS2 erst alle Daten auf die Platte, bevor es das Journal aktualisiert. Mit »date=writeback« erzwingt der Admin den von früheren Versionen bekannten Modus.

Der frisch gebackene OCFS2-Admin wundert sich vielleicht, dass trotz Eintrags in der »/etc/fstab« das OCFS2-Volume nach einem Reboot des Rechners nicht verfügbar ist. Für die Reboot-Resistenz des OCFS2-Mounts sorgt das mitgelieferte Init-Skript »/etc/init.d/ocfs2« . Einmal aktiviert scannt dieses Skript die Datei »/etc/fstab« nach OCFS2-Einträgen und bindet die entsprechenden Dateisysteme ein.

Ähnlich wie bei Ext 3/4 hat der Administrator auch nach dem Anlegen des Dateisystems die Möglichkeit, einige Eigenschaften zu verändern – ohne dabei Daten zu zerstören. Dafür steht das Werkzeug »tunefs.ocfs2« zur Verfügung. Wächst der Cluster unerwartet, sollen also mehr Rechner gleichzeitig auf das OCFS2 zugreifen können, wird eine zu klein gewählte Option »N« beim »mkfs.ocfs2« schnell zum Problem. Mit »tunefs.ocfs2« verändert der Admin dies im Handumdrehen. Gleiches trifft für die Größe des Journals zu (Listing 4).