GlusterFS fasst den Speicherplatz von mehreren Servern zu einem einzigen virtuellen Laufwerk zusammen. Dieses kann man wie ein herkömmliches Dateisystem über NFS oder Fuse auf einem Client-PC mounten. Während des Betriebs lassen sich jederzeit weitere Server hinzufügen oder vorhandene aus dem Speicherpool abziehen. Die Arbeitsweise von GlusterFS erinnert an eine Art "RAID im Netzwerk", und in der Tat erkennt man bei der Einrichtung viele RAID-Konzepte wieder.Seine Vorteile spielt GlusterFS vor allem aus, wenn man sehr große Datenmengen speichern, Dateien redundant lagern oder Daten sehr schnell wegschreiben und wieder abrufen möchte. Es jongliert spielend mit mehreren Petabytes, lässt sich leicht installieren und administrieren. Prinzipiell erhöht sich der Datendurchsatz mit jedem weiteren Server, limitierend wirkt dann die Netzwerkanbindung. GlusterFS kommt dabei mit TCP/IP-Verbindungen wie auch Infiniband RDMA zurecht. Dabei ist es egal, ob nur einer oder mehrere Tausend Clients gleichzeitig an der Strippe hängen. GlusterFS eignet sich daher gleichermaßen für kleine wie große Netzwerke. Obendrein verteilt es auf Wunsch die Nutz- und Metadaten geschickt auf alle Server, es ist somit fehlertolerant und hochverfügbar.
GlusterFS selbst hat schon ein paar Jährchen auf dem Buckel: Seine Entwicklung begann bereits 2005 bei der amerikanischen Firma Gluster, Inc. Den Quellcode stellten die Entwickler unter die GNU GPL, Geld spülte vor allem der kostenpflichtige Support in die Kassen. Ende 2011 kaufte Red Hat das verteilte Dateisystem für mehrere Millionen US-Dollar und hievte es so in die Schlagzeilen [2]. Am Vertriebsmodell ändert sich vorerst nichts. Die aktuellen GlusterFS-Versionen, auf deren Basis Red Hat einige kommerzielle Produkte in seiner Cloud-Computing-Sparte zusammenstrickt, stehen unter der GPL v3, .
Wie schnell und einfach GlusterFS aufgesetzt ist, zeigt ein einfaches Beispiel. In einem kleinen Netzwerk mit Gigabit-Ethernet stellen dabei drei Server ihre Festplattenkapazitäten bereit, die ein Client-PC nutzen möchte (Abbildung 1). GlusterFS verlangt auf den Servern jeweils mindestens 1 GByte Hauptspeicher, 8 GByte freien Festplattenplatz, mindestens Gigabit-Ethernet und schlussendlich ein 64-Bit-Linux.
Abbildung 1: Im Beispiel gibt es drei Server, deren Speicher GlusterFS bündelt und einem Client bereitstellt.
Für das zum Redaktionsschluss aktuelle GlusterFS 3.2.5 empfehlen die Entwickler Red Hat Enterprise Linux 6.1. Als kostenlose Alternative bietet sich CentOS an, das frisch installiert auch auf allen Rechnern des Beispiels laufen soll. Auf anderen Distributionen funktioniert die Installation und Einrichtung aber auf die exakt gleiche Weise (siehe Kasten "GlusterFS geht fremd").
GlusterFS geht fremd
Auch wenn Red Hat es nicht an die große Glocke hängt, arbeitet GlusterFS auf beliebigen anderen Linux-Distributionen. Auf der GlusterFS-Homepage warten sogar schon fertige Pakete für CentOS 5.7 und 6.x, Debian 5.0.3, Fedora 11 und 16 sowie Ubuntu 11.10. Benutzer einer anderen Distribution müssen zum Quellcode greifen, dessen Installation jedoch nicht wesentlich aufwendiger ist als das Einspielen der Pakete.
In jedem Fall muss man zunächst sicherstellen, dass Fuse, OpenSSH, Wget und bei Bedarf auch noch die Werkzeuge für NFS (unter Ubuntu im Paket »nfs-common«) installiert und eingerichtet sind. Dies ist bei den meisten Distributionen schon von Haus aus der Fall. Sofern die GlusterFS-Homepage passende Pakete bereithält, spielt man sie wie bei CentOS ein, Debian- und Ubuntu-Besitzer müssen sogar nur ein einziges Paket installieren.
Um GlusterFS aus dem Quellcode zu übersetzen, installiert man zunächst die Entwicklerpakete zu Readline und Fuse sowie die Werkzeuge Bison, Flex, GCC und Make. Dann muss man nur noch den Quellcode von [1] laden, ihn entpacken und via »./configure; make; sudo make install; sudo ldconfig« übersetzen und einspielen.
Sind alle Voraussetzungen erfüllt, wendet man sich zunächst den Servern zu, die zukünftig Speicherplatz bereitstellen sollen. Sofern diese unter einem aktuellen CentOS 6.2 arbeiten, lädt man die passenden GlusterFS-Pakete aus dem Internet herunter [3]. Man benötigt die Pakete »core«, »fuse« und »geo-replication«, die man auch in dieser Reihenfolge als Benutzer »root« einspielt:
rpm -Uvh glusterfs-core-Version.x86_64.rpmrpm -Uvh glusterfs-fuse-Version.x86_64.rpmrpm -ivh glusterfs-geo-replication-Version.x86_64.rpm
Ob die Installation geklappt hat, verrät »glusterfs -V«.
Ziegelsteine
Jeder Server übergibt eines seiner Verzeichnisse in die Obhut von GlusterFS. Diese Verzeichnisse bezeichnet GlusterFS als "Brick". Mehrere Bricks schnürt GlusterFS dann zu einem großen Datenspeicher, dem Volume, zusammen, das wiederum die Clients wie ein Laufwerk einbinden. Damit das funktioniert, muss man auf den Servern die passenden Ports öffnen.
Im Einzelnen sind dies der UDP-Port 111 sowie die TCP-Ports 111, 24007, 24008 und dann ab 24009 für jeden Brick einen weiteren Port. Wenn man später den Datenspeicher via NFS auf den Clients ansprechen möchte, muss man zusätzlich noch die Ports ab 38465 öffnen – auch hier für jeden Server einen. Unter einem frisch installierten CentOS 6.2 erledigen das die Kommandos aus Listing 1. Sie öffnen Ports für drei Bricks und drei Server, was für das Beispiel erst einmal genügen sollte. Abschließend wirft man auf allen Servern den GlusterFS-Daemon an. Unter CentOS klappt das via:
/etc/init.d/glusterd start
Öffnen der Firewall von CentOS
Abbildung 2: Wer das grafische Firewall-Konfigurationsprogramm von CentOS bevorzugt, wählt für das Beispiel diese Einstellungen.
Die Installationsskripte in den Paketen haben bereits dafür gesorgt, dass der Server zukünftig bei einem Systemstart mit hochfährt.
Nachdem die Vorbereitungen abgeschlossen sind, meldet man sich als »root« bei einem der Server an. Bei welchem ist egal, naheliegend ist natürlich der erste (»192.168.2.101«). Dort meldet man nun mit dem Hilfsprogramm »gluster« nacheinander die beiden anderen Server an:
gluster peer probe 192.168.2.102gluster peer probe 192.168.2.103
Anstelle der IP-Adressen darf man selbstverständlich auch die Domainnamen verwenden. Damit bilden jetzt die drei Rechner einen sogenannten Trusted Storage Pool (Abbildung 3). Nur auf diese Rechner greift GlusterFS im Folgenden zu. Ihren Status verrät:
gluster peer status
Abbildung 3: In diesem Beispiel besteht der Trusted Storage Pool aus insgesamt drei Rechnern. Den lokalen listet
Einen fälschlicherweise angemeldeten Server wirft
gluster peer detach IP-Adresse
wieder aus dem Trusted Storage Pool heraus. Das Werkzeug »gluster« heißt übrigens formal Gluster Management Console. Sie ist gewissermaßen das Schweizer Messer des GlusterFS. Im Gegensatz zu älteren GlusterFS-Versionen muss man dank ihm nicht mehr direkt die Konfigurationsdateien editieren. Wer dennoch manuell Hand anlegen möchte, wendet sich der Datei »/etc/glusterfs/glusterfsd.vol« zu. Im gleichen Verzeichnis liegt auch noch eine gut kommentierte Beispielkonfiguration »glusterfs.vol.sample«. Ihre Inhalte zu verstehen, sollte zusammen mit den folgenden Ausführungen leichtfallen. Apropos Konfiguration: Sämtliche Server im Storage Pool gleichen automatisch ihre Konfiguration ab, sie sind also immer alle auf dem aktuellen Stand.
Bauhaus
Als Nächstes muss man GlusterFS mitteilen, welche Verzeichnisse (alias Bricks) es auf den einzelnen Servern zu einem großen, neuen Volume zusammenschnüren soll. Im Beispiel steht dazu auf jedem der Server das Verzeichnis »/data« bereit, das GlusterFS für seine Zwecke in Beschlag nehmen kann. Als Dateisystem sollte dort laut Red Hat am besten XFS zum Einsatz kommen. GlusterFS arbeitet aber auch mit jedem anderen Posix-kompatiblen Dateisystem zusammen, wie etwa Ext3 oder Ext4. Die sind aber einerseits weniger gut getestet, und andererseits muss man dann unter Umständen auf einige der GlusterFS-Funktionen verzichten (wie etwa eine Zugriffskontrolle mit Access Control Lists).
Auf welcher Hardware das Dateisystem letztendlich liegt, ist GlusterFS weitgehend egal. So kann hinter »/data« eine herkömmliche Festplatte des Servers stecken, wie auch einen RAID-Verbund, Amazon EBS oder ein eingebundenes SAN. Ein neues Volume mit dem Namen »beispielvolume« erstellt schließlich der folgende Bandwurm:
gluster volume create beispielvolume transport tcp 192.168.2.101:/data 192.168.2.102:/data 192.168.2.103:/data
In diesem einfachen Beispiel kann man »transport tcp« sogar noch weglassen, GlusterFS nimmt dann automatisch an, dass es sich um eine TCP/IP-Verbindung handelt. Ob alles geklappt hat, verrät
gluster volume info
das alle vorhandenen Volumes und ihre jeweilige Zusammensetzung auflistet (Abbildung 4). Jetzt muss man das Volume nur noch starten:
gluster volume start beispielvolume
Abbildung 4: Das fertige Volume für das Beispiel.
