Mit Au-FS etabliert sich unter den transluzenten Dateisystemen Konkurrenz zu Union-FS, mit FS-Cache erhält NFS zudem einen persistenten Cache. Beides sind ideale Zutaten für einen Terminalclient. Dieser Artikel stellt beide Projekte näher vor.

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.

Zwischenspeicher

Um FS-Cache in Betrieb zu nehmen, ist der Aufwand etwas größer. Neben den Kernelpatches sind noch mindestens ein gepatchtes »mount.nfs«-Programm und der Cache-Backend-Daemon »cachefilesd« nötig. Die Kernelpatches lassen sich von [6] für die Kernelversion 2.6.19 herunterladen. Alle Patches werden nach »/usr/src/fscache« entpackt und auf den Kern angewendet:

cd /usr/src/linux
for p in $(ls ../fscache/patchset/*diff);do patch -p1 < $p; done

Bevor man nun den Kernel übersetzen und installieren sowie das System rebooten kann, ist noch der Kernel wie in Abbildung 2 und 3 zu konfigurieren, damit NFS den Cache auch verwendet.

Abbildung 2: Beim Menüpunkt »Caches« der Kernelkonfiguration empfiehlt es sich, alle Optionen fest einzubauen.

Abbildung 3: Die markierte Option »Provide NFS Client caching support« aktiviert schließlich den Cache für NFS.

Läuft das Übersetzen des Kernels, kann der Admin inzwischen von [8] die Quelle von »cachefilesd« besorgen und durch ein einfaches »make install« installieren. Das geht problemlos, sofern das System mit einer Glibc in mindesten Version 2.4 ausgestattet ist.

Der letzte Schritt der Vorbereitungen erzeugt einen neuen Mount-Helper »mount.nfs«, der die Option »fsc« versteht, um einen Cache anzukündigen. Auf [7] ist ein RPM-Paket erhältlich, das die Quellen für die NFS-Werkzeuge und die Patches des FS-Cache-Projekts beinhaltet. Dieses Paket lässt sich bei Bedarf zunächst mit »rpm2targz« umwandeln und anschließend entpacken.

Um den Eingriff in das bestehende System so klein wie möglich zu halten, erhält die neue Version den Namen »mount-fsc.nfs«:

cd nfs-utils
tar jxvf nfs-utils-1.0.9.tar.bz2
for p in $(ls *patch); do patch -p0 < $p; done
cd nfs-utils-1.0.9
./configure --disable-nfsv4 --disable-gss
make
cd utils/mount
make
cp mount.nfs /sbin/mount-fsc.nfs

Der neue Mount-Helper kündigt wie erwähnt mit der Option »fsc« die Verwendung des lokalen Cache an, der Backend-Dämon »cachefilesd« aktiviert ihn anschließend (siehe Listing 1). Dazu ist noch ein Ext-3-Dateisystem mit aktivierten Extended-Attributen notwendig:

mount-fsc.nfs 192.168.39.1:/export/test /mnt/test/N -o fsc,nolock,tcp
mount -t ext3 /dev/hdc1 /var/fscache -o user_xattr cachefilesd -s

Für einen Diskless Client kann der Administrator allerdings nicht in dieser Art verfahren, da dessen Kernel die Option »fsc« für den Kernelparameter »nfsroot« nicht unterstützt. Das ist jedoch zum Glück auch gar nicht unbedingt erforderlich, weil mit dem Initial-RAM-Filesystem (»initramfs«) dem Admin ein viel mächtigeres Werkzeug zur Verfügung steht, das zum selben Ziel führt.

# cd /mnt/test/
# ls -l big.tgz
-rw-r--r-- 1 1000 users 115399526 Jan 23 21:19 big.tgz
Der Cache ist fast leer:
# df /var/fscache
Filesystem      1K-blocks   Used Available Use% Mounted on
/dev/hdc1       1031800   18200  961188  2% /var/fscache

# file big.tgz
big.tgz: gzip compressed data, from Unix, last modified: Mon Jan 1 19:03:43 2007

# df /var/fscache
Filesystem      1K-blocks   Used Available Use% Mounted on
/dev/hdc1       1031800   18692  960696  2% /var/fscache

# cat big.tgz > /dev/null
# df /var/fscache
Filesystem      1K-blocks   Used Available Use% Mounted on
/dev/hdc1       1031800  131020  848368 14% /var/fscache

01 dir /var/fscache # ext3,fsc cache-filesystem
02 tag mycache   # Name des Cache
03 # Block-Grenzen
04 brun 10%     # oberhalb Normalbetrieb
05 bcull 7%     # Cache-Bereinigung
06 bstop 3%     # unterhalb Cache-Stop
07 # INode-Grenzen
08 frun 10%     # oberhalb Normalbetrieb
09 fcull 7%     # Cache-Bereinigung
10 fstop 3%     # unterhalb Cache-Stop

Ohne Platte braucht es RAM

Ohne näher auf »initramfs« einzugehen beschreibt dieser Artikel prinzipiell den Weg, der das Setzen der Kerneloption umgeht. In der RAM-Disk muss der Admin dafür »mount-fsc.nfs« inklusive abhängiger Bibliotheken zusätzlich zum »busybox«-Framework hinzufügen. Dann ist das »init«-Skript in der Lage, das NFS-Wurzelverzeichnis mit der Cache-Option zu montieren.

Außerdem kann das Skript nach einer geeigneten Cache-Partition auf der lokalen Platte suchen, diese ebenfalls montieren, danach ein »switch_root« durchführen und anschließend den Cache-Backend-Daemon starten.

Ideal ist die Kombination

In Kombination mit Au-FS ergibt sich damit eine ideale Verfahrensweise, um Rich oder Thin Clients zu betreiben, die keine besonderen Modifikationen im Root-Dateisystem benötigen und außerdem schnell sind. Ein Gentoo-System beispielsweise bootet unverändert von einem mit FS-Cache und Au-FS vorbereiteten NFS-Wurzelverzeichnis. Weiterführende Informationen, wie dies im Einzelnen zu bewerkstelligen ist, und eine beispielhafte »initramfs« finden sich im Internet auf [9].

Cache-Geschwindigkeit

Der tatsächlich erzielbare Leistungsgewinn hängt sehr stark von der Kombination aus NFS-Server, Netzwerk und Client ab. Es ergibt wenig Sinn, langsame Clients bei einem ausreichend schnellen NFS-Server und Netzwerk mit einem Cache auszustatten. Hier würde sich lediglich die langsame lokale Platte des Clients als Bremse auswirken.

Handelt es sich jedoch um eine Kombination, die bei geringer Last zwar ausreichend performant ist, aber durch eine große Anzahl Clients an ihre Grenzen stößt, kann sich ein lokaler Cache sehr wohl als nützlich erweisen.

Ein kalter Cache bremst in diesem Fall einen schnellen Client kaum, während sich bei warmem Cache und einer hohen Server- beziehungsweise Netzwerkbelastung deutliche Vorteile ergeben. Die für einen Rich Client über das Netz zu transportierende Datenmenge schrumpft unter diesen Umständen mindestens um die Hälfte. (jcb)