Parallele Dateisysteme

Für die verteilte und ausfallsichere Speicherung der Daten ist ein Netzwerk-Dateisystem nötig. Es ist leicht auf einem Raid zu installieren, was vor den Folgen von Plattenausfällen schützt. Ein solches paralleles Filesystem muss besonderen Ansprüchen genügen, denn in einem Cluster greifen im Ernstfall alle Knoten zugleich auf das Dateisystem zu.

Glücklicherweise ist Linux bereits mit Bordmitteln sehr gut für solche Anwendungszenarien gerüstet. Das in den Kernel integrierte Software-Raid-Subsystem [8] beherrscht die meisten Raid-Modi und steht auch bei der Leistung den meisten Hardwarelösungen wenig nach. Zudem lässt sich der im Pool verfügbare Speicher mit LVM2 [9] sogar dynamisch verwalten. Mit diesen beiden Werkzeugen lassen sich auf sehr preiswerte Art und Weise die Dateisystem-Knoten implementieren, die eine Grundlage für den Storage-Cluster liefern.

Die Auswahl an parallelen Dateisystemen unter Linux ist groß, denn es sind viele bereits in den Kernel integriert. Das bekannteste sollte wohl CIFS sein, das seit geraumer Zeit Cluster-fähig ist. Das von Red Hat freigegebene GFS2 (Global File System 2, [10]) ist ebenfalls direkt im Kernel enthalten und zudem bereits von Anfang an für den Einsatz in einem Cluster konzipiert.

Neben GFS2 gibt es noch OCFS2 (Oracle File System 2, [10]), das auch schon in aktuellen Linux-Kerneln integriert ist. Die beiden zuletzt genannten Dateisysteme waren vor ihrer Freigabe übrigens proprietär und teuer. Ein wirklich heißer Kandidat für ein besonders performantes und freies Cluster-Dateisystem ist das ab Kernelversion 2.6.34 enthaltene CEPH [11], das eine Forschungsgruppe programmiert hat.

Jobkontrolle

Wenn alle Knoten installiert, gebootet und überwacht sind, stellt sich die Frage, wer welche Programme auf dem Cluster ausführt und wie die Anfragen verschiedener Nutzer zu koordinieren sind. Die Software, die ein paralleles Programm auf einem Cluster startet, wird als Batchsystem oder Jobkontrolle bezeichnet. Solche Systeme [1] werden in zwei Kategorien eingeteilt: die Queue- und die Plan-basierten Systeme.

Der Fachjargon bezeichnet den Ausführungslauf eines Programms auf einem Cluster als Job. Der User muss dem Batchsystem mitteilen, wie viele Knoten er benötigt und ob es sich um einen Batch- oder einen interaktiven Job handelt. Liegt ein Batch-Job vor, braucht das System normalerweise noch ein Skript, das das Programm startet.

Queue-basierte Systeme sind die am weitesten verbreitete Art der Jobkontrolle auf Clustern. Anfragen für die Bereitstellung der gewünschten Ressourcen reihen sich hier in eine Warteschlange ein. Queue-Systeme arbeiten sie dann der Reihe nach anhand von Kriterien wie Größe, Priorität und Eingangszeit ab. Eines der ältesten Systeme ist das Portable Batch System, das die Nasa Mitte der 90er entwickelt hat. Als Open PBS [12] ist es quelloffen erhältlich. Viel gebräuchlicher ist aber heutzutage die ebenfalls freie Variante Torque [13].

Plan-basierte Systeme ermöglichen es dem Nutzer, sich im Vorhinein Teile des Clusters zu reservieren. Einem solchen System muss der Anwender beim Übermitteln eines Jobs noch mitteilen, wann der Job laufen soll. Dieses Feature ist besonders für interaktive Jobs geeignet, für die ein Nutzer Knoten reservieren möchte. Ein System dieser Gattung ist das ebenfalls freie Open CCS [14].