© Igor Shestakov, 123RF

Der Niedergang der NFS-Erfinderin Sun Microsystems nach der Übernahme durch Oracle im Jahr 2010 stürzte offenbar auch das Network File System in eine Schaffenskrise. Droht nun der völlige Bedeutungsverlust oder findet das Urgestein aus der Unix-Geschichte die Kraft, sich wieder zu erheben?

Für das Titelthema des Linux-Magazins 11/2008 lautete “Die große Fileserver-Frage” noch “NFS 4 vs. 3 – beherzt umsteigen oder Augen zu und weiter?” (Abbildung 1). Acht Jahre später würde die Redaktion NFS kein Themen-Spezial mehr widmen, denn seit Sun im Oracle-Konzern aufgegangen ist, scheint die Entwicklung des einst omnipräsenten Unix-Netzwerk-Dateisystems zum Erliegen gekommen zu sein. Konkurrent Samba auf der einen Seite und neue verteilte Netzwerkspeicher, die fürs Cloud Computing entstanden sind, auf der anderen Seite lassen – so scheint es – den einstigen Fixstern aller Unix- und Linux-Exports langsam verlöschen.

Abbildung 1: Ende 2008 war die NFS-Welt groß und die Frage, ob Admins von Version 3 auf Version 4 umstellen sollten, berechtigt.

Heute liegt die Entwicklung bei der Organisation IETF (Internet Engineering Task Force). Die aktuelle NFS-Version trägt die Nummer 4.1 und ist im RFC 5661 beschrieben [1]. Das Dokument datiert aus dem Jahr 2010, was die These von der stark gebremsten Innovation stützt.

Die aktuellen Linux-Implementierungen [2] bestehen aus mehreren Teilen. Der eigentliche NFS-Server, das NFS-Dateisystem und die Sun RPC befinden sich im Linux-Kernel. Heute lohnt es nur noch, sich mit dem Einsatz von NFSv4 zu befassen. Die architektonisch zur Unix-Glanzzeit gehörende NFSv3 passt technisch nicht mehr zur aktuellen Landschaft (Abbildung 2), allein schon weil sie die Authentifizierung auf dem Client vornimmt, diesem bezüglich der Sicherheit also blind vertraut.

Abbildung 2: Strukturvergleich zwischen der veralteten NFS-Version 3 und der aktuellen NFSv4.

Um den aktuellen NFS-Server aus dem Kernel in Betrieb zu nehmen, bieten einige Distributionen passende Hilfswerkzeuge in einem entsprechenden Paket an – unter Ubuntu etwa in »nfs-kernel-server« . Es enthält unter anderem den Befehl »exportfs« zum Exportieren von NFS-Shares und passende Unit-Dateien für Systemd. Als Alternative zum im Kernel eingebauten NFS-Server bieten einige Distributionen noch den Daemon »rpc.nfsd« an. Er läuft komplett im Userspace, kommt aber gewöhnlich in der Praxis nicht mehr zum Einsatz.

In jedem Fall kapselt ein separates Paket einige nützliche Kommandozeilentools. Diese NFS-Utils (aktuell in 1.3.3) stecken beispielsweise bei Ubuntu im Paket »nfs-common« . Generell lohnt ein Blick, wie progressiv der NFS-Maintainer der eigenen Linux-Distribution die Utils nachzieht; Debian zum Beispiel operierte bei Redaktionsschluss noch mit der Version 1.2.8. Zu den Tools gehören unter anderem die Befehle zum Mounten von NFS-Freigaben sowie einige Analysetools. Dazu zählen »nfsiostat« , »mountstat« und »showmount« – letzteres zeigt die verfügbaren Mounts an. Für die NFS-Utils gibt es Patches [3], die eine Unterstützung für Systemd nachrüsten.

Im Git-Respository sind diese Patches bereits angekommen, einige Distributionen bringen sie aber noch nicht mit. So lag bei Redaktionsschluss beispielsweise Debian selbst in Unstable nur die Version 1.2.8 der NFS-Utils vor. Enthalten sind die Patches jedoch erst in Version 1.3.

Großes Manko: Die mangelhafte Dokumentation

Wer wie die Autoren dieses Artikels versucht, Neuerungen in der NFS-(Kernel)-Entwicklung systematisch zusammenzutragen, bekommt eine weitere Auswirkung des Wegfalls von Sun Microsystems zu spüren: Die Qualität und Quantität der Dokumentation – oder vielmehr deren Fehlen. Zuerst stolpert man über einige veraltete Internetseiten wie die Linux NFS FAQ [2]. Im Linux NFS Wiki [4] mischen sich sogar munter veraltete mit aktuellen Informationen.

Fündig werden Administratoren am ehesten bei Anbietern, die kommerzielle Dienstleistungen rund um NFS anbieten. Dazu gehört das Unternehmen Netapp [5], bei dem die NFS-Client-Maintainer Trond Mykleburst und Anna Schumaker arbeiten. Panasas wiederum engagiert sich vor allem in Bezug auf P-NFS. Das Unternehmen stellt eine eigene Seite [6] mit zahlreichen Informationen und sogar Schulungsvideos rund um die Parallel-NFS-Technik bereit.

NFS-Entwickler und -Anwender diskutieren auf der Mailingliste Linux NFS [7] und bei Veranstaltungen wie Bake-a-Thon und Connectathon. Auf der Website Nfsv4bat.org finden Interessenten Vortragsfolien und mitunter auch Videos der beiden Veranstaltungen [8].

Entwicklungsstand der Software

Sowohl im NFS-Wiki als auch auf vielen anderen Internetseiten fehlen Informationen, welche NFS-Funktion mit welcher Kernelversion überhaupt nutzbar ist. Es bleibt somit eine kleine Sisyphusarbeit, den aktuellen Entwicklungsstand des NFS-Servers im Kernel, der Clientprogramme und der eigenen Linux-Distribution herauszufinden.

Einen ersten Einblick gibt ein Video von Panasas [9], das allerdings nur den Stand bis zum Kernel 3.2 behandelt. Komplett fehlen ein Changelog auf Funktionsebene und eine Feature-Matrix nach Kernelversion, wie man sie etwa vom Btr-FS-Wiki [10] kennt.

Linux diente ursprünglich als Prototyp-Plattform für die Implementation von NFS 4.1 [11]. Als Folge bieten alle halbwegs aktuellen Kernelversionen den Funktionsumfang von NFS 4.1. Der Kerneldokumentation zufolge, konzentriert sich die Implementierung des NFSv4.1-Servers dabei allerdings auf die vom NFS-Standard zwingend vorgegebenen Funktionen [12].

NFS 4.1 bietet gegenüber NFS 4 unter anderem Sessions, Directory Delegations und vor allem den parallelen Zugriff auf Dateien, die auf mehreren Servern gespeichert sind (P-NFS).

Datenbeschaffung beim Storage: Parallel-NFS

Wenn mehrere Clients gleichzeitig Daten anfordern und bearbeiten, bildet der NFS-Server schnell einen Flaschenhals. Das gilt insbesondere, wenn die Dateien auch noch über mehrere Festplatten beziehungsweise Speichersysteme verteilt sind. P-NFS soll den Datenzugriff parallelisieren und somit einen typischen Engpass von NFS beseitigen.

Eine erste P-NFS-Implementierung tauchte bereits 2006 im Linux-Kernel 2.6.14 auf, sie kam jedoch über den Prototypenstatus nicht hinaus. Vorsicht: Nicht wenige Dokumente im Internet beziehen sich verwirrenderweise auf diese frühe Implementierung.

Mit einem aktuellen Kernel agiert der NFS-Server ähnlich wie bei verteilten Dateisystemen à la Ceph nur noch als Metadaten-Server. In dieser Eigenschaft verrät er den Clients lediglich, wo sie die angeforderten Daten finden. Die Dateien fordern die Clients dann optional direkt von den Storagesystemen an (Abbildung 3). P-NFS ist fakultativ, der Client kann immer auch reguläres NFSv4-I/O verwenden [9].

Abbildung 3: Die Clients greifen bei P-NFS direkt auf die Speichersysteme zu.

Wenn der Client auf die Daten zugreifen möchte, klopft er zunächst beim NFS-Server an. Dieser teilt dem Client mit, wo er genau diese Daten findet und mit welchem Protokoll er darauf zugreifen muss. Diese und weitere Metainformationen fasst der NFS-Standard in einem so genannten Layout zusammen [13]. Abhängig von der Storage-Art enthält das Layout andere Daten. Der NFS-Standard unterscheidet derzeit vier verschiedene Layout-Typen: File-, Block-, Object- und Flexi-Layouts.

Zum NFSv4.1-Standard gehört nur die Spezifikation des File-Layouts, um die anderen Layouts kümmern sich jeweils eigene Standards. Mit einem File-Layout können Clients direkt auf einzelnen Dateien arbeiten, die über mehrere Server verteilt sind. Unter Linux existiert eine Implementierung auf Basis des verteilten Dateisystems GFS2 [14].

Das Block-Layout erlaubt den Zugriff auf verteilte, Block-basierte Geräte. Laut der Kernel-Dokumentation [15] exportiert der Linux-NFS-Server derzeit über das Block-Layout nur das XFS-Dateisystem, das sich zudem auf einem verteilten Speichersystem befinden muss – typischerweise einen I-SCSI-Verbund. Das Filesystem muss sich zudem direkt auf dem exportieren Volume befinden, Techniken wie Striping oder Concatenation von Volumes erlaubt Linux derzeit nicht. Das Block-Layout wählt der Server automatisch, sofern es das Dateisystem unterstützt. Damit der Zugriff klappt, muss auf dem Client der Kernel mit aktivierter Option »CONFIG_PNFS_BLOCK« übersetzt worden sein, der Blkmapd-Daemon aus den NFS-Utils laufen und das Dateisystem mit der Protokollversion 4.1 eingebunden sein (via »mount -o vers=4.1« ).

Damit es dabei zu keinen Datenverlusten kommt, ist es unbedingt erforderlich, dass der NFS-Server einen nicht mehr antwortenden Client aussperren darf. Dafür benötigt der Server ein Fencing-Skript, dessen Inhalt jedoch nicht dokumentiert ist. Immerhin liefert die Kernel-Dokumentation ein kleines unkommentiertes Beispielskript [15].

Eine Verbesserung der Situation verspricht das neue P-NFS-SCSI-Layout von Christoph Hellwig, der vor allem im Bereich XFS und Dateisysteme arbeitet ([16], [17]). Mit dem SCSI-Layout können Clients direkt auf die SCSI-LUNs zugreifen. Derzeit ist der Fileserver auch hier auf XFS angewiesen, und Striping sowie Concatenation sind nicht erlaubt. Die Unterstützung für das SCSI-Layout aktiviert der Server automatisch, wenn sein Kernel mit der Option »CONFIG_NFSD_SCSI« übersetzt ist, man das Dateisystem mit dem Parameter »pnfs« exportiert und das SCSI-Device mit den so genannten Persistent Reservations klarkommt. Auf der Client-Seite gelten die gleichen Voraussetzungen wie beim Block-Layout.

Beim Object-Layout erfolgt der Zugriff normalerweise über T10-OSD- und somit speziellen SCSI-Kommandos. Unter Linux existiert eine Implementation auf Basis des Exo-FS-Objekt-Dateisystems mit Raid-0-Striping, Raid-1-Mirroring und Raid-5 [18].

Recht neu ist das Flexible File Layout, meist mit Flexfiles oder Flexi-Layout abgekürzt. Es soll vor allem die Kommunikation mit dem Metadata-Server reduzieren [19]. Seit einem Jahr existiert eine erste Implementierung im Kernel.

Der Lesestoff ist auch für P-NFS mager: Admins müssen sich durch die Texte in der Kerneldokumentation [20] wühlen.

Dual-Protocol-Fileserver

Einen Fileserver für Linux- und Unix-Clients mit NFS oder einen Samba-Server für Windows-Clients aufsetzen, das gelingt praktisch jedem Admin. Wer aber eine heterogene Anwenderlandschaft mit einem Fileserver zu versorgen hat, kommt automatisch in die Versuchung, Shares mit beiden Protokollen einzurichten. Netzwerk-seitig ist das erwartungsgemäß unproblematisch.

Die tatsächlichen Probleme janusköpfiger Fileserver ergeben sich aus der bei Windows und Linux unterschiedlichen Art der Lockings und aus drohenden Inkonsistenzen, sobald Clients Daten cachen [21]. Eine weitere Schwierigkeit: NFS und Cifs organisieren ihre Access Control Lists anders, was früher bedeutet hat, dass nur ein Subset aus Posix-1003.1e-ACLs und Windows-ACLs als kleinster gemeinsamer Nenner blieben.

Die NFS-Version 4 verringert die Schwierigkeiten des Dual-Portokollbetriebs deutlich, indem sie sich mit Features wie Mandatory Locking, Share Reservations und Delegations strukturell mehr an Windows-Dateisysteme und insbesondere an Cifs anlehnt. Die Benutzer- und Gruppeninformationen überträgt NFSv4 zudem als UTF-8-Klartext und nicht mehr als numerische Kennung wie NFSv3. Der Idmap-Dienst setzt Benutzenamen und Gruppen dann auf die Kennungen des Fileservers um, was auch der Zusammenarbeit mit Samba dienlich ist.

Das Ganze ist standardisiert: RFC 3010 etablierte im Dezember 2000 ein neues ACL-System, das auf NFSv4 zugeschnitten ist und häufig implementiert wurde. ZFS beispielsweise unterstützt ACLs ausschließlich nach diesem Standard.

Der aus dem Cyrus-IMAP-Projekt stammende Greg Banks stellte beim Ottawa Linux Symposium 2010 das Projekt Richacls [22] vor – eine Implementation von NFSv4-ACLs im Linux-Kernel mit erweiterter Dateimaskierung –, das ein konsistentes Dateirechtemodell über alle Remote-Filesystem-Protokolle legt und sowohl auf Servern als auch auf Clients greift. Mitstreiter von Greg Banks war Suse-Mitarbeiter Andreas Grünbacher, der heute für Red Hat arbeitet. Er leitet das aktive Richacls-Projekt, das neben Kernelcode auch Patches für Samba, NFS und XFS beinhaltet.

NFSv4 unterstützt Named Attributes. Dabei handelt es sich um einen zusätzlichen Bytestrom, den NFS zusammen mit der eigentlichen Datei ablegt [23]. Windows kennt für sein NTFS-Dateisystem ein ähnliches Konzept, das unter der Bezeichnung Alternate Data Streams läuft. Named Attributes sind übrigens nicht mit den Extended Attributes des Ext-Dateisystems verwandt.

Multihosts und Zero Copy

NFSv4 gibt Ressourcen über ein Pseudodateisystem (virtuelles Root-Filesystem) frei, sodass der Admin beliebige Freigabepfade definieren darf. Clients hängen alle Freigaben mit einem einzigen Mount-Befehl ein, der nur den NFS-Server benennt. Seit Kurzem darf ein NFS-4.1-Client zudem beim Mounten mehrere Hostnamen angeben, was bei sich häufig ändernden Servernamen administrative Erleichterung verspricht [24].

Um die Geschwindigkeit zu steigern, können Clients mehrere Verbindungen mit dem NFS-Server aufbauen. Beim Session Trunking fasst NFS mehrere Verbindungen in einer Session zusammen [25]. Es gibt noch andere Performance-steigernde Maßnahmen im aktuellen NFS. Bei einer Kopieroperation etwa fordert der Client die zu kopierenden Daten an, um sie an anderer Stelle wieder auf den Server zu kopieren. Das ist offensichtlich keine effiziente Methode.

Doch mit Zero Copy kann der Server selbst die Operation durchführen, was im einfachsten Fall nur eine Copy-on-Write-Kopie erfordert. Diese Kopien, die Anwender zumindest bei Btr-FS und XFS manuell mit dem Befehl »cp –reflink« anlegen dürfen, benötigen zunächst keinen extra Speicherplatz. Erst bei Schreibzugriffen in die Kopie belegen die Dateisysteme zusätzlichen Speicher.

Samba unterstützt Zero Copy mit einem IOCTL. Und es gibt eine technisch besonders charmante Variante davon, die den virtuellen Kopiervorgang an Btr-FS auslagert [26]. Für NFS 4.2 existiert ein entsprechender Ansatz; die Patches von Anna Schumaker, die bei Netapp arbeitet, stehen aber noch in der Kritik [27].

Fazit und Ausblick

Der faktische Untergang von Sun hat das NFS-Projekt kräftig ins Stolpern gebracht. Einerseits geht die Entwicklung – zumindest in Sachen Versionssnummern – sehr schleppend voran. Es lässt sich kaum seriös prognostizieren, ob wohl je ein NFSv5 erscheinen wird. Zum anderen bremst die fehlende oder veraltete Dokumentation alle Anwender aus, die neue Features ausprobieren wollen: Es ist für jeden Admin schwer einzuschätzen, welche Funktion in seiner Linux-Distribution mit einer bestimmten NFS-Version bereits produktiv einsetzbar ist.

Während einige Funktionen reibungslos mit einem aktuellen Kernel und den NFS-Utils arbeiten, müssen Admins bei vielen optionalen Funktionen ausgiebig recherchieren und Erfahrungen mit einem Testsetup sammeln. Erschwerend kommt hinzu, dass nicht jede Linux-Distribution von sich aus alle NFS-Neuerungen im Kernel aktiviert und die neuesten NFS-Utils mitliefert.

Die Spezifikation des aktuellen NFS 4.1 stammt aus dem Jahr 2010. Zwar begannen bereits 2011 die Arbeiten an NFS 4.2, die entsprechende Spezifikation [28] liegt aber bis heute nur als Entwurf vor. Version 4.2 wird unter anderem effizienter mit so genannten Sparse Files umgehen können, Named Attributes und Zero Copy beherrschen. Neuere Kernel unterstützen bereits einige Funktionen aus der NFS-4.2-Spezifikation.

Diese dankenswerten Entwicklungen drohen jedoch unterzugehen, weil sich die aktuelle NFS-Heimat IETF wenig um die Popularisierung des Samba-Konkurrenten kümmert. Dieser Artikel versucht, dem durch die zusammengetragenen Informationen entgegenzuwirken.