NetApp Tech OnTap NetApp Logo
NetApp Tech OnTap
     
Zusammenarbeit von NetApp und Red Hat bei pNFS
Pranoop Erasani
Technical Director, NFS
Justin Parisi
Technical Marketing Engineer

Der Zugriff auf gemeinsam genutzte Daten ist von wesentlicher Bedeutung für die Performance einer Vielzahl an wissenschaftlichen, Engineering-, Business- und Finanzapplikationen. NFS – ein weitverbreiteter Standard für den Zugriff auf gemeinsam genutzte Daten – kann Engpässe in umfangreichen Computing Clustern verursachen, durch die Fileserver überfordert werden, die als einheitlicher Zugriffspunkt für alle Dateien eines Filesystems fungieren.

 

Die meisten verfügbaren Lösungen für gemeinsamen Datenzugriff mit hoher Performance sind überwiegend proprietär, bieten keine Unterstützung für heterogene Systeme und werden nicht so flächendeckend eingesetzt wie das Standardprotokoll NFS.

 

Der Parallel NFS Standard (pNFS), eine Subfunktion der Spezifikation für das Protokoll von NFS Version 4.1 (RFC 5661), behebt diese Engpässe und hat das Potenzial zu einer standardisierten Lösung für parallelen Datenzugriff. In diesem Artikel erläutern wir die Funktionsweise von pNFS, stellen gemeinsame Aktivitäten von NetApp und Red Hat für die weitere Entwicklung von pNFS vor und gehen auf die Implementierung von pNFS in NetApp Clustered Data ONTAP ein.

Was ist pNFS?

Das pNFS Protokoll ermöglicht Clients direkten Zugriff auf Dateien, die auf zwei oder mehr Datenservern verteilt sind. Durch den parallelen Zugriff auf mehrere Datenserver erzielen Clients eine erhebliche I/O-Beschleunigung. Das pNFS Protokoll bietet eine hohe Performance mit Client- und dateibasierter Skalierung sowie Rückwärtskompatibilität mit dem NFS Standardprotokoll. Clients ohne pNFS Erweiterung können trotzdem auf Daten zugreifen.

 

pNFS Architektur und Kernprotokolle

 

Die pNFS Architektur besteht aus drei Hauptkomponenten:

 

  • Der Metadatenserver ist für den gesamten nicht-datenspezifischen Verkehr zuständig. Er pflegt Metadaten, die beschreiben, wo und wie jede einzelne Datei gespeichert ist.
  • Datenserver speichern Dateidaten und antworten direkt auf die LESE- und SCHREIBanfragen des Clients. Dateidaten können auf verschiedenen Datenservern verteilt sein.
  • Ein oder mehr Clients können auf Basis der Informationen in den Metadaten, die vom Metadatenserver empfangen wurden, direkt auf Datenserver zugreifen.

 

Es werden drei Arten von Protokollen zwischen den Clients, dem Metadatenserver und den Datenservern verwendet:

 

  • Mithilfe eines Kontrollprotokolls wird der Metadatenserver mit den Datenservern synchronisiert. Dies ist nicht durch die pNFS Spezifikationen definiert und kann sich von Anbieter zu Anbieter unterscheiden.
  • Das pNFS Protokoll wird zwischen den Clients und dem Metadatenserver verwendet. Dabei handelt es sich im Wesentlichen um NFSv4 mit einigen pNFS typischen Erweiterungen. Es dient zum Abrufen und zur Bearbeitung von Layouts, in denen die Metadaten enthalten sind, die den Speicherort und das Storage-Zugriffsprotokoll beschreiben, die für den Zugriff auf Daten, die auf mehreren Datenservern gespeichert wurden, erforderlich sind.
  • Clients verwenden eine Reihe von Storage-Zugriffsprotokollen, um direkt auf Datenserver zuzugreifen. Der pNFS Standard definiert momentan drei Kategorien von Storage-Protokollen: dateibasierte (RFC5661), Block-basierte (RFC5663) und objektbasierte (RFC5664) Storage-Protokolle. Clustered Data ONTAP unterstützt derzeit das dateibasierte Storage-Protokoll und verwendet NFSv4.1 für den Zugriff auf Datenserver.

 

 

Elemente von pNFS. Clients fordern ein Layout vom Metadatenserver an (pNFS Protokoll) und greifen dann direkt auf Datenserver zu (Storage-Zugriffsprotokoll).

Abbildung 1) Elemente von pNFS. Clients fordern ein Layout vom Metadatenserver an (pNFS Protokoll) und greifen dann direkt auf Datenserver zu (Storage-Zugriffsprotokoll).

 

 

Für den Zugriff auf eine Datei kontaktiert der Client den Metadatenserver und fordert das Layout der Datei an, um diese zu öffnen. Sobald der Client das Datei-Layout erhalten hat, führt er mithilfe dieser Informationen den I/O parallel zu und von den Datenservern durch. Dabei verwendet er ein gültiges Storage-Zugriffsprotokoll, ohne den Metadatenserver weiter in Anspruch zu nehmen. pNFS Clients speichern das Layout im Cache, bis sie die parallelen I/O-Vorgänge abgeschlossen haben. pNFS Server haben das Recht, das Layout der Datei abzulehnen, wenn der Server keinen parallelen Zugriff auf die Server sicherstellen kann. pNFS ändert auch nicht den derzeit im NFS Server verfügbaren Mechanismus für Metadatenzugriff.

Gemeinsames Team von NetApp und Red Hat für die Entwicklung des pNFS Standards

Für eine pNFS Lösung müssen sowohl die Client- als auch die Serverkomponenten funktionieren. NetApp und Red Hat haben intensiv mit der Upstream Community zusammengearbeitet, um das erste auf Standards basierende umfassende pNFS Angebot zu entwickeln.

 

NetApp kombiniert Storage Clustering und pNFS, um die Herausforderungen der Skalierung zu bewältigen. NetApp FAS und V-Series Storage-Systeme mit Clustered Data ONTAP 8.1 oder höher lassen sich von nur einigen Terabyte bis auf mehr als 69 Petabyte skalieren und als eine Storage-Einheit managen. Dadurch wird das Management der pNFS Umgebung vereinfacht und geplante und ungeplante Ausfallzeiten werden vermieden.

 

Mit dem ersten, komplett unterstützten pNFS Client auf Red Hat Enterprise Linux können Sie jetzt skalierbare Filesystemlösungen der nächsten Generation auf Basis von pNFS planen und entwerfen. Applikations-Workloads können pNFS ohne Änderung optimal nutzen, sodass ein nahtloser Übergang für vorhandene Applikationen möglich ist.

pNFS und Clustered Data ONTAP

NetApp hat pNFS ab Clustered Data ONTAP 8.1 implementiert. (pNFS wurde nicht in 7-Mode oder Data ONTAP 7G implementiert.) Die in Clustered Data ONTAP implementierte pNFS Lösung bietet die folgenden Vorteile:

 

  • vereinfachte Infrastruktur: Die generelle Infrastruktur für pNFS ist einfacher im Vergleich mit anderen parallelen Filesystemen wie Lustre und GPFS, für die neben dem Storage außerdem viele dedizierte Server erforderlich sind.
  • Managebarkeit: pNFS umfasst in der Regel mehrere File Server, die separat gemanagt werden müssen. Mit Clustered Data ONTAP managen Sie alle Server-seitigen pNFS Komponenten in einem einzelnen System.
  • unterbrechungsfreier Betrieb: pNFS Installationen auf einem NetApp Cluster profitieren bei Wartungsarbeiten und der Lastverteilung, wie z. B. bei Storage Failovers, LIF-Migration und unterbrechungsfreien Volume-Verschiebungen, sowie allen anderen Workloads vom unterbrechungsfreien Betrieb.
  • Alle Nodes können als Metadatenserver fungieren. Bei der Clustered Data ONTAP Implementierung kann jeder Node im Storage-Cluster als Metadatenserver und als Datenserver fungieren. Dadurch werden potenzielle Engpässe durch nur einen Metadatenserver vermieden und Metadatenvorgänge können auf das gesamte Cluster verteilt werden.

 

 Vergleich von pNFS auf Data ONTAP mit NFS. Jeder Node kann als Metadatenserver und als Datenserver fungieren.

Abbildung 2) Vergleich von pNFS auf Data ONTAP mit NFS. Jeder Node kann als Metadatenserver und als Datenserver fungieren.

 

 

Damit Sie ein besseres Verständnis der Arbeitsweise von pNFS mit Clustered Data ONTAP bekommen, stellen Sie sich vor, ein Client mountet ein pNFS Filesystem von einem Node in einem Cluster. Um Zugriff auf eine Datei zu erhalten, sendet er Metadatenanfragen an den Node. Die pNFS Implementierung sammelt Informationen wie Speicherort, Layout der Datei und erforderliche Netzwerkinformationen, um zum Speicherort zu gelangen, und sendet sie zurück. Der Client greift mithilfe dieser Informationen direkt auf die Daten der Nodes zu, in denen sie gespeichert sind. Durch die Bereitstellung eines direkten Pfads zum Volume ermöglicht pNFS Applikationen, einen höheren Datendurchsatz und eine niedrigere Latenz zu erzielen.

 

pNFS lässt sich nahtlos in den unterbrechungsfreien Betrieb von Clustered Data ONTAP integrieren, darunter in Vorgänge wie LIF-Migration, Storage Failover und Volume-Verschiebungen. Wenn einer dieser Vorgänge durchgeführt wird, ermitteln pNFS Client und Server automatisch einen neuen direkten I/O-Pfad zum Server, sodass der Datendurchsatz unverändert bleibt – und das ohne Unterbrechungen für die Applikation. Das ist ein großer Vorteil für Storage-Administratoren, da sie keine Netzwerkpfade zu Filesystemen provisionieren müssen, wenn sie Wartungsarbeiten auf dem Cluster durchführen. pNFS mit Clustered Data ONTAP wirkt sich somit nicht nur positiv auf die Performance aus, sondern vereinfacht auch administrative Workflows bei Wartungsarbeiten. Bei der Bereitstellung und Implementierung großer Cluster ist dies unverzichtbar.

 

Ohne pNFS sind Metadaten und Datenpfade mehr oder weniger statisch. Mit pNFS wird der Metadatenservice auf mehrere Nodes verteilt und die Datenpfade führen direkt zur Netzwerkschnittstelle des Nodes, in dem die Datei gespeichert ist. Wenn Daten verschoben werden, passen sich die Datenpfade automatisch an, wodurch eine optimale Performance ermöglicht wird.

Abbildung 3) Ohne pNFS sind Metadaten und Datenpfade mehr oder weniger statisch. Mit pNFS wird der Metadatenservice auf mehrere Nodes verteilt und die Datenpfade führen direkt zur Netzwerkschnittstelle des Nodes, in dem die Datei gespeichert ist. Wenn Daten verschoben werden, passen sich die Datenpfade automatisch an, wodurch eine optimale Performance ermöglicht wird.

 

 

Best Practices

 

Um die bestmögliche pNFS Performance zu erzielen, sollten Sie einige Best Practices beachten:

 

  • Informieren Sie sich mithilfe der Interoperabilitätsmatrix von NetApp über aktuelle Kompatibilitätsangaben für NFSv4.1 und pNFS Clients (Zugriff auf die NetApp Support Site vorausgesetzt).
  • Jeder Cluster-Node, der pNFS unterstützt, sollte mit mindestens einer logischen Schnittstelle (LIF) konfiguriert werden, sodass pNFS Clients direkt auf die Volumes zugreifen können, die in diesem Node gespeichert sind.
  • Bei Workloads mit vielen Metadaten sollten pNFS Clients so konfiguriert werden, dass Mounts auf alle Nodes im Cluster verteilt werden, sodass sie alle als Metadatenserver fungieren können. Dies ist mithilfe eines externen Round Robin Domain Name Servers (DNS) oder durch einen integrierten DNS-Lastausgleich in Clustered Data ONTAP möglich.

 

Weitere Informationen zur Implementierung von pNFS in NetApp Storage-Systemen finden Sie in TR-4063.

Red Hat pNFS Client

Der Red Hat pNFS Client wurde erstmals 2011 auf Red Hat Enterprise Linux (RHEL) Version 6.2 Kernel veröffentlicht. RHEL 6.2 und RHEL 6.3 wurden jeweils als „Tech Preview“-Versionen von pNFS bezeichnet.

 

Das im Februar 2013 veröffentlichte RHEL 6.4 enthält die erste allgemein verfügbare Version von pNFS. Ausführliche Informationen zur Verwendung von Red Hat Clients mit NetApp Storage und NFS oder pNFS sind im TR-3183 enthalten. (Dieser technische Bericht wird momentan überarbeitet und steht möglicherweise zum Zeitpunkt der Veröffentlichung dieses Artikels nicht sofort zur Verfügung. Schauen Sie deshalb erneut vorbei.)

Anwendungsbeispiele für pNFS

Außer für hochgradig parallele Wissenschafts- und Engineering-Applikationen eignet sich pNFS aufgrund seiner einzigartigen Funktionen auch für eine Vielzahl an Enterprise-Applikationen.

 

Geschäftskritische Applikationen

 

Definitionsgemäß sind für geschäftskritische Applikationen die höchsten Service-Level erforderlich. Die Storage-Bandbreite und -Kapazität müssen sich reibungslos im Einklang mit den Serveranforderungen erweitern lassen. Wenn NetApp Storage Volumes transparent zu leistungsfähigeren Controllern im NetApp Cluster migriert werden, verfolgt der Red Hat Enterprise Linux pNFS Client automatisch die Datenverschiebung, passt sich eigenständig an und optimiert den Datenpfad neu. Dadurch entstehen fast keine Ausfallzeiten und es ist keine Neukonfiguration von Servern oder Applikationen erforderlich.

 

Mandantenfähige Storage-Lösung

 

Durch den parallelen Datenzugriff profitieren mandantenfähige, heterogene Workloads direkt von pNFS. Die Daten befinden sich auf dem NetApp Cluster und sind nicht an einen spezifischen NetApp Controller gebunden. Mithilfe von pNFS finden die Red Hat Enterprise Linux Server den optimalen Datenpfad und passen sich automatisch an. Dadurch erreichen Sie einen optimalen Durchsatz.

 

Unterschiedliche Clients und Workloads

 

NFSv4.1 und pNFS ermöglichen das flexible Mounten des Filesystems von einem beliebigen Ort im Cluster Namespace. Cluster-Applikationen lassen sich über pNFS mounten und ältere Applikationen über NFSv3. Clients können mit verschiedenen NFS Einstellungen in Filesystemen gemountet werden, die aus dem Storage exportiert wurden, sodass sie koexistieren können, ohne die Applikationen, die auf die Daten zugreifen, wesentlich zu verändern. Dank dieser hohen Flexibilität wird der Overhead für häufige Change Management-Aktivitäten verringert.

 

Virtualisierungsumgebungen

 

Hypervisoren und Virtual Machines, die den Red Hat Enterprise Linux pNFS Client verwenden, können pro Sitzung mehrere Verbindungen aufrechterhalten, wodurch die Last auf mehrere Netzwerkschnittstellen verteilt wird. Dies entspricht quasi Multipathing für NFS, ohne dass ein separater Multipath-Treiber oder eine Multipath-Konfiguration erforderlich ist.

Schlussfolgerung

NetApp hat aufgrund seiner leitenden Funktion in der Arbeitsgruppe eine wesentliche Rolle bei der Entwicklung von NFSv4.1 und pNFS gespielt. Darüber hinaus hat NetApp einen großen Teil der NFSv4.1 Spezifikation verfasst und bearbeitet. Dies bestätigt unser Engagement für die Bewältigung der Storage-Probleme mithilfe von Branchenstandards.

 

Dank der allgemeinen Verfügbarkeit des pNFS Clients durch die Veröffentlichung von RHEL 6.4 können Sie pNFS jetzt mithilfe von Red Hat Clients und Clustered NetApp Data ONTAP für Tests und/oder die Produktion implementieren.

Ihre Meinung?

Pranoop Erasani ist leitender NFS Architekt der NetApp Abteilung „Protocols Technology Engineering“, in der unter seiner Leitung NFS Protokolle für Data ONTAP entwickelt werden. Er spielte eine entscheidende Rolle bei der Entwicklung von pNFS für Clustered Data ONTAP. Pranoop Erasani ist ein entschiedener Fürsprecher der Nutzung von NFSv4.1/pNFS in Cluster-Systemen. Er hat sich an zahlreichen Diskussionen über den Standard pNFS IETF beteiligt und hält regelmäßig Vorträge auf NFS Interoperabilitätsveranstaltungen. Außerdem ist Pranoop Erasani ein wichtiger Berater für das technische Marketing und Produktmanagement für Kundenimplementierungen und Storage-Softwarelösungen.

Justin Parisi arbeitet seit fünf Jahren im NetApp Global Support im Research Triangle Park (RTP) als Technical Support Engineer und Escalations Engineer für kritische Problembehebungen. Sein Schwerpunkt ist Clustered Data ONTAP, für das er Kursunterlagen zur Fehlerbehebung sowie zahlreiche Knowledge Base-Artikel geschrieben hat. Seine Interessen liegen in den verschiedensten Bereichen, darunter CIFS, NFS, SNMP, OnCommand System Manager, Unified Manager, SnapDrive und SnapManager sowie Microsoft Exchange, SQL Server, Active Directory, LDAP und mehr, wodurch er als NetApp Allround-Talent gilt.

Explore
Explore
Weitere Informationen zu pNFS

Möchten Sie mehr über pNFS erfahren und herausfinden, wie Sie es implementieren können, um Ihre IT-Umgebung zu beschleunigen? Dann sehen Sie sich die folgenden Links an:

  • pNFS und zukünftige NFSv4.2 Funktionen
  • Horizontale Skalierung mit pNFS
    RHEL und KVM
  • pNFS und NFSv4.1 – ein Filesystem für Grid, Virtualisierung und Datenbank
  • pNFS Lösungsüberblick
  • Explore
     
    TRUSTe
    Kontakt   |   Bezugsquelle   |   Feedback   |   Karriere  |   Abonnements   |    Datenschutzrichtlinie   |    © 2013 NetApp