Verteilte Daten

Was passiert eigentlich, wenn man auf Daten entfernter Rechner per NFS zugreift? Ein Blick hinter die Theorie- und Praxiskulissen.

Bereits 1984, also lange, bevor Linus Torvalds auch nur annähernd an Linux dachte, und die Computer-Welt noch von Mainframes regiert wurde, machte sich das Unternehmen Sun Microsystems an die Aufgabe, ein System zu entwickeln, mit dem man über das Netzwerk auf Dateien anderer Rechner zugreifen und diese auslesen, verändern oder abspeichern konnte. 1985 war es schließlich soweit: Sun stellte "NFS Version 2" (NFS V2) der Öffentlichkeit vor. Mit der Veröffentlichung der Spezifikation selbst durchbrach Sun zum ersten Mal die geheiligte Tradition der Geheimhaltung solch technischer Einzelheiten – und ebnete damit letzten Endes den Siegeszug von NFS. Sun stellte allen anderen 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 alle möglichen Plattformen wie System V, BSD, AIX, HP-UX und später auch Linux portiert und ist heute Teil jeder Linux-Distribution. Doch was verbirgt sich hinter diesen drei Buchstaben? In erster Linie ein zustandsloses Protokoll, d. h., die beteiligten Programme müssen sich nicht merken, in welchem Zustand ihre Verhandlungen stehen, und sie müssen auch nicht dauernd miteinander reden.

Protokoll-Kollegen

1991 veröffentlichte SunSoft, eine Sun-Tochtergesellschaft, eine Protokoll-Suite namens ONC ("Open Network Computing"), in die alle an einem Datei-Zugriff über NFS beteiligten Protokolle integriert wurden.

Der NFS-Dienst vertritt dort die Applikationsebene, d. h., mit ihm wird direkt gearbeitet. Ein weiterer, wichtiger Kollege aus der ONC-Suite ist der "Remote Procedure Call"-Dienst (RPC), der die Empfangszentrale für Anfragen von Clients ist. Diese leitet er an die zugehörigen Ports und Server weiter, die die eigentliche Arbeit machen.

Da NFS verschiedenartige Plattformen, unabhängig von ihren Herstellern, verbinden möchte, gibt es bei der Verständigung oftmals Probleme. Diese löst der XDR-Dienst ("External Data Representation") durch Konvertierung der Daten, d. h., er übersetzt alle eingehenden Daten in ein für das Betriebssystem des Rechners verständliches Format. Auf der Applikationsebene tummeln sich nicht nur der NFS-Dienst selbst, sondern auch das Mount-Protokoll oder der Lock-Manager. Ersteres koordiniert den "Einhängevorgang" eines NFS-Server-Dateisystems in den Dateibaum des Client-Rechners. Dabei wird der NFS-Server gefragt und die Berechtigungsnachricht an den Client weitergegeben. Der Lock-Manager sperrt Dateien bzw. Ordner bei bereits bestehenden Verbindungen, um Sicherheit bei der Bearbeitung der Daten zu gewährleisten und konsistente Dateien sicherzustellen.

Der Portier

Da eine Kommunikation zwischen zwei Rechnern über sogenannte Sockets, also die IP-Adresse und die zugehörige Port-Nummer eines Dienstes, läuft, muss der Client, der seine Anfrage an den Server richtet, auch den Port kennen. Dies übernimmt der Portmapper, von Sun auch RPC-Bind genannt.

Abbildung 1: So funktioniert eine Client-Server-Abfrage

Dieses Server-Programm sollte standardmäßig auf Ihrem System installiert sein; es wird beim Booten meist automatisch gestartet. Es pflegt eine kleine Datenbank, in der sich die RPC-Dienste nach dem Startvorgang registrieren. Sie geben unter anderem ihre interne Programm- und Versionsnummer an, durch die bei Anfragen an den Portmapper eine Zuordnung zum richtigen Dienst sichergestellt wird. Man kann den Portmapper mit einem Portier vergleichen, der Ihnen, vorausgesetzt, Sie nennen Ihren richtigen Namen, Ihren Schlüssel aushändigt, mit dem Sie Ihr Zimmer aufschließen können.

Ein Client, der einen RPC-Dienst nutzen will, übergibt den passenden Protokolltyp, die Programm- und die Versionsnummer des Dienstes, sodass der Portmapper seine Datenbank durchsuchen und die auf die Anfrage passende Port-Nummer mitteilen kann.

Abbildung 2: Ausgabe der vom Portmapper verwalteten Versionsnummern und Dienstinfos

Dies geschieht pro Sitzung in der Regel einmal: Der Client merkt sich die Port-Nummer und interagiert nun auf direktem Wege mit dem passenden Server-Daemon. Doch wie starten Sie nun eine NFS-Anfrage?

Nehmen wir an, Sie möchten ein freigegebenes Datenverzeichnis /export/RPMS auf dem NFS-Server (nennen wir ihn defiant und geben ihm die IP-Adresse 192.168.1.1), manuell ins Verzeichnis /mnt/nfs/ auf dem Client-Rechner einhängen. Dazu verwenden Sie den Befehl mount, der vom Einhängen lokaler Datenträger hinlänglich bekannt sein dürfte. Dessen Syntax lautet

mount eventuelle_optionen
 server
:/pfad_zum_verzeichnis
 lokaler_mountpoint

…, in unserem Beispiel also

mount -t NFS defiant:/export/RPMS /mnt/nfs

Damit fragt der Client-Daemon beim RPC-Dienst und beim Portmapper an und übergibt diesem als Programmnummer 100005, als Version 2 und als Protokoll UDP. Programmnummer und Version entnimmt der mount-Client seinen eigenen, internen Daten, die diese standardisierten Nummern enthalten

Abbildung 3: Der NFS-Mount-Vorgang

Daraufhin gibt der Portmapper als Zugriffsport den Port 1033 an (vgl. Abbildung 2), eine Information, die unmittelbar an den Client-Daemon weitergegeben wird. Im nächsten Schritt greift der Client über das entsprechende Socket (192.168.1.1:1033, wobei vor dem Doppelpunkt die IP-Adresse des Servers, dahinter die Port-Nummer für diese NFS-Verbindung steht) auf den Server-Rechner zu, wo der dortige Mount-Daemon direkt angesprochen wird. Von dort aus kommt der NFS-Daemon ins Spiel, der die Berechtigungen prüft und ein sogenanntes File Handle erstellt. Dabei handelt es sich um ein Datenobjekt mit eindeutiger Zufallszahl, die die Identifikation der Datei gewährleisten soll und nur einmalig vergeben wird. Mit diesen Parametern versehen geht die Anfrage wieder zurück zum Client-Rechner, der seinen Aufruf wiederum an den NFS-Client weitergibt. Dieser baut die Verbindung auf, um mit den gewünschten Daten arbeiten zu können.