GlusterFS-Schnittstellen

Der Zugriff auf verteilten Speicher über eine POSIX-kompatible Schnittstelle ist nicht unumstritten. Strenge Konformität mit der von der IEEE definierten Schnittstelle würden erheblichen Einfluss auf die Performance und Skalierbarkeit haben. Im Falle von GlusterFS kommt dann noch FUSE als weiterer Kritikpunkt dazu. Seit Version 3.4 gibt es endlich die Möglichkeit, über eine Bibliothek direkt auf die Daten in GlusterFS zuzugreifen. In Abbildung 5 sieht man die Vorteile, die sich bei der Verwendung von »libgfapi« [11] ergeben.

Abbildung 5: Dank libgfapi ist der E/A-Pfad deutlich kürzer beim Zugriff auf GlusterFS.

Die Entwickler von Samba [12] und OpenStack [13] haben den Zugang schon begrüßt und in ihre Produkte eingebaut. Bei der Open-Source-Cloud ist das noch nicht vollständig geschehen. Hier findet der Benutzer noch ein paar GlusterFS-Mounts. Dabei benutzt »libgfapi« im Hintergrund die gleichen GlusterFS-Bausteine, etwa die schon erwähnten "Translatoren". Wer mit Qemu [14] arbeitet, kann auch auf die lästigen Mounts verzichten und die Daten direkt in GlusterFS ablegen. Wichtig ist nur, dass der Emulator und Virtualisierer mindestens die Version 1.3 hat:

# ldd /usr/bin/qemu-system-x86_64|grep libgfapi libgfapi.so.0 => /lib64/libgfapi.so.0 (0x00007f79dff78000) #

Es gibt sogar Python-Bindings für die Bibliothek [ 15 ]. Wie schon mit »glupy« öffnet GlusterFS auch seine Tore in die Welt dieser Skriptsprache.

Eine Besonderheit von GlusterFS ist sein modularer Aufbau. Die Basis-Baueinheit sind die eingangs erwähnten Translatoren. Quasi jede singuläre Eigenschaft eines Volumes ist durch einen dieser "Übersetzer" repräsentiert. Je nach Konfiguration kettet GlusterFS die entsprechenden Translatoren zu einem sogeannten Chain Graph zusammen, der dann die Gesamteigenschaft des Volumes bestimmt. Die Menge dieser Eigenschaftsbausteine zerfällt in mehrere Gruppen. Tabelle 1 listet diese zusammen mit einer Kurzbeschreibung auf.

Der Storage-Translator »posix« steuert beispielsweise, ob GlusterFS den VFS-Cache des Linux-Kernels benutzt oder nicht ( »O_DIRECT« ). Hier kann der Admin auch einstellen, ob das Löschen von Dateien im Hintergrund erfolgen soll. Auf der Verschlüsselungsseite gibt es leider noch nicht viel zu sehen. Eine Beispielimplementierung mit ROT13 [16] befindet sich im Lieferumfang des Quelltextes von GlusterFS. Eine brauchbare Version für Benutzer ist für die kommende Version geplant. Eine besondere Raffinesse ist die Binding-Gruppe. Eigentlich sind das keine richtigen Translators, sondern eher ein Gerüst, um diese in anderen Sprachen zu schreiben. Der bekannteste ist »Glupy« [17] und stellt die Schnittstelle zu Python her.

Erweiterungen und Schnittstellen bei Ceph

Im Gegensatz zu GlusterFS ist das Thema "Erweiterungen über Plugins" bei Ceph schnell durch: Ceph unterstützt augenblicklich keine Option, um Funktionalität über Module nachzuladen. Abgesehen von der quasi ab Werk vorgegebenen Konfigurationsvielfalt beschränkt sich Ceph auf das "Hinzuprogrammieren" externer Features über die schon erwähnten APIs wie die Librbd und die Librados.

Im Hinblick auf das Anbieten einer RESTful-API ist Ceph gegenüber GlusterFS klar im Vorteil. Denn das Speichern von binären Objekten beherrscht Ceph ja selbst schon, sodass lediglich ein entsprechendes Frontend mit RESTful-Schnittstelle fehlt. Bei Ceph nimmt diesen Platz das Rados-Gateway ein, das für einen Ceph-Cluster gleich zwei APIs zur Verfügung stellt: Einerseits spricht das Rados-Gateway das Protokoll von OpenStacks Objektspeicher Swift [18] , andererseits beherrscht es auch das Protokoll von Amazons S3-Speicher, sodass S3-kompatible Clients mit dem Rados-Gateway ebenfalls zu gebrauchen sind.

Im Hintergrund setzt das Rados-Gateway freilich auf »librados« . Überdies weisen die Ceph-Entwickler ausdrücklich darauf hin, dass das Gateway nicht jede einzelne Funktion von Amazons S3 oder OpenStack Swift beherrscht. Die Grundfunktionen funktionieren allerdings durch die Bank wie erwartet, und momentan konzentrieren die Entwickler sich auf die Implementierung wichtiger Zusatzfeatures: Seit kurzem beherrscht das Rados-Gateway beispielsweise die nahtlose Anbindung an OpenStacks Autentifizierungskomponente Keystone, sowohl für den Betrieb mit Swift wie auch für den Betrieb mit Amazon S3 (gemeint ist in beiden Fällen das Protokoll). Das ist insbesondere dann praktisch, wenn OpenStack in Kombination mit Ceph zum Einsatz kommt (Details zur Kooperation von Gluster oder Ceph und OpenStack finden sich Kasten "Speicher für OpenStack" ).