© Jakub Gojda, 123RF

Zwar bringt Open Stack mit Swift auch eine eigene Storagekomponente mit, doch wer sich Skalierbarkeit und eine einfache Verwaltung wünscht, kann die Cloudlösung mit Gluster-FS verheiraten.

Der Hype um die Wolke als Lösung aller (IT-)Probleme will nicht abnehmen. Wer sich dabei nachhaltig im Gehege quelloffener Software bewegen möchte, kommt an der Open-Stack-Suite [1] momentan kaum vorbei. Das gilt insbesondere für Datenspeicherlösungen, denn Storage ist ein zentraler Bestandteil der Open-Source-Cloud.

Varianten von verteilten Datenablagen stellte das Linux-Magazin bereits vor knapp einem Jahr vor [2], anhand von Gluster-FS [3] will dieser Artikel nun zeigen, wie gut zwei eigentlich voneinander getrennte Softwareprojekte im Verbund kooperieren.

Verteiltes Speichern

Wenn Unternehmen sich für ein Storagesystem entscheiden, schauen sie in erster Linie darauf, wie es sich verwalten lässt und wie es skaliert – natürlich muss auch der Datendurchsatz stimmen. Ein schöner Nebeneffekt ist, wenn sich mit der Storagetechnologie zugleich die Abhängigkeit von einem bestimmten Datenspeicher-Hersteller abschwächt oder gar vollständig löst – mitunter entscheidet dieser Punkt sogar die Wahl.

Die Gründer des Gluster-FS-Projekts wollten beim Start vor über fünf Jahren jedoch vor allem einen Storage aufbauen, der sich einfach administrieren und problemlos skalieren lässt. Als ein primäres Ziel galt in frühen Jahren die Ablösung von traditionellen NAS-Lösungen, etwa Filer von Netapp, oder Linux-basierten NFS-Servern.

NAS-Ablöse

Die Basis von Gluster-FS bilden gewöhnliche Linux-Rechner, die über freien Plattenplatz verfügen und auf die der Admin die entsprechende Software bügelt. In der Gluster-Sprache heißen diese Grundeinheiten Bricks. Die Server gehen ein Vertrauensverhältnis ein und werden so zum Grundgerüst des Storageverbunds.

Die Daemons »glusterd« und »glusterfsd« sind die maßgeblichen Prozesse auf den jeweiligen Bricks. Sie fassen die lokalen Verzeichnisse zu einem so genannten Volume zusammen und exportieren es dann. Die Außenwelt greift entweder über das native Gluster-FS-Protokoll oder über NFS darauf zu. Aus Client-Sicht verhält sich das Volume dabei analog zu einem NAS-Share (Abbildung 1).

Abbildung 1: Vereinfachte Architektur von Gluster-FS mitsamt Bricks und Volumes.

Die Eigenschaften der Volumes konfiguriert der Cloudarchitekt über das »gluster« -Werkzeug. Hinter den Kulissen verarbeitet Gluster-FS die gewünschten Einstellungen, indem es so genannte Translatoren kombiniert. Jeder Translator steht für eine Funktion, beispielsweise für eine Replikation oder eine Verteilung. Die Summe an Translatoren bestimmt auch die Gesamtheit der Eigenschaften eines Volume.

Die ursprüngliche Zielvorgabe des Projekts – das Ersetzen traditioneller NAS-Technologien – wäre nun bereits erreicht. Doch die Welt stand derweil nicht still – und schon gar nicht ihre IT-Abteilungen: Dem Einbruch der Virtualisierung in die Rechenzentren mussten auch die Storagelösungen Rechnung tragen. Hier konnte Gluster-FS punkten und sich Marktanteile sichern.

Prinzipiell kann der KVM- oder Xen-Admin die Gluster-FS-Volumes auf seinen Hosts an der gewünschten Stelle einhängen und so auch die virtuellen Server erreichen. Sind der Gluster-FS-Verbund und seine Anbindung passend eingerichtet, erhält der Cloud-Operator auf diesem Wege einen hochverfügbaren Datenspeicher für seine virtuellen Maschinen – Entsprechendes gilt für das Einbinden in Open Stack. Allerdings ist dieser Ansatz nicht sehr elegant.

Open-Stack-Integration: Klappe, die erste

Die Storagekomponente von Open Stack bringt drei wesentliche Bestandteile mit: Swift, Cinder und Glance. Der Objectstore Swift gilt als der Veteran und ist seit der ersten Version (Austin, Oktober 2010) Teil der Open-Source-Suite für die Wolke. Etwas vergröbert lässt sich Swift als quelloffene Version von Amazons S3 beschreiben.

Swift selbst besteht aus mehreren Komponenten: Proxy, Objekt, Container, Account und Autorisierung. Dabei verwalten der Account Container und der Container wiederum Objekte. Wer will, kann sich für diese Komponenten äquivalente Elemente in einem Posix-kompatiblen Dateisystem vorstellen: Das Objekt entspricht einer Datei, der Container einem Verzeichnis und der Account einem Volume. Bis zur Einführung von Version 3.3 war jedoch weder für Swift noch für Cinder oder Glance eine Objekt-basierte Gluster-FS-Anbindung möglich, da Letzteres sich ausnahmslos als Posix-Dateisystem verstand.

Auftritt: Der Hybrid

Unter dem Namen UFO (Unified File and Object) brachte Mitte 2012 die Version 3.3 von Gluster-FS eine signifikante Neuerung mit. UFO versöhnte das verteilte Dateisystem mit Objectstore. Bis dahin hatte Gluster-FS die Dateien als Verwaltungsobjekte behandelt, was sowohl die Repräsentation gegenüber dem Client als auch die interne Organisation betraf. Dank der neuen Version konnte es nun jede Posix-kompatible Datei auch als Objekt behandeln und umgekehrt.

Auf der Client-Seite ermöglichte das einen Zugriff auf dieselben Daten sowohl über HTTP als auch über das native Gluster-FS-Protokoll. Hinter den Kulissen verknüpfte das Backend-Dateisystem beide über einen Link miteinander (Listing 1): Bei echten Dateien handelte es sich um Hardlinks, bei Verzeichnissen um symbolische Links.

01 # ls -ali datei.txt .glusterfs/0d/19/0d19fa3e-5413-4f6e-abfa-1f344b687ba7
02 132 -rw-r--r-- 2 root root 6  8. Dec 14:16 datei.txt
03 132 -rw-r--r-- 2 root root 6  8. Dec 14:16 .glusterfs/0d/19/0d19fa3e-5413-4f6e-abfa-1f344b687ba7
04
05 # ls -alid dir1 .glusterfs/fe/9d/fe9d750b-c0e3-42ba-b2cb-22ff8de3edf0 .glusterfs/00/00/00000000-0000-0000-0000-000000000001/dir1/
06 4235394 drwxr-xr-x 2 root root  6  8. Dec 14:17 dir1
07 4235394 drwxr-xr-x 2 root root  6  8. Dec 14:17 .glusterfs/00/00/00000000-0000-0000-0000-000000000001/dir1/
08     135 lrwxrwxrwx 1 root root 53  8. Dec 14:17 .glusterfs/fe/9d/fe9d750b-c0e3-42ba-b2cb-22ff8de3edf0 -> ../../00/00/00000000-0000-0000-0000-000000000001/dir1

Der Weg nach Havanna

Im ersten Schritt bauten die Entwickler die von Swift bekannten Elemente Proxy, Objekt, Container und so weiter nach. Bei der Integration in Open Stack kam es in der Folge allerdings zum Konflikt zwischen den Gluster-FS-Varianten und den nativen Gegenstücken des Objectstore. Der Admin musste einen Teil der Open-Stack-Distribution entfernen, damit Gluster-FS an dessen Stelle treten konnte. RPM & Co. reagierten zudem mit Paketkonflikten.

Zu allem Überfluss war die Gluster-FS-Version von Swift genau auf eine bestimmte Version des Objectstore von Open Stack angepasst. Änderungen auf dieser Baustelle erforderten wiederum Nacharbeiten von den Gluster-FS-Entwicklern. Alles in allem war Version 3.3 zwar ein Schritt in die richtige Richtung, aber die Open-Stack-Integration insgesamt noch recht hakelig.

Vorhang: Cinder und Glance

Seit Version 3.4 von Gluster-FS und Open Stack 2013.2 (Havanna) ist die Swift-Integration zum Glück abgeschlossen. Auf beiden Seiten sind die notwendigen Änderungen im Quelltext angekommen und abgenickt. Der Open-Stack-Admin muss Swift nur noch so konfigurieren, dass es Gluster-FS benutzt – fertig, der Austausch von Paketen entfällt. In diesem Kontext kam auch ein neues Akronym auf: G4O (Gluster-FS for Open Stack).

Neben Swift nutzt Open Stack zwei weitere Komponenten für die Datenablage: Glance und Cinder. Glance ist seit Februar 2011 im Stack (Bexar, Februar 2011), mit ihm verwaltet Open Stack Abbilder von Festplatten oder sogar komplette virtuelle Rechner. Cinder hingegen ist noch recht neu und erst seit Folsom (September 2012) mit von der Partie. Es stellt persistente Blockgeräte für die virtuellen Instanzen bereit. Ursprünglich war Cinder Teil der Open-Stack-Komponente Nova und hieß Nova Volume.

Glance und Cinder verfügen über so genannte Backend-Treiber, mit deren Hilfe sie auf Datenspeicher zugreifen. Seit der Open-Stack-Version Grizzly (April 2013) unterstützt Cinder auch das Gluster-FS-Protokoll, für eine funktionierende Integration der Storage-Seite sorgte aber erst Version 3.4 von Gluster-FS.

Ähnlich wie bei Swift können die Besitzer älterer Gluster-FS-Varianten die Volumes an jenem Ort auf dem Linux-Rechner einhängen, an dem Open Stack seine Daten ablegen soll. Das Update auf eine neuere Softwareversion wäre aber die weitaus bessere Option. Der Artikel beschränkt sich darum auf die aktuellen Versionen von Open Stack und Gluster-FS.

Volles Volumen

Cinder genau so zu konfigurieren, dass es Gluster-FS verwenden kann, ist denkbar einfach und gut dokumentiert (Abbildung 2). Auf Cinder zuzugreifen hat für die Compute Nodes den Vorteil, VMs nicht mehr von lokalen Images booten zu müssen, sondern sie direkt von den Gluster-FS-Volumes zu holen, was Live-Migrationen erlaubt.

Abbildung 2: Cinder lässt sich einfach dazu überreden, Gluster-FS als Storage-Backend zu nutzen.

Damit das klappt, muss der Admin auf der Storage-Seite Vorkehrungen treffen und auf den Cinder-Hosts zunächst Volumes anlegen. Open Stack ist es dabei egal, ob die Storage-Seite n-fach repliziert oder die Daten auf x Server verteilt. Allerdings muss der Kuppler hier Vorsicht walten lassen, andernfalls kommt es schnell zur Verwirrung: Ein Volume im Cinder-Jargon entspricht einer regulären Datei im Gluster-FS-Volume. Letzteres führt etwa dazu, dass sich bislang keine Snapshots von Gluster-FS-Volumes erstellen lassen.

Glance’ Verzahnung mit Gluster-FS weist Parallelen zu der von Cinder auf: Auch hier konnte der Admin Volumes früher behelfsmäßig integrieren, indem er sie an entsprechender Stelle mountete, etwa nach »/var/lib/glance« . Vor Open Stack 2013.2 konnte er noch den Kniff probieren, Swift als Backend für die Verwaltung der Abbilder einzutragen, was Gluster-FS quasi indirekt ins Spiel brachte.

Lib statt Fuse

Ein Kritikpunkt an Gluster-FS bestand lange Zeit darin, dass es nötig war, die Posix-Schicht zu verwenden, was im Verbund mit der Fuse-Technologie keine Spitzenwerte in Sachen Leistung ergab. Mit Version 3.4 zeichnete sich die Lösung in Form der Schnittstellenbibliothek »libgfapi.so« [4] ab. Ist die Anwendung entsprechend programmiert und gegen die Bibliothek gelinkt, kann sie auf lästige Kontextwechsel verzichten und direkt mit dem Gluster-FS-Storage kommunizieren (Abbildung 3). Es gibt auch Java- und Python-Bindings für die Bibliothek.

Abbildung 3: Die neue Schnittstellenbibliothek Libgfapi erspart Anwendungen Umwege.

Mit Qemu [5] und Samba [6] setzen gleich zwei weitere große Softwareprojekte die Bibliothek gewinnbringend ein. Nun ist es möglich, die Daten der virtuellen Gäste direkt im Gluster-FS-Verbund abzulegen, Mounten ist nicht nötig. Die Integration in Qemu kommt auch indirekt der Open-Source-Cloud zugute: Sowohl Cinder als auch Nova können davon Gebrauch machen – und Glance im Endeffekt auch, wenn es direkt auf den Blockstorage von Open Stack zeigt.

In Bezug auf Cinder und die Libgfapi ist die vorhandene Dokumentation allerdings etwas irreführend: Noch immer verwalten Fuse-Mounts den Blockstorage. Die neue Schnittstelle kommt erst zum Zuge, wenn der virtuelle Server vom konfigurierten Volume startet.

Was noch?

Im Gefolge der Wolke rollt die große Welle um Big Data über die IT-Welt – Hadoop ist eine prominente Vertreterin. Mit HDFS (Hadoop Distributed File System) ist eine verteilte Storagelösung Teil der Software. Der gewitzte Gluster-FS-Admin stellte sich allerdings sofort die Frage, ob er hier nicht auch seine Technologie verwenden könne – die Entwickler kamen offenbar auf die gleiche Idee [7].

Seit Version 3.3 gibt es ein Plugin, um den verschiedenen Hadoop-Distributionen Gluster-FS als Datenspeicher unterzuschieben. Zwar blieb es bis vor Kurzem recht ruhig um dieses Teilprojekt, was sich aber bald ändern kann, denn das Open-Stack-Lager zeigt großes Interesse an Hadoop, das entsprechende Unterprojekt heißt Savanna [8].

Über ein zweites Unterprojekt könnte Gluster-FS im Open-Stack-Biotop gar zu seinen Wurzeln zurückkehren: Manila [9] möchte FaaS (Filesystem as a Service) in Open Stack integrieren. Gluster-FS ist schon längst als Backend gelistet – kein Wunder, hat es doch als Datei-basierter Storage angefangen.

Neue Projekte unter der Schirmherrschaft von Open Stack sind keine Seltenheit, dazu gehören der Datenschutz-Dienst Raksha [10], der Datenbank-Dienst Trove [11] und ein noch namenloses Projekt zur Datenrettung [12]. Tabelle 2 listet einige gegenwärtige und potenzielle Aufgaben für Gluster-FS im Rahmen der Open-Source-Cloud auf.

Was bleibt?

Gluster-FS hat bereits eine lange Wanderschaft hinter sich. Die Integration in Open Stack verlief zunächst schleppend, die Kernkomponenten sind jedoch inzwischen auf einem akzeptablen Niveau angelangt. Als essenziell erwies sich in diesem Zusammenhang die Libgfapi: Sie holte nicht nur einen Leistungsgewinn gegenüber Fuse-Mounts heraus, sondern sorgt auch dafür, dass nicht alle Anwendungsfälle eine Posix-kompatible Schicht voraussetzen.

Mit Red Hat steht zudem eine einflussreiche Open-Source-Firma hinter Gluster-FS und bietet auf dessen Basis den Red Hat Storage Server [13] (siehe folgenden Artikel) an, was eine Nachhaltigkeit der Entwicklung andeutet.

Doch gibt es auch erfolgreiche Alternativen im quelloffenen Storagebereich: So macht zum Beispiel Ceph [14] im Open-Stack-Umfeld eine gute Figur. Es bleibt also wolkig.