Workshop: Transluzente Filesysteme und Caches beschleunigen

Besonders wenn es um viele Clients geht, ist die Diskless-Variante sehr attraktiv. Leistungsstarke PCs können als Rich Clients dienen, auf denen die Benutzerprozesse direkt laufen, schwächere arbeiten als Thin Clients, die im Wesentlichen nur als Ein- und Ausgabestation und Endpunkt für lokale Geräte fungieren. Die Clients können zudem mit verschiedenen Linux-Distributionen starten. Die Auswahl der Betriebsart oder Distribution ist beim Booten möglich. All dies erfordert keine lokale Installation. Die prinzipiellen Einrichtungsmöglichkeiten beschreibt [1].

Essenziell für den effizienten Umgang mit Diskless Clients ist, dass sich die Administration ihres Wurzeldateisystems auf dem Server nicht von der eines normalen Diskfull Clients unterscheidet. Der Administrator macht sich seine Aufgabe wesentlich leichter, wenn er damit Anpassungen seiner Distribution für den plattenlosen Betrieb vermeidet.

Dieses Ziel lässt sich durch ein transluzentes Dateisystem auf dem Client erreichen. Für diesen Zweck kommt beispielsweise Union-FS [2] in Frage. Der NFS-Server exportiert dann das Wurzelverzeichnis read-only an alle Clients. Lokale Modifikationen der Dateien in »/etc«, »/var« oder »/media« kopiert das transluzente Dateisystem in eine RAM-Disk.

Union-FS baut auf dem FIST-Framework (Framework for Instrumentation in Software Dynamic Translators) auf, was eine sehr große Komplexität mit sich bringt. Leider sind dadurch Stabilität und Performance etwas vermindert. Auch wenn die Auswirkungen auf einem Thin oder Rich Client typischerweise nicht gravierend sind, berechtigen sie doch die Suche nach Alternativen. Für den Serverbetrieb, bei dem es unter anderem darum geht, die Wurzeldateisysteme vieler unterschiedlicher plattenloser Clients elegant und effizient zu verwalten, ist Union-FS sowieso wegen einiger Bugs nicht zu empfehlen [4].

Als alternatives transluzentes Dateisystem kommt Au-FS (Another Union-FS) [3] ins Spiel. Auch Knoppix ist ab der Version 5.1 darauf umgestiegen. Au-FS ist von Grund auf neu implementiert und hat keine gemeinsame Codebasis mit Union-FS. Trotzdem gleichen sich Funktionen und Schnittstellen.

Wenn auch Au-FS noch ein junges Projekt mit einer sehr kleinen Entwicklergemeinde ist, steht seinem Einsatz kaum etwas entgegen. Stabilität und Performance übertreffen derzeit die von Union-FS (siehe Kasten "Another Union-FS: Au-FS"). Leider finden sich noch keine fertigen Pakete in den gängigen Linux-Distributionen.

NFS mit Cache

Diskless Clients, die ein transluzentes Dateisystem benutzen, sind zustandslos [1]. Das ist für die Administration sehr vorteilhaft, bringt aber bei ausgelastetem Server und Netzwerk eine Leistungseinbuße mit. Ein lokaler, persistenter Cache kann hier Abhilfe schaffen. Dafür ist aber wieder eine Festplatte nötig. Das Projekt FS-Cache [5] bietet eine Möglichkeit, einen persistenten Cache für Netzwerk-Dateisysteme aufzubauen. Dies ist zwar derzeit nur für AFS und NFS möglich, doch NFS kommt ja ebenfalls häufig bei Diskless Clients zum Einsatz.

FS-Cache besteht aus mehreren Teilen. Zunächst benötigt der Linux-Kern einen Satz Patches, die allerdings gute Chancen haben, bald im offiziellen Kernel zu landen. Zudem sind ein Cache Backend und ein modifiziertes »mount«-Programm, das die »fsc«-Option versteht, nötig. Die »fsc«-Option kündigt die spätere Verwendung eines Cache an.

Für das Cache Backend gibt es grundsätzlich die beiden Alternativen »cachefilesd« und »cachefs«. »cachefilesd« verwendet ein Ext-3-Dateisystem als Persistenzschicht, während »cachefs« ein Blockgerät selbst als Cache verwaltet. Der Algorithmus von »cachefs« neigt über eine längere Laufzeit jedoch zu einer starken Fragmentierung des Blockgeräts und damit zu großen Performance-Einbußen. Die Entwickler raten daher selbst von »cachefs« ab. Abbildung 1 zeigt seinen Aufbau, die wichtigsten Eigenschaften erläutert der Kasten "FS-Cache im Detail".

Abbildung 1: Das Zusammenspiel der Komponenten von FS-Cache.

Au-FS einbauen

Au-FS besteht aus einem Kernelmodul und einigen Userspace-Tools. Die Kernelversionen ab 2.6.19 verlangen zusätzlich noch ein (unkritisches) Patch, wenn sich ein Zweig der Vereinigung auf einem NFS-Dateisystem befindet. Im Diskless-Einsatz ist dies also zwingend. Ein weiteres Patch exportiert ebenfalls eine Kernfunktion aus Effizienzgründen. Das Kommando

cvs -d :pserver:anonymous@aufs.sourceforge.net:/cvsroot/aufs co aufs

checkt die aktuelle Au-FS-Version in ein eigenes Unterverzeichnis »aufs« aus. Im Makefile »local.mk« sind für die obigen Patches jetzt noch diese Zeilen anzupassen:

CONFIG_AUFS_LHASH_PATCH = y
...
CONFIG_AUFS_KSIZE_PATCH = y

Die folgenden Patch-Kommandos bringen die Linux-Quellen auf den notwendigen Stand:

cd /usr/src/linux
patch -p0 < /root/aufs/lhash.patch
patch -p0 < /root/aufs/ksize.patch

Anschließend übersetzt und installiert der Administrator den Kern wie üblich. Parallel dazu kann er auch das »aufs«-Modul erzeugen:

cd /root/aufs
make KDIR=/usr/src/linux -f local.mk
cp aufs.ko /lib/modules/2.6.19/fs/
depmod -a 2.6.19

Nach einem Reboot in den neuen Kern steht der Verwendung von Au-FS nichts mehr entgegen.

Beispielsweise erzeugt das folgende Kommando eine Vereinigung der beiden Verzeichnisse »/tmp/readwrite« und »/tmp/readonly« und montiert diese nach »/tmp/aufs«:

mount -t aufs -o dirs=/tmp/readwrite=rw:/tmp/readonly=ro none /tmp/aufs

Überall dort, wo bislang in einem Diskless Client Union-FS zum Einsatz kommt, kann Au-FS als dessen direkter Ersatz dienen.