Definition Was ist das Network File System (NFS)?

Autor / Redakteur: Walter Schadhauser / Rainer Graefen

Mit dem Aufkommen der Client-Server-Architektur musste das Problem gelöst werden, wie man die auf dem Server liegenden Dateien auf dem Client darstellen kann. Beide Rechner verfügen eventuell über unterschiedliche Betriebssystem und könnten auch über unterschiedliche Netzwerktopologien verbunden sein. Das Ganze muss zudem für eine skalierfähige Umgebung funktionieren. NFS, das Network File System, löst dieses Kommunikationsanforderung vor allem für die Unix/Linux-Umgebung.

Anbieter zum Thema

Das Network File System (NFS) hat schon viele Stürme überstanden.
Das Network File System (NFS) hat schon viele Stürme überstanden.
(Bild: CBIT)

Obwohl es kaum einen Bereich gibt, der in den letzten Jahren so sehr an Bedeutung gewonnen hat, wie die Vernetzung von Server und Clients – man denke nur an die allgegenwärtige Cloud-Diskussion – tat sich lange Zeit nur wenig im Bereich der Netzwerkdateisysteme oder Dateiprotokolle.

Beim wichtigsten Vertreter SMB herrschte weitgehend Stillstand, die ersten Kommentatoren mutmaßten schon, dass Microsoft die Weiterentwicklung zugunsten von NFS einstellen könnte. Doch im April 2012 stellte der Windows-Gigant SMB 3.0 vor, dass während der Entwicklung noch als Version 2.2 bekannt war.

Grundlegender Datenaustausch

Wie in der Unix/Linux-Welt üblich werden Internet-Standards per Request of Comment (RFC) veröffentlicht. Bei NFS handelt sich sich um einen Internet-Standard, der die Verfahrensweisen in einem verteilten Dateisystem regelt. Während das seit vielen Jahre benutzte NFS-Protokoll in Version 3.0 (NFSv3) den Client-Rechner authentisiert, ändert sich das mit NFSv4.x. Hier muss sich wie beim SMB-Protokoll von Windows der Benutzer authentifizieren.

Unter der Überschrift Schematischer Ablauf der Datenübertragung bei NFSc3 findet sich bei Wikipedia eine Beschreibung der Kommunikationsaufnahme zwischen Server und Client.

Im Prinzip geht es um technische Vorgaben (Metadaten) über welche Ports und mit welchen Programmen "gesprochen" wird und welches Filehandle, eine Art Betreff, für den Datenaustausch genutzt wird.

Zum Schluss dieser Prozedur verfügt der Client über ein Server-Dateiverzeichnis, den er sich in sein lokales Filesystem einhängen kann (mounten).

NFSv4.x

Bei NFSv4.x wurde eine weitreichend überarbeitet Fassung der oben angedeuteten Prozeduren notwendig. Mangelnde Geschwindigkeit, strengere Sicherheitsaspekte beim Zugriff auf Maschinen und Daten wie auch virtuelle Maschinen und Container erforderten diese weitreichende Protokollupdate. Unix-spezifischer Code wurde generalisiert und nicht zuletzt wird durch Multi-Prozessorsysteme die Parallelisierung des Datenaustauschs zwischen virtuellen und physischen Quellen und Zielen unverzichtbar.

So wurden mit NFS 4.1 Anfang 2010 unter anderem Sessions und Statefulness eingeführt. Damit sind Recovery-Aktionen deutlich einfacher und schneller möglich, denn Server und Client können nach einem Verbindungsfehler relativ simpel klären, welche Locks aktiv und welche Dateien geöffnet waren sowie welche Daten schon geschrieben wurden.

Die Version NFSv4.2 sollte 2015 schon vor der Freigabe sein, 2016 war sie es immer noch nicht. Für 2017 haben wir nichts gefunden. Es geht in dieser Fassung um Detailverbesserungen wie Application Data Blocks, Guaranteed Space Reservation und Server Side Copy.

Vor allem Server Side Copy, eine Technik um bei großen Transfers den Client möglichst aus der Bandbreiten-intensiven Arbeit herauszuhalten, zeigt, worauf die NFS Special Interest Group der SNIA den Entwicklungsschwerpunkt legt: auf hohen Durchsatz, um mit zum Standard werdenden Non-Volatile-Speichern wie SSDs optimal umgehen zu können.

Einfacher, paralleler Datenzugriff mit pNFS

Obwohl es eine ganze Reihe interessanter Erweiterungen in NFSv4.1 gab, verdient pNFS ebenso Aufmerksamkeit. Die Protokollerweiterung wurde im Januar 2010 freigegeben und ist in RFC-5661 definiert. pNFS legt fest, wie Daten in einem verteilten Datensystem gelagert werden. Ein Metadaten-Server (MDS) verwaltet das Layout mit den Speicherorten der Dateien.

Im Prinzip geht es darum, den Weg der physikalischen Daten von der klassischen Aufteilung Client – Server – Speichersystem zu befreien und den Server aus der Transaktionen weitgehend herauszuhalten. Trotzdem soll nach wie vor auch herkömmlicher Zugriff auf die Dateien möglich sein.

Clients, die pNFS unterstützen, fragen beim MDS nach dem Lagerort der gewünschten Daten und beziehen die Dateien direkt vom Speicherort, ohne über einen Server als zwischengeschaltete Instanz gehen zu müssen. Die Daten können über mehrere Speicherorte verteilt sein, der Client hat die Möglichkeit parallel von allen Lagerorten zu lesen.

Ihre Vorteile macht die Technik vor allem bei der Bearbeitung von vielen kleinen oder sehr großen Dateien geltend, besonders im Umfeld geclusterter Server, die parallelen Zugriff benötigen. Allerdings sind noch viele praktische Fragestellungen zu klären, liest man des Häufigeren.

Verteilte Datensysteme profitieren von pNFS

Für eine schnelle Implementierung von pNFS sollte der grundlegende Aufbau sorgen. So ist die Parallelität kein Attribut der Daten, sondern ein Arrangement zwischen Server und Client. So können auch Clients ohne pNFS-Unterstützung nach wie vor mit den gespeicherten Dateien arbeiten.

Ein Vorteil, der nicht sofort ersichtlich ist, ist die Multipath-Fähigkeit. Die gewünschte Datei kann zum Beispiel auf mehreren Servern liegen und auch über mehrere Pfade parallel gelesen werden. Durch diese Fähigkeit werden innerhalb des NFSv4.1-Standards Probleme mit dem bisher genutzten Point-to-Point-Modell gelöst.

Je nach genutztem Layout bietet pNFS Unterschiede bei Funktionalität und Leistung. So könnte beispielsweise eine objektbasierte pNFS-Implementation RAID-Parity Berechnungen in der Software auf dem Client durchführen und damit die Leistungsfähigkeit des RAID-Arrays mit steigender Anzahl der Clients skalieren.

Artikelfiles und Artikellinks

(ID:45015337)