Verteilte Dateisysteme – Anwendungsbereiche von Cluster Dateisystemen

Wann braucht man ein Cluster-Dateisystem? In meinem Beitrag mache ich Vorüberlegungen zur Auswahl von Cluster-Dateisystemen und gebe einen Überblick der Anwendungsbereiche der Dateissysteme.
Wobei in Zeiten der Cloud parallel verteilte Dateisysteme wie XtreemFS ein Hoch erleben.
In der Regel gibt es zwei verschiedene Einsatzszenarien, bei denen ein verteiltes Dateisystem sinnvoll wird.

1. Zugriff mit einer hohe Anzahl an Clients auf den gleichen Datenbestand
2. Hohe Anzahl an Daten, die nicht mehr von einer einzelnen Hardware zu bewältigen sind

In unserer Ausgangsposition gehe ich von dem Fall aus, dass sogar beide Bedingungen zutreffen.

Vorüberlegungen zur Auswahl eines Cluster Dateisystems

Zugriff auf das Dateisystem

Die meisten Dateisysteme bieten hierfür ein Fuse-Modul (Filesystem in UserSpace) an, das den Zugriff auf Dateiebene direkt im Linux-Userspace ermöglicht.

Replikationsmöglichkeiten

Wie die Replikation der Daten erfolgt ist ebenfalls wichtig. Die meisten Cluster-Dateisysteme bieten hier für direkt mit implementierte Funktionen an, um die Daten redundant vorzuhalten.

Block- oder objektorientiert

Außerdem sollte man sich mit der Frage beschäftigen, ob das verwendete Dateisystem block- oder objektorientiert sein soll. Bei einem blockorientierten Dateisystem liegen die Dateien eigentlich nicht als Dateien innerhalb des Dateisystems vor. Stattdessen befinden sie sich in einzelnen über das Gesamtkonstrukt verteilten Blöcken. Über Meta-Daten wird für das Dateisystem definiert aus welchen Blöcken ein File besteht.

Bei einem objektorientiertem Dateisystem liegen die Dateien auf den Datanodes verteilt und sind nicht fragmentiert. Hierdurch ist ein Zugriff auf die Dateien direkt auf der Datanode möglich ohne den Umweg über einen Client. Dies kann dann dazu verwendet werden Dateien zu katalogisieren, um herauszufinden welche Datei auf welcher Node liegt.

Das Replikationslevel ist hierbei auch ein Thema, dieses regelt wie oft eine Datei im Cluster vorgehalten wird, hierüber werden im Fall eines Ausfalls verlorene Nodes kompensiert.

Überblick einzelner Dateisysteme

Ceph

Ceph besteht aus mehreren Management-Services, die zusammen den Storage-Cluster bilden. Dies können zum Beispiel die sogenannten Cluster Monitors, Metadata Servers und Object-Storage-Devices sein. Jeder Server kann alle Aufgaben übernehmen und jeder Client kann einen beliebigen Server im Cluster-Verbund ansprechen, um an die Daten zu kommen. Der Object Storage teilt dem Client mit, auf welcher Node eine Datei liegt. Ceph erfordert einen selbstkompilierten Kernel auf dem Client.

XtreemFS

Bei XtreemFS liegen die Metadaten getrennt von den eigentlichen Daten. Das Hauptaugenmerk wurde auf Skalierbarkeit und Verfügbarkeit gelegt, die Performance hat nur eine untergeordnete Rolle. Ein Replikationslevel von „kleiner 2“ ist nicht möglich.

Lustre

Lustre ist eine blockorientierte Lösung für große Umgebungen. Daten, die auf einer ausgefallenen Node liegen, sind nicht erreichbar solange die Node nicht wieder gestartet wird. Ein Listing der Daten auf den einzelnen Nodes ist so nicht möglich. Im Worst Case sind Blocks aller Dateien von dem Problem betroffen.

GlusterFS

Bei GlusterFS liegen die Files direkt auf jeder Node in einem lokalen Dateisystem, das vom GlusterFS-Daemon nach außen propagiert wird. Dadurch ist ein Datei-Listing auf der jeweiligen Node ohne Zugriff auf das GlusterFS möglich. Das Hinzufügen und Entfernen von Nodes ist On-The-Fly möglich. Weiterhin wird mittlerweile ein Balancing der Daten unterhalb der Nodes unterstützt. Ein Fehlen einzelner Nodes beeinträchtigt den Client nicht, die Files existieren für ihn schlichtweg nicht. Eine Mountbarkeit unter Linux ist über ein entsprechendes Paket gegeben.