Verteilen der Daten auf mehrere Server

Die Daten eines Volumes kann SDFS auf mehrere Server verteilen. Die Rechner im so entstehenden SDFS-Cluster sollten jeweils über eine statische IP-Adresse und eine möglichst schnelle Netzwerkanbindung verfügen. Die einzelnen Knoten kommunizieren per Multicast via UDP. Die vorhandenen Firewalls müssen die entsprechenden Pakete durchlassen. Darüber hinaus unterbinden einige Virtualisierer wie KVM Multicast. Ein Cluster lässt sich dann nicht, nur eingeschränkt oder nur mit einer bestimmten Konfiguration mit virtuellen Maschinen aufbauen.

Auf allen Servern, die Speicherplatz für ein Volume bereitstellen sollen, installieren Sie zunächst das SDFS-Paket. Anschließend starten Sie die Dedup Storage Engine, kurz DSE. Dieser Dienst nimmt die deduplizierten Datenblöcke entgegen und speichert sie ab. Bevor Sie eine DSE anwerfen können, müssen Sie sie mit folgendem Befehl konfigurieren:

mkdse --dse-name=sdfs --dse-capacity=100GB --cluster-node-id=1

Der erste Parameter gibt der DSE einen Namen, im Beispiel "sdfs". Der zweite Parameter bestimmt die maximale Speicherkapazität, die der DSE im Cluster bereitstellen wird. Als Blockgröße kommen standardmäßig 4 KByte zum Einsatz. Abschließend verpasst "--cluster-node-id=" dem Knoten noch eine eindeutige Identifikationsnummer, die zwischen 1 und 200 liegen muss. Im einfachsten Fall nummerieren Sie einfach die Knoten von 1 an durch. Eine DSE verweigert ihren Start, wenn bereits eine Kollegin im Netz mit der gleichen ID läuft.

"mkdse" schreibt die Konfiguration der DSE ins Verzeichnis »/etc/sdfs/« . Dort fügen Sie in der Datei "jgroups.cfg.xml" unterhalb der Zeile "<UDP" die folgende Zeile hinzu:

bind_addr="192.168.1.101"

Die IP-Adresse tauschen Sie dabei gegen die IP-Adresse des Servers aus. Wie der Dateiname »jgroups.cfg.xml« andeutet, kommunizieren die SDFS-Komponenten mithilfe des JGroups-Toolkits miteinander [6]. Anschließend können Sie den DSE-Dienst starten:

startDSEService.sh -c /etc/sdfs/sdfs-dse-cfg.xml &

Auf den anderen Knoten verfahren Sie genauso, wobei Sie dort die Zahl hinter "--cluster-node-id=" immer um eins erhöhen.

Standardmäßig speichern die DSEs die angelieferten Datenblöcke auf der Festplatte des jeweiligen Knotens. Sie lassen sich aber auch so einstellen, dass die Daten in der Cloud landen. Zum Redaktionsschluss unterstützte SDFS Amazons AWS und Microsoft Azure. Um die Daten in eine der beiden Clouds zu schieben, müssen Sie an "mkdse" lediglich ein paar weitere Parameter anhängen. Die verraten im Wesentlichen nur die Zugangsdaten, hängen damit aber auch von der jeweiligen Cloud ab. Die notwendigen Parameter verrät der Aufruf von »mkdse --help« , weitere Starthilfe liefert die Seite unter [7].

Sobald die Knoten vorbereitet sind, können Sie auf einem weiteren Server das Volume erstellen und einhängen. Diese Aufgaben übernimmt der sogenannte File System Service. Ein neues Volume mit dem Namen "pool1" und einer Kapazität von 256 GByte legt der Administrator dabei mit folgendem Kommando an:

mkfs.sdfs --volume-name=pool1 --volume-capacity=256GB --chunk-store-local false

Es ist das gleiche Kommando wie bei einem lokal angelegten Volume: Beim Betrieb auf einem einzelnen Rechner sind DSE und FSS in einem Prozess vereint. Der letzte Parameter "--chunk-store-local false" sorgt dafür, dass der FSS das Volume über die DSEs erzeugt (wie es Bild 2 veranschaulicht). Die Blockgröße muss zudem mit denen der DSEs übereinstimmen, im Beispiel sind das die standardmäßig verwendeten 4 KByte. Danach mounten Sie das Volume wie gewohnt:

mount.sdfs pool1 /media/pool1

Hochverfügbarkeit und Redundanz

Die Datenblöcke kann SDFS im Cluster redundant speichern. Dazu teilen Sie "mkfs.sdfs" über den Parameter "--cluster-block-replicas" mit, wie viele DSE-Knoten einen Datenblock speichern sollen. In folgendem Beispiel landet jeder im Volume gespeicherte Datenblock auf drei unabhängigen Knoten:

mkfs.sdfs --volume-name=pool3 --volume-capacity=400GB --chunk-store-local false --cluster-block-replicas=3

Fällt ein DSE aus, springen die anderen für ihn ein. Diese Replikation hat allerdings einen kleinen Haken: SDFS garantiert lediglich die Hochverfügbarkeit der eigentlichen Datenblöcke, nicht aber der Metadaten des Volumes. Um deren Sicherung muss sich der Administrator selbst kümmern.