NetApp Tech OnTap
     

Beschleunigter Zugriff auf gemeinsam genutzte Daten für Rechner-Cluster


Der Zugriff auf gemeinsam genutzte Daten ist ein maßgebender Faktor für die Performance heutiger Rechner-Cluster, die eine Vielzahl von wissenschaftlichen, technischen und geschäftlichen Applikationen bewältigen. Der gängigste Standard für den Zugriff auf gemeinsam genutzte Daten - NFS - kann bei großen Rechner-Clustern zu Engpässen führen und die File Server, die als einziger Zugriffspunkt für alle Dateien in einem gemeinsam genutzten File System dienen, überlasten.

Abbildung 1) Standard NFS File Server verursachen bei wachsender Clustergröße Engpässe. Damit erhöht sich die Latenz (L) auf inakzeptable Werte und der Durchsatz (T für throughput) erreicht die Server-Limits.

Jene Lösungen, die höhere Performance beim Zugriff auf gemeinsam genutzte Daten ermöglichen, waren bisher im Wesentlichen proprietäre Protokolle, die nicht im selben Ausmaß wie standardisierte Protokolle, wie z.B. NFS, systemübergreifend unterstützt werden und folglich auch weniger verbreitet Anwendung finden.

Die Spezifikation des NFS Protokolls Version 4.1. liefert mit Parallel NFS eine neue Standard-Komponente, die das Problem der autretenden Engpässe bei Einzelservern zu beheben und die Lösung für parallelen Datenzugriff zu werden verspricht. In diesem Artikel werden wir die Funktionsweise von pNFS erörtern und den aktuellen Entwicklungstand dieses Standards besprechen.


Was steckt hinter pNFS?


Das pNFS Protokoll gewährt Clients direkten Zugriff auf Dateien, die auf zwei oder mehreren Datenservern verteilt sind (Striping). Durch den parallelen Zugriff auf mehrere Datenserver wird die I/O Leistung des Clients beträchtlich erhöht. Das pNFS Protokoll wurde entwickelt, um Skalierbarkeit und hohe Performance für sowohl Client-basierte als auch File-basierte Zugriffe zu liefern, ohne auf die Kompatibilität mit dem Standard NFS-Protokoll verzichten zu müssen: Clients ohne pNFS Erweiterung können weiterhin auf die Daten zugreifen.

pNFS Architektur und Kernprotokolle

Die pNFS Architektur besteht aus drei Hauptkomponenten:
  • dem Metadatenserver (MDS), über den der gesamte Nicht-Daten-Traffic abgewickelt wird. Der Metadatenserver hält die Metadaten betreffend den Speicherort und die Speicherart der einzelnen Dateien vor.
  • den Datenservern, die File-Daten speichern und direkt auf Lese- und Schreibanfragen des Clients antworten. File-Daten können mittels Striping auf mehrere Datenserver verteilt werden.
  • einem oder mehreren Clients, die - basierend auf den Metadateninformationen, die sie vom Metadatenserver erhalten - direkt auf die Datenserver zuzugreifen können.
Clients, Metadatenserver und Datenserver kommunizieren über die drei folgenden Protokolltypen:
  • ein Kontrollprotokoll, das für die Synchronisierung zwischen Metadatenserver und Datenservern sorgt
  • ein pNFS Protokoll für die Kommunikation zwischen den Clients und dem Metadatenserver. Dabei handelt es sich im Wesentlichen um NFSv4 mit einigen pNFS-spezifischen Erweiterungen. Dieses Protokoll wird genutzt, um Layouts aufzurufen und zu verändern; die Layouts enthalten die Metadaten, die den Speicherort und das Speicherzugriffsprotokoll beschreiben, das für den Zugriff auf die Daten notwendig ist, die auf mehreren Datenservern gespeichert sind.
  • eine Reihe von Speicherzugriffsprotokollen, mittels derer Clients direkt auf Datenserver zugreifen. ie pNFS Spezifikation ist derzeit mit drei Kategorien von Storage-Protokollen einsetzbar: File-basierte, Block-basierte oder Objekt-basierte Protokolle. Anhand dieser Protokolle kann pNFS sich diversen Layout-Typen anpassen und verschiedene Arten von Storage-Infrastruktur unterstützen.

Layout-Typen

Welches Storage-Zugriffsprotokoll verwendet wird, hängt vom Storage-Typ auf den betreffenden Datenservern ab. Der Metadatenserver übermittelt dem Client das File-Layout, das Auskunft darüber gibt, wo die einzelnen Stripes einer Datei gespeichert sind und wie bzw. mit welchem Protokoll darauf zugegriffen werden kann.

  • Bei einem File-basierten Layout setzt pNFS multiple NFSv4.1. File Server als Datenserver ein. In diesem Fall dient NFSv4 selbst als FAP (File-Zugriffsprotokoll).
  • Wird ein Block-basiertes Layout eingesetzt, werden Festplatten-LUNs auf einem SAN gehostet. Für den Zugriff auf SAN Geräte wird entweder das iSCSI oder das Fibre Channel Protokoll gemeinsam mit dem SCSI Block-Befehlssatz genutzt.
  • Objekt-basierte Layouts erlauben die Datenspeicherung auf Objekt-basierten Storage-Geräten (OSDs) und den Datenzugriff über das OSD-Protokoll, das zurzeit vom T10 Komitee standardisiert wird.
Beispiel für den File-Zugriff

Abbildung 2) Funktionsweise von pNFS: Die Clients fordern das Layout vom Metadatenserver an (1, pNFS Protokoll) und greifen dann direkt auf die Datenserver zu (2, Storage-Zugriffsprotokoll).

Um auf eine Datei zuzugreifen, kontaktiert der Client unabhängig vom Layout-Typ den Metadatenserver, um die Datei zu öffnen und das File-Layout anzufordern. Anhand der Informationen, die der Client über das File-Layout empfängt, führt er I/O Operationen direkt und parallel von und zu den Datenservern aus und verwendet dabei das entsprechenden Storage-Zugriffsprotokoll; der Metadatenserver ist in diesen Vorgang nicht mehr involviert. Nach Fertigstellung der I/O Operationen sendet der Client die veränderten Metadaten an den Metadatenserver zurück und schließt die Datei.

Die Wahl eines Layout-Typs

Im Folgenden einige Kriterien, die bei der Wahl eines für die Verwendung mit pNFS bestimmten Layouts in Erwägung gezogen werden sollten:

Ausgangslage

  • Wenn Sie von einer NAS-Architektur ausgehen, ist ein File-basiertes Layout zweifellos am sinnvollsten. Sie können Ihre bestehenden NAS-Systeme und Netzwerke verwenden.
  • Wenn Sie über ein bestehendes Fibre Channel SAN verfügen, ist ein Block-basiertes Layout empfehlenswert.
  • Wenn Sie eine neue Infrastruktur aufbauen möchten, lesen Sie weiter.

Netzwerk-Infrastruktur

  • Bei einem File-basierten Layout können bestehender NAS Storage und bestehende Ethernet-Infrastruktur weiter verwendet werden. Es ist nicht unbedingt notwendig, mehr Bandbreite hinzuzufügen.
  • Bei einem Block- oder Objekt-basiertem Layout, werden Sie wahrscheinlich ein Fibre Channel Storage Area Network (SAN) verwenden. Alle Clients müssen eine Verbindung zum FC SAN herstellen und direkt auf die Datenserver zugreifen. iSCSI wäre eine kostengünstigere Alternative.

Sicherheit

  • Bei einem File-basierten Backend führt jeder einzelne Datenserver Sicherheitsmaßnahmen aus, wobei dieselben Methoden wie bei Standard NFS Servern, einschließlich Kerberos-Authentifizierung, Zugriffskontrolllisten (ACLs) etc. angewandt werden. Diese Sicherheitsmaßnahmen sind allgemein bekannt und nachvollziehbar.
  • Wird pNFS mit Block- oder Objekt-basiertem Backend verwendet, müssen die Sicherheitsaufgaben zu einem großen Teil von der pNFS Client-Implementierung übernommen werden. Da der Client Teil des Client-Betriebssystems ist, können die ausgeführten bzw. nicht ausgeführten Sicherheitsmaßnahmen nur in geringem Maß beeinflusst werden. Anders gesagt: da Sie, was die Client-Implementierungen betrifft, nicht viel Entscheidungsfreiheit haben, ist es eventuell vorzuziehen, ein Layout zu wählen, bei dem die Datenserver für die Sicherheit zuständig sind.

Zugriff multipler Clients und Management

  • Bei einem File-basierten Layout, können zwei unterschiedliche pNFS Clients gleichzeitig auf denselben logischen Bereich einer Datei für Lese- oder Schreiboperationen zugreifen.
  • Bei Block-oder Objekt-basierten Layouts, kann nur jeweils ein pNFS Client auf einem bestimmten Dateibereich Schreiboperationen ausführen.

Verfügbarkeit von Komponenten

  • Objektbasierter Backend-Storage ist möglicherweise nur begrenzt verfügbar.

Aktueller Stand der pNFS Entwicklung


Der pNFS Standard

Der NFSv4.1. Standard, zu dem pNFS gehört, ist Gegenstand der Bemühungen einer Arbeitsgruppe innerhalb der Internet Engineering Task Force (IETF). Diese Arbeitsgruppe setzt sich aus Experten und Entwicklern zusammen und spiegelt einen breiten Querschnitt der führenden Storage- und Systemanbieter sowie Forschungsinstitutionen, wie z.B. NetApp, EMC, IBM, Universität von Michigan und Sun Microsystems wider. Die Standardisierung von NFSv4.1. und pNFS ist abgeschlossen und die Fertigstellung der Spezifizierung durch die IETF wird vor Ende 2008 erwartet.

NetApp hat zur Entwicklung von NFSv4.1. und pNFS maßgeblich beigetragen, unter anderem durch eine leitende Position innerhalb der Arbeitsgruppe. Außerdem hat NetApp einen beträchtlichen Anteil der NFSv4.1. Spezifizierung verfasst und editiert. Dies entspricht unserer Bemühung, zur Lösung von Storage-Problemen auf Industriestandards zu setzen.

Weitere Informationen zur IETF Spezifikation für NFSv4.1. und pNFS finden Sie hier: Webseite der IETF NFS v4 Arbeitsgruppe.

NFSV4.1/pNFS Tests

Genauso wie es für NFS der Fall war, ist die Interoperabilität für die Akzeptanz von pNFS entscheidend. Diese wird durch die nahtlose Zusammenarbeit von Client- und Serverimplementierungen sicherlich beschleunigt werden. Die Interoperabilität diverser pNFS Implementierungen wird seit März 2005 getestet. NFSv4.1. und pNFS wurden beim jährlichen Connectathon, einem anbieterneutralen Forum für Hardware- und Software- Interoperabilitätstests, getestet.

Außerdem werden mehrmals jährlich Bake-a-thons abgehalten. Der letzte Bake-a-thon, auf dem sechs pNFS Server Implementierungen und zwei Client-Implementierungen getestet wurden, fand im September 2008 statt. Dabei stieß man weder bei NFSv4.1. noch bei den pNFS Spezifikationen auf Schwierigkeiten, das Protokoll entwickelt sich also zufrieden stellend. Informationen zum aktuellen Stand der pNFS Tests finden Sie meistens auf Mike's NFS Blog.

Linux Client und Server-Entwicklung

Aufgrund der dominierenden Stellung von Linux im Bereich der Rechner-Cluster, die für viele der wissenschaftlichen, technischen und sonstigen Applikationen eingesetzt werden, die aus pNFS erwartungsgemäß den größten Nutzen ziehen werden, ist es wichtig, über einen gut entworfenen und gründlich getesteten Client für Linux zu verfügen, der die Performance-Anforderungen dieser Applikationen erfüllt. NetApp sowie andere Anbieter haben dies erkannt und investieren in die Schaffung eines robusten Linux pNFS Clients. Mit fortschreitender Entwicklung dieses Clients wird die Implementierung Teil des Mainlinie Linux Kernels werden. Dies wird die Verwendung von pNFS auf Linux Rechnern ermöglichen, ohne zusätzliche Software installieren und verwalten zu müssen.

NetApp ist intensiv an der Entwicklung dieses pNFS Clients sowie dem File-Layout-Treiber beteiligt und entwickelt außerdem einen Server für Linux. Mit einem einfachen pNFS Server zusätzlich zum Client wird potenziellen pNFS Anwendern eine Plattform für Tests, Konzeptüberprüfungen und zum Einarbeiten geboten.

Fazit

Als anerkannter Standard, der knapp vor der Fertigstellung steht, breite Unterstützung der Anbieter genießt und es ermöglicht, bestehende Storage-Infrastruktur weiter zu nutzen, scheint pNFS gute Chancen zu haben, ein weit verbreiteter Standard für hoch-performante, parallele I/O Operationen zu werden. Zudem ist er in der Lage, die Anforderung jeder Applikation zu erfüllen, die mehr I/O Performance benötigt, als ein einzelner File-Server bieten kann.

Ihre Meinung zu pNFS?

Stellen Sie Fragen, tauschen Sie Ideen aus und teilen Sie Ihre Meinung mit der NetApp Online Community!
Mike Eisler

Mike Eisler
Senior Technical Director
NetApp

Mike leitet NetApp's Entwicklungen rund um NFS. Er ist der Autor der NFSv4 Spezifikation und einiger anderer Spezifikationen, die mit NFS und Sicherheit in Zusammenhang stehen. Mike kam mit dem Thema NFS und NIS erstmals bei Lachman Associates. in Berührung, wo er für die Übertragung von NFS und NIS auf System V Plattformen zuständig war. Bevor er zu NetApp stieß, war er für Sun tätig, wo er für mehrere Projekte im Bereich NFS und Sicherheit verantwortlich war.

Joshua Konkle

Joshua Konkle
Technical Evangelist für NAS und Engineering Applikationen
NetApp

Joshua entwickelt Technologien und Lösungen, die Kunden zu mehr Produktivität verhelfen. Er bringt sowohl UNIX als auch Windows-Erfahrung mit, seine Kernkompetenz ist die Sicherheit. Er hat auf verschiedensten branchenspezifischen und technischen Veranstaltungen über zahlreiche Themen im Bereich Storage und Sicherheit referiert.

Weitere Infos hier