Evaluierung von Cluster-Dateisystemen für den Einsatz auf Parallelrechnern


Bachelorarbeit, 2006

83 Seiten, Note: 1


Leseprobe


Fachhochschule
Bonn-Rhein-Sieg
University of Applied Sciences
Fachbereich Informatik
Department of Computer Science
Abschlussarbeit
im Bachelor Studiengang
Evaluierung von Cluster-Dateisystemen
für den Einsatz auf Parallelrechnern
von
Ace Crngarov
Eingereicht am: 07.08.2006

ii
Eidesstattliche Erklärung
Hiermit erkläre ich an Eides statt, dass ich die vorliegende Bachelorarbeit selbständig ver-
fasst und keine anderen als die angegebenen Quellen und Hilfsmittel verwendet habe.
Die Arbeit wurde bisher keiner Prüfungsbehörde vorgelegt und noch nicht veröffentlicht.
Sankt
Augustin,
07.08.2006
_________________________
(Ace Crngarov)

iii
Zusammenfassung
Zur Ein- und Ausgabe großer Datenmengen auf Parallelrechnern und Cluster-Systemen wer-
den spezielle Dateisysteme eingesetzt, die den parallelen Zugriff von mehreren Rechnern
gleichzeitig effizient unterstützen. Beispiele für solche Cluster-Dateisysteme sind Parallel
Virtual File System (PVFS / PVFS2), Oracle Cluster File System (OCFS2), Red Hat Global
File System (GFS), IBM General Parallel File System (GPFS) und Lustre.
Diese Arbeit evaluiert die oben genannten Produkte hinsichtlich ihrer Effizienz und prakti-
schen Einsetzbarkeit in einer Parallelrechnerumgebung. Zu Beginn werden die verschiede-
nen Cluster-Dateisysteme vorgestellt, der Schwerpunkt liegt hier auf frei verfügbaren Datei-
systemen. Weiter legt diese Arbeit geeignete Effizienzkriterien und Strategien zur Beurtei-
lung solcher Dateisysteme fest. Zu den Kriterien zählen neben einer hohen Transferrate auch
eine geringe Latenzzeit bei Zugriffen auf kleine Dateien. Ein Benchmark-Programm setzt die
festgelegten Kriterien und die Strategie um. Dazu wird ein neues Benchmark-Programm
entwickelt, da kein verfügbares Programm alle festgelegten Kriterien untersuchen kann.
Die vorgestellte Auswahl an Cluster-Dateisystemen wird mit dem entwickelten Benchmark-
Programm untersucht. Diese Arbeit präsentiert und vergleicht die gewonnenen Ergebnisse.
Abschließend werden die resultierenden Leistungsdaten analysiert und darauf aufbauend
Empfehlungen gegeben.

iv
Inhaltsverzeichnis
1
Einleitung ...1
1.1
Ziel und Motivation dieser Arbeit ...1
1.2
Vorgehensweise...2
1.3
Abgrenzung ...2
2
Dateisysteme für Parallelrechner-Cluster...3
2.1
Begriffsdefinitionen und Bedeutung ...3
2.1.1
Cluster ...3
2.1.2
Cluster-Dateisystem ...4
2.1.3
Datei-intensive Anwendungen ...4
2.2
Architekturen von Cluster-Dateisystemen...5
2.2.1
Shared Storage ...5
2.2.2
Intelligente Server ...5
2.3
Technische Übersicht ...6
2.3.1
Parallel Virtual File System 2 ...6
2.3.2
Lustre...8
2.3.3
Oracle Cluster File System 2...9
2.3.4
General Parallel File System ...9
2.3.5
Global File System...10
2.3.6
Weitere Cluster-Dateisysteme...11
2.3.7
Techniken zur Optimierung von Zugriffen ...12
3
Kriterien zur Beurteilung von Cluster-Dateisystemen ...14
3.1
Zugriffsmuster wissenschaftlicher Anwendungen ...14
3.2
Festlegung der zu untersuchenden Leistungsdaten...16
3.3
Erhebung der festgelegten Leistungsdaten in Form von Testszenarien ...17
3.3.1
Sequentieller Zugriff, gemeinsame Datei...18
3.3.2
Sequentieller Zugriff, unterschiedliche Dateien...18
3.3.3
Schrittweiser Zugriff ...19
3.3.4
Metadaten...19
3.3.5
Pufferfähigkeit...20
3.3.6
Systemauslastung ...20
4
Umsetzung der konzipierten Szenarien und Testvorbereitung...21
4.1
Benchmark-Programm zur Umsetzung der Szenarien ...21
4.1.1
Anforderungen an ein Benchmark-Programm ...21
4.1.2
Auswahl eines Benchmark-Programms ...22
4.1.3
Entwicklung und Umsetzung eines Benchmark-Programms ...23
4.2
Testvorbereitung...27
4.2.1
Testumgebung ...27
4.2.2
Gruppierung der Rechner ...28
4.2.3
Installation und Konfiguration ...30
5
Ergebnisse der Testdurchführung...32
5.1
Testergebnisse der Szenarien...32
5.1.1
Sequentieller Zugriff, gemeinsame Datei...32
5.1.2
Sequentieller Zugriff, unterschiedliche Dateien...36
5.1.3
Schrittweiser Zugriff ...42
5.1.4
Metadaten...49

v
5.1.5
Pufferfähigkeit...56
5.1.6
Systemauslastung ...60
5.2
Diskussion der Ergebnisse...62
5.2.1
Sequentieller Zugriff, gemeinsame Datei...62
5.2.2
Sequentieller Zugriff, unterschiedliche Dateien...63
5.2.3
Schrittweiser Zugriff ...65
5.2.4
Metadaten...67
5.2.5
Pufferfähigkeit...69
6
Fazit der Untersuchung und Handlungsempfehlungen...71
Literaturverzeichnis ...74
Anhang ...77

1
1 Einleitung
Die Geschwindigkeit, die Arbeitsspeichergröße und die Speicherkapazität von Parallelrech-
nern nehmen rasant zu, wohingegen sich die Geschwindigkeit von einzelnen Festplatten
jedoch nicht in dem selben Maße erhöht [May01]. Das hat zur Konsequenz, dass Parallel-
rechner Daten nicht so schnell lesen und schreiben können, wie sie Daten erzeugen. Die Fol-
ge davon ist, dass die Leistungsfähigkeit von Anwendungen auf Parallelrechnern dadurch
beschränkt sein kann. In Zukunft wird das Problem durch die sich immer weiter öffnende
Schere zwischen Rechen- und Festplattengeschwindigkeit noch größer.
Cluster-Dateisysteme sollen diese Schere wieder zusammenführen, indem sie Daten über
mehrere Knoten eines Parallelrechners verteilen. Die Knoten schreiben ihren zugewiesenen
Teil der Daten auf die lokale Festplatte; die akkumulierte Leistungsfähigkeit der einzelnen
Knoten lässt sich dadurch ausnutzen. Der Benutzer eines Cluster-Dateisystems erhält trotz
der physikalischen Verteilung der Daten eine transparente Datensicht auf das Dateisystem,
ohne zu wissen, dass die Daten physikalisch verteilt liegen [Bau06].
1.1
Ziel und Motivation dieser Arbeit
Das Ziel dieser Arbeit ist die systematische Untersuchung von verschiedenen Cluster-
Dateisystemen hinsichtlich ihrer Effizienz und der praktischen Einsetzbarkeit in einer Paral-
lelrechnerumgebung. Diese Arbeit evaluiert unterschiedliche Produkte aus dem Bereich der
Cluster-Dateisysteme und vergleicht sie anhand von festgelegten Kriterien. Der Fokus liegt
dabei auf Produkten, die in einer Umgebung ohne gemeinsamen Festplattenspeicher (engl.
shared storage [Gro03]) funktionieren. Systematische Untersuchungen in der Form existieren
dazu bislang nicht. In [Cop05] und [Mau05] finden sich zwei Studien zu Cluster-
Dateisystemen, die einen Leistungsvergleich zwischen unterschiedlichen Systemen anstellen.
Dies geschieht jedoch in beiden Fällen auf Grundlage einer Umgebung mit Zugriff auf einen
gemeinsamen Festplattenspeicher.
Einige Hersteller von Cluster-Dateisystemen haben selber Benchmarks mit ihren eigenen
Produkten durchgeführt und teilweise mit anderen Cluster-Dateisystemen verglichen
([CLUb], [IBMb]). So stellt es sich in den Ergebnissen der Hersteller dar, dass das Produkt
aus dem eigenen Haus am besten abschneidet. Um einen unabhängigen Vergleich durchzu-
führen, sollten alle Produkte jedoch auf der selben Hardware und unter dem selben Betriebs-
system getestet werden.

2
Diese Arbeit untersucht das Parallel Virtual File System 2 (PVFS2) [PVFS2a], das Oracle
Cluster File System (OCFS) [ORAa], das Red Hat Global File System (GFS) [REDa], das
IBM General Parallel File System (GPFS) [IBMa] und Lustre von Cluster File Systems
[CLUa].
1.2 Vorgehensweise
Die Arbeit gliedert sich im Weiteren wie folgt. Kapitel zwei gibt einen Überblick über die
wichtigsten Cluster-Dateisysteme; der Schwerpunkt liegt hier auf frei verfügbaren Dateisys-
temen. Des Weiteren werden geeignete Effizienzkriterien zur Beurteilung solcher Dateisys-
teme in einer Cluster-Umgebung festgelegt und Strategien zur Messung dieser Kriterien
entwickelt (Kapitel drei). Ein entsprechendes Benchmark-Programm wird hierfür in Kapitel
vier konzipiert und umgesetzt. Außerdem wird in diesem Kapitel die Testumgebung vorge-
stellt. Kapitel fünf präsentiert und diskutiert die Ergebnisse des Benchmark-Programms.
Darauf aufbauend gibt das Fazit der Arbeit Empfehlungen für den Einsatz der verschiedenen
Produkte.
1.3 Abgrenzung
Diese Arbeit untersucht nicht die speziellen Funktionen, die jedes Produkt mit sich bringt,
wie z. B. die Replikation bei dem Cluster-Dateisystem GPFS. Da diese Funktionen nicht in
allen Produkten enthalten sind, können sie deswegen nicht miteinander verglichen werden.
Ferner nennt diese Arbeit zwar die speziellen Schnittstellen der Cluster-Dateisysteme (siehe
Kapitel 2.3.7), die eine Optimierung von Zugriffen ermöglichen, untersucht sie aber nicht
weiter, da nicht jedes Cluster-Dateisystem diese Schnittstellen unterstützt.
Auch stellt diese Arbeit keine Installationsanleitung für die Cluster-Dateisysteme dar. Kapi-
tel 4.2.3 gibt eine kurze Darstellung über die verwendeten Parameter bei der Testdurchfüh-
rung.

3
2
Dateisysteme für Parallelrechner-Cluster
Dieses Kapitel definiert zunächst Begriffe und stellt die Bedeutung und Notwendigkeit von
Cluster-Dateisystemen dar. Des Weiteren beschreibt es die unterschiedlichen Architekturen
von Cluster-Dateisystemen und gibt eine technische Übersicht der evaluierten Produkte.
2.1 Begriffsdefinitionen
und
Bedeutung
2.1.1 Cluster
Ein Cluster ist ein paralleler Computer, der aus handelsüblichen, nicht speziell angefertigten,
Komponenten besteht und ebenso ein handelsübliches Betriebssystem fährt. Ein einzelner
Computer in einem Cluster wird als Knoten bezeichnet. Ein Knoten kann ein oder mehrere
Prozessoren beinhalten und der lokale Speicher wird gemeinsam von allen Prozessoren des
Knotens benutzt. Außerdem kann an einen Knoten Peripherie angeschlossen sein (z. B. Fest-
platten). Die Knoten sind untereinander durch ein Netzwerk verbunden, das es erlaubt, Daten
auszutauschen [Gro03]. Dabei können die einzelnen Knoten eines Clusters durchaus hetero-
gen sein, d. h. die Hard- und Softwarekomponenten können von unterschiedlichen Herstel-
lern und unterschiedlicher Leistung sein.
Cluster dienen den Anwendungsfällen, die eine hohe Leistungsfähigkeit an ein Computersys-
tem stellen, können aber auch bei einem hohen Anspruch an Verfügbarkeit eingesetzt wer-
den. Durch die Auslegung für eine hohe Fehlertoleranz stellt ein Cluster sicher, dass ein
System für einen Benutzer verfügbar ist [Gro03].
Die Problematik bei einem Cluster liegt in der Verteilung einer Anwendung auf verschiede-
ne Knoten [Sum02]. Dadurch ist es schwierig, bestimmte Ressourcen (z. B. ein Dateisystem)
gemeinsam zu nutzen. Ohne ein gemeinsames Dateisystem müssen die zu bearbeitenden
Daten jedoch auf andere Weise organisiert werden. Ein Anwendungsfall ohne ein gemein-
sames Dateisystem ist z. B. der Folgende: bestimmte Daten, die ein Knoten für seine Be-
rechnung benötigt, liegen lokal auf seiner Festplatte. Eine solche Organisation der Daten
verursacht jedoch einen hohen administrativen Aufwand [Bau06]. Durch die Notwendigkeit,
die für die Berechnung benötigten Daten auf alle Knoten zu replizieren und die geschriebe-
nen Ergebnisse von dort abzurufen, entsteht ein hoher administrativer Aufwand, der sich
letztendlich auf die Leistung und Zuverlässigkeit des Clusters auswirken kann.

4
2.1.2 Cluster-Dateisystem
Ein paralleles Dateisystem erfüllt dieselben Aufgaben wie ein lokales Dateisystem; es ver-
waltet Daten auf der Speicherhardware (z. B. Festplatte) und präsentiert diese als Verzeich-
nishierarchie. Zudem gewährleistet es den Zugriff auf Dateien und Verzeichnisse in konsis-
tenter Form [Gro03]. Verglichen mit einem lokalen Dateisystem beschäftigen sich die Ent-
wickler eines parallelen Dateisystems mit der Frage, wie eine große Anzahl an Prozessen auf
unterschiedlichen Rechnern auf dieselben Dateien gleichzeitig und effizient zugreifen kann
[May01].
Ein Cluster-Dateisystem ist ein paralleles Dateisystem, welches auf einem Cluster läuft und
mit Heterogenität in Hard- und Software umgehen kann [May01]. Es bietet eine transparente
Sicht für alle Nutzer des Dateisystems, was bedeutet, dass jeder Knoten auf dieselben Daten
zugreifen kann. Änderungen an den Daten sind direkt für alle Benutzer des Dateisystems
sichtbar und es bietet sich dadurch eine bequeme Sicht auf den gemeinsamen Datenbestand.
Ein umständliches Kopieren der Daten auf die Knoten, wie vorher geschildert, ist somit nicht
erforderlich. Um zu vermeiden, dass durch den Ausfall eines einzigen Knotens das komplet-
te Dateisystem nicht mehr verfügbar ist, sollte ein gewisses Maß an Redundanz unterstützt
werden. Durch die Verteilung der Daten auf verschiedene Knoten skaliert, bei einem guten
Design, ein Cluster-Dateisystem besonders gut. Dies bedeutet, dass bei steigender Client-
Zahl jeder Knoten die Daten weiterhin effizient lesen und schreiben kann [Bau06]. Eine Ab-
grenzung von Cluster-Dateisystemen gegenüber Netzwerkdateisystemen (z. B. das Network
File System [Ste95]), ergibt sich dadurch, dass Letztere weder im Stande sind, effizient mit
steigender Anzahl an Clients zu skalieren, noch mit mehreren Servern verwendet werden
können [Cop05], [Car00].
2.1.3 Datei-intensive
Anwendungen
Es existieren drei Arten von Datei-intensiven Anwendungen, die ein schnelles Input-Output-
System (I/O) benötigen und damit von einem performanten Cluster-Dateisystem profitieren
würden: wissenschaftliche Simulationen, Multimedia-Applikationen und Datenbank Mana-
gement Systeme [Sum02]. Diese Anwendungen haben im Wesentlichen zwei bedeutende
Anforderungen an ein Dateisystem, auf das sie lesend und schreibend zugreifen: hohe Ge-
schwindigkeit und große Speicherkapazität. Weitere Anforderungen sind Datenintegrität und
Verfügbarkeit. Die Geschwindigkeit setzt sich aus der Transferrate und der Zugriffszeit zu-
sammen. Ausschlaggebend für parallele Anwendungen ist jedoch hauptsächlich die Trans-
ferrate des Dateisystems [May01]. Solche Anwendungen würden damit sehr stark von einem
leistungsfähigen Cluster-Dateisystem profitieren.

5
2.2 Architekturen
von
Cluster-Dateisystemen
Dieses Kapitel nennt und beschreibt die Architekturen für Cluster-Dateisysteme. Nach
[Gro03] lassen sich die Architekturen in ,,Shared Storage" und ,,Intelligente Server" auftei-
len.
2.2.1 Shared
Storage
Die erste Kategorie bildet die Architektur mit Zugriff auf gemeinsam genutzte Speicher-
hardware (engl. shared storage). Häufig findet diese ihren Einsatz in Produktionsumgebun-
gen, z. B. in Storage Area Networks, da diese sehr populär sind [Gro03]. Die Gemeinsamkeit
solcher Dateisysteme ist der entfernte Zugriff auf blockorientierte Geräte. Dies erfolgt ent-
weder durch direkt angeschlossene Hardware (z. B. fibre-channel-Festplatten) oder durch
zwischengeschaltete I/O-Server, die eine blockorientierte Schnittstelle zu ihren lokalen Fest-
platten anbieten. In beiden Fällen ist eine Schlüsselkomponente das Subsystem für die Sper-
rung von Dateien [Gro03]. Das Sperren von Dateien ist notwendig, um den Zugriff von ver-
schiedenen Knoten auf die gemeinsame Komponente zu koordinieren.
Einige dieser Dateisysteme benutzen ein virtuelles blockorientiertes Gerät, um den Zugriff
auf die logischen Blocks von den physikalischen zu abstrahieren. Das virtuelle blockorien-
tierte Gerät ermöglicht es außerdem einen Mechanismus zu etablieren, der ein Hinzufügen
und Entfernen von Festplatten während des laufenden Betriebs zulässt. Damit kann das Da-
teisystem bei Bedarf wachsen, ohne die bestehenden Dateien zu sichern und nach der Erwei-
terung neu aufzuspielen. Allerdings bringt dieser Komfort auch Nachteile mit sich: bei jeder
Anfrage an das Dateisystem muss eine Übersetzung zwischen der logischen und der physika-
lischen Schicht durchgeführt werden, was zusätzlichen Aufwand bedeutet. Red Hats GFS
beispielsweise benutzt ein solches virtuelles blockorientiertes Gerät [Gro03].
2.2.2 Intelligente
Server
Die zweite Kategorie stellt die Architektur der intelligenten Server dar [Gro03]. Intelligenz
bedeutet in diesem Fall, dass die Server nicht bloß eine blockorientierte Schnittstelle zu
einem lokalen Speichergerät exportieren. Die Kommunikation zwischen Client und Server
erfolgt in der Regel mit Konstrukten auf höherer Ebene, z. B. mit Dateien oder Verzeichnisse
anstatt mit einfachen Blöcken. Intelligente Server haben außerdem Kenntnis darüber, dass
die Daten, die sie speichern, zu einer bestimmten Dateisystem-Entität gehören (z. B. eine
Datei oder ein Verzeichnis) und nicht einfach nur beliebige Blöcke auf einem Speichergerät
sind. Dadurch können sie komplexe, strukturierte Anfragen annehmen. In dieser Architektur
werden außerdem Metadaten und Daten häufig voneinander getrennt. Diese Trennung er-

6
laubt eine hohe Flexibilität, da sich Operationen auf Metadaten und Daten auf unterschiedli-
che Server verteilen lassen. Verteilte Behandlung von Metadaten ist kompliziert, weswegen
einige Systeme nur einen einzigen Metadaten-Server unterstützen. Diese Beschränkung kann
jedoch bei hoher Last auf dem Metadaten-Server ein potentieller Flaschenhals des Cluster-
Dateisystems sein. PVFS und Lustre sind Systeme mit einer solchen Architektur [Gro03].
2.3 Technische
Übersicht
Dieses Kapitel stellt zunächst die untersuchten Cluster-Dateisysteme und zwei weitere vor.
Eine Zusammenstellung von Cluster-Dateisystemen ist auf dieser Webseite [BER] zu finden.
Weiterhin präsentiert es Techniken zur Optimierung von Zugriffen, die einige Produkte an-
bieten, in dieser Arbeit aber nicht verwendet werden.
Da bestimmte Begriffe bei allen Cluster-Dateisystemen auftauchen, werden sie an dieser
Stelle erläutert: Ein Metadaten-Server hat die Aufgabe Informationen zu allen Dateien des
Cluster-Dateisystems zu speichern und ist außerdem für die Operationen bezüglich des Na-
mensraums, Verzeichnis-Layouts und Zugriffsrechte für jedes Objekt (Datei oder Verzeich-
nis) zuständig [Gro03]. Ein I/O-Server nutzt einen Partition oder eine gesamte Festplatte als
Speicherplatz für das Cluster-Dateisystem und speichert im Gegensatz zum Metadaten-
Server den eigentlichen Inhalt der Dateien.
2.3.1
Parallel Virtual File System 2
PVFS2 gehört zu den Produkten der Architektur mit intelligenten Servern [Gro03]. PVFS2
ist ein gemeinsames Projekt zwischen dem Parallel Architecture Research Laboratory der
Clemson University und dem Mathematics and Computer Science Division am Argonne
National Laboratory.
Das Cluster-Dateisystem PVFS2 bildet sich durch einen oder mehrere Metadaten-Server,
mehrere I/O-Server und den Clients, die das Dateisystem benutzen. In PVFS2 kann ein Kno-
ten sowohl die Aufgabe des Metadaten-Servers als auch die Aufgabe des I/O-Servers über-
nehmen. Daten werden nach einem Round-Robin Verfahren über die verschiedenen I/O-
Server verteilt. Durch dieses einfache Verfahren lässt sich leicht berechnen, welcher I/O-
Server welchen Teil einer Datei hält [Gro03].
PVFS2 unterstützt keine redundante Auslegung von Daten. Fällt ein einziger I/O-Server aus,
ist das Dateisystem nicht mehr erreichbar. Deswegen besteht hier die Notwendigkeit, den
Ausfall einer Festplatte über ein Sicherungskonzept (z. B. über eine RAID-Spiegelung der

7
Festplatten) abzufangen. Ebenso verhält es sich mit dem Metadaten-Server. Ist dieser nicht
erreichbar, ist kein Zugriff auf das Cluster-Dateisystem möglich [Gro03].
PVFS2 unterstützt nicht die POSIX-Semantik, sondern eine Semantik, die von den Entwick-
lern ,,non-conflicting write semantic" [PVFS2b] genannt wird. Die POSIX-Semantik bei
Dateioperationen stellt folgendes Verhalten sicher: wenn ein Prozess lesend auf einen be-
stimmten Dateibereich zugreift und dieser im selben Moment von einem anderen Prozess
überschrieben wird, dann soll der lesende Prozess entweder alle Änderungen oder keine se-
hen. Die ,,non-conflicting write semantic" besagt, dass alle I/O-Operationen, die nicht auf
den selben Datenbereich zugreifen, konsistent sind. Schreibende Operationen, die zueinander
in Konflikt stehen, enden in einem undefinierten Zustand. Lesende Operationen, die in Kon-
flikt mit schreibenden Operationen stehen, enden in einem undefinierten Zustand zwischen
den alten, bereits eingelesenen, und den neu geschriebenen Daten [PVFS2b]. Eine Sperrung
von Dateien nimmt PVFS2 somit nicht vor.
Ein wichtiger Bestandteil dieses Cluster-Dateisystems ist eine Abstraktionsschicht, die eine
Einbindung von verschiedenen Netzwerktypen ermöglicht. Diese Schicht nennt sich ,,Buffe-
red Message Interface". Ein anderer Netzwerktyp kann einfach über diese Schnittstelle ein-
gebunden werden. Neben der Implementierung von TCP/IP existieren noch Weitere für My-
ricom GM und Infiniband [PVFS2b].
Der Benutzer kann auf unterschiedliche Art und Weise auf das Cluster-Dateisystem PVFS2
zugreifen. Die erste Möglichkeit besteht darin, ein Kernel-Modul zu erstellen und zu laden.
Mit diesem Modul kann der PVFS2-Client in Verbindung mit den I/O-Servern treten. Das
Cluster-Dateisystem kann so wie ein lokales Dateisystem in den Verzeichnisbaum eingebun-
den und benutzt werden. Auf diese Weise können die bereits existierenden Anwendungen
ohne Anpassung das Cluster-Dateisystem benutzen. Des Weiteren besteht die Möglichkeit,
über die MPI-IO-Schnittstelle auf das Dateisystem zuzugreifen [PVFS2b]. MPI-IO ist die
Standard-Schnittstelle für parallele Ein- und Ausgabe und Teil der MPI-2-
Schnittstellendefintion (Message Passing Interface) [Gro03]. Jedoch müssen zu Verwendung
dieser Schnittstelle die bestehenden Anwendungen, die nicht die MPI-IO-Schnittstelle be-
nutzen, umgeschrieben werden.
Das Cluster-Dateisystem PVFS2 lässt sich nur dann um weitere I/O-Server erweitern, wenn
die Clients das Dateisystem nicht benutzen und die Serversoftware abgeschaltet ist. Ein Hin-
zufügen neuer I/O-Server funktioniert auch ohne den bereits vorhandenen Datenbestand zu
entfernen. Jedoch bleiben diese Daten nur auf den bisherigen I/O-Servern gespeichert. Denn

8
es findet keine automatische Neuverteilung auf alle I/O-Server statt. Neu geschriebene
Dateien hingegen werden automatisch auf die neue Server-Struktur verteilt [PVFS2c].
Jedoch ist das Entfernen eines I/O-Servers aufwändig; da aufgrund des eingesetzten Round-
Robin Verfahrens Dateien auf allen I/O-Servern verteilt liegen, muss der komplette Dateibe-
stand des Cluster-Dateisystems zunächst gesichert werden. Nachdem der I/O-Server entfernt
ist, kann der Dateibestand wieder auf das PVFS2-Dateisystem kopiert werden.
2.3.2 Lustre
Auch Lustre von dem Unternehmen Cluster File Systems gehört zu der Kategorie der intelli-
genten Server [Gro03]. Ebenso wie beim vorher beschriebenen PVFS2 teilen sich die betei-
ligten Komponenten von Lustre in drei Teile auf: Clients, Metadaten-Server und ,,Object
Storage Server". Die ,,Object Storage Server" übernehmen die eigentliche Speicherung der
Daten und stellen damit die I/O-Server dar. Ein ,,Object Storage Server" kann ein oder meh-
rere ,,Object Storage Targets" anbieten, was eine Software-Schnittstelle zu einer exportieren
Partition oder kompletten Festplatte ist. Die Komponente ,,Object Storage Target" bietet
damit einen Speicherplatz für Dateisystem-Objekte an [CLUc].
Lustre unterstützt die Verteilung der Daten auf verschiedene I/O-Server in Form des RAID-
Levels Null, wodurch es keine redundanten Informationen schreibt. Die Größe der zu vertei-
lenden Stücke kann als beliebiges Vielfaches von sechszehn Kilobyte eingestellt werden. Bei
einem Ausfall einer einzigen Serverkomponente fällt damit aber auch das komplette Cluster-
Dateisystem aus. Deswegen unterstützt Lustre eine Ausfallsicherung für die Metadaten- und
I/O-Server, die automatisch bei einem Fehlerfall auf einen Standby-Server umschaltet.
Jedoch benötigt es für diesen Dienst ein Server-Paar, welches an gemeinsame Speicherhard-
ware angeschlossen ist, um das nahtlose Umschalten zu ermöglichen [CLUc].
Die Dateisystemkonsistenz von Lustre wird durch den Distributed Lock Manager (DLM)
gewährleistet. Das Design von Lustres DLM ist stark an das Design von IBMs VAX Clusters
DLM angelehnt und hat einige Erweiterungen zu diesem [Sch03]. Mit Lustre kann auf Da-
teiebene ein Bereich für die Sperre gesetzt werden, so dass hier mehrere Clients gleichzeitig
unterschiedliche Teile einer Datei schreiben können.
Die Netzwerk-Schicht von Lustre baut auf dem Message-Passing Paket Portals auf. Durch
eine Abstraktionsschicht, dem Network Abstraction Layer von Portals, unterstützt Lustre wie
PVFS2 zahlreiche Netzwerktypen. Beispiele hierfür sind TCP/IP, Quadrics Elan 3, Myrinet
und SCI [Sch03].

9
2.3.3
Oracle Cluster File System 2
Das Cluster-Dateisystem von Oracle in der Version zwei kann im Gegensatz zur ersten Ver-
sion als universelles Dateisystem eingesetzt werden. Mit der ersten Version war das Einsatz-
gebiet auf die Cluster-Datenbanken von Oracle beschränkt [ORAb]. OCFS2 ist seit der Ker-
nel-Version 2.6.16 ein fester Bestandteil des Linux-Kernels [LIN]. Jedoch ist es lediglich für
eine Einsatzumgebung vorgesehen, in der alle Cluster-Knoten Zugriff auf ein gemeinsames
Speichergerät haben [ORAb]. OCFS2 bringt demnach selber keine Möglichkeit mit, block-
orientierte Geräte von Knoten zu exportieren, um das Cluster-Dateisystem darauf aufzu-
bauen. Deswegen fällt es bei der weiteren Untersuchung heraus.
2.3.4
General Parallel File System
Das General Parallel File System von IBM gehört zu der Gruppe der Produkte, die für eine
Umgebung mit Zugriff auf gemeinsame Speichergeräte konzipiert sind. Jedoch bietet es
ebenso die Möglichkeit einzelne Festplatten oder Partitionen, die an I/O-Server angeschlos-
sen sind, über eine Software im Netzwerk anzubieten. Für das Betriebssystem AIX und mit
spezieller Hardware heißt die Software-Schicht Virtual Shared Disk (VSD) [Sch02]. Für
Linux gibt es eine ähnliche Variante, die Network Shared Disk (NSD), die keine spezielle
Hardware benötigt. Die Komponenten VSD oder NSD übernehmen dabei kein Logical Vo-
lume Management [Kof06], sondern stellen nur ein Application Programming Interface
(API) zur Verfügung, um den Zugriff auf die Geräte zu ermöglichen. Dadurch kann das
Cluster-Dateisystem GPFS direkt Einfluss auf die Verteilung der Dateien über die exportier-
ten Geräte nehmen sowie die Fehlertoleranz selber regeln. Denn GPFS bietet als einziges
Produkt in diesem Test eine Daten- und Metadaten-Replikation an [Gro03]. Wenn die Repli-
kation aktiviert ist, belegt das Dateisystem Platz für zwei Kopien einer Datei auf unter-
schiedlichen Geräten sowohl für Daten als auch für Metadaten. Dadurch lässt sich der Weg-
fall von Festplatten oder ganzen Knoten abfangen [Sch02]. Die Replikation wirkt sich jedoch
auf die Leistungsfähigkeit aus, da das Kopieren über die Software geregelt wird und über das
Netzwerk übertragen werden muss.
Die maximale Größe einer einzelnen Festplatte, die in das Cluster-Dateisystem eingebunden
werden kann, beträgt zwei Terabyte und die Anzahl an Festplatten höchstens 4096. Aus die-
sen Werten errechnet sich die maximale Dateisystemgröße von acht Petabyte. Als größte
unterstützte Dateianzahl wird 2
31
-1 angeben [IBMc].
Das Cluster-Dateisystem von IBM versucht Zugriffsmuster von Anwendungen automatisch
zu erkennen und diese zu optimieren. Folgende Muster gehören dazu: sequentiell, rückwärts

10
sequentiell und verschiedene Formen von schrittweisem Zugriffsmuster (engl. strided
accesspattern). Für Anwendungen, die ein anderes Muster aufweisen, bietet GPFS eine
Schnittstelle an, um Hinweise an das Cluster-Dateisystem zu geben, damit auch solche Zu-
griffe gut unterstützt werden können [Sch02].
GPFS implementiert die POSIX-Semantik für Operationen im Cluster-Dateisystem [Gro03].
Dafür wird sowohl das verteilte als auch das zentralisierte Sperren von Dateien verwendet.
Verteiltes Sperren ermöglicht eine größere Parallelität, sofern verschiedene Knoten auf un-
terschiedlichen Bereichen in einer Datei arbeiten. Vom zentralisierten Sperren wird dann erst
Gebrauch gemacht, wenn sich Daten und Metadaten häufig ändern, da der Kommunikations-
Overhead bei verteiltem Sperren zu groß wäre. Um die Anfragen von verschiedenen Anwen-
dungen so gut wie möglich zu unterstützen, verwendet GPFS beide Mechanismen [Sch02].
GPFS ist das einzige Cluster-Dateisystem in dieser Arbeit, das nicht frei verfügbar und kein
Open-Source Produkt ist. Im Rahmen dieser Arbeit wird die Version 2.3 [IBMa] evaluiert.
2.3.5 Global
File
System
Das Global File System hat seinen Ursprung an der University of Minnesota, wurde dann
von dem Unternehmen Sistina weiterentwickelt und schließlich von Red Hat übernommen.
Bei Red Hat steht es jetzt unter der GNU Public License, und der Quellcode ist frei verfüg-
bar. Es gehört zur Familie der Architekturen, deren Knoten Zugriff auf gemeinsame Spei-
chergeräte haben [Gro03], [REDa].
Wie bei IBMs Cluster-Dateisystem gibt es auch bei GFS eine Software-Schicht, die ein
blockorientiertes Gerät in ein Netzwerk exportieren kann. Mittels GFS kann ein Dateisystem
über mehrere solcher exportierter Geräte aufgespannt werden. Die Software-Schicht zum
Exportieren nennt sich in diesem Fall Global Network Block Device (GNBD). Um die ex-
portierten Geräte zu einem gemeinsamen Dateisystem zu verbinden, benötigt GFS einen
Logical Volume Manager. In der Version 6.1 von GFS findet dafür der im Linux-Kernel
enthaltene Logical Volume Manager 2 (LVM2) [Kof06] zusammen mit der eigenen Kompo-
nente namens Cluster Logical Volume Manager (CLVM) Verwendung. LVM2 aggregiert
die exportierten Geräte zu einem großen logischen Datenträger, und CLVM verteilt die In-
formationen über den erstellten Datenträger an alle Clients im Cluster. CLVM ist damit eine
Cluster-weite Implementierung von LVM, welche es ermöglicht, den selben logischen
Datenträger auf allen Knoten im Cluster zu benutzen [Kee04].

11
Jedoch gibt es bei der Benutzung der exportierten Geräte eine wesentliche Einschränkung:
Ein GNBD-Server sollte die exportierten Geräte laut Dokumentation [REDb] nicht selber
benutzen. Es gibt zwar die Möglichkeit, das exportierte Gerät wieder zu importieren, jedoch
muss, um die Dateikonsistenz zu bewahren, der Cache deaktiviert werden [Kee04]. Mit einer
solchen Konfiguration leidet die Leistung von GFS sehr stark, so dass eine derartige Ver-
wendung nicht empfohlen wird. Im Test kann GFS deswegen nur in Verbindung mit dedi-
zierten GNBD-Servern verwenden werden, die selber nicht als Clients fungieren.
Bei der Einrichtung von GFS kann zwischen zwei verschiedenen Mechanismen zur Datei-
sperre gewählt werden. Eine Möglichkeit ist die Verwendung des Grand Unified Lock Ma-
nagers. Bei diesem Mechanismus muss ein dedizierter Rechner als Sperren-Server dienen.
Die zweite Möglichkeit bildet ab der GFS Version 6.1 der Distributed Lock Manager
(DLM), der verteiltes Sperren implementiert und deswegen keinen dedizierten Sperren-
Server benötigt. Red Hat empfiehlt die Verwendung des DLM [REDb].
Die maximale Dateisystemgröße von GFS mit allen exportierten Geräten beträgt acht Tera-
byte. Falls ein größeres Dateisystem nötig ist, muss ein zweites, vom ersten unabhängiges
Dateisystem aufgebaut werden. Dies bedeutet jedoch, dass es keine globale Datensicht auf
die unabhängigen Dateisysteme gibt [REDb].
2.3.6 Weitere
Cluster-Dateisysteme
Die Literatur erwähnt noch weitere Dateisysteme, die im Rahmen dieser Arbeit nicht näher
untersucht werden. Dieses Unterkapitel stellt beispielhaft zwei Cluster-Dateisysteme kurz
vor.
xFS ist ein an der Berkeley University entwickeltes Dateisystem. Es verteilt die Dateien über
Stripe-Gruppen, und jede solche Gruppe bildet eine Software-kontrollierte RAID-Einheit.
Vorteilhaft ist die Tatsache, dass durch das RAID eine Datei nicht korrupt wird, wenn ein
einzelner Knoten ausfällt. Es gibt keine dedizierten I/O-Server, sondern die Datei-
Management-Software läuft auf allen Rechenknoten im Cluster [May01]. Der Quelltext ist
auf der Webseite [XFS] verfügbar. Allerdings ist das letzte Release auf September 1997
datiert. Das Projekt scheint somit nicht mehr weiterentwickelt worden zu sein.
Ein weiteres Dateisystem nach der Architektur mit intelligenten Servern ist das Galley Da-
teisystem, das Mitte der 90er entwickelt wurde. Dieses Dateisystem war dafür gedacht,
Dateistrukturen und Anwendungsschnittstellen für parallele Ein- und Ausgabe zu erforschen.
Jedoch mangelt es an administrativen Programmen und einem Kernel-Modul für Unix, um

12
das Cluster-Dateisystem in den Verzeichnisbaum einzubinden. Dadurch ist es für einen pro-
duktiven Einsatz unbrauchbar. Jedoch ist es ein sehr gutes Beispiel für ein frühes Cluster-
Dateisystem mit intelligenten Servern [Gro03]. Der Quellcode ist immer noch auf der Web-
seite [GAL] verfügbar.
2.3.7
Techniken zur Optimierung von Zugriffen
Um sowohl kleine als auch große Zugriffe zu unterstützen, haben Entwickler von Dateisys-
temen Techniken entwickelt, die entweder direkt im Dateisystem integriert sind oder in einer
Software-Schicht zwischen der Applikation und dem Dateisystem liegen. In beiden Fällen
wird diese Schicht ,,I/O-Software" genannt. Sie lässt sich in drei Kategorien einteilen: unzu-
sammenhängende Anfragen (engl. discontiguous requests), kollektives I/O (engl. collective
I/O) und adaptive Methoden (engl. adaptive methods). Unzusammenhängende Zugriffe lesen
und schreiben unterschiedliche Teile einer Datei in einer Anfrage. Kollektives I/O behandelt
mehrere Anfragen von unterschiedlichen Rechnern als einzelne Operation. Über die adaptive
Methode wird entweder der I/O-Software mitgeteilt, welche Zugriffe zu erwarten sind, oder
sie versucht es automatisch festzustellen, um den Zugriff dahingehend zu optimieren. Alle
diese Techniken erfordern eine spezielle I/O-Schnittstelle, die sich von der Standard Unix
I/O-Schnittstelle unterscheidet [May01]. Einige der Cluster-Dateisysteme unterstützen diese
Techniken zur Optimierung, die im Folgenden erläutert werden.
PVFS2 unterstützt neben der UNIX I/O-Schnittstelle auch die MPI-IO-Schnittstelle. Es fehlt
jedoch die Unterstützung für einige Funktionalitäten von MPI-IO [PVFS2b].
GPFS handelt nach der adaptiven Methode und versucht selbstständig, Zugriffsmuster von
Anwendungen zu erkennen und daraufhin zu optimieren [IBMd]. Gelingt eine automatische
Erkennung jedoch nicht, gibt es für den Entwickler von Anwendungen eine Möglichkeit,
Hinweise auf das Zugriffsmuster an GPFS weiterzugeben. Beispielsweise kann ein Entwick-
ler den Bereich des Zugriffs über eine C-Struktur namens ,,gpfsAccessRange_t" angeben. In
dieser Struktur kann auch der Hinweis gegeben werden, ob es ein lesender oder schreibender
Zugriff ist. Um diese zusätzlichen Funktionen zu verwenden, bindet ein Entwickler die Bi-
bliothek ,,libgpfs" in die Anwendung mit ein.
GFS und Lustre bieten laut Dokumentationen ([REDb], [CLUc]) keine Möglichkeiten für
einen Eingriff von außen bzw. der Einflussnahme seitens des Entwicklers einer Anwendung.
Um keines der Cluster-Dateisysteme zu bevorzugen und eine Vergleichbarkeit aller Produkte
zu gewährleisten, verwendet das entwickelte Benchmark-Programm (siehe Kapitel 4.1.3)
Ende der Leseprobe aus 83 Seiten

Details

Titel
Evaluierung von Cluster-Dateisystemen für den Einsatz auf Parallelrechnern
Hochschule
Fachhochschule Bonn-Rhein-Sieg
Note
1
Autor
Jahr
2006
Seiten
83
Katalognummer
V186219
ISBN (eBook)
9783869438450
ISBN (Buch)
9783867469371
Dateigröße
971 KB
Sprache
Deutsch
Schlagworte
evaluierung, cluster-dateisystemen, einsatz, parallelrechnern
Arbeit zitieren
Ace Crngarov (Autor:in), 2006, Evaluierung von Cluster-Dateisystemen für den Einsatz auf Parallelrechnern, München, GRIN Verlag, https://www.grin.com/document/186219

Kommentare

  • Noch keine Kommentare.
Blick ins Buch
Titel: Evaluierung von Cluster-Dateisystemen für den Einsatz auf Parallelrechnern



Ihre Arbeit hochladen

Ihre Hausarbeit / Abschlussarbeit:

- Publikation als eBook und Buch
- Hohes Honorar auf die Verkäufe
- Für Sie komplett kostenlos – mit ISBN
- Es dauert nur 5 Minuten
- Jede Arbeit findet Leser

Kostenlos Autor werden