Network File System/Server/Beschreibung

Beschreibung

Historie

Bereits 1984, also lange bevor Linus Torvalds auch nur annähernd an Linux dachte und die Computerwelt noch von den Mainframes regiert wurde, widmete sich das Unternehmen SUN Microsystems der Aufgabe, ein System zu entwickeln, das den transparenten Zugriff auf die auf entfernten Rechnern liegenden Daten und Programme ermöglichen konnte

Nahezu ein Jahr nach dieser Ankündigung (1985) stellte SUN NFS Version 2 (NFS V2) der Öffentlichkeit vor

Das Herausragende dieser Präsentation waren jedoch nicht die technischen Finessen, die das System mit sich bringen würde, sondern die Veröffentlichung der Spezifikation an sich
SUN durchbrach zum ersten Mal die Heiligkeit der Geheimhaltung solcher Interna und ebnete damit auch unwillkürlich den Siegeszug von NFS

SUN stellte allen interessierten Firmen die Entwicklungsergebnisse als Lizenz zur Verfügung und ermöglichte somit einen de-facto-Standard in der UNIX-Welt, der sich bis heute durchgesetzt hat und immer noch eine der erfolgreichsten UNIX-Technologien darstellt

Nach und nach wurde NFS auf weitere Plattformen wie System V, BSD, AIX, HP-UX und später auch Linux portiert, wo NFS zur Standardausstattung einer jeden Distribution gehört
Selbst viele Nicht-Unix-Systeme, die es zu einer gewissen Verbreitung gebracht haben, warten mit einer NFS-kompatiblen Implementierung auf

Protokollkollegen

1991 veröffentlichte SUNSoft, eine Tochtergesellschaft von SUN, erstmals eine komplette Sammlung zusammenwirkender Protokolle namens ONC (Open Network Computing), in der alle Bestandteile der Netzwerkkommunikation vom Zugriff auf die Netzwerkhardware bis hin zu Netzwerkanwendungen integriert wurden

Der NFS-Dienst ist Teil dieser ONC-Protokoll-Suite (Abbildung 1) und vertritt dort die Anwendungsebene, d. h. mit dem NFS-Dienst wird direkt gearbeitet
Protokollsuiten

Abbildung 1: Vergleich verbreiteter Protokollstacks

Wie auch das OSI-Modell hat sich die ONC-Protokollsuite als Schema in der Praxis nicht durchgesetzt, auch wenn Protokolle wie XDR (External Data Representation) und der Remote Procedure Call (RPC) untrennbar mit dem NFS-Dienst einhergehen

XDR dient der Konvertierung der zu übermittelnden Daten in ein standardisiertes Format
Dies ist notwendig, da das NFS-Protokoll nicht auf ein System und eine Hardware-Plattform beschränkt ist und unterschiedliche Systeme und Hardware mitunter unterschiedliche Darstellungen der Daten praktizieren

Hinter dem Entferntem-Prozedur-Aufruf (RPC) steckt die Idee, dass Programme auf Funktionen zurückgreifen, die nicht zwingend auf dem gleichen Rechner erbracht werden, wobei sich der Funktionsaufruf aus Sicht des Programms nicht von einem normalen lokalen Funktionsaufruf unterscheidet

Der interessierte Leser findet im Abschnitt Remote Procedure Call des Kapitels Netzwerk-Grundlagen eine umfassende Diskussion der Mechanismen und Probleme des RPCs

Auf der Anwendungsebene tummeln sich nicht nur der NFS-Dienst selbst, sondern auch noch (verwandte) Protokolle wie das Mount-Protokoll, der Netzwerk-Lock-Manager (NLM) und der Netzwerk-Status-Monitor (NSM)

Das Mount-Protokoll ist für den Einhängevorgang des Dateisystems zuständig, ein konkretes Beispiel des doch recht komplexen Vorgangs folgt zu einem späteren Zeitpunkt
NLM und NSM ermöglichen den exklusiven Zugriff auf Dateien über Rechnergrenzen hinweg
Beide Dienste sind für den Betrieb von NFS nicht zwingend erforderlich, ob Sie sie benötigen, erfahren Sie im Abschnitt Interna

Kernel-/Nutzeradressraum-NFS

Wer mit der Materie wenig vertraut ist, wird womöglich zum ersten Mal mit beiden Begriffen konfrontiert sein

Eigentlich erübrigt sich eine Diskussion über Vor- und Nachteile, hat sich doch der kernel-basierte Serverdienst gegenüber der alteingesessenen Implementierung als im Nutzeradressraum tätiger Serverprozess eindeutig durchgesetzt
Und dennoch verlangt eine umfassende Betrachtung einen tieferen Blick hinter die Kulissen

Der so genannte User-Space NFS Server, wie er vor wenigen Jahren noch jeder Linux-Distribution beilag, zeichnet sich vor allem durch eine einfach zu realisierende Implementierung aus

Allein die Tatsache, dass ein Client dieselbe Sicht auf ein gemountetes Dateisystem hat, wie auch der Server, ermöglicht ein simples Mapping von lokalen Gruppen- und Benutzeridentifikationen (gid, uid) auf die vom importierten Dateisystem verwendeten Nummern
Dem User-Space-NFS-Server stand hierzu ein Rpc-Dienst (rpc.ugidd) zur Seite, der anhand einer Tabelle die Umsetzung der Benutzeridentifikationen vornahm
Nicht zuletzt aus Sicherheitsgründen unterstützt der neue Kernel-NFS-Server nur eine stark eingeschränkte Variante dieses Verfahrens (vergleiche Squashing )

Wenn der kernel-basierte Server so aufwändig zu implementieren ist, warum hat man es nicht beim User-Space NFS Server belassen? Im Großen und Ganzen führen alle Überlegungen auf einen Grund zurück: Im Kernel arbeitet der Server entschieden schneller!

Der alte User-Space-NFS-Server kannte kein Threading (vereinfacht ausgedrückt, kann ein thread-basiertes Programm mehrere Aufgaben quasi gleichzeitig verrichten)
Dieses Manko hätte eine Reimplementierung sicher noch behoben, aber auf Grund der strikten Schutzmechanismen im Betriebssystem bleiben dem Kernel-Server etliche Kopieroperationen erspart, da er bspw. die Berechtigung besitzt, Daten direkt in den Speicherbereich der Netzwerkkarte zu befördern
Ein Server im Nutzeradressraum müsste hierzu erst den Kernel bemühen, was allein schon einen Taskwechsel - und damit Zeit - bedingt
Weitere Unzulänglichkeiten sind die fehlende Unterstützung für NLM (Network Lock Manager) und NSM (Network Status Monitor) sowie die leidige Beschränkung der Dateigröße auf 2GB

Die Vorteile des Kernel-Space NFS Servers liegen neben dem Geschwindigkeitsgewinn in dessen erweitertem Funktionsumfang

So beherrscht er mittels der NLM und NSM Protkolle das Setzen von Dateisperren auf exportierten Verzeichnissen
Und da die Überwachung der exports-Datei als Systemruf implementiert ist, müssen Server und Mountd nicht explizit über Änderungen unterrichtet werden
Die (theoretische) Beschränkung der Dateigröße liegt nun bei 263 Bit

Leider besitzt auch die Kernelrealisierung noch eine Schwäche

So werden Dateisysteme, die sich unterhalb eines exportierten Verzeichnisses befinden, nicht automatisch exportiert (bis auf einen Fall; siehe später)
Für diese wird ein extra Eintrag in der exports-Datei und damit clientseitig ein weiterer Mountvorgang notwendig

So komplex obige Ausführungen auch anmuten mögen, aus Sicht des Administrators bestehen bez. der Einrichtung von NFS keinerlei Unterschiede zwischen User- und Kernel-Space NFS

Ausblick

Im kurzen historischen Abriss war von NFS Version 2 die Rede

Version 3 ist seit Jahren existent und an Version 4 wird gestrickt
Die aktuellen NFS-Server (Kernelversionen ab 2.2.19) unterstützen alle Forderungen der Version 2 und bereits wesentliche Teile von Version 3
Die letzte Hürde (NFS via TCP) zur vollständigen Umsetzung von Version-3-Funktionalität ist als experimenteller Patch (ab Kernel 2.4.19) bereits genommen, die stabile Version ist somit nur noch eine Frage der Zeit
Auch Entwicklungen zur Umsetzung von NFS der 4. Version sind angelaufen