Informationen zur pNFS-Architektur in ONTAP
Änderungen vorschlagen
PDFs
Die pNFS Architektur besteht aus drei Hauptkomponenten: einem NFS-Client, der pNFS unterstützt, einem Metadatenserver, der einen dedizierten Pfad für Metadatenoperationen bereitstellt, und einem Datenserver, der lokalisierte Pfade zu Dateien bereitstellt.
Der Clientzugriff auf pNFS erfordert eine Netzwerkverbindung zu den auf dem NFS-Server verfügbaren Daten- und Metadatenpfaden. Wenn der NFS-Server Netzwerkschnittstellen enthält, die für die Clients nicht erreichbar sind, kann der Server dem Client Datenpfade mitteilen, die nicht zugänglich sind, was zu Ausfällen führen kann.
Metadatenserver
Der Metadatenserver in pNFS wird eingerichtet, wenn ein Client eine Einbindung über NFSv4.1 oder höher initiiert, sofern pNFS auf dem NFS-Server aktiviert ist. Dabei wird der gesamte Metadatenverkehr über diese Verbindung gesendet und bleibt während der gesamten Einbindungsdauer auf dieser Verbindung, selbst wenn die Schnittstelle auf einen anderen Knoten migriert wird.
Die pNFS-Unterstützung wird während des Mount-Aufrufs, genauer gesagt in den EXCHANGE_ID-Aufrufen, ermittelt. Dies lässt sich in einer Paketaufzeichnung unterhalb der NFS-Operationen als Flag erkennen. Wenn die pNFS-Flags EXCHGID4_FLAG_USE_PNFS_DS und EXCHGID4_FLAG_USE_PNFS_MDS auf 1 gesetzt sind, ist die Schnittstelle für Daten- und Metadatenoperationen in pNFS geeignet.
Metadaten in NFS bestehen im Allgemeinen aus Datei- und Ordnerattributen wie Dateihandles, Berechtigungen, Zugriffs- und Änderungszeiten sowie Eigentümerinformationen. Metadaten können auch Erstellungs- und Löschvorgänge, Verknüpfungs- und Aufhebungsvorgänge sowie Umbenennungen umfassen.
In pNFS gibt es außerdem eine Teilmenge von Metadatenaufrufen, die spezifisch für die pNFS-Funktion sind und in "RFC 5661" ausführlicher behandelt werden. Diese Aufrufe werden verwendet, um pNFS-geeignete Geräte, Zuordnungen von Geräten zu Datensätzen und weitere erforderliche Informationen zu ermitteln. Die folgende Tabelle zeigt eine Liste dieser pNFS-spezifischen Metadatenoperationen.
| Betrieb | Beschreibung |
|---|---|
LAYOUTGET |
Ruft die Datenserver-Zuordnung vom Metadatenserver ab. |
LAYOUTCOMMIT |
Server übernehmen das Layout und aktualisieren die Metadatenzuordnungen. |
LAYOUTRETURN |
Gibt das Layout oder das neue Layout zurück, wenn die Daten geändert wurden. |
GETDEVICEINFO |
Der Client erhält aktualisierte Informationen von einem Datenserver im Speichercluster. |
GETDEVICELIST |
Der Client fordert die Liste aller Datenserver an, die am Storage-Cluster beteiligt sind. |
CB_LAYOUTRECALL |
Der Server ruft das Datenlayout vom Client ab, wenn Konflikte festgestellt werden. |
CB_RECALL_ANY |
Gibt alle Layouts an den Metadatenserver zurück. |
CB_NOTIFY_DEVICEID |
Meldet Änderungen der Geräte-ID. |
Datenpfadinformationen
Nachdem der Metadatenserver eingerichtet ist und die Datenverarbeitung beginnt, beginnt ONTAP, die für pNFS-Lese- und Schreibvorgänge geeigneten Geräte-IDs sowie die Gerätezuordnungen zu verfolgen, die die Volumes im Cluster den lokalen Netzwerkschnittstellen zuordnen. Dieser Vorgang tritt auf, wenn ein Lese- oder Schreibvorgang im Mountpunkt durchgeführt wird. Metadatenaufrufe wie GETATTR lösen diese Gerätezuordnungen nicht aus. Daher wird durch die Ausführung eines ls Befehls innerhalb des Mountpunkts die Zuordnung nicht aktualisiert.
Geräte und Zuordnungen sind mit der ONTAP CLI im erweiterten Berechtigungsmodus sichtbar, wie unten gezeigt.
::*> pnfs devices show -vserver DEMO (vserver nfs pnfs devices show) Vserver Name Mapping ID Volume MSID Mapping Status Generation --------------- --------------- --------------- --------------- ------------- DEMO 16 2157024470 available 1 ::*> pnfs devices mappings show -vserver SVM (vserver nfs pnfs devices mappings show) Vserver Name Mapping ID Dsid LIF IP -------------- --------------- --------------- -------------------- DEMO 16 2488 10.193.67.211
|
In diesen Befehlen sind die Volume-Namen nicht vorhanden. Stattdessen werden die numerischen IDs verwendet, die diesen Volumes zugeordnet sind: die MSID und die DSID. Um die Volumes zu finden, die den Zuordnungen zugeordnet sind, kann volume show -dsid [dsid_numeric] oder volume show -msid [msid_numeric] im erweiterten Berechtigungsmodus der ONTAP CLI verwendet werden.
|
Wenn ein Client versucht, eine Datei zu lesen oder zu schreiben, die sich auf einem Knoten befindet, der für die Verbindung zum Metadatenserver remote ist, handelt pNFS die geeigneten Zugriffspfade aus, um die Datenlokalität für diese Operationen sicherzustellen, und der Client wird zum angegebenen pNFS-Gerät umgeleitet, anstatt zu versuchen, das Clusternetzwerk zu durchqueren, um auf die Datei zuzugreifen. Dies hilft, die CPU-Überlastung und die Netzwerklatenz zu verringern.
pNFS Steuerpfad
Zusätzlich zu den Metadaten- und Datenanteilen von pNFS existiert auch ein pNFS Kontrollpfad. Der Kontrollpfad wird vom NFS-Server verwendet, um Dateisysteminformationen zu synchronisieren. In einem ONTAP Cluster repliziert das Backend-Cluster-Netzwerk regelmäßig, damit alle pNFS Geräte und Gerätezuordnungen synchron sind.
pNFS Device Population Workflow
Im Folgenden wird beschrieben, wie ein pNFS-Gerät in ONTAP eingebunden wird, nachdem ein Client eine Anfrage zum Lesen oder Schreiben einer Datei in einem Volume gestellt hat.
-
Der Client fordert einen Lese- oder Schreibvorgang an; ein OPEN wird ausgeführt und der Dateihandle abgerufen.
-
Sobald der OPEN-Vorgang ausgeführt wurde, sendet der Client den Dateihandle in einem LAYOUTGET-Aufruf über die Metadatenserververbindung an den Speicher.
-
LAYOUTGET gibt Informationen über das Layout der Datei wie die Status-ID, die Streifengröße, das Dateisegment und die Geräte-ID an den Client zurück.
-
Der Client nimmt dann die Geräte-ID und sendet einen GETDEVINFO-Aufruf an den Server, um die zugehörige IP-Adresse mit dem Gerät abzurufen.
-
Der Speicher sendet eine Antwort mit der Liste der zugehörigen IP-Adressen für lokalen Zugriff auf das Gerät.
-
Der Client setzt die NFS-Kommunikation über die lokale IP-Adresse fort, die vom Storage zurückgesendet wird.
Wechselwirkung von pNFS mit FlexGroup Volumes
FlexGroup Volumes in ONTAP präsentieren Speicher als FlexVol volume-Bestandteile, die sich über mehrere Knoten in einem Cluster erstrecken, was es einer Arbeitslast ermöglicht, mehrere Hardware-Ressourcen zu nutzen und dabei einen einzigen Mountpoint beizubehalten. Da mehrere Knoten mit mehreren Netzwerkschnittstellen mit der Arbeitslast interagieren, ist es ein natürliches Ergebnis, dass Remote-Datenverkehr das Backend-Clusternetzwerk in ONTAP durchquert.
Bei Verwendung von pNFS behält ONTAP die Datei- und Volume-Layouts des FlexGroup volume im Blick und ordnet sie den lokalen Datenschnittstellen im Cluster zu. Befindet sich beispielsweise ein Bestandteil-Volume, das eine zugegriffene Datei enthält, auf Knoten 1, informiert ONTAP den Client, den Datenverkehr an die Datenschnittstelle auf Knoten 1 umzuleiten.
pNFS ermöglicht zudem die Bereitstellung paralleler Netzwerkpfade zu Dateien von einem einzelnen Client, was NFSv4.1 ohne pNFS nicht bietet. Wenn ein Client beispielsweise gleichzeitig auf vier Dateien vom selben Mount mit NFSv4.1 ohne pNFS zugreifen möchte, würde derselbe Netzwerkpfad für alle Dateien verwendet, und das ONTAP Cluster würde stattdessen Remote-Anfragen an diese Dateien senden. Der Mountpfad kann zu einem Engpass für die Operationen werden, da alle einem einzigen Pfad folgen, an einem einzigen Node ankommen und neben den Datenoperationen auch Metadatenoperationen verarbeitet werden.
Wenn pNFS verwendet wird, um gleichzeitig von einem einzelnen Client auf dieselben vier Dateien zuzugreifen, verhandeln Client und Server lokale Pfade zu jedem Knoten mit den Dateien und nutzen mehrere TCP-Verbindungen für die Datenoperationen, während der Mount-Pfad als Speicherort für alle Metadatenoperationen dient. Dies bietet Vorteile hinsichtlich der Latenz durch die Verwendung lokaler Pfade zu den Dateien, kann aber auch den Durchsatz durch die Nutzung mehrerer Netzwerkschnittstellen erhöhen, vorausgesetzt, die Clients können genügend Daten senden, um das Netzwerk auszulasten.
Die folgenden Ergebnisse stammen aus einem einfachen Testlauf auf einem einzelnen RHEL 9.5 Client, bei dem vier 10-GB-Dateien (alle auf unterschiedlichen Volumes zweier ONTAP Clusterknoten) parallel mit dd gelesen wurden. Für jede Datei verbesserten sich der Gesamtdurchsatz und die Abschlusszeit bei Verwendung von pNFS. Bei Verwendung von NFSv4.1 ohne pNFS war die Leistungsdifferenz zwischen Dateien, die lokal am Einhängepunkt lagen, und entfernten Dateien größer als mit pNFS.
| Test | Durchsatz pro Datei (MB/s) | Bearbeitungszeit pro Datei |
|---|---|---|
NFSv4.1: kein pNFS |
|
|
NFSv4.1: mit pNFS |
|
|