HPC Cluster Storage

Aufbau von HPCC Storage
Seit vielen Jahren wird Cluster Storage als nachgeordnete Design-Komponente beim Entwurf von Clustern angesehen. Im Laufe der Zeit ist die Rolle des HPC Cluster Storage (HPCC) mit der Potenzierung der Datenmengen stark gewachsen und wird als Kernkomponente bei der Gestaltung von Clustern von Anfang an konzeptionell berücksichtigt. Für einfache und kleinere Cluster sind die Speicher-Konzepte noch relativ einfach. Für größere oder komplexere Systeme, kann die Komplexität der Speicherkonzeption vergleichbar zu anderen Clusterkomponenten sein, oder diese übertreffen.

Cluster benötigen fast immer ein „Shared File System“, welches den Knoten Zugriff auf gemeinsame Bereiche und Dateien ermöglicht. Ein Lese- und Schreibzugriff von mehreren Knoten auf die gleiche Datei kann bei unsachgemäßer Einrichtung gefährlich sein, ist aber möglich.

Ein Klassiker unter den Shared File Systemen ist das Network File System, auch Network File Service (NFS) genannt. NFS ist ein von Sun Microsystems entwickeltes Protokoll, welches den Zugriff auf entfernte (remote) Dateien über ein Netzwerk ermöglicht. Dateien werden dabei, anders als bei FTP, nicht zu den Rechnern der Anwender übertragen, der Zugriff auf Dateien entfernter Rechner erfolgt vielmehr so, als ob diese sich direkt auf lokalen Festplatten befinden würden. „Shared“ Filesysteme sind zentrale Bestandteile von Clustern. NFS ist ein weit verbreiteter Internet-Standard (RFC 1094, RFC 1813, RFC 3530).

Dem besseren Verständnis von HPCC Storage, kann folgende Skizze dienen:

Storage-Media sind Raidsysteme oder Raidserver mit Fiber-Channel-,Infiniband-, SAS-, iSCSI- oder Ethernet-Schnittstellen, welche mit File-Servern (I/O Nodes) über ein Storage-Netzwerk verbunden sind. Auf den Storage-Media sind die Daten abgespeichert, auf welche die Client-Rechner zugreifen. Aufgabe der I/O-Nodes ist es, Client-Rechnern die Dateisysteme der Storage-Media zur Verfügung zu stellen. I/O-Nodes werden über ein File-Server- bzw. I/O-Node-Netzwerk mit dem Client-Netzwerk verbunden. In fast allen Fällen, das gilt besonders für kleinere Cluster, werden das Storage- und I/O-Node-Netzwerk zu einem Netzwerk zusammengefasst. Clients werden über das Client-Netzwerk mit dem Daten-Netzwerk verbunden. In vielen Fällen sind Client- und Datennetzwerk zu einem Netzwerk zusammengefasst. Bei Einsatz eines parallelen Filesystems können sich Verzeichnisse und Dateien auf Clients und File-Servern (I/O-Knoten) verteilt befinden. Das Datei-System kommuniziert mit den Speichermedien über das Storage-Netzwerk.
Vorliegendes Beispiel beschreibt den Extremfall eines HPCC Storage, bei welchem fast alle möglichen "Bausteine" dieser Lösung eingesetzt worden sind. Die meisten Anwendungsfälle beschränken sich aber auf einen Subset der allgemeinen Lösung. Wenden wir uns deshalb einige, häufig eingesetzten Konfigurationen zu.

Network-File-System (NFS)
Eine Schlüsselfunktionalität, welche die Entwicklung von Clustern erst ermöglichte, ist das Network-File-System. NFS ist das einzige standardisierte „sharable“ Filesystem. Es ermöglicht verteilten Rechnern den Zugriff auf gemeinsame Daten, wodurch parallele Anwendungen die gleichen Dateien lesen und beschreiben zu können. Da NFS ein Standard ist, können Systeme mit unterschiedlichen Betriebssystemen, oder verschiedenen Versionen, mit dem gleichen Datenbestand arbeiten.

Anhand der oben beschriebenen HPCC-Storage-Skizze, können wir die Funktionsweise von NFS ziemlich einfach erklären. Das Storage-Netzwerk entspricht dem PCI-Bus der Daten-Server, welche, über Onboard- oder Zusatz-Controller, mit fest eingebauten oder Hot-Swap-fähigen HDD-Laufwerke verfügen. Obwohl es andere, komplexere Konfigurationen gibt, ist das die am weitest verbreitete. Für jedes bestimmte NFS-Dateisystem gibt es nur einen Daten-Server, der auch als Filer-Head bezeichnet wird. Häufig werden Head-Node und Daten-Server gemeinsam auf der selben physikalischen Hardware realisiert. sein. Der Daten-Server wird mit den Clients über das Daten-Netzwerk verbunden.

NFS wird seit langer Zeit für Workstations, Desktops, Server und Cluster eingesetzt und ist ein gut verstandenes Dateisystem, welches von vielen Anwendungen verwendet wird. Bisher wurden folgende Versionen veröffentlicht:

•     1980 - NFSv2 (UDP Daten-Transport-Protokoll)
•     1995 - NFSv3 (UDP + TCP Daten-Transport-Protokoll)
•     2003 - NFSv4 (zusätzliche Protokoll-Security-Mechanismen implementiert).

NFS leidet aber an einigen Einschränkungen, problematisch ist besonders, ein NFS-Dateisystem an einen einzelnen Servers gebunden ist. Das führt zu einem Flaschenhals, da der gesamte I/O-Verkehr der Client-Nodes über einen einzigen Server abgewickelt wird. Da der NFS-Server in vielen Fällen mit dem gleichen Link wie die Client-Nodes (Gbs oder 10 Gbs Ethernet, Infiniband, Myrinet, …) an dasselbe Cluster-Netzwerk angeschlossen sind, verschärft sich die Engpass-Situation. Die Situation wird allerdings etwas entschärft, weil entschärft, weil nicht alle Client-Nodes zur gleichen Zeit schreibend oder lesend auf das NFS-Filesystem zugreifen. Negativ ist allerdings ist aber, was oft vergessen wird, dass NFS Probleme hat, wenn mehrere Clients Gleichzeitig auf eine Datei zugreifen wollen. Das Problem wird durch zwischenzeitliches „Locking“ behoben, was aber zu Wartezeiten für nachfolgende Prozesse führt.

Da viele parallele Anwendungen über einen sogenannten "root"-Prozess (Rang 0-Prozess) verfügen, welcher alle I/O-Operationen für die Anwendung durchführt, wobei der über den ersten Knoten einer Knoten-Gruppe der gesamte i/O-Verkehr abgewickelt wird. Die Anzahl der Knoten, welche auf den NFS-Server zugreifen, ist somit kleiner als die Anzahl der Rechenknoten, weshalb NFS-Dateisysteme für Cluster mit einer angemessenen Größe gut einsetzbar sind. Obwohl NFS erfolgreich für Cluster von bis zu 300 Knoten eingesetzt wird, sollten bei Clustern mit mehr als 64-128 Knoten andere Dateisysteme eingesetzt werden.

Distributed Parallel-Storage
Für große Cluster, Cluster-Anwendungen mit einem hohen Bedarf an „shared“ I/O und Cluster mit hohen Anforderungen an Performance- und Kapazitäts-Skalierbarkeit sind parallele Dateisystem zwingend erforderlich ist.

Für Gegebenheiten, bei denen eine NFS-Lösung nicht ausreicht, ist ein verteiltes, paralleles Storage-System die erste Wahl, auch wenn die Komplexität solcher Systeme eine NFS-Implementierung bei weitem übersteigen kann.

Es werden nicht immer alle der in Skizze „HPCC Storage“ aufgeführten Komponenten eingesetzt, da das von der spezifischen Lösung abhängt. Der Sprung von NFS zum verteilten parallelen Dateisystem erfordert eine Vorausplanung und ggf. auch den Aufbau eines Testsystems, um alle Implikationen und Tuning-Aspekte zur Erzielung der optimalen Leistung zu verstehen.

Für die Implementierung verteilter paralleler Storage-Lösungen stehen zwei Anwendungsgruppen zur Verfügung:

Dateisysteme mit Block-basierter Speicherung

• IBRIX
• GPFS
• GFS
• GlusterFS
• Rapidscale
• EMC Highroad (MPFSi)
• SGI CXFS

Objekt-basierte Dateisysteme:

• FhFS
• Lustre
• Panasas
• PVFS

Da eine Darstellung des Aufbaus und der Diskussion der verschiedenen Vor-und Nachteile jeder einzelnen Lösung den Rahmen dieser Einführung sprengen würde, verweisen wir hier auf das Internet mit den Websites der jeweiligen Hersteller und http://www.clustermonkey.net/

Vor einer Entscheidung, welche Technologie oder Lösungen Sie einsetzen wollen, stellen Sie sich aber folgenden Fragen:

• •    Welches Ziel verfolge ich beim Einsatz/Verwendung eines parallelen Dateisystems? Geht es um
  • höhere Leistung?
  • skalierbare Kapazität?
  • Zentralisierung der Storage-Lösung für mehrere Cluster?
• Gibt es ausreichende Systemerfahrung mit verteilten, parallelen Storage-Lösungen?
• Welche Anwendungen kommen zum Einsatz und wie sehen die jeweiligen I/O-Muster aus?
• Welche Anfangskapazität soll implementiert werden und wie schnell wird die Kapazität anwachsen?
• Wie soll die Datensicherung (Backup) erfolgen? Gibt es Implementierungen, welche ohne Backup auskommen?
• Könnte ein Hierarchical-Storage-Management (HSM) Teil der Storage-Lösung sein?
• Was sind meine Anforderungen an Disaster Recovery?
• Wie viele Administratoren kann für die Verwaltung der Storage-Lösung abstellen?
• Zusätzlich zum Kaufpreis muss folgendes feststehen:
  • Wie hoch sind die Anschaffungskosten? Sind Installation und ggf. Ausbildung enthalten?
  • Was ist meine Kosten für Speichererweiterungen?
  • Sind Speichererweiterungen ohne Ausfallzeiten für das laufende System möglich?
  • Wie hoch sind die jährlichen Wartungskosten und welche  und wie viel Unterstützungsleistung ist im Preis enthalten?
  • Welche Art von Netzwerk soll implementieren werden? Wie passt der neue Speicher zu diesem Netzwerk?
  • Welche Anforderungen zur Speicherung von Notfall-Daten an anderen Orten bestehen (Off-Site-Daten für Notfälle)?
  • Wie soll die Übernahme bestehender Daten auf das neue System erfolgen? Welchen Zeitrahmen wird die Übertragung einnehmen? Wie viel Zeit steht zur Datenübernahme zur Verfügung?
• Wie viele Anwender werden mit dem neuen System arbeiten? In welcher Umgebung laufen ihre Anwendungen und wie werden sie mit dem Storage-System interagieren?
• Sind Disk-Quotas erforderlich (Disk-Quotas sind Limits, welche durch den System-Administrator gesetzt werden, um bestimmte Nutzungsmöglichkeiten von File-Systemen moderner Operating-Systeme zu begrenzen)?
• Gibt es bestimmte Archivierung-Anforderungen seitens der Anwender?

Je nach Aufgabenstellung existieren unterschiedliche Antworten auf diese Fragen, Antworten die zur Auswahl der besten Speicherlösung(en) führen können. Mit einem erweiterten Verständnis über die eigenen Bedürfnisse und die Möglichkeiten, welche moderne „verteilte parallele File-Systeme“ bieten, sollte man vor einer Auswahl noch einmal folgende Prozesse gedanklich durchgehen:

• Quotas
• Verwendung von Scratch-Platz
• Backups
• Migration alter Dateien
• Datenrettung
• Archivierung
• Off-Site-Storage
• Disaster Recovery
• Migration von Daten von einer Storage-Plattform zu einer anderen

Im Rahmen dieser Überprüfung, sollte eine Aufnahme erfolgen, wie die existierenden Anwender ihre Arbeiten ausführen und wie der Storage zurzeit genutzt wird und wie die Arbeiten zukünftig durchgeführt werden sollen.