Netzwerkdateisysteme

Das von der Firma Sun entwickelte Network File System (NFS) stellt ein verteiltes Dateisystem dar, welches unter U.n.i.x-Betriebssystemen den Zugriff eines Rechners auf die Dateisysteme eines anderen Rechners über das Netz gewährleistet und für die Hersteller anderer OS lizensiert wurde.

NFS arbeitet unabhänig von der Hardware und dem OS, insoweit eine entsprechende Portierung der TCP/IP-Protokollsäule(TCP/IP-Stack) im OS implementiert ist.

NFS ist in der Lage Dateisystemresourcen, transparent für andere Rechner im Netz zur Verfügung zu stellen wobei die per NFS gemounteten Dateisysteme von Benutzern und Applikationen wie lokale FS behandelt werden können; kein spezielles Zugriffsverfahren ist notwendig, da die notwendigen Vorraussetzungen von der TCP/IP-Protokollsäule(bzw. ONC bei Solaris) realisiert werden.

Eine Standalone Workstation z.Bsp. ist vom OS her grundsätzlich unabhängig, kann jedoch Daten und Applikationen über NFS vom Server zur Verfügung gestellt bekommen.

Weiter bindet der abhängige Dataless Client oft /usr und Applikationen in sein lokales FS ein, wogegen der Diskless Client alle Daten, also OS, Applikationen und Daten, vom NFS-Server zugeteilt bekommt.

Seit Solaris 2.5 unterstützt Sun den Autoclient, welcher eine lokale HDD besitzt, auf dieser jedoch nur Swap- und Cachefs anlegt und somit durch Caching und Swapping das Netzwerk entlastet.

Client und Server

Verteilte Dateisysteme arbeiten auf dem Client/Server-Prinzip, wobei Server Rechnern Festplattenresourcen zur Verfügung stellen.

Auch Mischformen der sich gegenseitig zur Verfügung stellenden Resourcen via NFS sind möglich, wobei darauf zu achten ist, dass sich die Client- und Serverdienste der beteiligten Rechnern nicht durch ihre gegenseitigen Abhänigkeiten beim Systemstart blockieren, einen sogenanten Deadlock erzeugen.

Bei dem ,,Thin Server Fat Client"-Konzept beschränkt sich der Server hauptsächlich passiv auf die Realisierung der Schreib- und Leseanforderungen der Clients, wogegen die Clients nicht nur den Zugriff anfordern, sondern auch durch Verfahren zur Fehlerkorrektur aktiv diesen aufrechterhalten, welches eine gute Performance begünstigt.

BEISPIEL folgt später ?

Funktionsweise von NFS

Die Struktur und Funktionalität von NFS weist fogende Aspekte auf.

Transparenz

NFS ermöglicht einen Hardware- und Betriebssystemtyp unabhänigen Zugriff auf Dateisystemresourcen entferter Rechner im Netz.

Dabei wird ein Zugriff des Cliens auf ein über NFS gemountetes Dateisystem als Betriebssystemaufruf an die Dateisystemschnittstelle, dem allen Dateisystemen übergeordneten VFS (Virtual File System), interpretiert.

Das VFS ordnet allen im Dateisystembaum vorhandenen Dateien eine eindeutige vnode-Nummer zu, wodurch eine eindeutige und unabhängige Identifizierung ein jeder Datei ermöglicht wird.

Der vnode einer Datei bestimmt, ob auf dieselbige lokal oder über NFS zugegriffen wird.Bei lokaler Lagerung wird mit Hilfe eines Plattentreibers die Datei von der Festplatte gelesen, der Netzzugriff erfolgt über NFS.

Diese Zugriffe sind transparent, dass heist, dass Systemaufrufe wie read() oder write() ohne die Eingabe spezieller Befehle wie lokale Operationen erfolgen.

Neutralität

Die betriebssystemspezifische Funktionalität wird durch das in der 6. Schicht (Presentation Layer) angesiedelte Protokoll XDR (External Data Representation) und das sich in der 5. Schicht (Session Layer) befindenden TI-RPC (Transport Independent Remote Procedure Call)-Protokolls in ein betriebssystemunabhängiges Format umgewandelt.

Die angeforderten Daten müssen auf dem Server lokal vorhanden sein, der das Ergebnis in entgegengesetzter Reihenfolge an den Client in kleinen Paketen notwendiger Grösse zurück überträgt.

Unabhänigkeit

Dem Server werden vom Client jeweils unabhänige, selbstständig abarbeitbare Netzwerkpakete zugeschickt. Das führt zu einer konsistenten Abarbeitung, da der Server nach Erhalt der Anfrage diese komplet duchführen kann.

!!!!!!!!!!!!!!!!!!!!!Transport Layer ????? TCP

Ein fehlerhaftes Paket wird nicht bearbeitet.

Zustandslosigkeit

Client und Server müssen dank NFS-Protokoll in keiner feststehenden Kommunukationsverbindung miteinander stehen, unabhängig ob auf das UDP- oder TCP-Protokoll zugegriffen wird.

Dieses z.B. bei Verbindungsproblemen vorteilhafte Prinzip wird als Zustandslosigkeit (stateless) bezeichnet.

Bei nichterreichen des Servers wird vom Client das entsprechende Paket nocheinmal versand, ein Server ist völlig unabhängig von einer Verbindung zum Client.

Veränderungskontrolle

Der Server erzeugt beim ersten Zugriff auf eine Datei oder Verzeichnis für den Client ein sogenanntes Filehandle.

Dieses ist eine hexadezimale Zahl, die eine Datei oder ein Verzeichnis eindeutig auf dem Server identifiziert und u.a. Gerätenummern des Dateisystems und Versionsnummern enthält.

Bei jedem weiteren Zugriff des Clients auf die Datei, das Verzeichnis, übermittelt der Client das Filehandle an den Server, wodurch dieser erkennen kann, auf welche Datei, Verzeichnis der Client Zugriff hat.

Über die Versionsnummer kann festgestellt werden, ob die Datei, das Verzeichnis zwischenzeitlich manipuliert wurde und ggf. eine Fehlermeldung ausgeben.

Ein Sperren (Filelocking) verhindert Inkonsistenzen.

NFS-Versionen

Bis Solaris 2.4 war die NFS Version 2 im Einsatz.

NFS Version 2 greift auf das UDP-Protokol zu und ist somit verbindungslos (unreliable), d.h. die Transportschicht (Transport Layer) überprüft nicht, ob die ensprechenden Datenpakete den Zielrechner erreichen, dieses wird vom NFS-Protokoll realisiert.

Dieses erhöht den Netzwerkverkehr, da der Client nach verstreichen einer bestimmten Zeitspanne, die der Server nicht reagiert hat, die Datenpakete erneut auf Reisen schickt.

Ab Solaris 2.5 werden die Versionen 2 und 3 zur Verfügung gestellt, wodurch zwischen Server und Client jeweilig ausgehandelt wird, auf welche Version zugegriffen wird, welches Protokoll, UDP oder TCP, angewand wird.

Ist sowohl auf dem Client als auch auf dem Server die NFS Version 3 implementiert, wird diese immer verwendet.

NFS Version 3 erzeugt eine deutlich verbesserte Performance ohne die Zuverlässigkeit des Netzwerkzugriffs zu beschränken.

Auch werden Dateien grösser 2 GB und Zugriffsregelungen auf der Basis von ACL unterstützt.

Das TCP-Protokoll ist ab NFS Version 3 standard, es ermöglicht einen verbindungsorientierten (reliable) Zugriff.

Kommunikationsprobleme werden direkt in der Transportschicht erkannt und behoben, was zu einer Reduzierung des Netzwerkzugriffs führt und den NFS-Dienst in der Anwendungsschicht (Applikation Layer) sowie die CPU entlastet.

Da eine TCP/IP-Verbindung zu einem Server im Vergleich zu einer UDP-Verbindung erheblich aufwendiger ist, wird ab NFS Version 3 eine multiplexe, d.h. eine mehrfach verwendbare TCP-Verbindung aufgebaut, über die sämmltliche gemounteten Dateisysteme kommunizieren.

Im Gegensatz zu NFS Version 2, bei der die maximale Paketgrösse für den Datenaustausch 8 kbytes beträgt, wird bei NFS Version 3 keine feste Grösse festgelegt; es ist jedoch ab Solaris 2.5 eine maximale Transfergrösse von 32 kbytes implementiert.

Unterstützen sowohl Server als auch Client NFS Version 3, wird zwischen beiden die optimale Paketgrösse, in Abhänigkeit von Bandbreite und Qualität, für den Transfer ausgehandelt, ansonsten gilt die 8 kbytes Grenze von NFS Version 2.

Die Transfergrösse von NFS ist nicht identisch mit der Blockgrösse der zugrundelegenden Dateisysteme.

Ab Solaris 2.6 unterstützt NFS den Einsatz von Ersatzservern (Failover).

Der Schreibvorgang bei NFS

Die Zeitdauer die eine Applikation benötigt, um die Daten sicher auf einem Datenträger des Servers zu speichern, stellt die Geschwindigkeit des Schreibvorgangs dar.

Der synchrone Schreibmodus (synchronus write) von NFS Version 2 schreibt die Daten des Clients in den lokalen NFS-Cache im Hauptspeicher, leitet diese an den zuständigen Server weiter und wird von diesem umgesetzt; ein Client-Schreibzugriff erzeugt einen direkten Server-Schreibzugriff.Anschliessend meldet der Server den Vollzug des Schreibvorgangs an den Client, worauf dieser die entsprechenden Daten aus seinem NFS-Cache im Hauptspeicher löscht und die Applikation darüber informiert. Geschieht dieses innerhalb eines bestimmten Zeitrahmens nicht, überträgt der Client seine Daten aus dem NFS-Cache erneut an den Server.

Im Gegensatz dazu arbeitet NFS_Version 3 im asynchronen Schreibmodus (safe asynchronous write), wobei, wie bei NFS Version 2, der Client seine Daten im NFS-Cache seines Hauptspeicher schreibt und diese anschliessend an den Server weiterleitet, jedoch vom Server sofort eine Empfangsmeldung über den Schreibvorgang erhält, ohne tatsächlich den Schreibvorgang durchgeführt zu haben, so das dieser der Applikation den erfogreichen Schreibvorgang melden kann. Aus Sicherheit behält der Client die entsprechenden Daten solange im NFS-Cache seines Haupspeichers, bis er vom Server für seine Schreibvorgänge, es können durchaus mehrere verschiedene sein, eine Bestätigung derselbigen verlangt (commit) und diese vom Server erhalten hat.

Der NFS-Server sammelt mehrere Schreibvorgänge durchaus mehrerer Clients und schreibt diese als einen Schreibvorgang auf seine Platten.

Die Client, bzw. ihre Applikationen löschen die dementsprechenden NFS-Pakete nach Erhalt der Schreibbestätigung durch den Server aus ihren NFS-Caches (close-to-open).

Kann der Server die Daten nicht speichern, wird dieses den Applikationen der Clients mitgeteilt, so dass sie die Anwender über eine Fehlermeldung darüber informieren.

Bei NFS Version 3 wird vor dem Öffnen einer Datei eine Überprüfung der Zugriffsrechte durchgeführt und g.g.f. eine FM "Open Error" anstatt wie bei NFS Version 2 "Read Error" und "Write Error".

Der Lesevorgang von NFS

Die Zeitdauer die eine Applikation warten muss, um die angeforderten Daten vom Server zu erhalten, wird als Lesegeschwindigkeit bezeichnet.

NFS Versionen 2 und 3 verwenden für den Lesezugriff die gleichen Verfahren, bei dem einerseits die Lesedaten im Hauptspeichers des Clients gepuffert werden, andererseits vorrausschauend mehr daten vom Server geliefert werden (read ahead).

Dieses soll die Lesezugriffe der Clients reduzieren.

Jedoch erzeugt dieses Caching die Möglichkeit einer Dateninkonsistenz.

Befinden sich Daten im NFS-Cache eines Clients, so besteht die Möglichkeit, dass die Oiginaldaten auf dem Server in der Zwischenzeit durch den Zugriff anderer Clients manipuliert wurden.

Um möglichst aktuelle Daten im NFS-Cache des Clients zu haben, vergleicht dieser, ist der Caching-Eintrag älter als 30 Sekunden, über einen getattr-Aufruf, Cach- mit Originaldaten.

NFS Version 3 gleicht bei jedem Zugriff die Attribute der sich im NFS-Cache des Clients befindenden Daten mit den Originaldaten ab, um die Daten aktuell zu halten, was bei NFS Version 2 durch einen expliziten getattr-Aufruf realisiert wurde.

Zusätzlich wurde bei NFS Version 3 die Methode für das Übertragen von Datei- und Verzeichnisinformationen (lookup) optimiert.

Insgesammt führt das zu einer Performancesteigerung im Vergleich zu NFS-Version 2 von 20-30 %.

Wichtige Hintergrundprozesse für NFS

Der Rechner führt beim Hochfahren in den Systemzustand (Runlevel) 2 (Init-Level 2) das Skript /etc/rc2.d/S73nfs.client aus, was die NFS-Clientfunktionalität aktiviert.

Die von o.g. Skript gestarteten Daemonen statd und lockd sollten immer laufen, da sie auch für die lokale Arbeit mit dem Dateisystem benötigt werden.

Beim Beenden des Runlevel 2 werden die Skripten /etc/rc2.d/K60nfs.server und /etc/rc2.d/K65nfs.client abgearbeitet und somit alle NFS-Dienste beendet.

Wird der Rechner in den Runlevel 3 gefahren, wird vom Betriebssystem der NFS-Serverdienst durch das Skript /etc/rc3.d/S15nfs.server ausgeführt, vorrausgesetzt, in der Datei /etc/dfs/dfstab ist ein gültiger share-Eintrag vorhanden und dadurch die Hintergrundprozesse nfsd und mountd gestartet.

Duch die Eingabe in der Shell von

                                 # /etc/init.d/nfs.client {start | stop}

                                 # /etc/init.d/nfs.server {start | stop}

können die Dienst auch manuell gestartet bzw. beendet werden.

Folgende Hintergrundprozesse müssen abhänig davon, ob es sich um einen NFS-Server oder NFS-Client handelt, im System vorhanden sein:

                                 nfsd

                                 mountd

                                 lockd

                                 statd - status daemon ??????????????

                                 rpcbind- remote procedure call binding

                                 keyserv

nfsd

Der nfsd-Prozess läuft nur auf NFS-Servern und bearbeitet die Zugriffsanfragen von Clients.

Im Gegensatz zu vielen anderen U.n.i.x-Systemen, die für eine optimale Unterstützung der Clients mehrere Instanzen von nfsd starten müssen, kann bei Solaris aufgrund der Programmierung des nfsd in Multithreatingtechnologie eine effiziente Unterstützung von Clients durch die Abspaltung von Threads verwirklicht werden.

Für jeden NFS-aktiven Clientprozess müssen grundsätzlich zwei nfsd-Threads gestartet werden, wobei bei MicroSPARC-Prozessoren 32, bei SuperSPARC-Prozessoren 64 und bei UltraSPARC-Prozessoren maximal 128 nfsd-Threads pro Prozessor gestartet werden können.

Die Multithreatingtechnologie von Solaris ermöglicht die optimale Verteilung der nfsd-Threads auf mehrere Prozessoren.

Auch ist die Netzwerkkapazität und die Ein-/Ausgabebelastung der Festplatten nicht zu vernachlässigen und sollte g.g.f. durch den Einsatz von RAID-Systemen optimiert werden.

Das Anzahl der zu startenden nfsd-Threads als auch das Starten und Beenden des NFS-ServerDaemons sollte grundsätzlich nur über das Startskript /etc/init.d/nfs.server erfolgen.

                                 /etc/init.d/nfs.server