Seminar: Aktuelle Probleme der Netz- und Systemadministration Network File System Version 4

Transkript

1 Seminar: Aktuelle Probleme der Netz- und Systemadministration Network File System Version 4 Björn Fischer Technische Fakultät Universität Bielefeld Sommersemester 2000 Zusammenfassung Mit NFSv4 gibt es zum ersten Mal einen NFS-Standard von der IETF. Dieses Dokument beschäftigt sich mit den Problemen bisheriger NFS-Spezifikationen und -Implementierungen, mit den Design- Überlegungen und -Anforderungen für NFSv4 (RFC 2624 [8]) sowie deren Umsetzung (RFC 3010 [11]). Inhaltsverzeichnis 1 Einleitung NFS Transparent für Applikationen NFSv4 ein Standard der IETF Entstehungsgeschichte Anforderungen und Designkriterien Komplexität der Spezifikation bfischer@techfak.uni-bielefeld.de 1

2 3 Skalierbarkeit Hohe Latenz Synchron vs. asynchron Aggregierung von Lese- und Schreibzugriffen Reduzierung der Anzahl der RPC-Requests COMPOUND-Prozedur Niedrige Bandbreite Delegation und Callbacks Internet-Tauglichkeit (Accessibility) Firewalls und Proxies Anforderungen an den Transport Interoperabilität und Portabilität Persistente und volatile Filehandles Erweiterte Attribute Disk-Quota Migration Groß-/Kleinschreibung Attribut-Verzeichnisse Sicherheit RPC-Authentication-Flavors RPCSEC GSS File-Locking Network Lock Manager Blocking Locks Leases Internationalisierung (I18N) 23 9 Fazit 24 2

3 1 Einleitung Netzwerk-Dateisysteme 1 sind mittlerweile aus mittleren bis großen Rechnerverbunden nicht mehr wegzudenken. Zu den Hauptursachen zählen sicherlich die enormen Einsparungen im Ressourcenverbrauch in den Bereichen Massenspeicher und Administration, die sich durch den Einsatz derartiger Dateisysteme erschließen. Allein die Vereinfachungen bei der Verwaltung von Dateien auf mehreren Rechnern sind nicht zu unterschätzen: Vor allem dem Benutzer wird einiges an Infrastruktur bildenden Maßnahmen erspart, da ihm auf jedem Rechner seine Dateien sofort und transparent zur Verfügung stehen. Ferner muß der Administrator eines Rechnerverbundes nicht mehr n Kopien der Dateien auf n Rechnern pflegen; nur das Orginal auf dem NFS-Server muß ggf. aktualisiert werden. Das unter Unix TM am weitesten verbreitete Netzwerk-Dateisystem ist NFS (Network File System). Die NFS-Spezifikation liegt mittlerweile in der Version 4 vor, die von der IETF entwickelt und als RFC 3010 [11] (Request For Comments) veröffentlicht wurde. Das vorliegende Dokument soll unter anderem herausstellen, welche Probleme bei Implementierung und Nutzung von NFSv2/v3 auftreten und wie diese Probleme in NFSv4 vermieden oder entschärft werden. 1.1 NFS Transparent für Applikationen Der NFS-Client ist in der Regel ein Teil des Betriebssystem-Kerns und nicht etwa eine Applikation, die auf dem Betriebssystem läuft 2. Für Applikationen, wie z.b. einen Texteditor, ist NFS völlig transparent, d.h. die Applikation weiß nicht, ob zu bearbeitende Dateien auf einem lokalen Massenspeicher oder von einem entfernten Server per NFS zur Verfügung gestellt wird. Wie auf Abbilbung 1 schematisch dargestellt, sind aus der Sicht der Applikation alle Schreib- und Lesezugriffe lokal. Der Hauptvorteil der transparenten Integration von NFS in das Betriebssystem ist also, daß eine Applikation keine besonderen Schnittstellen oder 1 Gemeint sind nichtlokale Client-Server-Systeme, nicht etwa verteilte oder globale Dateisysteme, bei denen Dat(ei)en benutzertransparent auf vielen verschiedenen Rechnern verteilt sind. 2 Auf Ausnahmen wie WebNFS [4, 5] soll hier nicht eingegangen werden. 3

4 Client Host Applikation Local I/O Server NFS Client NFS I/O Abbildung 1: NFS-I/O und lokales I/O Fähigkeiten haben muß, um auch in Verbindung mit NFS zu funktionieren. Das bedeutet aber auch, daß es für das Betriebssystem normalerweise keine Möglichkeit gibt, die Applikation über bestimmte NFS-spezifische Fehlersituationen zu informieren, beispielsweise eine zusammengebrochene Netzwerkverbindung, die erst wieder aufgebaut werden muß, ehe der Lese- oder Schreibvorgang fortgesetzt werden kann. Ein Problem, das in diesem Zusammenhang leider viel zu häufig auftritt, ist das Resultat schlampiger Programmierung: Entwickler von Applikationen machen oft fatalerweise Annahmen, die zwar bei der Verwendung von lokalen Dateisystemen im allgemeinen zutreffen, aber im Zusammenhang mit NFS mindestens gefährlich sind. Im Laufe dieses Dokuments wird auf einige dieser Annahmen eingegangen. 4

5 2 NFSv4 ein Standard der IETF Die Entwicklung der Spezifikation von NFS Version 4 wurde erstmalig von der IETF (Internet Engineering Task Force) betreut [7]. Die IETF organisiert u.a. Entwicklung und Pflege fast aller Netzwerk-Standards, die das Internet betreffen. Auch wenn viele Referenz-Implementierungen diverser Internet- Standards auf Unix entwickelt werden, hat die IETF eher wenig mit Unix oder anderen Betriebssystemen an sich zu tun. 2.1 Entstehungsgeschichte NFS Version 2 NFSv2 [1] wurde, wie auch die erste Version, für die es nie eine veröffentlichte Spezifikation gab, von Sun Microsystems TM entwickelt. Wie auch alle neueren Versionen setzt es auf dem ebenfalls von Sun entwickelte Sun-RPC (Remote Procedure Call) auf. RPC ist ein transportunabhängiges Verfahren, das es ermöglicht, auf anderen Rechnern Prozeduren in transparenter Art und Weise so auszuführen, als seien sie lokal. Auch wenn NFSv2 von Sun entwickelt wurde, war und ist es ein offener Standard, jeder kann sich die Spezifikation beschaffen und eine eigene Implementierung entwickeln. Das war neben der eher auf Pragmatik ausgerichteten Spezifikation an sich einer der Hauptgründe, die für die enorme Verbreitung von NFS gegenüber anderen Netzwerk-Dateisystemen, wie z.b. AFS 3 von der Carnegie Mellon University, innerhalb der letzten Jahre sorgten. Da außer Sun auch andere Hersteller eine NFSv2-Implementierung in ihre Betriebssysteme integrierten, manifestierten sich recht bald Wünsche nach kleinen Erweiterungen und Verbesserungen: Der eine Hersteller wollte beispielsweise Device-Nodes mit 32 Bit auch über NFS benutzen können, ein anderer wollte asynchrone Schreibzugriffe, um noch billigere Server bauen zu können, usw. NFS Version 3 Damit nicht jeder Hersteller sein eigenes proprietäres Süppchen kocht und NFS somit seine Kompatibilität einbüßt, wurde ein informelles Hersteller

6 Konsortium gegründet, das die Weiterentwicklung von NFS vorantreiben sollte. Das Produkt dieses Konsortiums war NFSv3 [2]. Die Mitglieder des Konsortiums waren fast ausschließlich Hersteller von Unix-Betriebssystemen. Demzufolge ist die Verwandtschaft mit typischen Unix-Dateisystemen (z.b. UFS) nicht zu übersehen. Tatsächlich genügt NFSv3 gerade den POSIX- Minimalanforderungen. Andere Betriebssysteme, die nicht auf Unix basieren, tun sich dementsprechend schwer, wenn es darum geht, eine halbwegs vollständige NFSv3-Implementierung zur Verfügung zu stellen. 2.2 Anforderungen und Designkriterien Als die IETF Mitte 1997 anfing, sich intensiver mit NFS auseinanderzusetzen, wurde eine Art Forderungskatalog für die neue Version von NFS aufgestellt. Die im Juli gegründete NFS Version 4 Working Group veröffentlichte im RFC 2624 die Anforderungen und Designkriterien für NFSv4 [8]. In den nächten Abschnitten werden die wichtigsten Kriterien sowie deren Umsetzung in der NFSv4-Spezifikation [11] genauer beschrieben: Skalierbarkeit: Hier ist neben des sinnvollen Betriebs auf schnellen wie langsamen Netzwerken auch die Unabhängigkeit vom Netzwerk-Medium und sonstiger Hard- und Software von Bedeutung. Fer- ner ist natürlich auch die Erweiterbarkeit und Bandbreite der Nutzungsmöglichkeiten gemeint. Internet-Tauglichkeit: NFSv4 soll nicht nur im lokalen Netzwerk, sondern auch im Internet ohne Schwierigkeiten einsetzbar sein. Viele Voraussetzungen dafür werden schon von den anderen Kriterien erfüllt. Es fehlen lediglich wichtige Kleinigkeiten wie Verträglichkeit mit Firewalls, Congestion Control, etc. Interoperabilität und Portabilität: NFSv4 muß auch auf anderen Plattformen als Unix ohne größere Schwierigkeiten implementierbar sein. Die Implementierungen müssen natürlich untereinander kompatibel sein. Sicherheit: Anders als bei bisherigen Versionen von NFS sollen für NFSv4 sichere Authentisierung und Verschlüsselung unter der Verwendung starker Kryptographie Pflicht sein. 6

7 File-Locking: Das File-Locking, das bisher über ein sogenanntes Sideband- Protokoll abgewickelt wurde, ist in NFS zu integrieren. Internationalisierung (I18N): Vor allem Pfad- und Dateinamen sollen nicht auf ASCII beschränkt sein, eine Repräsentation von beliebigen Glyphen sollte möglich sein. 2.3 Komplexität der Spezifikation NFS Version 4 ist keine Erweiterung von NFSv3, sondern ein eigenständiger Standard, der von Grund auf neu entwickelt wurde. Zwar wurden viele Konzepte, Algorithmen und Mechanismen aus früheren NFS-Versionen übernommen, aber auch andere Netzwerk-Dateisysteme wie z.b. AFS wurden in dieser Hinsicht beliehen. Um eine Implementierung zu vereinfachen, und vor allem, um die Minimalanforderungen an eine NFSv4-Implementierung klar definieren zu können, wurde auf zusätzliche Protokolle, sogenannte Sideband-Protokolle wie z.b. MOUNT oder NLM, verzichtet. Auf MOUNT und NLM wird später noch genauer eingegangen. Es wurde viel Wert darauf gelegt, insbesondere für den Bereich Netzwerksicherheit bereits bestehende Infrastrukturen zu verwenden, um eine möglichst schlanke Spezifikation zu erhalten und vor allem, um sich nicht auf neue ungetestete Sicherheitsmechanismen einlassen zu müssen. Gerade auf diesem Gebiet wurden mit NFS in der Vergangenheit schmerzhafte Erfahrungen gesammelt [9]. NFSv4 soll leicht erweiterbar sein. Neben einem funktionierenden Versionsmanagement, das auch die zukünftige Interoperabilität sicherstellt, sind Schnittstellen von Bedeutung, die Entwicklern Möglichkeiten zur Verfügung stellen, auf Basis von NFSv4 auch sehr komplexe Anwendungen zu realisieren. Konkrete Beispiele für diese Schnittstellen sind selbst definierbare Dateiattribute und ACLs (Access Control Lists). So sind mit NFSv4 ohne weiteres selbstreplizierende Dateisysteme (z.b. cachefs), Hochverfügbarkeits- Lösungen oder eine HTTP-Alternative (WebNFS) machbar, ohne eine speziell veränderte oder erweiterte also nicht-konforme NFS-Implementierung zu verwenden. NFSv4 ermöglicht diese Anwendungen ohne Verletzung oder Erweiterung der Spezifikation. 7

8 3 Skalierbarkeit NFSv4 muß auch auf weniger leistungsfähigen Netzwerken sinnvoll einsetzbar sein. Für die Betrachtung der Leistungsfähigkeit eines Netzwerks soll hier eine recht grobe Vereinfachung auf die beiden Parameter Latenz und Bandbreite genügen. Die bisherigen Versionen von NFS waren fast ausschließlich für die Nutzung auf einem LAN mit entsprechend niedrigen Latenzen und hohen Bandbreiten vorgesehen. Auf einem LAN liegen Netzwerk-Latenzen gewöhnlich unter einer Millisekunde. Die Verzögerungen, die auf dem Server entstehen, wenn eine Anforderung bearbeitet und beantwortet werden muß (z.b. Festplattenzugriffe), sind bei typischen NFS-Operationen deutlich größer. Daher wurde NFS bis zur Version 3 hauptsächlich im Hinblick auf die Server-Latenzen optimiert. Die NFSv4 zu bescheinigende Internettauglichkeit fordert vor allem eine Toleranz gegenüber hohen Netzwerk-Latenzen, die sich auf dem Internet von einigen zehn Millisekunden bis in den Sekundenbereich 4 erstrecken können. Daher betrachten wir zunächst Mechanismen, die NFS resistenter gegenüber hohen Netzwerk-Latenzen machen. 3.1 Hohe Latenz Synchron vs. asynchron Wie schon erwähnt, hatte man es bei der Entwicklung von NFSv3 vor allem auf die Server-Latenzen abgesehen. Die NFSv2-Spezifikation fordert synchrone Schreibzugriffe, d.h. bei einer Schreibanforderung darf die Rückmeldung über die erfolgreiche Verarbeitung derselben erst erfolgen, wenn der Server die Daten in nichtflüchtigem Speicher abgelegt hat. Die Computerindustrie hat sogar aufwendige 5 NFS-Server hervorgebracht, die mit nichtflüchtigem RAM (sog. NVRAM) ausgestattet waren, um NFS-Schreibzugriffe zu be- 4 Schon eine ungünstige Satellitenverbindung im Datenpfad kann eine Verzögerung von ein oder zwei Sekunden verursachen. 5 sprich: wirklich teure 8

9 schleunigen 6. NFSv3 erlaubt asynchrone Schreibzugriffe, d.h. der Server kann eine Schreibanforderung bestätigen, sobald er sie erhalten hat. Doch auch hier hat der Client mit einer sog. COMMIT -Prozedur die Möglichkeit, den Server zu zwingen, alle noch ausstehenden Schreibanforderungen abzuarbeiten. Erst wenn sich alle Daten auf nichtflüchtigem Speicher (normalerweise Festplatte) befinden, darf er die COMMIT -Prozedur bestätigen Aggregierung von Lese- und Schreibzugriffen Eine Optimierung, die viele Betriebssysteme unabhängig von NFS mitbringen, ist die Aggregierung von Lese- und Schreibzugriffen, auch bekannt als Caching, das nicht nur bei NFS sondern auch bei anderen (lokalen) Dateisystemen Anwendung findet. Grob vereinfacht kann der NFS-Client (der Betriebssystemkern) bei (linearen) Leseanforderungen der Applikation schon weitere Daten quasi im Voraus per NFS anfordern (Read Ahead) sowie häufig benötigte Daten (z.b. Verzeichnisse) lokal zwischenspeichern. Insbesondere dann, wenn die Applikation immer wieder nur wenige Bytes liest, rentiert sich diese Vorgehensweise extrem schnell. Umgekehrt kann im Schreibfall der Betriebssystemkern erst einmal ein paar Schreibzugriffe der Applikation sammeln und später als einen einzigen NFS-Schreibzugriff an den Server weiterleiten (Write Behind oder Write Clustering). Dies stellt keine Verletzung der NFSv2-Spezifikation dar, weil die Aggregierung vollständig im Client vollzogen wird und nicht im Server Reduzierung der Anzahl der RPC-Requests Bei der Implementierung eines NFS-Servers hat man zwar Einfluß auf die Server-Latenz, die Netzwerk-Latenz läßt sich innerhalb einer NFS-Implementierung aber kaum bis gar nicht beeinflußen. Das NFS-Protokoll muß also möglichst resistent gegenüber langen Netzwerk-Verzögerungen sein; die Performanz darf bei langsamen Netzwerken nicht zu stark sinken. Um dieses Ziel zu erreichen, bleibt nur die Möglichkeit offen, für typische 6 Es gibt auch eine NFSv2-Implementierung in einem aus Finnland stammenden Betriebssystem, das die Spezifikation verletzt und dem Client eine Antwort schickt, sobald die Daten im (flüchtigen) Arbeitsspeicher sind. 9

10 Operationen auf einem Dateisystem (z.b. lies Datei /homes/joe/bigfile oder lies das Verzeichnis /homes/joe) möglichst wenige RPC-Requests zu erzeugen, d.h. möglichst wenige Pakete hin- und herzuschicken. Denn bei hoher Netzwerk-Latenz und Bandbreite ist die Anzahl der RPC-Requests ein direkter Faktor der Gesamtdauer einer NFS-Operation: Halbiert man die Anzahl der RPC-Requests, halbiert sich auch die Gesamtdauer. Aus der Sicht von NFSv2 ist beispielsweise das Unix-Kommando ls -l. extrem teuer: Für jede Datei im Verzeichnis müssen mit den Prozeduren LOOKUP und GETATTR die Attribute (also Größe, Zeitstempel, etc.) gelesen werden. Selbst auf einem LAN entstehen da schnell je nach Anzahl der Verzeichniseinträge Verzögerungen im Sekundenbereich. Speziell für Abläufe wie ls -l. wurde in NFSv3 eine neue Prozedur entwickelt: READDIRPLUS. Sie erledigt ls -l. sozusagen in einem Rutsch. Dadurch sinkt die Laufzeit von ls -l. von O(n) auf O(1). Die Prozedur GETATTR (lesen der Datei-Attribute) ist ohnehin eine der häufigsten NFS-Operationen: Wenn der NFS-Client Daten auf der lokalen Festplatte oder im RAM zwischenspeichert (Cache), muß er in bestimmten Zeitabständen mittels GETATTR feststellen, ob die zwischengespeicherten Daten im Cache noch gültig sind. NFSv3 hat keinen speziellen Mechanismus, um Cachekohärenz zu gewährleisten. Caching ist bis NFSv3 also immer ein Kompromiß zwischen Performanz und Kohärenz. Leider enthält die NFSv3- Spezifikation nicht einmal Richtlinien, wie lange den Daten aus dem Attribut- Cache vertraut werden kann, bevor sie neu angefragt werden sollten. Es muß also damit gerechnet werden, daß sich verschiedene Implementierungen hier sehr unterschiedlich verhalten können COMPOUND-Prozedur Noch einen Schritt weiter bei der Reduzierung der Anzahl von RPCs geht NFSv4: Was in Version 3 mit READDIRPLUS für einen sehr speziellen Sonderfall entwickelt wurde, stellt Version 4 in einer mächtigeren und universelleren Art und Weise zur Verfügung: Die COMPOUND-Prozedur (Abbildung 2). Sie kann quasi beliebig viele Einzelanfragen enthalten. Dadurch werden READDIRPLUS oder die Möglichkeit, die GETATTR-Funktionalität an andere Operationen zu koppeln, überflüssig. Das Cachekonsistenz-Problem bei hoher Netzwerk-Latenz ist mit COMPOUND natürlich auch nicht vollständig 10

11 zu lösen. Jedoch ist NFSv4 dadurch bestens für zukünftige Anwendungsszenarien gerüstet. 3.2 Niedrige Bandbreite Die zweite wichtige Größe für die Performanz von Netzwerken ist die Bandbreite. Innerhalb eines LANs mit zur Zeit üblichen 100 MBit/s lassen sich per NFS Datentransferraten erreichen, die mit etwa 10 MB/s schon fast an lokale Dateisysteme auf Festplatten erinnern. In einem WAN (z.b. Internet) jedoch muß man normalerweise mit erheblich niedrigeren Datenraten auskommen. Man denke an einen reisenden Mitarbeiter, der per Laptop und Modem vom Hotel aus Verbindung zum Netz seiner Firma aufnimmt. Ohne aggressives Caching ist an eine praxisgerechte Benutzung von NFS nicht zu denken. Jedoch ist gerade die bei Caching notwendige Konsistenzprüfung bei hoher Netzwerk-Latenz extrem teuer. Für jede Leseanforderung ein GETAT- TR zu senden ist indiskutabel. Daher haben sich die Entwickler von NFSv4 etwas Neues 7 einfallen lassen: Delegation und Callbacks Delegation und Callbacks Die Idee bei diesem Verfahren ist, daß der Server auf Anfrage des Clients die Verantwortung für oft benutzte Dateien an den Client delegieren kann. Betrachten wir das folgende einfache Szenario: Der Benutzer 8 öffnet eine Textdatei mit einem Editor um diese zu verändern. Der NFS-Client (im Betriebsystemkern) besorgt sich eine Delegation für diese Datei. Solange der Client diese Delegation hat und die Datei vollständig übertragen wurde, muß für diese Datei fast kein NFS-Verkehr erzeugt werden. Alle Änderungen verbleiben zunächst auf dem Client. Der Client muß lediglich das mit der Delegation verbundene Lease 9 in festgelegten Zeitabständen erneuern, damit der Server weiß, daß der Client die Delegation noch verwendet. Wenn der Editor die Datei wieder schließt, aktualisiert der NFS-Client die Datei auf dem NFS- 7 Ganz so neu doch nicht: Andere Netzwerk-Dateisysteme, wie z.b. AFS, verwenden vergleichbare Verfahren. 8 im Hotel mit Laptop und Modem 9 zu verstehen als Gültigkeitsdauer 11

12 Server und gibt die Delegation zurück 10. Falls in der Zwischenzeit allerdings eine andere Applikation auf einem anderen NFS-Client auf die gleiche Datei zugreift sei es auch nur read-only muß der NFS-Server die Delegation vom NFS-Client mit einem sog. Callback vorzeitig wieder zurückfordern. Erst, nachdem der Client die Datei auf dem Server aktualisiert und die Delegation zurückgegeben hat, kann der Server Anfragen von dritter Seite bezüglich der Datei bearbeiten. Antwortet der NFS-Client auf ein Callback nicht innerhalb eines festgelegten Zeitrahmens, verfällt der Delegation-Status auf dem Server und mit ihm alle Änderungen an der Datei. Der Zeitrahmen ist zweckmäßigerweise so gewählt, daß beispielsweise eine zusammengebrochene Modemverbindung wieder aufgebaut und die NFS- Sitzung fortgesetzt werden kann. Obwohl die Folgen einer gecancelten Delegation im obigen Beispiel einer Editor-Sitzung einigermaßen fatal ausfallen können, funktioniert das Delegation- Konzept in der Praxis (z.b. bei AFS) gut und weitgehend ohne derartige Zwischenfälle. Das hat zwei Gründe: Zum einen gibt es separate Schreib- und Nur-Lese-Delegations, wobei die Nur-Lese-Delegations für ein und dieselbe Datei von mehreren NFS-Clients gemeinsam genutzt werden können (shareable). Ein NFS-Server muß einem Client mit einer Nur-Lese-Delegation nur dann einen Callback schicken, wenn sich Dateiinhalt oder Attribute ändern. Im Normalfall stellen Nur-Lese-Zugriffe die deutliche Mehrheit aller Dateioperationen dar. Und andererseits, wenn eine Datei zum Schreiben geöffnet wird, ist es extrem selten, daß auf einem anderen Client genau auf dieselbe Datei zugegriffen wird. Wenn mehrere Benutzer gemeinsam Dateien editieren, ist ohnehin eine andere Infrastruktur indiziert, wie sie z.b. CVS bietet. Eigentlich offenbart das Delegation-Konzept keine Schwächen, die nicht auch bei lokalen Dateisystemen, wie UFS, auftreten: Auch bei UFS können nicht zwei Benutzer (oder Applikationen) schreibend auf dieselbe Datei zugreifen, ohne daß Inkonsistenzen entstehen. Nur ein Locking-Mechanismus, der prinzipbedingt ähnliche Probleme beim Recovery hat wie Delegations, kann das verhindern. Von dieser Seite betrachtet stellen Delegations nichts anderes dar, als eine spezielle Form von Locking. 10 Spätestens hier sollte offensichtlich sein, warum die weit verbreitete Annahme close() schlägt nie fehl, daher braucht man den Rückgabewert nicht zu überprüfen fatal sein kann. Es ist nicht überraschend, daß diese Annahme oft mit der Unkenntnis von fsync() korreliert. 12

13 4 Internet-Tauglichkeit (Accessibility) In den vorhergehenden Abschnitten wurde Skalierbarkeit als eine für NFSv4 unverzichtbare Eigenschaft ausgiebig erörtert. Skalierbarkeit spielt für die Internet-Tauglichkeit eines Protokolles natürlich eine zentrale Rolle. Die Resistenz gegen niedrige Bandbreiten und/oder hohe Latenzen allein genügen aber nicht. In diesem Abschnitt werden weitere Kriterien aufgezählt, die NFSv4 internettauglich machen sollen. Viele davon wie z.b. Sicherheit und Zugriffskontrolle sind so umfangreich, daß sie gesondert behandelt werden. 4.1 Firewalls und Proxies Es gibt Protokolle, die einem Systemadministrator regelmäßig Kopfschmerzen bereiten, wenn es darum geht, einen Paketfilter oder gar eine Firewall einzurichten und zu pflegen. In der Geschichte des Internets ist das Konzept der Firewall relativ neu. Viele weit verbreitete Protokolle wurden erdacht, als es diese Art von Paketfilterung noch gar nicht gab. Heute hat sich herausgestellt, daß das eine oder andere Protokoll Schwierigkeiten beim Einsatz von Firewalls oder Paketfiltern macht. Eines der bekanntesten Problemkinder ist das unausrottbare Datei-Transfer-Protokoll FTP (File Transfer Protocol). FTP benutzt zwei separate TCP-Verbindungen, je eine für Steuerungsanweisungen und eine für die eigentlichen Daten. Von diesen Verbindungen hat nur eine einen fest zugewiesenen Port. Der Port für die Datenverbindung wird über die Steuerungsverbindung verhandelt, ist also prinzipiell nicht vorherzusehen, ohne die Steuerungsverbindung mitzulesen und das Gelesene zu verstehen. Eine Firewall, die IP-Datagramme basierend auf IP-Adressen und Port-Nummern filtert und Protokollebenen, die sich oberhalb von TCP und UDP befinden, nicht verarbeitet, kann FTP nicht sinnvoll filtern. Bei NFS gibt es ein ähnliches Problem. NFS benutzt für die Abwicklung von Datentransfer und Kommunikation das transport-unabhängige RPC- Protokoll. Auf der RPC-Schicht gibt es das Port-Konzept von TCP/IP nicht. Soll RPC in Verbindung mit UDP oder TCP als Transport benutzt werden, sucht sich der Server einen freien Port aus und registriert diesen beim sogenannten Portmapper. Der Client wendet sich an diesen Portmapper, um dann den Port für den entsprechend registrierten Dienst zu erfahren. Im Falle von NFS ist es aber noch etwas komplizierter: NFS selbst hat nämlich per 13

14 Konvention schon einen fest zugewiesenen Port 11. Nur reicht das nicht aus, um als Client mit einem NFSv3-Server zu kommunizieren: Alle NFS-Prozeduren basieren auf opaken Filehandles, d.h. ein Client kann keine Annahmen über das Filehandle irgendeines Objekts machen, auch dann nicht, wenn der vollständige Dateiname des Objekts bekannt ist. Nur der NFS-Server kann zu einem gegebenen Dateinamen das entsprechende Filehandles ermitteln. Auch Verzeichnisse werden wie Dateien nur über ihr Filehandle angesprochen. Wenn der Client also mit READDIR oder READ- DIRPLUS den Inhalt eines Verzeichnisses lesen will, um die Filehandles der enthaltenen Dateien und Verzeichnisse zu erfahren, muß er das Filehandle des Verzeichnisses angegeben werden und nicht etwa den Namen. Wenn der Client am Anfang einer NFS-Session noch kein einziges Filehandle kennt, gibt es ein Problem: Wie soll der Client ohne ein Filehandle das Wurzelverzeichnis lesen, um sich die weitere Filehandles zu beschaffen, die er zum Arbeiten braucht? Dieses Bootstrapping-Problem wurde bis einschließlich NFSv3 mit dem zusätzlichen Mount-Protokoll gelöst. Dieses Protokoll hat lediglich die Aufgabe, das initiale Filehandle für ein Wurzelverzeichnis 12 an den NFS-Client zu übermitteln. Nun hat aber gerade das Mount-Protokoll, das ebenso wie NFS auf RPC aufsetzt, keinen fest zugewiesenen Port und ist damit genauso Firewall-unfreundlich wie FTP. Bei NFSv4 wurde auf Sideband-Protokolle vollständig verzichtet. So wird das Bootstrapping hier mit Hilfe spezieller Filehandles vollzogen. NFSv4 hat neben den opaken eine Klasse spezieller Filehandles mit definierter Semantik: z.b. das Root-Filehandle ROOT FH oder das Public-Filehandle PUBLIC FH. Diese Technik hat sich schon bei der NFS-Variante WebNFS [4, 5] 13 bewährt. Der Client kann mit dem Root- Filehandle jederzeit das Wurzelverzeichnis lesen, ohne auch nur ein einziges opakes Filehandle zu kennen. So elegant, wie das Bootstrapping mit dem Root-Filehandle auch ist, diese Methode bringt nicht nur Vorteile mit sich. Das Mount-Protokoll konnte für einen Server mehrere unabhängige Verzeichnisbäume per NFS exportie- 11 einen sogenannten well known port, wird von der IANA zugewiesen 12 Bis NFSv3 muß das Wurzelverzeichnis des NFS-Mounts nicht unbedingt mit dem Wurzelverzeichnis des exportierten lokalen Dateisystems übereinstimmen. Es können auch beliebige Teilbäume per NFS gemountet werden. 13 WebNFS ist eine Erweiterung von NFSv2 und NFSv3, die von Sun als Ersatz für HTTP entwickelt wurde. 14

15 ren, die auf der Client-Seite an unterschiedlichen Stellen in den Verzeichnisbaum eingehängt werden konnten. Da es bei NFSv4 aber nur ein einziges Root-Filehandle gibt, kann der Server entsprechend nur noch einen Verzeichnisbaum exportieren. Soll ein Unix-Server z.b. die Verzeichnisse /homes und /usr/local exportieren, wurde bei NFSv3 jeweils das Mount-Protokoll bemüht, um die Filehandles für die beiden Verzeichnisse zum Client zu übertragen. Bei Verwendung von NFSv4 muß eine andere Lösung gefunden werden. Würde man das Root-Filehandle für /homes benutzen, kann man es nicht gleichzeitig auch für /usr/local verwenden. Daher wird bei NFSv4 generell mit dem Root-Filehandle das tatsächliche Wurzelverzeichnis übertragen. Verzeichnisse, die nicht an die Clients exportiert werden sollen, werden serverseitig auf der NFS-Ebene ausgeblendet. Für den Client sieht es also so aus, als gäbe es nur die Verzeichnisse /homes und /usr, und in /usr wiederum nur local. Bei Implementierungen von NFSv4-Servern, deren Betriebssystem mehrere Verzeichnisbäume über Laufwerksbuchstaben oder Volume-Namen verwaltet, wird ein virtuelles Dateisystem aufgebaut, in dem alle Laufwerke und Volumes mit ihren Bezeichnern als Verzeichnisnamen zusammengefaßt sind. 4.2 Anforderungen an den Transport Wie schon beschrieben, setzt NFS nicht direkt auf TCP/IP auf, sondern benutzt den RPC-Mechanismus, wodurch NFS auf jedem Datendienst funktioniert, für den eine entsprechende Spezifikation implementiert ist. Neben der reinen RPC-Spezifikation muß auch festgelegt werden, wie NFS diese nutzen soll. Man könnte meinen, es sei egal, welcher Datendienst letztenendes benutzt wird, weil auf der RPC-Ebene von allen denkbaren Unterschieden abstrahiert wird. Das stimmt leider nicht ganz: Die überwiegende Menge an Dateitransfers im Internet wird über TCP (respektive FTP oder HTTP) abgewickelt. Das hat seinen Grund, denn TCP verfügt über sehr ausgefeilte Algorithmen, die dafür sorgen, daß jederzeit ein nahezu optimaler Datentransfer möglich ist. TCP muß nicht nur auf die typischen Übertragungsfehler 14 von IP Verlust oder Duplizierung von Paketen, Änderung der Reihenfolge reagieren, sondern mit der Anpassung einer Vielzahl von Parametern auf sich 14 Genaugenommen sind es keine Fehler, weil die Spezifikation von IP hier nichts verspricht, was nicht gehalten werden kann. Die Spezifikation erlaubt ausdrücklich diese Fehler. 15

16 ständig ändernde Größen wie Latenz, Netzwerkauslastung, Paketverlustrate, usw. antworten. Einer der einfachsten und gleichzeitig wichtigsten Algorithmen, die solche Anpassungen vornehmen ist Congestion Control. Congestion Control sorgt beim Sender dafür, daß nicht mehr Netzwerkverkehr erzeugt wird, als das schwächste Element in der Reihe bis zum Empänger zur Zeit noch bewältigen kann. Es ist für verbindungsorientierte Datentransfers im Internet ausgesprochen sinnvoll, diese z.t. relativ komplexen Algorithmen in die TCP-Schicht zu verlagern, und nicht etwa separat in jedes darauf aufbauende Protokoll, wie FTP oder HTTP. Der bei NFS verwendete RPC- Mechanismus ist nicht immer verbindungsorientiert. Die RPC-Schicht erbt die Eigenschaft, verbindungslos oder verbindungsorientiert zu sein, vom darunter liegenden Transport. Daher gibt es auf der RPC-Ebene auch keine Optimierungsalgorithmen wie bei TCP. Wird bei NFSv3 UDP als Transport benutzt, ist es nicht unwahrscheinlich, daß in keiner Protokollschicht Congestion Control stattfindet. Auf einem LAN ist das nicht allzu tragisch, wenn nicht gerade zwei verschiedene Ethernet-Geschwindigkeiten unglücklich aufeinandertreffen oder das Netz stets im Sättigungsbereich betrieben wird. Andererseits kann bei Datentransfers über das Internet auf Congestion Control nicht verzichtet werden. Daher verlangt die NFSv4-Spezifikation, daß Congestion Control auf der NFS-Schicht implementiert werden muß, wenn der Transport nicht selbst darüber verfügt. Es wird natürlich empfohlen, möglichst TCP für den Transport zu verwenden, weil in diesem Protokoll bereits ausgefeilte Algorithmen implementiert sind. Eine dauerhafte TCP- Verbindung ist vielen kurzlebigen unbedingt vorzuziehen, weil nur dann die Optimierungsalgorithmen von TCP greifen. 5 Interoperabilität und Portabilität Während sich NFSv3 noch stark an Unix orientierte, soll NFSv4 auch auf anderen Plattformen (Windows NT, MacOS, etc.) ohne größere Schwierigkeiten zu implementieren sein. Zu den Faktoren, die Einfluß auf die Interoperabilität und Portabilität von NFSv4 haben, zählen neben den hier aufgeführten auch Netzwerksicherheit und Internationalisierung (I18N), die wegen ihres Umfangs separat beschrieben werden. 16

17 5.1 Persistente und volatile Filehandles Wie schon erwähnt, spielen Filehandles bei NFS eine zentrale Rolle. Filehandles stellen für alle Objekte eines Filesystems jeweils eindeutige Identifikatoren dar. Sie werden als Integer repräsentiert. Filehandles sind gewöhnlich opak, d.h. clientseitig können und dürfen keine Vermutungen darüber angestellt werden, welches Filehandle zu welchem Objekt gehört. Jedes Filehandle muß explizit beim Server erfragt werden. Serverseitig wird also die Operation, Filehandles und Filesystem-Objekte einander zuzuordnen, relativ häufig angewendet. Daher sollte diese Operation möglichst schnell und einfach durchzuführen sein. Bei unixbasierten NFS-Servern wird daher fast immer auf die Inode-Nummern und ggf. Device-IDs der lokalen Filesysteme zurückgegriffen. Diese sind bereits eindeutig und es kann schnell darauf zugegriffen werden. Allerdings kann es durchaus möglich sein, daß bei bestimmten Dateisystemen insbesondere bei anderen Betriebssystemen als Unix keine so bequeme Möglichkeit besteht, jedem Objekt im Dateisystem ein eindeutiges Filehandle zuzuordnen. Für diese Fälle hält die Spezifikation von NFSv4 sogenannte volatile Filehandles bereit. Normalerweise sind Filehandles persistent, d.h. sie ändern sich auch über mehrere NFS-Sessions oder Reboot-Zyklen des NFS- Servers hinweg nicht. Der Client kann sicher sein, daß eine Datei, die einem bestimmten Filehandle zugeordnet ist, auch weiterhin mit diesem Filehandle angesprochen werden kann. Was aber passiert, wenn der NFS-Server nicht nur rebootet wird, sondern auch das Dateisystem, das er exportiert, aus einem Backup zurückgespielt werden muß? Hierbei können sich, je nach Backup- Verfahren, die Inode-Nummern, und damit die NFS-Filehandles, durchaus ändern. Bis NFSv3 konnten die Clients dann oft nur nach einem Reboot oder zumindest einem Remount wieder arbeiten. NFSv4-Clients dagegen müssen explizit auch mit volatilen Filehandles zurechtkommen, d.h. er muß sich ggf. ein neues Filehandle beschaffen, wenn das entsprechende alte ungültig wird. 5.2 Erweiterte Attribute Verschiedene Betriebssysteme unterstützen oft auch unterschiedliche Dateiattribute. So werden unter Windows NT zum Beispiel ACLs (Access Control Lists) anstelle von POSIX-üblichen Benutzer-, Gruppen- und Welt-Rechten verwendet. Der eine Mechanismus ist auch nicht verlustfrei auf den anderen 17

18 abbildbar, wobei ACLs den eindeutig flexibleren Ansatz darstellen. Wenn verschiedene Sätze von Dateiattributen schon nicht kompatibel zueinander sind, sollten sie wenigstens vollständig per NFS übertragen werden können. Während NFSv3 in bezug auf Dateiattribute noch gerade die minimalen POSIX-Anforderungen erfüllte, legt sich NFSv4 gar nicht erst auf einen vorbestimmten Satz von Attributen fest. An eine NFSv4-Implementierung wird lediglich eine Minimalanforderung in Form von wenigen elementaren Attributen (wie z.b. Zeitstempel) gestellt. Weitere Attribute, wie ACLs oder in POSIX oder im Win32-API beschriebene, werden lediglich empfohlen. Das liegt unter anderem daran, daß in vielen Situationen, in denen ein per NFS exportiertes Dateisystem über den Bereich einer administrativen Domain hinausgeht, einigen Attributen keine sinnvolle Semantik mehr zugeordnet werden kann (z.b. UID und GID). In die Kategorie der von der NFSv4-Spezifikation empfohlenen Attribute fallen auch Disk-Quota und Migration Disk-Quota Während Disk-Quota auf lokalen Dateisystemen bereits ein etabliertes Mittel zur administrativen Begrenzung des Massenspeicherverbrauchs pro Benutzer ist, kann es zu Problemen kommen, wenn ein Benutzer per NFS auf ein Dateisystem zugreift und sein Quota nahezu ausgeschöpft ist, weil der Quota- Status bis einschließlich Version 3 nicht per NFS übertragen werden kann. Erst wenn eine Schreibanforderung wegen einer Quotaüberschreitung nicht mehr ausgeführt werden kann, bemerkt das Betriebssystem des Clients das Problem. Die NFSv4-Spezifikation empfiehlt daher die Implementierung des Quota-Attributs Migration Das Migrations-Attribut soll es ermöglichen, sog. Hochverfügbarkeitslösungen zu entwickeln, ohne daß in die NFS-Clients irgendwelche speziellen Mechanismen integriert werden müssen. Mit Hilfe des Migrations-Attributs kann der Client sich automatisch an einen Backup-Server wenden, falls der eigentliche NFS-Server nicht zur Verfügung steht. Auch generelle Umzüge von Dateisystemen auf einen neuen Fileserver sind auf diese Weise ohne Ausfallzeiten 18

19 durchführbar Groß-/Kleinschreibung Nicht jedes lokale Dateisystem kann bei Pfadnamen zwischen Groß- und Kleinschreibung unterscheiden. Daher empfiehlt die NFSv4-Spezifikation die Attribute case insensitive und case preserving, um dem Client zu vermitteln, welche Fähigkeiten das Server-Filesystem in bezug auf Groß- /Kleinschreibung hat Attribut-Verzeichnisse Bis NFSv3 war es nicht möglich, ohne Erweiterung der Spezifikation neue Dateiattribute einzuführen. NFSv4 stellt universelle Attribut-Verzeichnisse zur Verfügung, die beliebige selbst definierbare Attribute aufnehmen. Wenn ein Hersteller für ein auf NFSv4 basierendes Produkt auf bestimmte Datei-Attribute angewiesen ist, kann er auf eine existierende NFSv4- Implementierungen zurückgreifen und muß lediglich das Generieren und Behandeln der neuen Attribute neu implementieren. 6 Sicherheit Sowohl bei NFS bis Version 3 als auch bei NFSv4 sind die Sicherheitsfunktionen, die eine unbefugte Nutzung von NFS-Diensten unterbinden sollen, nicht direkt Bestandteil von NFS. Sie werden vielmehr von der darunterliegenden RPC-Schicht zur Verfügung gestellt. 6.1 RPC-Authentication-Flavors RPC stellt verschiedene Authentication-Flavors zur Verfügung: AUTH NONE, AUTH SYS, AUTH DH, AUTH KERB und ein neues Flavor, auf das später genauer eingegangen wird. Die ersten vier Flavors beschränken sich lediglich auf eine der drei heute üblichen Sicherheitsfunktionen: Authentisierung. Datenintegrität und Verschlüsselung können damit nicht realisiert werden. 19

20 AUTH NONE authentisiert, wie der Name schon sagt, überhaupt nicht. Bei NFS wird AUTH NONE nur für die NULL-Prozedur verwendet. Dieser RPC wird vom Server lediglich bestätigt, löst aber keine Aktion aus. Mit der NULL-Prozedur kann der Client feststellen, ob der Server (noch) erreichbar ist. AUTH SYS verwendet zur Authentisierung die unter Unix üblichen Userund Group-IDs. Der NFS-Server hat allerdings keine Möglichkeit, die Angaben des Clients zu überprüfen und muß dem Client vertrauen. Von einer rudimentären Authentisierung kann also nur ausgegangen werden, wenn Server und Client derselben administrativen Kontrolle unterliegen und der Server nur NFS-Anfragen von sicheren Ports akzeptiert. All dies ist stark an Unix orientiert, und bereitet bei Implementierungen auf anderen Betriebssystemen Schwierigkeiten. AUTH DH war der Versuch, einen Authentication-Flavor zu schaffen, der nicht auf blindem Vertrauen basiert. Mit dem Diffie-Hellman-Verfahren einigen sich Server und Client auf einen gemeinsamen Schlüssel (Conversation Key), ohne den Schlüssel selbst auf dem Netzwerkmedium übertragen zu müssen. Der NFS-Client schickt mit jedem RPC die aktuelle Uhrzeit, die mit diesem Schlüssel verschlüsselt wurde, zum Server. Der Server entschlüsselt die Uhrzeit wieder und akzeptiert den RPC, wenn die Uhrzeit ungefähr mit der Systemzeit übereinstimmt. Leider wurde ein Parameter von AUTH DH zu klein dimensioniert, und so hat sich später herausgestellt, daß die von AUTH DH gebotene Sicherheit völlig unzureichend ist [9]. AUTH KERB benutzt Tickets von Kerberos 4 zur Authentisierung. Auch, wenn sich AUTH KERB sehr viel besser bewährt hat als AUTH DH, gilt Kerberos 4 heute als überholt und wurde durch Kerberos 5 abgelöst. 6.2 RPCSEC GSS Aus dieser Bedarfslage heraus boten die bisherigen Authentication-Flavors doch lediglich eine eher fragliche Authentisierung, wurde ein neuer Authentication-Flavor entwickelt: RPCSEC GSS. Da RPCSEC GSS neben Authentisierung auch Datenintegrität und Verschüsselung bietet, wur- 20