pNFS in ONTAP funktioniert sowohl mit FlexVol Volumes als auch mit FlexGroup Volumes, aber für die besten Gesamtergebnisse sind FlexGroup Volumes zu bevorzugen.

FlexGroup Volumes bieten:

"Informationen zum Management von FlexGroup Volumes"

Nicht alle NFS-Clients unterstützen pNFS, aber die meisten modernen Clients tun dies. RHEL 6.4 und Fedora 17 waren die ersten unterstützten pNFS-Clients (etwa 2014), daher ist es naheliegend anzunehmen, dass in den letzten Jahren veröffentlichte Clientversionen die Funktion vollständig unterstützen. ONTAPs NFS-Unterstützungsansatz lautet: „Wenn der Client die Funktion unterstützt und RFC-konform ist und wir die Funktion unterstützen, dann wird die Kombination unterstützt.“ Es gilt jedoch als Best Practice, sicherzustellen, dass pNFS vom Client-OS-Anbieter unterstützt wird.

ONTAP ermöglicht das unterbrechungsfreie Verschieben von Volumes zwischen Knoten oder Aggregaten innerhalb desselben Clusters, um Flexibilität bei der Kapazitäts- und Leistungsbalance zu bieten. Wenn eine Volume-Verschiebung in ONTAP erfolgt, werden die pNFS-Gerätezuordnungen automatisch aktualisiert, um Clients bei Bedarf über die neue Volume-zu-Schnittstelle-Beziehung zu informieren.

"Informationen zum Verschieben eines Volumens"

ONTAP bietet die Möglichkeit, Netzwerkschnittstellen zwischen Knoten im selben Cluster zu verschieben, um eine ausgewogene Performance und Wartungsflexibilität zu gewährleisten. Wie bei Volume-Verschiebungen werden bei einer Migration einer Netzwerkschnittstelle in ONTAP die pNFS-Gerätezuordnungen automatisch aktualisiert, sodass Clients bei Bedarf die neue Volume-zu-Schnittstelle-Beziehung nutzen können.

Da NFSv4.1 jedoch ein zustandsbehaftetes Protokoll ist, kann eine Migration der Netzwerkschnittstelle zu Störungen bei Clients führen, die das NFS-Mount aktiv nutzen. Es gilt als Best Practice, Migrationen der Netzwerkschnittstelle in einem Wartungsfenster durchzuführen und Clients über mögliche Netzwerkunterbrechungen zu informieren.

pNFS berücksichtigt dieselben Aspekte des Storage-Failovers wie NFSv4.1. Diese werden ausführlich in "NetApp Technischer Bericht 4067: NFS Best Practices-Leitfaden und Implementierungsleitfaden" behandelt. Generell sollten alle Storage-Failover- und Giveback-Vorgänge mit pNFS in einem Wartungsfenster erfolgen, da aufgrund der Zustandsabhängigkeit des Protokolls mit potenziellen Storage-Unterbrechungen zu rechnen ist.

Metadatenoperationen sind klein und können je nach Arbeitslast in großer Anzahl auftreten (Erstellen Sie eine große Anzahl von Dateien? Führen Sie „find“-Befehle aus?) sowie in Bezug auf die Gesamtdateianzahl. Daher können Arbeitslasten mit vielen Metadatenaufrufen die CPU des NFS-Servers stark beanspruchen und potenziell zu einem Engpass über eine einzelne Verbindung führen. pNFS (und NFSv4.x im Allgemeinen) ist für leistungsabhängige Arbeitslasten mit hohem Metadatenaufkommen nicht geeignet, da die Zustandsverwaltung, die Sperrmechanismen und einige Sicherheitsfunktionen der Protokollversion die CPU-Auslastung und Latenz negativ beeinflussen können. Diese Arbeitslasttypen (wie viele GETATTR- oder SETATTR-Aufrufe) sind in der Regel mit NFSv3 besser bedient.

Der Metadatenserver in pNFS wird beim initialen Mounten eines NFS-Exports eingerichtet. Wenn der Mountpunkt festgelegt ist, bleibt er bestehen, bis er erneut gemountet oder die Datenschnittstelle verschoben wird. Aus diesem Grund gilt es als Best Practice, sicherzustellen, dass mehrere Clients, die auf dasselbe Volume zugreifen, dieses auf unterschiedlichen Knoten und Datenschnittstellen innerhalb der SVM mounten. Dieser Ansatz sorgt für eine Lastverteilung der Metadatenserver auf die Knoten und CPU-Ressourcen und maximiert gleichzeitig die Nutzung der Netzwerkschnittstellen im Cluster. Eine Möglichkeit, dies zu erreichen, ist die Einrichtung eines Round-Robin-DNS-Setups, das in "NetApp Technischer Bericht 4523: DNS-Lastverteilung in ONTAP" behandelt wird.

NFSv4.x bietet Sicherheitsfunktionen auf vielfältige Weise (ausführlich beschrieben in "NetApp Technischer Bericht 4067: NFS Best Practices-Leitfaden und Implementierungsleitfaden"). NFSv4.x ID-Domänen sind eine dieser Möglichkeiten, wobei sich Client und Server auf die ID-Domänen einigen müssen, wenn Benutzer und Gruppen in einem NFS-Export authentifiziert werden sollen. Eine der Nebenwirkungen einer nicht übereinstimmenden ID-Domäne besteht darin, dass der Benutzer oder die Gruppe als anonymisierter Benutzer (im Wesentlichen unterdrückt) angezeigt wird, um unerwünschten Zugriff zu verhindern. Bei NFSv4.x (und auch pNFS) gilt als Best Practice, dass die NFSv4.x ID-Domänen auf Client und Server übereinstimmen.

Wie bereits erwähnt, kann nconnect in ONTAP die Leistung bei bestimmten Workloads verbessern. Bei pNFS ist es wichtig zu verstehen, dass nconnect zwar die Leistung durch eine deutliche Erhöhung der Gesamtzahl der TCP-Verbindungen zum Speichersystem steigern kann, aber auch Probleme verursachen kann, wenn viele Clients die Mount-Option nutzen und dadurch die TCP-Verbindungen auf dem Speicher überlasten. Das NetApp Hardware Universe enthält die TCP-Verbindungslimits pro Knoten.

Wenn die TCP-Verbindungsgrenzen eines Knotens überschritten werden, sind keine neuen TCP-Verbindungen zulässig, bis bestehende Verbindungen freigegeben werden. Dies kann in Umgebungen, die Mount-Stürme erleben könnten, zu Komplikationen führen.

Die folgende Tabelle zeigt, wie pNFS mit nconnect die TCP-Verbindungsgrenzen überschreiten könnte:

¹ Überschreitet die meisten ONTAP TCP-Verbindungsgrenzen für einzelne Knoten

Session trunking in ONTAP kann zur Erhöhung des Durchsatzes und der Pfad-Resilienz bei NFSv4.x-Mounts verwendet werden. In Verbindung mit pNFS kann jeder Node in einem Cluster einen Session trunk einrichten. Session trunks erfordern jedoch mindestens zwei Schnittstellen pro Node, und pNFS erfordert mindestens eine Schnittstelle pro Node, damit es wie vorgesehen funktioniert. Zusätzlich müssen alle Schnittstellen in der SVM zu den NFS-Clients routbar sein. Session trunking und pNFS funktionieren nicht ordnungsgemäß, wenn gleichzeitig nconnect genutzt wird. nconnect und Session trunking sind als sich gegenseitig ausschließende Funktionen zu betrachten.

"Informationen zu NFS Trunking"

pNFS benötigt auf jedem Knoten eines Clusters eine routingfähige Netzwerkschnittstelle, damit die Funktion ordnungsgemäß gewährleistet ist. Wenn im selben SVM wie der NFS-Server, der pNFS bereitstellt, weitere Netzwerkschnittstellen existieren, die für NFS-Clients nicht routingfähig sind, werden diese Schnittstellen von ONTAP dennoch in der Gerätezuordnung für Clients angekündigt. Wenn der NFS-Client versucht, über Schnittstellen in einem anderen Subnetz auf Daten zuzugreifen, kann keine Verbindung hergestellt werden, was zu einem Ausfall führt. Es gilt als Best Practice, in einem SVM bei der Verwendung von pNFS nur solche Netzwerkschnittstellen zuzulassen, die von Clients erreicht werden können.

NFSv4.0 kann auf einem ONTAP NFS Server neben NFSv4.1 aktiviert werden. Allerdings funktioniert pNFS nicht über NFSv4.0. Wenn NFSv4.0 auf dem NFS Server aktiviert ist, können Clients möglicherweise unbeabsichtigt diese Protokollversion einbinden und pNFS nicht nutzen. Daher gilt es als Best Practice, NFSv4.0 bei Verwendung von pNFS explizit zu deaktivieren. NFSv4.1 muss weiterhin aktiviert sein und kann unabhängig von NFSv4.0 funktionieren.

NFSv4.1-Referrals lokalisieren den Mount-Pfad vom Client zur Netzwerkschnittstelle des Knotens, dem das Volume gehört. pNFS lokalisiert den Datenpfad, und der Mount-Pfad wird zu einem Metadatenserver.

Obwohl die beiden Funktionen grundsätzlich zusammen verwendet werden können, kann die Verwendung von NFSv4.1-Verweisen mit pNFS den unerwünschten Effekt haben, dass mehrere Metadatenserver auf demselben Knoten gestapelt werden und die Möglichkeit, Metadatenserver auf mehrere Clusterknoten zu verteilen, eingeschränkt wird. Wenn die Metadatenserver bei der Verwendung von pNFS nicht gleichmäßig über einen Cluster verteilt sind, kann die CPU eines einzelnen Knotens durch Metadatenanfragen überlastet werden und einen Performance-Engpass verursachen.

Daher empfiehlt es sich, bei der Verwendung von pNFS auf NFSv4.1-Verweise zu verzichten. Stattdessen sollten die Mountpunkte auf mehrere Netzwerkschnittstellen und Knoten im Cluster verteilt werden.

"Informationen zum Aktivieren oder Deaktivieren von NFSv4-Verweisen"

Mit NFS Kerberos ist es möglich, die Authentifizierung mit krb5 zu verschlüsseln und Datenpakete zusätzlich mit krb5i und krb5p zu verschlüsseln. Dies wird pro Netzwerkschnittstelle in einer SVM aktiviert und ist ausführlich in "NetApp Technical Report 4616: NFS Kerberos in ONTAP mit Microsoft Active Directory" beschrieben.

Da pNFS den Datenverkehr über Knoten und Netzwerkschnittstellen in der SVM umleiten kann, muss NFS Kerberos auf jeder Netzwerkschnittstelle in der SVM aktiviert und funktionsfähig sein. Wenn eine Netzwerkschnittstelle in der SVM nicht für Kerberos aktiviert ist, kann pNFS beim Versuch, auf Datenvolumes auf diesen Schnittstellen zuzugreifen, nicht ordnungsgemäß funktionieren.

Beispielsweise zeigte ein Lesetest mit parallelem dd auf einer pNFS-fähigen SVM mit zwei Netzwerkschnittstellen (nur eine davon für Kerberos aktiviert), dass die auf der Kerberos-aktivierten Schnittstelle befindlichen Dateien eine gute Leistung erbrachten, während die Dateien auf dem Knoten mit der Schnittstelle ohne aktiviertes Kerberos ihre Lesevorgänge nie abschließen konnten. Als Kerberos auf beiden Schnittstellen aktiviert war, konnten alle Dateien wie erwartet verarbeitet werden.

NFS Kerberos kann mit pNFS verwendet werden, sofern NFS Kerberos auf allen Netzwerkschnittstellen in der SVM aktiviert ist. Dabei ist zu beachten, dass NFS Kerberos aufgrund der Verschlüsselung und Entschlüsselung der Pakete zu Leistungseinbußen führen kann, weshalb es als bewährte Praxis gilt, pNFS mit NFS Kerberos gründlich mit den eigenen Workloads zu testen, um sicherzustellen, dass etwaige Leistungseinbußen die Workload nicht übermäßig beeinträchtigen.

Nachfolgend ein Beispiel für die Leistung beim parallelen Lesen mit krb5 (Authentifizierung) und krb5p (Ende-zu-Ende-Verschlüsselung) mit pNFS auf einem RHEL 9.5 Client. Krb5p verzeichnete in diesem Test einen Leistungsabfall von 70 %.

"Informationen zu Kerberos mit NFS für hohe Sicherheit"

NFSv4.2 wurde in ONTAP 9.8 eingeführt und ist die aktuellste verfügbare NFSv4.x-Version (RFC-7862). NFSv4.2 bietet keine explizite Option zum Aktivieren/Deaktivieren. Stattdessen wird es zusammen mit NFSv4.1 aktiviert/deaktiviert (-4.1 enabled. Unterstützt ein Client NFSv4.2, wird beim Mount-Befehl die höchste unterstützte NFS-Version ausgehandelt, sofern nicht anders mit der minorversion=2 Mount-Option angegeben.

NFSv4.2 in ONTAP unterstützt die folgende Funktionalität:

pNFS wurde mit NFSv4.1 eingeführt, wird aber auch mit NFSv4.2 sowie den dazugehörigen Funktionen unterstützt.

"Informationen zur ONTAP Unterstützung für NFSv4.2"