PVFS - Parallel Virtual File System Clusterseminar

PVFS - Parallel Virtual File System Clusterseminar Thorsten Schütt <schuett@cs.tu-berlin.de> Juli 2001 1 Einleitung Verteilte Dateisysteme gewinnen durch die stärkere Verbreitung von Clustercomputern immer mehr an Bedeutung für deren effiziente Nutzung. Ein konkretes verteiltes Dateisystem ist PVFS der Clemson Universität, das im folgenden genauer vorgestellt werden soll. Zunächst wird im zweiten Abschnitt dieser Arbeit ein allgemeiner Überblick über verteilte Dateisysteme gegeben. Der dritte Abschnitt erklärt den Aufbau und die Installation von PVFS. Benchmark-Ergebnisse werden im vierten Teil besprochen. Im fünften und sechsten Abschnitt werden die Erkenntnisse zusammengefaßt. 2 Eigenschaften von verteilten Dateisystemen Es gibt verschiedene verteilte Dateisysteme, die sich durch ihre Eigenschaften voneinander unterscheiden. Ein paar dieser Unterscheidungsmerkmale sollen hier zunächst unabhängig von PVFS eingeführt werden. Bei verteilten Dateisystemen, die einen globalen Namensraum bieten, werden Dateien auf verschiedenen Rechnern mit dem gleichen Namen angesprochen. Von einem verteilten Dateisystem verspricht man sich eine erhöhte Zugriffsgeschwindigkeit und bessere Nutzung freien Speicherplatzes. Wenn man einen einzelnen Server mit NFS (siehe Abbildung 1) einsetzt, um in einem Cluster von 100 Rechnern das Home-Verzeichnis zu speichern, kann man nur mit erheblichen Investitionen in Netzwerk und Server eine akzeptable Zugriffszeit erreichen, da sich alle Rechner die Verbindung zum Server teilen müssen. Wenn ein Dateisystem es erlaubt, die Daten über mehrere Server zu verteilen, können sich die Clients die Bandbreite von mehreren Servern teilen (siehe Abbildung 2). Durch Installation einer genügend großen Zahl von Servern kann man genug I/O-Leistung für alle Clients zur Verfügung stellen. Mit der Verteilung des Dateisystems über mehrere Rechner steigt die Wahrscheinlichkeit des Ausfalls, wenn für den Betrieb alle Server benötigt werden. Wenn die Wahrscheinlichkeit für einen Ausfall eines bestimmten Rechners p ist, 1

High Speed Disk Abbildung 1: Beispiel für eine NFS-Server-Konfiguration High Speed Disk High Speed Disk High Speed Disk High Speed Disk Abbildung 2: Beispiel für eine Rechnerkonfiguration mit verteiltem Dateisystem 2

ergeben sich für die Verfügbarkeit eines einzelnen Servers und eines Clusters von Servern, bei dem alle Server verfügbar sein müssen, folgende Formeln. P verfügbar (Server = 1) = (1 p) P verfügbar (Server = n) = (1 p) n Schon bei einem kleinen Cluster sinkt die Verfügbarkeit erheblich. Bietet das Dateisystem aber Redundanz der Daten, kann die Verfügbarkeit erhöht werden. Ein Problem stellen auch Backups dar. Unter Umständen muss man Dateisysteme auf mehreren Servern sichern und gleichzeitig sicherstellen, dass diese Sicherung einen konsistenten Zustand des verteilten Dateisystems widerspiegelt, da es zu Änderungen am Dateisystem während des Backups kommen kann. Wenn die Meta-Daten separat von den eigentlichen Daten gespeichert werden, kann es passieren, dass zwischen dem Backup der Meta-Daten und dem der Dateiinhalte Dateien gelöscht werden. In diesem Fall ist das erzeugte Backup nicht konsistent. Deshalb ist es erforderlich, dass das Dateisystem eine Snapshot- Funktion zur Verfügung stellt, die den Dateisystemzustand für das Backup einfriert, aber trotzdem ein weiterbenutzen des Dateisystems ermöglicht. Ein weiteres Problem bei verteilten Dateisystemen sind Locks. Locks erlauben der exklusiven Zugriff auf Dateien und werden unter anderem in Datenbanken eingesetzt. Es muss eine Möglichkeit geben Locks auf Dateien anzulegen, die für alle Clients sichtbar sind. Das Dateisystem muss eine zentrale Instanz vorsehen, die Locks verwaltet, oder einen verteilten Lock-Algorithmus implementieren. 3 Implementierung eines verteilten Dateisystems 3.1 Parallel Virtual FileSystem - PVFS Die Abkürzung PVFS setzt sich wie folgt zusammen: Parallel: PVFS speichert die Daten auf mehreren Rechnern Virtual: PVFS besteht eigentlich aus mehreren User-Space Deamons, die auf das lokale File System zugreifen File System: PVFS ermöglicht dem Benutzer das Speichern und Laden von Dateien mit den üblichen Funktionen(open, read, write, close) PVFS wird seit ca. 1996 entwickelt und ist auf x86/linux und Alpha/Linux unter der GNU-Lizenz verfügbar. Ziel war es einerseits eine Forschungsplattform zu entwickeln, andererseits sollte PVFS auch in Clustern eingesetzt werden und dort eine hohe Bandbreite für Dateisysteme zur Verfügung stellen. 3

3.2 Komponenten Das PVFS-System besteht aus folgenden Komponenten, die auf jedem Rechner laufen können: File-Manager I/O Server Client Je PVFS-System gibt es genau einen File-Manager, der die Meta-Daten des Dateisystems verwaltet. Dabei handelt es sich um den Namen der Dateien, ihre Besitzer und Gruppen, die Zugriffsrechte und um die physikalische Verteilung der Datei über die Server. I/O Server speichern Inhalte von Dateien und ermöglichen den Benutzern Zugriff auf diese. Clients können PVFS-Dateisysteme mounten und auf die Dateien zugreifen. Jeder Rechner kann mehrere Rollen übernehmen und es ist durchaus üblich, dass der File-Manager auch gleichzeitig I/O Server ist. 3.3 Installation Die Installation beschränkt sich auf das Kompilieren von zwei tar-archiven. pvfs-*.tgz enthält die Server-Programme für den File-Manager und die I/O Server. pvfs-kernel-*.tgz enthält alle Programme, die für Clients nötig sind. Auf dem Server müssen drei Konfigurationsdateien erstellt werden. Der Administrator wird dabei durch ein mitgeliefertes Skript unterstützt. Anschließend müssen auf dem Server einige Daemons gestartet werden. Auch hierfür werden fertige Init-Skripte mitgeliefert. Auf den Clients muss ein Device-File angelegt, ein Kernel-Modul geladen und ein Daemon gestartet werden. Dann kann man Laufwerke, die vom File- Manager exportiert werden, mounten. Die Installation ist detailliert in [3] beschrieben. 3.4 Datenlayout Die Dateien werden über alle I/O Server verteilt, wobei jede Datei blockweise über alle Server verteilt ist. Dadurch können Lese- und Schreibzugriffe über alle Server verteilt werden. Einem einzelnen Client bringt das keine Vorteile, wenn die Zugriffe durch seine Netzanbindung begrenzt werden. Aber es können mehrere Clients hohe Datentransferraten erreichen. Alle Server-Komponenten benutzen zur Speicherung ihrer Daten vorhandene Dateisysteme. Der File-Manager wird nur einmal konsultiert, wenn die physikalische Verteilung der Datei und die traditionellen Datei-Eigenschaften wie Zugriffsrechte, Besitzer und Gruppe 4

abgefragt werden. Bei Lese- und Schreib-Zugriffen kann der File-Manager deshalb nicht zum Flaschenhals werden. In den Veröffentlichungen der Autoren von PVFS[1] wird angegeben, dass man die Größe der Blöcke, in denen die Datei verteilt wird, konfigurieren kann, aber der Dokumentation konnte keine derartige Möglichkeit entnommen werden. Um auf die Dateien zugreifen zu können, braucht man eine globale Ordnung über die Server. PVFS kann nicht damit umgehen, wenn Server im Betrieb hinzugefügt oder entfernt werden. Das Dateisystem ist dann nicht in der Lage, die Dateien wieder zusammenzusetzen. 3.5 Systemintegration Zum transparenten Zugriff für Programme auf das Filesystem gibt es 2 Möglichkeiten. ein Kernel-Modul oder eine Wrapper-Bibliothek um die Glibc Das Kernel-Modul wird beim Booten geladen und erlaubt jedem Programm den Zugriff. Die Nutzung der Wrapper-Bibliothek wird über die Umgebungsvariable LD PRELOAD des dynamischen Linkers/Laders realisert. Dann wird sie jedes Mal geladen, bevor die Glibc geladen wird. Dadurch können dynamisch gelinkte Programme auf das Filesystem zugreifen. Statisch gelinkten Programmen ist dieser Weg verwehrt. Bei Benutzung des Kernel-Moduls müssen die Daten einen langen Weg durch das Betriebssystem machen. Der Vorteil ist, dass jedes Programm auf die Dateien zugreifen kann. In Abbildung 3 ist ein open-funktionsaufruf dargestellt. Der Funktionsaufruf wird von der Applikation über die Glibc an den Kernel weitergeleitet. Dort überprüft das Virtual Filesystem für welches Dateisystem der Aufruf bestimmt ist und reicht den Aufruf an das PVFS-Kernel-Modul weiter. Hier werden die Daten über ein Device-File wieder an den User-Space zurückgegeben. Der pvfs-daemon übernimmt den Dateinamen und schickt ihn per TCP an den File-Manager. Der liest die Meta-Daten für die Datei über VFS, ext2, Blockdevice und Harddisk ein. Anschließend wandern die Informationen über den gleichen Weg zurück. Statt ext2 kann auch jedes andere Dateisystem, das von Linux unterstützt wird, verwendet werden, da PVFS seine Daten auf vorhandenen Dateisystemem speichert. Bei Verwendung der Wrapper-Bibliothek kann ein Teil abgekürzt werden. Da die Bibliothek den open-aufruf schon im User-Space erkennt, kann sie die Daten direkt per TCP an den File-Manager weitergeben. Die Autoren von PVFS führen ihre Benchmarks mit der Wrapper-Bibliothek durch und sparen sich damit einige Wechsel zwischen User- und Kernel-Modus. Zugriffe über das Kernel-Modul würden etwas schlechtere Ergebnisse liefern. Andererseits wollen sie die Entwicklung der Bibliothek einstellen, da es zu aufwendig ist, sie immer an die aktuellen Glibcs anzupassen. Neben dem transparenten Zugriff bietet PVFS Zugriff über 2 weitere Schnittstellen: 5

Host 1 Host 2 User Space Kernel Space App Glibc VFS read: /mnt/pvfs/foo pvfsd Systemcall req:read Block /pvfs_data/001/f1092157504 Treiber /dev/pvfsd INode Mapping TCP/IP Network device Netz TCP/IP Network device iod VFS ext2 Blockdevice Harddisk normaler Kommunikationsweg Shortcut mit pvfs lib Abbildung 3: Einzelne Arbeitsschritte des Systemcalls open eine native PVFS-Bibliothek MPI-IO Beides sind Bibliotheken, die es ermöglichen strided-zugriffe auf Dateien auszuführen. Mit diesen Zugriffen kann man z.b. sehr einfach eine Matrix zeilenweise über mehrere Rechner in einem Cluster verteilen. Man kann mit diesen Schnittstellen Zugriffe folgender Form ausführen: lese jede 10. Zeile der Matrix aus Datei matrix.dat. MPI-IO ist ein offizieller Standard, der in MPI 2[4] integriert ist, während die native PVFS-Bibliothek nur von PVFS benutzt wird. 3.6 Einschränkungen PVFS unterliegt folgenden Einschränkungen: Die maximale Dateigrösse ist auf 2nGB beschränkt, wobei n die Anzahl der Server ist. Diese Einschränkung wird von Linux verursacht. Links funktionieren nur von nicht-pvfs-dateisystemen nach PVFS-Dateisystemen, aber nicht in die andere Richtung. PVFS hat keinen eingebauten Cache. Das Caching findet nur durch das Betriebssystem statt (VFS). Durch die hohe Anzahl an Servern erhält man aber auf Server-Seite einen relativ großen Cache. Das Hinzufügen und Entfernen von I/O Servern im Betrieb ist nicht möglich. Das System ist sehr fehleranfällig. Es gibt mindestens zwei single points of failure. Wenn ein I/O Server oder der File-Manager ausfällt, kann auf keine Datei mehr zugegriffen werden. PVFS hat keine eingebaute Redundanz. 6

4 Benchmarks Für die Benchmarks haben die Autoren von PVFS 60 PIII-500 mit jeweils 512MB benutzt[1]. Das Netzwerk bestand aus geswitchtem Fast-Ethernet und Myrinet. Für die Netze wurden folgende Messwerte für reines TCP ermittelt: 10.2MB/s und 37.7 MB/s. Alle Zugriffe liefen wie erwähnt über die Wrapper- Bibliothek. Die stripe size wird von den Autoren mit 16KB angegeben. Der Benchmark liest bzw. schreibt pro Client 2nMB in eine Datei. Wieder ist n die Anzahl der Server. Abbildung 4: Bandbreite für das Lesen mit Ethernet bei verschiedener Anzahl von Clients Ethernet/Lesen (Abbildung 4): Man sieht sehr deutlich, dass trotz 32 I/O Servern nicht bessere Werte als mit 24 I/O Servern erreicht werden. Die PVFS- Autoren schließen daraus, dass bei 24 Servern das Ende der Skalierbarkeit von Fast-Ethernet erreicht ist. Je Server konnte im Durchschnitt eine Bandbreite von 11MB/s erreicht werden. Die Werte stiegen bis ca. 25 Clients an und sanken dann ab. Das Absinken ist aber nicht gleichmäßig. Es sind immer wieder größere Ausreißer in den Kurven. Eine Erklärung für diese Ausreißer könnte die verwendete Netzwerktopologie sein. Wenn 24-Port Switches verwendet wurden, kann es sein, daß ab 24 Servern die Server an verschiedenen Switches hängen und es dadurch Nebeneffekten bei den Messungen kommt. Ethernet/Schreiben (Abbildung 5): Die Schreibraten steigen nur um 10MB/s pro zusätzlichem Server. Die Peak-Bandbreite lag ein wenig höher als beim Lesen. Es konnten 226MB/s erreicht werden. Myrinet/Lesen (Abbildung 6): Die Datenraten waren bei Myrinet wesentlich höher als bei Fast Ethernet. Es konnten Steigerungen von 37MB/s zusätzlichem 7

Abbildung 5: Bandbreite für das Schreiben mit Ethernet bei verschiedener Anzahl von Clients Abbildung 6: Bandbreite für das Lesen mit Myrinet bei verschiedener Anzahl von Clients 8

pro Server beobachtet werden. Abbildung 7: Bandbreite für das Schreiben mit Myrinet bei verschiedener Anzahl von Clients Myrinet/Schreiben (Abbildung 7): Sowohl beim Lesen als auch beim Schreiben, blieben die Werte nach erreichen das Maximums konstant. Es gab weder größere Ausschläge noch ein Absinken. Die erzielten Bandbreiten sind beim Schreiben wieder größer als beim Lesen. Bei Myrinet ist der Unterschied wesentlich deutlicher. Die höchste Datenrate, die in den Tests gemessen wurde, waren 700MB/s beim Schreiben mit Myrinet. Die erzielten Ergebnisse sind beeindruckend und zeigen, dass PVFS auch moderne Netzwerke auslasten kann. Aber es handelt sich hier um synthetische Tests, die in der Form in der Realität nicht vorkommen. Es wurden auch noch Tests mit einem flow solver gemacht, bei dem strided Zugriffe auf eine Datei ausgeführt wurden. Dabei konnten 50-60% der Peak-Leistung erreicht werden. 5 Eigene Erfahrungen Die Installation war sehr einfach. Bei größeren Installationen muss man die Software allerdings auf mehr Rechnern einspielen als bei den hier durchgeführten Tests. Während der gesamten Versuche kam es immer wieder zu Abstürzen einzelner Rechner des Test-Clusters. Bis heute ist leider nicht klar, ob die Abstürze an PVFS oder an anderen Komponenten liegen. Dass auch die AFS-Tests durch Abstürze behindert wurden, spricht für Probleme mit der vorinstallierten Software oder der Hardware. 9

Durch die zahlreichen Abstürze konnten keine vernünftigen Geschwindigkeitstest gemacht werden. Die Tests haben aber ergeben, dass die Geschwindigkeit von PVFS sehr von der verwendeten Blockgröße abhängt. Tests mit dd lieferten die besten Resultate, wenn die Blocksize(bs) 32KB betrug. 6 Zusammenfassung PVFS lässt sich einfach installieren und ist transparent für alle Anwendungen. Die Hardwareanforderungen sind moderat. Man kann einige einfache Rechner zu einem bestehenden Cluster als Server hinzufügen. Es muss keine spezielle Hardware wie SCSI-Festplatten o.ä. beschafft werden oder zur Verfügung stehen. In der Universität Paderborn wird PVFS im PC 2 Rechenzentrum erfolgreich[9] eingesetzt, um mit geringen Hardwareeinsatz (8 dual-processor PII) 150GB Plattenplatz für temporäre Ergebnisse anzubieten. Der Eindruck wird aber durch die Abstürze getrübt. Dabei zeigt sich auch, dass eine Redundanz im Dateisystem angebracht ist. Bei den Tests wäre es schön gewesen, wenn PVFS den Ausfall von einzelnen Servern überlebt hätte. Dadurch kann man PVFS nicht für wichtige Daten empfehlen. Man sollte nicht Home-Verzeichnisse o.ä. auf PVFS-Server legen. Um mit hoher Geschwindigkeit Zwischenergebnisse zu speichern, kann man PVFS durchaus verwenden. Man könnte z.b. ein globales Verzeichnis für temporäre Dateien anlegen, auf das alle Rechner im Cluster schreiben können. Literatur [1] P. H. Carns, W. B. Ligon III, R. B. Ross und R. Thakur, PVFS: A Parallel File System For Linux Clusters, Proceedings of the 4th Annual Linux Showcase and Conference, Atlanta, GA, Oktober 2000. [2] http://parlweb.parl.clemson.edu/pvfs/, The PVFS Webpage, Juli 2001. [3] http://parlweb.parl.clemson.edu/pvfs/quick.html, Quick Start Guide, Juli 2001. [4] MPI-2: Extensions to the Message-Passing Interface, Message Passing Interface Forum, Juli 1997. [5] R. B. Ross, Providing Parallel I/O on Linux Clusters, Second Annual Linux Storage Management Workshop, Miami, FL, Oktober 2000. [6] W. B. Ligon III und R. B. Ross, An Overview of the Parallel Virtual File System, Proceedings of the 1999 Extreme Linux Workshop, Juni 1999. [7] M. M. Cettei, W. B. Ligon III und R. B. Ross, Support for Parallel Out of Core Applications on Beowulf Workstations, Proceedings of the 1998 IEEE Aerospace Conference, März 1998. 10

[8] W. B. Ligon III und R. B. Ross, Implementation and Performance of a Parallel File System for High Performance Distributed Applications, Proceedings of the Fifth IEEE International Symposium on High Performance Distributed Computing, August 1996. [9] http://www.uni-paderborn.de/pc2/projects/ccs/manual/psc/psc pvfs.html, Using the Parallel File System on the Paderborn SCI Cluster (PSC2), Juni 2001. 11