NetApp Tech OnTap

Was ist neu in Version 4 von NFS?

Seit seiner Einführung 1984 ist das Network File System (NFS) ein Standard für Network File Sharing, speziell in UNIX- und Linux-Kreisen. Im Laufe der letzten 20 Jahre hat sich das NFS-Protokoll allmählich weiterentwickelt, um sich an neue Anforderungen und an Veränderungen des Marktes anzupassen.

Den größten Teil dieser Zeit hat NetApp an der Weiterentwicklung von NFS gearbeitet, um es an die neuen Anforderungen seitens der Benutzer anzupassen. Brian Pawlowski, CTO von NetApp, hat an den Spezifikation von NFS Version 3 (die heute allgemein genutzte Version) mitgearbeitet und ist Vorsitzender der NFSv4-Arbeitsgruppe (NFS Version 4). Mike Eisler und Dave Nioveck von NetApp sind Koautoren der NFS-Spezifikation Version 4 (der neuesten verfügbaren Version von NFS) und Herausgeber der NFS Version 4.1 Spezifikation, die sich derzeit in der Entwicklung befindet.

 
NFSv3
NFSv4
Personality Stateless Stateful
Semantik Nur UNIX Suport UNIX und Windows
Authentikation Schwach(AUTH_SYS) Stark (Kerberos)
Identifikation 32 bit UID/GID String-basiert (xyz@netapp.com)
Zugriffserlaubnis UNIX-basiert Wie bei Windows
Transport UDP & TCP TCP
Caching Ad-hoc Delegations

Abbildung 1: Vergleich von NFSv3 und NFSv4

NFS besteht aus Server Software – beispielsweise der Software, die auf NetApp Storage läuft – und Client Software, die auf Hosts läuft, die Zugriff auf Netzwerkspeicher benötigen. Für gute Performance und ordnungsgemäße Funktion müssen beide Seiten der Verbindung – Client und Server – korrekt implementiert sein. Obwohl NFS Version 4 von NetApp seit DataONTAP 6.4 ausgeliefert wird, wurden eine Menge Änderungen an unserer Codebasis vorgenommen. Sie ist nun ausgereifter, so dass NFSv4 den Punkt erreicht hat, dass es unserer Meinung nach für den produktiven Einsatz tauglich ist.

Clientseitige Implementierungen laufen heute immer stabiler. NetApp hat bedeutende Änderungen und Verbesserungen an Data ONTAP 7.3 vorgenommen, um NFSv4 zu unterstützen. In diesem Artikel werde ich drei wichtige Funktionen von NFSv4 besprechen, die viel Beachtung gefunden haben:

  • Access-Control-Listen (ACLs) für Sicherheit und Windows-Kompatibilität
  • Notwendige Sicherheit mit Kerberos
  • Delegations für clientseitiges Caching
Diese Diskussion wird zu großen Teilen für jede NFSv4 Implementierung relevant sein. Ich werde jedoch einige Details beschreiben, die es nur bei NetApp gibt, und werde an den entsprechenden Stellen Best Practices diskutieren.

  AIX Client Server BSD/OSX Client Server (von Apple nicht unterstützt) EMC Server Humingbird Client Linux Client Server
(RHEL5)
NetApp Server Solaris 10 client Server
Delegationen Ja   Ja   Ja Ja Ja
Access-Control-Listen Ja   Ja   Ja Ja Ja
Kerberos V5 Ja Ja Ja Ja Ja Ja Ja
File-Ströme           Ja Ja
I18n Ja Ja   Ja Ja Ja Ja
Global Namespace/Referrals Ja       Ja künftig  

Abbildung 2: Status der NFSv4 Implementierung bei Client und Server

Access-Control-Listen (ACLs)
ACLs sind eine der am häufigsten von NetApp Kunden nachgefragten Funktionen, die eine höhere Kompatibilität für Windows Clients wünschen. Die ACLs von NFSv4 verbessern deutlich die Sicherheit von NFS und dessen Interoperabilität mit CIFS.

ACLs ermöglichen die Vergabe oder die Verweigerung von Zugriffsberechtigungen auf Benutzerebene für jedes Dateiobjekt, was eine viel feinere Zugriffskontrolle und mehr Selektivität gewährleistet als herkömmliche Berechtigungsbits nach Art von UNIX. ACLs von NFSv4 basieren auf dem NT-Modell, doch enthalten sie keine Besitzer-/Gruppeninformationen. ACLs von NFSv4 bestehen aus einer Reihe von Zugriffskontrolleinträgen (ACEs), die Informationen über Zugriff erlaubt/abgelehnt, Berechtigungsbits, Benutzername/Gruppenname und Flags enthalten.

Da NetApp bereits ACL-Unterstützung für CIFS-Clients bietet, bringt die Ergänzung von ACLs in NFSv4 einige spezielle Erwägungen mit sich. NetApp stellt drei Typen von qTrees (Unix, NTFS und gemischt) für die Nutzung mit verschiedenen Clients bereit. Die Art, in der mit NFSv4 ACLs umgegangen wird, hängt von der Art des qTree ab:

UNIX qTree

 

  • NFSv4 ACLs und Mode-Bits aktiv
  • Windows-Clients können keine Attribute setzen
  • UNIX-Semantik gewinnt

NTFS qTree

  • NT ACLs und Mode-Bits aktiv; Unix-Clients können keine Attribute setzen
  • NFSv4 ACLs werden aus den Mode-Bits für NFS-Clients, die mit einer NT ACL auf Dateien zugreifen, erzeugt
  • NT-Semantik gewinnt

Gemischter qTree

  • NFSv4 ACLs, NT ACLs und Mode-Bits aktiv
  • Windows- und UNIX-Clients können Attribute setzen
  • NFSv4 ACL wird aus den Mode-Bits für Dateien mit NT ACLs erzeugt

Selbstverständlich müssen Sie die Art von qTree, die Sie verwenden, sorgfältig auswählen, um die gewünschten Ergebnisse zu erzielen:

  • Nur NFS-Zugriff: UNIX-qTree
  • Gemischter Zugriff: Gemischter qTree
  • Überwiegend CIFS-Zugriff: NTFS qTree
  • Nur CIFS: NTFS qTree

Die einzige zusätzliche Best Practice hinsichtlich ACLs ist, niemals mehr als 192 ACEs pro ACL zu verwenden. Man kann die Anzahl der ACEs pro ACL bis auf derzeit maximal 400 erhöhen. Tut man dies jedoch, kann es zu Problemen kommen, sollte man auf eine frühere Version von Data ONTAP zurückgehen müssen oder sollte über SnapMirror auf eine frühere Version zugegriffen werden.

Notwendige Sicherheit

Zusätzlich zur Integration von ACLs verbessert NFSv4 auch die Sicherheit von früheren NFS Versionen durch:

  • Anforderung der Verfügbarkeit von starker RPC-Sicherheit, die auf Verschlüsselung beruht
  • Aushandlung der Art von Sicherheit, die zwischen Server und Client verwendet wird, über ein In-Band-System
  • Verwendung von Zeichenfolgen statt Ganzzahlen, um Benutzer- und Gruppen-IDs darzustellen

Die Sicherheit von NFS wurde gestärkt, indem Sicherheit auf der Basis des Generic Security Services API (GSS-API), RPCSEC_GSS [RFC2203] genannt, hinzugefügt wurde. Alle Versionen von NFS können RPCSEC_GSS nutzen. Jedoch muss eine konforme NFS Version 4 Implementierung RPCSEC_GSS implementieren. RPCSEC_GSS wird analog der allgemein genutzten AUTH_SYS-Sicherheit, die die Standardmethode in früheren NFS Versionen war, zugewiesen.

RPCSEC_GSS unterscheidet sich auf zweierlei Weise von AUTH_SYS und anderen herkömmlichen NFS Sicherheitsmechanismen:

  • RPCSEC_GSS leistet mehr als Authentifizierung. Es kann Integritäts-Prüfsummen und Verschlüsselung für den gesamten Body von RPC-Request und -Response durchführen. So bietet RPCSEC_GSS Sicherheit über die bloße Authentifizierung hinaus.
  • Da RPCSEC_GSS einfach die GSS API Messaging Tokens einkapselt – es fungiert bloß als Vehikel für mechanismusspezifische Tokens für Sicherheitssysteme wie Kerberos –, macht das Hinzufügen von neuen Sicherheitsmechanismen (solange sie mit dem GSS API konform sind) nicht das Neuschreiben großer Teile von NFS erforderlich.

NFS AUTH System















Abbildung 3: NFS mit AUTH_SYS im Vergleich zu RPCSEC-GSS-Sicherheit.

Sowohl NFSv3 wie auch NFSv4 können RPCSEC-GSS nutzen. Jedoch ist AUTH_SYS der Standard für NFSv3. Der einzige Sicherheitsmechanismus, den NetApp oder die meisten NFSv4 Clients derzeit unter RPCSEC_GSS bereitstellen, ist Kerberos 5. Kerberos ist ein Authentifizierungsmechanismus, der Verschlüsselung mit symmetrischen Schlüsseln einsetzt. Er verschickt niemals Passwörter über das Netzwerk, weder im Klartext noch in verschlüsselter Form, und verwendet verschlüsselte Tickets und Sitzungsschlüssel, um Benutzer zu authentifizieren, bevor sie auf Netzwerkressourcen zugreifen können. Das Kerberos-System arbeitet mit Schlüsselverteilungszentren (KDCs), die eine zentralisierte Datenbank für Benutzernamen und Passwörter enthalten. NetApp unterstützt zwei Arten von KDCs: UNIX und Windows Active Directory.

Man hat aber dennoch die Möglichkeit, die schwache Authentifizierungsmethode früherer NFS Versionen (AUTH_SYS) zu verwenden, sollte dies nötig werden. Man erzielt dies, indem man sec=sys auf der exportfs-Befehlszeile oder in der Datei /etc/exports angibt. Data ONTAP unterstützt nur maximal 16 ergänzende Gruppen-IDs in einem Credential plus primäre Gruppen-ID, wenn AUTH_SYS verwendet wird. Mit Kerberos werden maximal 32 zusätzliche Gruppen-IDs unterstützt.

Delegations für clientseitiges Caching

Bei NFSv3 funktionieren Clients normalerweise so, als ob es einen Streit um die Dateien gäbe, die sie offen halten (auch wenn dies häufig nicht der Fall ist). Schwache Cache-Konsistenz wird durch häufige Anfragen vom Client an den Server aufrechterhalten, um herauszufinden, ob eine offene Datei durch jemand anderen verändert wurde, was unnötigen Netzwerkverkehr und Verzögerungen in Umgebungen mit hoher Latenz verursachen kann. In Situationen, in denen ein Client eine Datei sperrt, müssen sämtliche I/Os synchron sein, was die clientseitige Performance in zahlreichen Situationen zusätzlich beeinträchtigt.

NFSv4 unterscheidet sich von früheren NFS Versionen dadurch, dass es einem Server erlaubt, spezifische Dateioperationen an einen Client zu delegieren, um aggressiveres Caching von Daten beim Client zu ermöglichen und Caching des Sperrstatus zu erlauben. Ein Server überlässt einem Client die Kontrolle von Datei-Aktualisierungen und des Sperrstatus mittels Delegation. Dies reduziert Latenz, indem der Client verschiedene Operationen und das Daten-Caching lokal durchführen darf. Derzeit gibt es zwei Arten von Delegations: Der Server kann eine Delegation von einem Client zurückrufen, falls es Streit um eine Datei gibt.

Hält ein Client eine Delegation, kann er Operationen an Dateien ausführen, deren Daten lokal zwischengespeichert wurden, um Netzwerklatenz zu vermeiden und I/O zu optimieren. Das aggressivere Caching, das aus Delegations resultiert, kann eine große Hilfe in Umgebungen mit den folgenden Merkmalen sein:

  • häufiges Öffnen und Schließen
  • häufige GETATTRs
  • Sperren von Dateien
  • Dateizugriff im Ready-Only-Modus
  • hohe Latenz
  • schnelle Clients
  • stark beanspruchter Server mit vielen Clients

Data ONTAP unterstützt Delegations sowohl im Lese- wie im Schreib-Modus, und man kann den NFSv4 Server separat so einstellen, dass eine oder beide Arten von Delegations aktiviert oder deaktiviert sind. Wenn Delegations eingeschaltet sind, vergibt Data ONTAP automatisch eine Lese-Delegation an einen Client, der eine Datei im Lesezugriff öffnet, oder eine Schreib-Delegation an einen Client, der eine Datei im Schreibzugriff öffnet.

Die Optionen zum Aktivieren oder Deaktivieren von Lese- und Schreib-Delegations wurden bereitgestellt, um einem eine gewisse Kontrolle über die Auswirkung von Delegations zu geben. Idealerweise bestimmt der Server, ob er Clients eine Delegation gibt oder nicht. Das Einschalten von Lese-Delegation in einer Umgebung mit hoher Intensität an Lesezugriffen wird vorteilhaft sein. Schreib-Delegations in Entwicklungsumgebungen, in denen jeder Benutzer in separate Build-Files schreibt, ohne dass es Streit um die Datei gibt, wird ebenfalls die Performance verbessern. Jedoch nützen Schreib-Delegations in Szenarien möglicherweise nicht, in denen mehrere Benutzer in dieselbe Datei schreiben.

Lesen Sie mehr dazu

Falls Sie sich Sorgen um die Datensicherheit machen (und wer tut das nicht?): Die neuen NFSv4 Funktionen wie die ACL-Unterstützung und unerlässliche Sicherheit können das Risiko unbefugten Datenzugriffs deutlich reduzieren. Ein weiteres wichtiges Designziel bei NFSv4 war verbesserte Performance im Internet. Verbessertes Caching-Verhalten von Clients durch Delegations sollte dabei helfen, dieses Ziel zu erreichen.

Zusätzlich zu den offenkundigen Neuerungen, die ich beschrieben habe, enthält NFSv4 eine Reihe weiterer wichtiger Änderungen, wie zum Beispiel:

  • Beseitigung des unabhängigen Mount-Daemon und anderer Zugriffsdienste, die zusätzliche offene Ports erfordern
  • Zusammengesetzte Anfragen, die Routineaufgaben in einer einzigen Operation zusammenfassen, um die Antwort zu beschleunigen und den Netzwerkverkehr zu reduzieren

Wenn Sie mehr über diese und andere Funktionen von NFSv4 erfahren möchten, ist TR-3085 eine gute Quelle.

author

Bikash R. Choudhury
Solutions Architect
NetApp

Bikash fing vor acht Jahren bei NetApp als Technical Support Engineer an und wurde später Technical Global Advisor (TGA) für einen der größten Kunden von NetApp. Als TGA kümmerte er sich gleichermaßen um den Aufbau guter Beziehungen zu den Kunden wie um technische Lösungen. In seiner derzeitigen Funktion als NFS/Technical Application Solutions Architect beschäftigt sich Bikash mit der Konzeption von Architekturen für technische Applikationslösungen, die NFS nutzen, der Durchführung von Funktionstests und Zertifizierungen und der Bereitstellung von Support für NFS Best Practices für den Bereich Global Partner Alliance.

Kommentar
Explore