© BMW Group

Wo sehr große Files und Dateisysteme vorkommen und gleichzeitig hohe Performance gefragt ist, müssen herkömmliche Dateisysteme passen. Einen Ausweg bietet Lustre, ein Performance-optimiertes verteiltes Dateisystem für Hochleistungsrechner.

High-Performance-Computing ist, so scheint es, ein ständiger Kampf gegen den Mangel: Einst ersannen Rechensüchtige die PC-Cluster, um der notorisch knappen CPU-Zyklen Herr zu werden, nur um wenig später festzustellen, dass nun das Netzwerk die Prozessoren ausbremste. Die Lösung lieferten Hochleistungsnetze wie Quadrics Elan [1], Rapid Array, Myrinet der Firma Myricom [2] oder Infiniband [3]. Doch auch sie beförderten nur das nächste Thema auf Platz eins der Cluster-Engpassliste: den Speicherplatz.

Berechnungsergebnisse in TByte-Größe sind keine Seltenheit, überquellende Fileserver eher die Regel. Da nicht nur das Datenaufkommen insgesamt anwächst, sondern auch die Größe einzelner Dateien, nützt es wenig, lediglich zusätzliche NFS-Freigaben zu exportieren. Vielmehr muss der Platz in einem oder möglichst wenigen Dateisystemen verfügbar sein, um lästiges Umkopieren zu vermeiden. Zudem sollte das Dateisystem auf jedem Clusterknoten verfügbar sein und bestehende Hochgeschwindigkeitsnetze für den Datentransport nutzen.

Die Lösung heißt Lustre

Wer eine Lösung dieser Probleme sucht, kommt an Lustre [4] kaum vorbei, einem verteilten Dateisystem, das die US-Firma Cluster File Systems (siehe Kasten “Cluster File Systems”, [5]) vertreibt, entwickelt und jedermann unter GPL-Lizenz zur Verfügung stellt. Der Name der Software entspricht nur zufällig dem englischen Begriff für Lüster. Eigentlich ist er ein Wortspiel aus Linux und Cluster – kennzeichnend für den bevorzugten Einsatzort des verteilten Dateisystems. Unter den Clustern der Top-500-Liste der Supercomputer [6] erfreut es sich großer Beliebtheit. Selbst Blue Gene/L, die Nummer eins, sichert seine Daten mit Hilfe von Lustre.

Das ist keineswegs selbstverständlich, denn Hersteller IBM hat selbst das konkurrierende Dateisystem GPFS [7] im Programm. Im grundlegenden Design durchaus ähnlich zur Lustre-Architektur, bietet das kommerzielle GPFS den größeren Funktionsumfang, was beispielsweise Backups und eine hierarchische Speicherverwaltung mit einschließt. Die Lustre-Entwickler hingegen haben nicht so sehr Features, sondern vor allem höchste Performance im Visier.

LNET vermittelt

Obwohl es vor allem auf den Clustermarkt zielt, ist Lustre jedoch kein Clusterdateisystem im engeren Sinn. Darunter versteht man gewöhnlich ein Filesystem, über das mehrere Rechner gleichzeitig auf ein gemeinsames Blockgerät zugreifen, etwa in einem SAN über Fibre Channel oder I-SCSI oder aus mehreren virtuellen Maschinen heraus.

Vertreter dieser Gattung wie GFS [8] oder OCFS2 [9] kommen häufig in Hochverfügbarkeitsclustern zum Einsatz, seltener in Hochleistungsclustern, da ihr Datendurchsatz bei vielen Knoten nur begrenzt skaliert und zumindest ein herkömmliches Fibre-Channel-SAN darüber hinaus auch erhebliche Kosten verursacht.

Die Lustre-Architektur hingegen folgt in erster Linie dem Vorbild verteilter Dateisysteme wie AFS [10] oder dem für Version 4.1 vorgesehenen parallelen NFS-Standard PNFS. Sie fassen lokal auf mehreren Rechnern liegende Daten zu einem einheitlichen Dateisystembaum zusammen. Letztlich speichert zwar auch hier ein Blockgerät die Daten, aber im Unterschied zu den Clusterdateisystemen greift bei ihnen nur ein bestimmter Rechner auf jedes Blockgerät zu. Den konkurrierenden Zugriff regeln bereits höhere Softwareschichten.

Will ein Client Daten aus einem Lustre-System verwenden, fragt er zunächst einen Metadatenserver, wo die gewünschten Daten gespeichert sind, und besorgt sie sich in einem zweiten Schritt. Alle beteiligten Maschinen sprechen dazu das speziell für Lustre entwickelte Protokoll LNET, das nicht nur gewöhnliches TCP/IP unterstützt, sondern auch direkt über Hochleistungsnetzwerke wie Infiniband, Quadrics oder Myrinet kommuniziert.

Im Lustre-Jargon heißen die LNET-Treiber für die unterschiedlichen Netzwerktypen meist kurz LND. Auch die übrigen Komponenten eines Lustre-Systems verwirren durch eine Vielzahl dreibuchstabiger Abkürzungen: Der erwähnte Metadatenserver heißt meist nur MDS, die eigentlichen Nutzdaten liegen auf Object-Storage-Servern, kurz OSS. Dazu gibt es noch einen Managementserver (MGS), der alle Konfigurations-Informationen zentral verwaltet (Abbildung 2).

Um Daten von einem der Server abfragen zu können, besitzt jede Komponente auch die passende Clientsoftware, also MGCs, MDCs und OSCs. Danach wird es spitzfindig, denn ein Server ist in der Lustre-Terminologie nur der Computer, der einen bestimten Dienst anbietet. Die zugehörigen Programme auf einem Server firmieren unter dem Namen Target oder abgekürzt MGT, MDT und OST. Datenpartitionen auf den Storage-Servern heißen Object Storage Devices (OSD), ein komplettes Lustre-Dateisystem nennt sich Logical Object Volume (LOV). Wer sich mit Lustre beschäftigen will, kommt an diesen Abkürzungen nicht vorbei.

Abbildung 1: Schematischer Aufbau eines komplexen Lustre-Clusters mit der nötigen Ausfallsicherung.

Abbildung 2: Das Zusammenspiel der verschiedenen Serverkomponenten und Clients (LOV/OSC/LND, MDT/LND, OBD/OST/LND).

Zweistufiger Zugriff

Prinzipiell laufen Zugriffe auf Daten in einem Lustre-Dateisystem in zwei Stufen ab: Ein Client nimmt zunächst Verbindung mit dem MDS auf. Von dort erhält er Informationen über gewöhnliche Metadaten, etwa welche Dateien und Verzeichnisse vorhanden sind oder welche Zugriffsrechte sie besitzen. Vor allem aber teilt ihm der MDS mit, welche OSS-Knoten für die eigentlichen Nutzdaten einer gewünschten Datei zuständig sind. Der Client liest und schreibt seine Daten dann direkt auf die OSTs, ohne weitere Umwege zum MDS.

So funktioniert im Grunde auch der Dateisystem-Oldie AFS [10]. Das Besondere an Lustre aber ist die Art und Weise, wie es Daten auf den OSS-Knoten ablegt. Denn anders als beispielsweise AFS speichert es dort nicht etwa vollständige Dateien, sondern so genannte Objekte. Das sind Bruchstücke, die nur einen Teil der ursprünglichen Daten enthalten. So lässt sich eine Datei über mehr als ein OST verteilen. Ein Client besorgt sich die Fragmente von den OSTs und setzt sie für den Benutzer transparent wieder zur ursprünglichen Datei zusammen. Das Prinzip ist vergleichbar mit dem eines Raid-0-Verbunds, der Daten in so genannten Stripes auf mehrere Festplatten verteilt (Abbildung 3). Dadurch erhöht sich der Datendurchsatz, außerdem ermöglicht es dieses Prinzip, Dateien abzuspeichern, die größer sind als die Partitionen einzelner OSTs.

Abbildung 3: Aufteilung einer Datei in Objekte auf mehreren OSTs.

Der oben noch erwähnte Managementserver ist selbst kein Teil eines Lustre-Dateisystems, auch wenn er in der Regel auf demselben Rechner läuft, der einen MDS beherbergt. Ins Spiel kommt der MGS lediglich zu Beginn: Egal ob MDS, OSS oder Lustre-Client, jeder andere Dienst nimmt beim Start zunächst Kontakt zum MGS auf und bekommt von dort alle noch fehlenden Konfigurationsinformationen.

Will ein Client beispielsweise ein Lustre-Dateisystem einbinden, enthält das entsprechende Mount-Kommando den Namen des MGS. Der verweist den Client dann anhand des Dateisystemnamens für den eigentlich Mountvorgang an den zuständigen MDS. Der Managementdienst ist eine Neuerung in der aktuellen Lustre-Versionsreihe 1.6. Zuvor war es nötig, eine Datei mit Konfigurationsinformationen auf alle beteiligten Rechnern zu verteilen und synchron zu halten.

Vorbereitungen und Installation

Wer die ersten Schritte mit Lustre unternimmt, stößt unmittelbar auf ein grundlegendes Problem. Die Software besteht größtenteils aus Komponenten für den Linux-Kernel. Das sind sowohl eigenständige Module, aber auch Änderungen an den übrigen Kernelquellen. Die Patches betreffen zentrale Stellen wie das virtuelle Dateisystem, die häufigen Änderungen unterliegen.

Lustre mit einem bestimmten Linux-Kernel zum Laufen zu bringen, ist deshalb auch für hartgesottene Anwender ein durchaus anspruchsvolles Unterfangen. Für den Anfang empfiehlt es sich, eine der offiziell unterstützten Linux-Versionen einzusetzen, auch wenn die meist einige Revisionen hinter den jeweils aktuellen Kernelversionen hinterherhinken.

Außerdem bleiben die meisten Distributionskernel außen vor: Lustre-Hersteller CFS unterstützt neben den ungepatchten Kernel.org-Quellen lediglich die Kernel der Enterprise-Distributionen SLES 9 und 10 sowie Red Hat EL 4 und EL 5, für die auch fertige Binärpakete als RPMs zum Download bereitstehen (Tabelle 1).

Darüber hinaus bietet gegenwärtig einzig Debian offiziell im Unstable-Zweig eigene Lustre-Pakete an. Immerhin, Lustre-Clients kommen seit Kernelversion 2.6.16 bei Bedarf auch ohne die lästigen Kernelpatches aus, müssen in diesem Fall aber geringe Performance-Einbußen in Kauf nehmen. Für die Serverkomponenten hingegen sind die Patches ein Muss.

Außerdem benötigt Lustre ein sehr modernes E2fsprogs-Paket, das die relativ neu in Ext3/Ext4 hinzugekommene und immer noch experimentelle Fähigkeit zur Extent-basierten Adressierung unterstützt. Die aktuelle Version 1.39 sollte genügen. RPMs mit passend erweiterten »e2fsprogs« gibt es auf den Lustre-Seiten zum Download.

Weitere Voraussetzungen für reibungslosen Betrieb sind ferner zwischen allen beteiligten Rechnern synchronisierte Uhren sowie zur Authentisierung ein einheitlicher Bereich von Benutzer- und Gruppen-IDs für alle Zugriffsrechte auf das Lustre-Dateisystem. Erste Vorabversionen der künftigen Lustre 1.8 enthalten die Möglichkeit, anstelle von IDs über Kerberos zu authentisieren.

Da Lustre größtenteil über Kernelmodule implementiert ist, kann es nicht ohne Weiteres auf Konfigurationsdateien im normalen Dateisystem zugreifen. Frühere Versionen verwendeten deshalb das spezielle Kommandozeilen-Tool »lconf«, um die Einstellungen an den Kernel weiterzureichen. In 1.6 haben die Entwickler eine neue Methode ersonnen, die zwar äußerst bequem anzuwenden ist, dafür aber konzeptionell fragwürdig erscheint. Das so genannte Mountconf erweitert die bekannten Programme »mkfs«, »tunefs« und »mount« so, dass sie alle Parameter für ein Lustre-Dateisystem festlegen können.

Ldisk-FS als Backend-Filesystem

Damit wird es möglich, dass Lustre die Daten des MGT, MDT oder der OSTs auf den lokalen Partitionen selbst wieder in einem Dateisystems speichert, dessen Inhalt und Struktur dem Anwender aber verborgen bleiben. Aktuell benutzt Lustre dazu Ldisk-FS, eine Weiterentwicklung des Standarddateisystems Ext 3, die inzwischen unter dem Namen Ext 4 auch im herkömmlichen Linux-Kernel enthalten ist.

Soll eine bestimmte Partition als Teil eines Lustre-Dateisystems dienen, muss man darauf zunächst das lokale Backend-Dateisystem anlegen. War das bislang nur ein Implementierungsdetail, macht es Mountconf nun für den Admin sichtbar, denn er initialisiert eine Partition mittels »mkfs« (Listing 1).

01 root@metanode # mkfs.lustre --fsname ex1fs --mdt --mgs /dev/sda1
02 Permanent disk data:
03 Target: ex1fs-MDT0000
04 Index: unassigned
05 Lustre FS: ex1fs
06 Mount type: ldiskfs
07 Flags: 0x75 (MDT MGS needs_index first_time update)
08 Persistent mount opts: errors=remount,ro,iopen_nopriv,user_xattr
09 Parameters:
10 checking for existing Lustre data: not found
11 device size = 4096MB
12 formatting backing filesystem ldiskfs on /dev/sda1
13 target name examplefs-MDT0000
14 4k blocks 0
15 options -J size=160 -i 4096 -I 512 -q -O dir_index -F
   mkfs_cmd = mkfs.ext2 -j -b 4096 -L ex1fs-MDT0000 -J 
   size=160 -i 4096 -I 512 -q -O dir_index -F /dev/sda1
16 Writing CONFIGS/mountdata

Das Beispiel richtet auf dem Rechner mit der Netz-ID »metanode« (siehe Kasten “LNET”) die Partition »/dev/sda1« als MDT-Backend für ein Lustre-Dateisystem mit Namen »ex1fs« ein. Außerdem nutzt es eine Besonderheit: Da ein MGS nur sehr wenige Daten verwaltet, erlaubt es Lustre, eine Partition gleichzeitig für MDT und MGT zu benutzen. Für ein weiteres Lustre-LOV benötigt man dann ein neues MDT, kann aber den bestehenden Managementdienst mitbenutzen. Der passenden Befehl lautet dann:

root@metanode # mkfs.lustre --fsname ex2fs --mdt --mgsnode=metanode /dev/sda2

Ganz ähnlich lässt sich eine Datenpartition auf dem Rechner »node0« für die Verwendung als OST vorbereiten. MGS und der Name des zugehörigen Dateisystems sind die einzigen zwingend erforderlichen Parameter (Listing 2).

options lnet networks="tcp,o2ib"

options lnet ip2nets="tcp 192.168.16.*; U o2ib 192.168.17.*"

options lnet routes="o2ib U 192.168.16.42@tcp"

options lnet routes="o2ib U192.168.16.42@tcp; tcp 192.168.17.42@o2ib"

01 root@node0 # mkfs.lustre --fsname ex1fs --ost --mgsnode=metanode /dev/sda1
02 Permanent disk data:
03 Target: ex1fs-OST0000
04 Index: unassigned
05 Lustre FS: ex1fs
06 Mount type: ldiskfs
07 Flags: 0x72 (OST needs_index first_time update)
08 Persistent mount opts: errors=remount-ro,extents,mballoc
09 Parameters: mgsnode=192.168.16.21@tcp
10 device size = 4096MB
11 formatting backing filesystem ldiskfs on /dev/sda1
12 target name ex1fs-OST0000
13 4k blocks 0
14 options -J size=160 -i 16384 -I 256 -q -O dir_index -F mkfs_cmd = mkfs.ext2 -j -b 4096 -L ex1fs-OST000
   -J size=160 -i 16384 -I 256 -q -O dir_index 
   -F /dev/sda1
15 Writing CONFIGS/mountdata

Auch hier steckt unter der Haube ein gekapselter »mkfs.ext2 -j«-Aufruf, der ein Ldisk-FS auf der angegebenen Partition »/dev/sda1« einrichtet und durch Angabe spezieller Parameter für Blockgröße, Directory Hashes und Journal Size schon etwas in puncto Performance optimiert.

Der Name des Lustre-Dateisystems spiegelt sich in dem Dateisystem-Label des zugrunde liegenden Ldisk-FS wider: Es kann aus maximal 16 Zeichen bestehen und hat die Form »lustrefs-Name-MDTxxxx« für ein MDT oder »lustrefs-Name-OSTxxxx« für ein OST. Die letzten vier Ziffern (»xxxx«) entsprechen dem laufenden Index des OST, den der Benutzer mit der »mkfs«-Option »–index« von Hand festlegen kann. Andernfalls vergibt Lustre die Indizes sequenziell beim ersten Start der OSTs.

»mount« ohne zu mounten

Der Administrator startet die Lustre-Dienste durch kreativen Missbrauch des Mount-Befehls:

root@metanode # mount -t lustre /dev/sda1 /lustre/ex1/mdt

Dieses Kommando bedeutet nämlich nicht, dass hier ein Lustre-Dateisystem im Mountpunkt »/lustre/ex1/mdt« eingehängt würde. Vielmehr heißt es: Starte die im Ldisk-FS auf »/dev/sda1« konfigurierten Dienste. Das letzte Argument hat keinerlei Bedeutung, »/lustre/ex1/mdt« bleibt ein Mountpunkt ohne Dateisystem-Semantik, der alle Zugriffsversuche mit einem Ein- oder Ausgabefehler quittiert. Lediglich das »df«-Kommando liefert sinnvolle Ausgaben und zeigt den aktuellen Füllstand des zugehörigen MDT an. OSTs starten auf ähnliche Weise mit dem Kommando:

root@node0 # mount -t lustre /dev/sda1/lustre/ex1/ost0

Das Lustre-Kommando »lctl« gestattet einen Einblick in den aktuellen Zustand der Server. »lctl dl« etwa zeigt eine Übersicht über die aktuell laufenden Services. Auf einem MDS:

root@metanode # lctl dl
0 UP mgs MGS MGS 5
1 UP mgc MGC192.168.16.21@tcp bf0619d6-57e9-865c-551c-06cc28f3806c 5
2 UP mdt MDS MDS_uuid 3
3 UP lov ex1fs-mdtlov ex1fs-mdtlov_UUID 4
4 UP mds ex1fs-MDT0000 ex1fs-MDT0000_UUID 3

Und auf dem OSS:

root@node0 # lctl dl
0 UP mgc MGC192.168.16.21@tcp 7ed113fe-dd48-8518-a387-5c34eec6fbf4 5
1 UP ost OSS OSS_uuid 3
2 UP obdfilter ex1fs-OST0000 ex1fs-OST0000_UUID 5

Analog lassen sich für ein Lustre-Dateisystem bis zu 1020 OSTs anlegen. Dagegen ist jedes Dateisystem auf ein einziges MDT fixiert. Allerdings arbeitet Hersteller CFS bereits daran, künftig auch Cluster von Metadaten-Servern anbieten zu können.

Die Größe des MDT beschränkt die Anzahl der Dateien und Verzeichnisses, die das Dateisystem aufnehmen kann. Jeder Eintrag schlägt mit bis zu 4 KByte zu Buche. Wie viele Nutzdaten das LOV speichern kann, ergibt sich schlicht als Summe der Größen der zugehörigen OSTs. Wird der Platz einmal knapp, kann der Administrator im laufenden Betrieb auch weitere OSTs hinzufügen. Allerdings empfiehlt CFS, während dieser Zeit nicht aktiv auf das Dateisystem zuzugreifen, da die Entwickler das Hinzufügen von OSTs unter Last bislang noch nicht ausreichend testen konnten.

Ein Lustre-Client bindet das Dateisystem ganz gewöhnlich über einen Mount-Befehl ein. Er benötigt dazu die Netz-ID des MGS sowie den Namen des LOV:

root@client # mount -t lustre /mnt/ex1fs

Dieser Mount-Befehl arbeitet übrigens wieder bestimmungsgemäß.

Lustre im Alltag

Im Normalbetrieb weist Lustre wenige Besonderheiten auf. Als Dateisystem unterstützt es praktisch alle Anforderungen des Posix-Standards. In den Standardeinstellungen verzichtet es auf Locking-Funktionalität für »lockf()« und »flock()«. Die Mount-Option »flock« fordert Locking jedoch explizit an.

Mit der Option »localflock« vergibt Lustre die Locks deutlich performanter, sie sind aber nicht mehr global über alle beteiligten Knoten konsistent, sondern nur noch lokal auf einem Rechner. Das kann in jenen Fällen sinnvoll sein, wenn bereits anderweitig sichergestellt ist, dass nur Prozesse auf einer Maschine um eine Ressource konkurrieren. Die Mount-Option »acl« bringt einem Lustre-Dateisystem darüber hinaus auch den Umgang mit Posix-ACLs bei.

Dem Endanwender erlaubt das Kommandozeilen-Tool »lfs« Einblicke ins Innenleben von Lustre. »lfs getstripe Dateiname« beispielsweise zeigt an, auf welche OSTs und in welche Objekte eine Datei verteilt ist. Mit »lfs setstripe« kann ein Anwender auch selbst das Striping-Verhalten einer neuen Datei bestimmen, sie beispielsweise einem bestimmten Server zuweisen oder besonders große Dateien auf viele OSTs verteilen. Auf ein Verzeichnis angewandt, setzt »lfs setstripe« die Standardvorgabe für alle darin neu erstellten Dateien und Unterverzeichnisse. Nachträglich lassen sich die Einstellungen einer Datei nur noch durch Umkopieren ändern.

Dateisystem-Quotas verwaltet Lustre ebenfalls mit Hilfe von »lfs« – die zugehörigen Befehle sind selbsterklärend. Wichtiger noch ist in manchen Fällen der Befehl »lfs find«, nämlich dann, wenn Wartungsarbeiten es erzwingen, einen OSS abzuschalten. Mit der Option »–obd« spürt »lfs find« alle Dateien auf, die davon betroffen wären – sofern Anwender oder Administration nicht zuvor »lfs setstripe« benutzen, um die Daten auf andere OSTs zu kopieren.

Performance-Tuning

Typischerweise dienen Raid-Verbünde als Storage-Backends für die einzelnen Lustre-Dienste. Bei der Auswahl des Raid-Levels sollte der Administrator beachten, dass die Leistung eines mit Parität arbeitenden Raid wie Raid 5 oder Raid 6 beim Schreiben kleiner Datenblöcke erheblich einbricht. Denn füllt ein Block keinen kompletten Stripe, muss das Array die restlichen Daten von Platte lesen, daraus die Parität neu berechnen und kann erst danach den kompletten Chunk wieder zurückschreiben. Der zusätzliche Lesezyklus kostet Zeit und damit Performance.

Für den MDT, der vor allem Inodes von wenigen KByte Größe speichern muss, empfiehlt es sich deshalb, einen paritätslosen Raid-Level wie Raid 10 als Backend zu wählen. Raid 5 und Raid 6 kommen zwar für OSTs prinzipiell in Betracht, doch sollte der Admin hier den Prozess »kjournald« im Auge behalten: Blockiert er häufig, so liegt das daran, dass auch das Journal des Ldisk-FS-Backend viele kleine Schreibzugriffe erfährt. Ein externes Journal auf einer eigenen kleinen Partition mit paritätslosem Raid-Level umgeht das Problem und behebt damit den Engpass.

Scheduler und Performance

Darüber hinaus zeigt sich, dass die Performance von Lustre stark von der Wahl des verwendeten I/O-Schedulers unter Linux abhängt, der ungeschickterweise auch Elevator heißt, obwohl der Elevator-Algorithmus nur einer unter mehreren möglichen I/O-Schedulern ist. Sie puffern I/O-Anfragen und sortieren diese je nach verwendetem Algorithmus nach gewissen Kriterien, um so die Performance zu optimieren.

Neuere Linux-Kernel kennen vier verschiedene Scheduler-Algorithmen: Completely Fair Queueing (CFQ), Anticipatory, Deadline und NOOP. Der letzte ist der einfachste Algorithmus überhaupt: Er sortiert Requests überhaupt nicht um, sondern belässt sie in der Reihenfolge, in der sie anfallen (Fifo-Prinzip). Dieser Algorithmus ist geeignet, wenn Storage-Controller am Server angeschlossen sind, die ihrerseits bereits die I/O-Anfragen optimieren.

Der CFQ-Scheduler ist bei den meisten Linux-Distributionen Standard, aber für den Einsatz in Fileservern nahezu ungeeignet, da sein Algorithmus eher für den Anwendungsfall eines Allround-Servers mit einigen schwach I/O-lastigen Prozessen optimiert ist. Anticipatory hat die typische I/O-Last auf Workstations mit einfacher, eingebauter Festplatte im Blick und ist auf Durchsatzmaximierung ausgelegt statt auf Latenzminimierung. Für Fileserver eignet er sich damit ebenfalls nur wenig.

Der Deadline-Scheduler zu guter Letzt minimiert in erster Linie die I/O-Latenz und eignet sich so für Server mit simpler Storage-Ausstattung wie einfache Festplatten, Software-Raid oder LVM. Je nach Hardware-Ausstattung der Lustre-Knoten verwendet man also NOOP oder Deadline als Scheduler eines OSS.

Einstellen lässt sich der geeignete I/O-Scheduler über den Kernelparameter »elevator=Name«, den man beispielsweise über einen Bootloader wie Grub angeben kann. Aktuelle Kernel erlauben es ferner, Scheduler zur Laufzeit geräte-spezifisch über das Sys-Pseudodateisystem auszutauschen:

root@node0 # cat /sys/block/sda/queue/scheduler
noop anticipatory deadline [cfq]
root@node0 # echo "noop" > /sys/block/sda/queue/scheduler
root@node0 # cat /sys/block/sda/queue/scheduler
[noop] anticipatory deadline cfq

Eine ausführliche Dokumentation der einzelnen I/O-Scheduler sowie des Block-I/O unter Linux im Allgemeinen ist in verschiedenen Dateien in den Kernelquellen unter »Documentation/block/« und unter [11] zu finden.

Redundanz und Datensicherheit

Bei der Entwicklung des Lustre-Dateisystems stand erkennbar die Performance im Mittelpunkt, als schnelles Scratchverzeichnis für große Linux-Cluster ist es deshalb erste Wahl. Das Thema Datensicherheit dagegen ist zurzeit die Achillesferse. Zwar betreibt die CFS-Qualitätssicherung großen Aufwand, um durch umfangreiche Testläufe Datenverluste aufgrund von Fehlern in der Lustre-Software zu vermeiden. Auf Fehler von außen reagiert Lustre jedoch mitunter wenig robust, Redundanz in den Daten ist derzeit nicht vorgesehen.

Wünschenswert wäre daher beispielsweise die Möglichkeit, ähnlich wie bei Festplatten in einem Raid-1-Verbund die Daten auf mehreren OSTs zu spiegeln, sodass das Dateisystem den Ausfall eines OSS problemlos verkraften kann. Die entsprechende Funktionalität, mitunter als Lustre-Raid-1 oder LAID1 bezeichnet, existiert zwar schon auf dem Reißbrett für Lustre 2.0, aber noch nicht in der Praxis.

Speichern ohne Garantie

Überhaupt gibt Lustre kaum Garantien dafür, dass geschriebene Daten tatsächlich dauerhaft gesichert bleiben. Das kann im Extremfall zu bizarren Situationen führen. Schreibt man Daten in ein privates File auf einem Lustre-Dateisystem, wartet einige Minuten und öffnet die Datei danach neu, ist nicht sicher, dass die Datei die geschriebenen Daten enthält, selbst wenn alle Systemaufrufe ohne Fehlermeldung ablaufen. Das kann passieren, wenn beispielsweise vorübergehende Probleme in der Netzanbindung manche Clients vom Netz trennen, andere aber noch Verbindung zu den Servern haben und potenziell Daten verändern könnten.

Aus Lustre-Sicht ist es daher vernünftig, die verlorenen Clients bei ihrer Rückkehr anzuweisen, ihre Zwischenspeicher zu leeren. Der Haken daran: Während ein Anwender meist sofort bemerkt, wenn ein lokales Dateisystem wegen eines Absturzes Daten verliert, ist ihm bei einem Netzdateisystem wie Lustre oft gar nicht bewusst, dass überhaupt Probleme aufgetreten sind, weil es die Daten schleichend verfälscht.

NFS umgeht diese Schwierigkeit ab Protokollversion 3 durch so genanntes Sync on Close: Da der »close()«-Systemaufruf der letzte Zeitpunkt ist, um eine Applikation über aufgetretene Fehler zu informieren, kehrt er bei einer NFS-Datei erst wieder zurück, wenn der Server sämtliche Daten auf ein dauerhaftes Speichermedium geschrieben hat.

Lustre bietet keine vergleichbare Funktion. Stattdessen empfehlen die Entwickler den Sync-Befehl oder die Systemfunktionen »sync()« und »fdatasync()« aufzurufen, um Datenintegrität zu gewährleisten. Das mag von Hand noch machbar sein, in bestehende Programme ist dies oft nur mit Mühe zu integrieren. Erst die Ende August veröffentlichte Version 1.6.2 bietet nun eine Mount-Option »sync« an, die alle Lustre-Dateisystemaufrufe synchron ausführt – erhebliche Performance-Einbußen inklusive.

Vermisst: Tragfähiges Backup-Konzept

Auch ein schlüssiges Backup-Konzept fehlt der Software bislang. Zwar lassen sich prinzipiell von jedem Client aus herkömmliche Sicherungen à la »tar« ziehen, doch gehen dabei alle Lustre-spezifischen Metainformationen wie beispielsweise die Stripingmuster verloren. Fällt ein OST aus, muss der Admin potenziell eine vielfach höhere Datenmenge zurückschreiben, da das Backup jede Datei komplett restaurieren muss, auch wenn nur einzelne Stripes durch den Defekt verloren gegangen sind.

Der Mehraufwand kann die Rücksicherung erheblich verlängern, denn typische Lustre-Dateisysteme umfassen Datenmengen von vielen TByte bis hin zu einigen PByte. Tatsächlich plant CFS auch bereits Backup-Lösungen, die es erlauben sollen, zum Beispiel mit Hilfe von LVM-Snapshots einzelne OSTs zu sichern. Bislang ist das jedoch noch Zukunftsmusik.

Die Empfehlung

Wer ein Lustre-Dateisystem produktiv betreiben will, sollte aus den genannten Gründen Fehlerquellen für Hardware-Ausfälle oder Datenverlust mit allen Mitteln vermeiden. Vor allem sind Raids, möglichst mit batteriegepufferten Caches, ein absolutes Muss. Der MDS sollte über einen redundanten Ersatz verfügen und auch auf OSS-Seite bieten sich Hochverfügbarkeits-Paare an.

Lustre bietet Failover-Mechanismen, die es erlauben, in Verbindung mit Software wie Heartbeat oder Cluster Manager einzelne Dienste bei laufendem Betrieb auf einem anderen Rechner zu übernehmen.Den Preis dafür zahlt man auf Seiten der Hardware, denn statt günstiger lokaler Festplatten benötigt eine solche Konfiguration Shared Storage, wahlweise über externe Arrays mit einem gemeinsamen SCSI-Bus oder LUNs in einem Fibre-Channel- oder I-SCSI-SAN.

Ohne redundante Hardware-Ausstattung sollte man Lustre derzeit noch nicht als dauerhaften Datenspeicher einsetzen. Für Homeverzeichnisse etwa eignet es sich nicht besonders gut. Als schneller Scratchbereich etwa für Clusterberechnungen taugt es jedoch allemal und lässt in diesem Bereich auch kaum Wünsche offen – die Top 500 beweist es.

Die Software selbst präsentiert sich ausgereift, die verfügbare Dokumentation ist umfangreich und gut gepflegt. In der Praxis legt die Kernel-seitige Implementierung den Anwender auf bestimmte Betriebssystemversionen fest. Dafür erhält er höchste Speicherkapazitäten mit ungeahnter Performance. (jcb)