Vernetzte Speichersysteme sind nicht nur teuer, sondern basieren auch auf der proprietären Hardware der jeweiligen Hersteller. Die Erweiterungsmöglichkeiten halten sich je nach Modell meist in Grenzen. Bis zu einer gewissen Anzahl rüsten Nutzer Platten-Shelves nach. Dadurch erhöht sich die Kapazität, nicht aber die Performance, denn der Controller und damit das Nadelöhr bleibt meistens der gleiche.

Schon seit ein paar Jahren werden Produkte, die auf Software-defined Storage (SDS) beruhen, immer beliebter. Die Idee dahinter: Aus normalen Rechnern mit direkt angeschlossenen Festplatten entstehen mithilfe schlauer Speichersoftware ausfallsichere und skalierende Speichersysteme. SDS-Verbände nutzen dabei die Rechenleistung jedes einzelnen Knotens, anstatt nur einen Kontrollkopf mit "dummen" JBOD-Erweiterungen einzusetzen.

Eine dieser SDS-Lösungen, die sich für verschiedene Szenarien einsetzen lässt, ist das Scale-out-Filesystem GlusterFS. Wie der Name schon sagt, handelt es sich dabei um ein Netzwerkdateisystem ähnlich SMB/CIFS oder NFS. Gluster lässt sich zudem für Block- oder Objektspeicher nutzen, aber nur über kleinere Umwege, denn im Kern ist und bleibt es ein verteiltes Dateisystem.

Historisch gibt es eine ganze Reihe verschiedener Ansätze, um Dateisysteme über mehrere Knoten zu verteilen. Ein großes Problem waren dabei stets die Metadaten. Wer Dateien oder Datenblöcke auf mehreren Rechnern verteilt oder gespiegelt sichert, muss diese schließlich beim Lesen wiederfinden. Ältere Ansätze nutzten eine funktionelle Verteilung. Wollte ein Client Daten schreiben, suchte das Cluster-Dateisystem diejenigen Knoten heraus, die gerade wenig zu tun hatten und über viel freien Speicher verfügten. Die Metadaten gingen in einen besonderen Speicherbereich, der auf allen Knoten vorgehalten wurde. Beispielsweise setzen frühe Versionen des Scale-out-Storage Isilon (mittlerweile Dell EMC) ein Infiniband-Netzwerk zur Cluster-internen Kommunikation und dezidierte SSDs für das "Inhaltsverzeichnis" ein. Das machte die Lösungen natürlich teuer.

GlusterFS vereinfacht den Umgang mit Metadaten ungemein – es braucht nämlich keine. Die Verteilung der Daten im Cluster übernehmen bei GlusterFS sogenannte "xlators" (Translators: Übersetzer). Diese Module ermitteln die Verteilung der Daten im Verbund. Gluster berechnet aus dem Namen (Datei und Verzeichnis) einer Datei einen eindeutigen Hash-Code, der via xlator die Verteilung bestimmt. Vereinfacht ausgedrückt bedeutet das, dass bei einem Zwei-Knoten-Cluster die Dateien, deren Name mit den Buchstaben A bis K beginnen, auf den Knoten eins und L bis Z auf den Knoten zwei gesichert werden.

Das Besondere daran: Greift ein Linux-System auf GlusterFS über den GlusterFS-Client zu, bekommt es vom Cluster den aktiven xlator des jeweiligen Dateisystems übermittelt. Die Daten müssen daher nicht über den Umweg eines Kontrollkopfs im Dateisystem verteilt werden. Der Client selbst berechnet die Verteilung und liest und schreibt somit die Dateien direkt von/zu den jeweiligen Gluster-Knoten. Damit skaliert die Geschwindigkeit mit zunehmender Zahl an Knoten und Clients. Ändert sich der xlator, weil der Administrator beispielsweise Knoten hinzufügt, bekommen die Clients den neuen xlator mitgeteilt, während die Server zusätzlich noch den alten kennen. Greift ein Client mit dem neuen xlator auf Daten zu, die aber noch nach dem vorhergehenden gesichert sind, korrigiert der Cluster den jeweiligen Zugriff. Um diese Redirects längerfristig zu vermeiden, stößt der Administrator nach Änderungen des Verbunds ein sogenanntes "Rebalance" an, das die Dateien passend zum neuen Xlator im Cluster umverteilt.

GlusterFS nutzt im Wesentlichen drei xlators und Kombinationen davon:

- Replicated: Schreibt eine Datei auf mehrere Knoten.

- Distributed: Verteilt Dateien auf mehrere Knoten.

- Dispersed: Nutzt Erasure Coding (RAID auf Dateiebene), um Dateien auf mehrere Knoten zu verteilen und Parity Informationen hinzuzufügen. Das spart gegenüber dem Modus "Replicated" Speicherplatz ein.

Ein populärer Betriebsmodus ist hierbei "Distributed Replicated". Dabei verteilt sich ein GlusterFS-Volume auf mindestens vier Knoten und zu jeder Datei existieren zwei Kopien. Geht der Speicher zur Neige, kann der Administrator ein neues Knotenpaar hinzufügen und das Volume auf sechs, acht oder zehn Knoten erweitern. Ein wichtiger Vorteil eines "Distributed Replicated"-Volumes: Beim Schreiben einer Datei auf das Volume sind nur zwei, beim Lesen nur ein Knoten beschäftigt. Kommen sehr große Dateien zum Einsatz, beispielsweise wenn GlusterFS als Speicher für virtuelle Maschinen arbeitet, kann der Verwalter das sogenannte "Sharding" einschalten. Das zerlegt die gesicherten Dateien in kleinere Bruchstücke. Somit verteilen sich kleine I/O-Operationen innerhalb einer großen Datei auf mehrere Shards und damit auf andere Gluster-Knoten.

"Dispersed Volumes" sparen Kapazität ein, da sie keine vollständigen Kopien der Daten, sondern verteilte Blöcke mit zusätzlicher Paritätsinformation sichern – eine Art Raid 6 auf Dateiebene. Gluster unterstützt Dispersed Volumes nur in bestimmten Konstellationen und Knotenzahlen, wie beispielsweise sechs Knoten (4+2), elf Knoten (8+3) oder 20 Knoten (16 + 4). Dispersed Volumes arbeiten zwar platzsparend, aber erheblich langsamer als Distributed/Replicated Volumes. Schreibzugriffe belegen alle Knoten, während Lesezugriffe die Gesamtzahl der Knoten minus Paritätsknoten beschäftigen. Somit generieren Dispersed Volumes auch eine höhere CPU-Last auf den GlusterFS-Knoten.

GlusterFS dient oftmals nicht nur als gün­stiger skalierender Speicher, sondern auch als Shared Storage eines Failover-Clusters. Wie üblich sollte ein solcher niemals aus einer geraden Zahl von Knoten bestehen, denn sonst kann es zum gefürchteten "Split Brain" kommen. Dabei stürzt nicht etwa ein HA-Knoten ab, sondern die Kommunikation zwischen den Clusterknoten fällt aus. Nun denken beide Seiten "Ich habe überlebt und arbeite weiter" und verursachen so möglicherweise ein großes Datenchaos.

Cluster-Setups nutzen daher drei oder fünf Knoten mit einer Quorum-Regel: "Wer sich in der Unterzahl befindet, stellt den Betrieb sofort ein". Fällt in einem Drei-Knoten-Cluster die Kommunikation mit einem Knoten weg, bleibt dieser stehen und die beiden, die noch voneinander wissen, arbeiten weiter.

Für diesen Modus kann GlusterFS mit einem "Replicated 3"-Volume arbeiten, verbraucht dabei aber gleich den dreifachen Speicher. Hier hilft ein sogenannter "Arbiter"-Knoten. Gluster legt ein Volume hierbei mit einer gespalteten Redundanz an: Die eigentlichen Daten werden nur auf zwei Knoten gespiegelt, während der dritte Arbiter-Knoten lediglich die Metadaten der zu sichernden Dateien, wie Dateiname, Shards, letzter Zugriff, Attribute und Rechte et cetera, sichert. Der Cluster ist somit vor Dateiverlust und Split Brain geschützt.

Als Datensicherungsfunktion unterstützt GlusterFS eine asynchrone Replikation oder auch Geo-Replikation, die selbst über langsame Netzwerke und VPNs funktioniert. Dabei spiegelt ein Master-Volume alle Änderungen auf ein Slave-Volume. Bei aktiver Geo-Replikation läuft das Slave-Volume im Read-Only-Modus und hört nur auf Änderungen vom Master. Stoppt der Verwalter im Desaster-Fall des Masters die Replikation, lässt sich das Slave-Volume regulär benutzen und kann seine Änderungen später zum reparierten Master zurücksenden. Master und Slave können unterschiedlich konfigurierte Volume-Typen verwenden.

In der Praxis kommt GlusterFS häufig zum Einsatz bei:

- IP-basierten Videoüberwachungen, die sehr viele, aber separate (und damit verteilbare) Streams speichern müssen.

- in Verbindung mit clustered Samba und Windows/Mac-Clients als klassisches Netzwerkdateisystem.

- als geräumiger, günstiger Speicher für Backups.

- als Shared Storage für den statischen Inhalt (HTML, Bilder et cetera) von Webserver-Farmen.

- als Shared Storage bei auf libvirt/kvm oder ovrit/kvm basierenden Virtualisierungslösungen.

Jeder Gluster-Knoten benötigt mindestens einen "Brick". Dabei handelt es sich technisch nur um ein Unterverzeichnis in einem lokalen Dateisystem. Bricks setzen ein Posix-Dateisystem voraus mit der Möglichkeit, erweiterte Attribute zu sichern (zum Beispiel EXT, XFS, BTRFS oder ZFS), und sollten nicht auf demselben Laufwerk wie das System-Root liegen. Dabei braucht nicht jeder Brick zwangsweise ein separates Dateisystem. Der Nutzer kann auch ein großes Dateisystem auf­setzen und mehrere Bricks einfach in verschiedenen Unterverzeichnissen oder Subvolumes (BTRFS) anlegen. Gluster-Knoten laufen in virtuellen Maschinen oder direkt auf dem Server. Die empfohlene Mindestausstattung sind zwei vCPUs, 4 GByte RAM und ein 1-GBit/s-Netzwerk. GlusterFS funktioniert zwar mit weniger Ressourcen, aber dann können Rebuilds sehr lange laufen und sich Zugriffe währenddessen stark verzögern.

Kommerzielle Installationen setzen auf XFS in Logical Volumes (LV) und erstellen pro Brick ein eigenes LV, gerne auch über Thin Provisioning. Die Methode erfordert etwas mehr Verwaltungsaufwand, erlaubt aber GlusterFS-Volume-Snapshots. Dazu erstellt das Dateisystem simultane LVM-Snapshots aller Bricks.

Anders als Ceph, das die Platten eines Knotens alle einzeln verwaltet, möchte GlusterFS die Platten des Systems möglichst in einem großen Raid5/6-Verband haben. Pro Volume kommt nur ein Brick pro Knoten zum Einsatz. Jeder Node kann mehrere Bricks für verschiedene Volumes mit unterschiedlichen xlators beherbergen. Dabei müssen die Volumes nicht zwangsweise alle Knoten verwenden. Ein wichtiger Vorteil von Gluster: Die Nodes dürfen unterschiedliche CPU, Arbeitsspeicher und Plattenkonfigurationen einsetzen. Die Performance richtet sich nach dem schwächsten Knoten. So können Gluster-Laufwerke im laufenden Betrieb die Hardware wechseln. Der Nutzer fügt einen neuen Node (bei DiRep-Volumes ein Paar) ein, erweitert das Volume, startet das Rebalance und nimmt im Anschluss den auszumusternden Knoten (oder das Paar) aus der Konfiguration.

Für Tests wie in diesem Beispiel erstellen sich Nutzer gerne eine Reihe von virtuellen Maschinen. Am schnellsten geht das, wenn Sie nur eine VM mit allen benötigten Paketen vorbereiten und diese Maschine dann mehrfach klonen. Gerade bei Tests mit Cluster-Software kann diese Methode jedoch furchtbar schiefgehen: Cluster-Setups wie auch GlusterFS verwenden eine eindeutige Maschinen-ID, um den Knoten zu identifizieren. Manche Lösungen errechnen die ID aus der MAC-Adresse der ersten Netzwerk-Karte, andere nutzen die von Systemd erzeugte ID in "/etc/machine-id". Wieder andere greifen auf die Seriennummer des BIOS zurück – was im Übrigen in der Praxis sehr oft bei physischen Clustern mit fehlerhaften AMI-Bios-Versionen schiefgeht.

Stellen Sie also beim Klonen sicher, dass jede VM erst einmal eine individuelle MAC-Adresse bekommt, denn sonst funktioniert das Netzwerk ohnehin nicht. Löschen Sie in jedem Klon nach dem ersten Start die Datei "/etc/machine-id", erstellen Sie eine neue via "systemd-ma-chine-id-setup" und starten Sie die virtuelle Maschine neu. Installieren und konfigurieren Sie Ihre Cluster-Software – in unserem Fall GlusterFS – erst, nachdem Sie eine neue MachineID erstellt haben. Um sicher zu gehen, prüfen Sie auf Ihren Knoten die Datei "/var/lib/glusterd/glusterd.info" und stellen Sie sicher, dass die Zeile "UUID=" bei jedem Knoten eine andere ID anzeigt.

Die üblichen Linux-Distributionen bringen alle nötigen GlusterFS-Pakete über den eingebauten Paketmanager mit. Der GlusterFS-Client benötigt die "Fuse"-Bibliotheken (File System in User Space). Die Speicherknoten installieren das "glusterfs-server"-Paket, das alle erforderlichen Dependencies über den Paketmanager einrichtet.

Für GlusterFS gibt es derzeit kein aktuelles grafisches "Point-and-Click"-Managementtool. Es gab ein Cockpit-Plug-in, das aber nicht mehr weiterentwickelt wird. Frühe Gluster-Versionen nutzten den Ovirt-Manager. Um die Verwaltungsarbeit mit vielen Nodes zu erleichtern, hilft das Tool "Gdeploy" auf Basis von Ansible. Hier schreibt der Nutzer die gewünschte Gluster-Konfiguration in eine YAML-Datei und gibt Gdeploy die Inventory-Liste mit den benötigten Gluster-Knoten mit.

Die "händische" Installation verläuft nach einem simplen Verfahren: Zuerst installieren Sie die Gluster-Server-Binaries via Paketmanager. Dann schalten Sie die Firewall des Knotens ab. Für die interne Kommunikation zwischen den Nodes setzt GlusterFS einen TCP-Port pro Volume und Knoten ein. Wer RHEL, Cent­OS oder Fedora verwendet, kann zudem auf Nodes, die ausschließlich für Storage zuständig sind, das SElinux komplett abschalten (deactivated, nicht permissive), um dessen zusätzliche Disk-IOs loszuwerden. Richten Sie eine zuverlässige Zeitsynchronisation aller Knoten via NTP oder cronny ein.

Danach geht es daran, einen oder mehrere Bricks zu erstellen. Für unser Test-Setup kommt ein großes Laufwerk mit XFS zum Einsatz, das pro Brick ein eigenes Unterverzeichnis anlegt. Fügen Sie die GlusterFS-Knoten über gluster peer probe zu einem Verbund zusammen. Einen Master gibt es bei GlusterFS nicht. Alle Nodes arbeiten gleichberechtigt. Der Befehl gluster peer status gibt Aufschluss darüber, ob die Knoten korrekt kommunizieren. Nicht erschrecken: Geben Sie bei einem Vier-Knoten-Gluster das Kommando gluster peer status ein, erhalten Sie die Antwort "Number of Peers: 3" – gemeint ist das als "die drei anderen und ich".

Im Anschluss legen Sie das erste Laufwerk über gluster volume create an. Auf das Kommando folgt der Name des Volumes, der Typ und die Liste der zu verwendenden Bricks. Letztere folgt dem Format "<node>:/<directory>". Besondere Konfigurationen des Volumes erledigt gluster volume set x. Das folgende Beispiel erstellt ein Distributed Replicated Volume auf vier Knoten und schaltet Sharding mit 16

MByte Shard-Größe ein:

Denken Sie immer daran, dass Sie auf einem Gluster-Knoten keine Daten direkt in ein Brick-Laufwerk kopieren dürfen. Wollen Sie direkt auf einem der Knoten auf das Volume zugreifen, mounten Sie es zunächst:

Dann können Sie via /mnt/gluster/vol1 auf den Inhalt des Volumes zugreifen. Um nicht alle Volume-Einstellungen individuell per volume set konfigurieren zu müssen, unterstützt GlusterFS Konfigurationsgruppen. Eine "Group" ist dabei nicht mehr als eine Textdatei mit allen Einstellungen.

Optimal arbeitet GlusterFS mit Linux-Systemen, die den GlusterFS-Fuse-Client einsetzen. Aber auch für Windows-Umgebungen lässt sich GlusterFS nutzen. Hier kommt ein geclusterter Samba-Server zum Einsatz. Die Windows-Systeme schreiben ihre Daten dann zwar nicht direkt auf die GlusterFS-Knoten, verteilen ihre IO-Last aber gleichmäßig auf die verfügbaren Samba-Server.

Dazu setzen Sie einen Samba-Server mit CTDB, der geclusterten Version von Sambas "Trivial Database System", auf. CTDB steuert die Zugriffe auf virtuelle IPs und kümmert sich darum, dass alle Samba-Server zeitsynchron arbeiten und dabei einheitliche Locking-Informationen nutzen. Zudem könnte CTDB die komplette "smb.conf" ersetzen und die Konfiguration in die Datenbank integrieren. In der Regel legen Nutzer aber lieber die Konfigurationsdateien von CTDB und Samba in ein Unterverzeichnis eines geteilten GlusterFS-Volumes.

Windows-Clients greifen dann ganz regulär auf einen Samba-Server zu, der sich hinter einer der virtuellen IPs von CTDB verbirgt. Samba regelt die Verteilung der SMB/CIFS-Zugriffe auf die verschiedenen Samba-Server und diese wiederum verteilen die Daten im GlusterFS.

Da sowohl Samba als auch GlusterFS mit vergleichsweise wenig CPU- und Memory-Ressourcen klarkommen, bedarf es keines separaten Samba-Server-Knotens. Dieser Dienst kann auf einigen ausgewählten GlusterFS-Knoten mitlaufen.

In der Praxis hat sich dabei Folgendes bewährt: Legen Sie auf einem Gluster-Volume ein Verzeichnis mit allen Konfigurationsdateien für CTDB und Samba an. Diese Dateien verlinken alle GlusterFS-Knoten, also beispielsweise "/gluster/volume/samba-conf/smb.conf" zu "/etc/samba/ smb.conf". So liegt die Cluster-Konfiguration an einer zentralen Stelle und steht dabei allen Knoten zur Verfügung.

GlusterFS optimiert mit den folgenden Kommandos das Volume für einen Samba-Server:

Dabei gibt es aber zwei kleine Stolperfallen: Der Befehlsteil "user.smb enable" schreibt freundlicherweise gleich einen passenden Freigabe-Eintrag in die Datei "smb.conf". Dabei überschreibt er leider den symbolischen Link zur gesharten "smb.conf". Erstellen Sie also diesen Link erst ganz am Ende. Zudem setzt GlusterFS die Freigabe als "Gluster native" in der "smb.conf" fest:

Der Pfad ist hier relativ zum GlusterFS-Volume angegeben. Nach unseren Erfahrungen haben neuere Versionen von Samba mit dem vfs-Objekt "glusterfs" jedoch Probleme. Mounten Sie daher auf allen Samba-Knoten das GlusterFS-Volume lokal und geben Sie es über ein vfs-Object "glusterfs_fuse" frei, dann mit der Pfadangabe zum Mountpoint:

Hängen Sie dann allen angebundenen Knoten beim Systemstart das GlusterFS-Volume über die Datei "/etc/fstab" nach folgendem Schema ein:

Nach einem ähnlichen Prinzip wie Samba richten Sie Gateway-Dienste für NFS (via NFS-Ganesha) ein. Dieses Setup mit nfs-ganesha und Pacemaker ist aufwändiger als die Kombo aus CTDB und Samba. Sie kommt zum Glück weniger häufig vor. Nur wenn Sie Legacy-Unix-Systeme (AIX, Solaris, HP-UX) oder "unixartige" Geräte ohne GlusterFS-Client (zum Beispiel IP-Überwachungskameras) verwenden, benötigen Sie die NFS-Gateway-Funktion. Alle anderen kommen eigentlich mit dem Linux-Fuse-Client (auch für BSD verfügbar) oder Samba zurecht.

Wer parallel zu File-Diensten Objekte via S3 auf Gluster-Volumes ablegen will, kann das ebenfalls mit einem simplen Gateway erledigen. Das alte "gluster-swift"-Modul aus frühen OpenStack-Zeiten hat dafür jedoch ausgedient. Etliche frühere Core-Entwickler des GlusterFS-Projekts arbeiten in der Zwischenzeit an Minio, einem kleinen flotten S3-Gateway. Das lässt sich ohne große Anpassungen mit einem shared-Filesystem als Backend betreiben, somit auch mit GlusterFS. Da Minio selbst wenig CPU- und Memory-Ressourcen verschlingt, kann es problemlos auf den GlusterFS-Storage-Knoten mitlaufen.

GlusterFS kann weiterhin als FileIO-Back­end für iSCSI-Laufwerke dienen. Da es als shared-Dateisystem aber nur über sehr begrenzte Write-Caching-Mechanismen verfügt, dürfen Sie keine Performancerekorde von iSCSI-Laufwerken auf GlusterFS erwarten. Für diese Funktion legen Sie einfach entsprechende Disk-Abbilder auf einem GlusterFS-Laufwerk an und nutzen diese als FileIO-Backend in einem der zwei verfügbaren iSCSI-Target-Dienste LIO oder TGT. Dabei kopieren Sie die iSCSI-Target-Konfiguration auf alle Knoten mit iSCSI-Target. Wichtig ist dabei, dass die ID einer iSCSI-LUN auf allen Knoten identisch sein muss. Der iSCSI-Client unter Windows oder Linux muss sich dann mit allen iSCSI-Servern verbinden, sodass der OS-eigene Multipath-Daemon die Verteilung der IO auf die verschiedenen Knoten vornimmt. Für iSCSI-Dienste empfehlen sich Gluster-Volumes mit eingeschaltetem Sharding, die nicht mit dem Dispersed-xlator arbeiten. Es gibt mit "gluster-block" ein Toolset, um den Umgang mit Blockspeicher auf GlusterFS zu vereinfachen. Die Entwicklung der Lösung hinkt momentan etwas hinterher und bei unserem Probelauf funktionierte das Setup mit gluster-block leider nicht.

Zu guter Letzt dient GlusterFS als verteilter und ausfallsicherer Speicher in Umgebungen mit Virtualisierung. Sowohl das aufwendigere, aber komfortable Ovirt als KVM-Management als auch die simple Virtualisierung über kvm/libvirt unterstützen GlusterFS als VM-Storage. Passende Zwei- oder besser Drei-Knoten-Hypervisor-Setups können damit Maschinen verteilen, im laufenden Betrieb umziehen und bei Rechnerausfällen die VMs im Failover neu starten. Auch GlusterFS-Laufwerke unter Virtualisierungsknoten sollten keinen Dispersed-Translator einsetzen, sondern Sharding verwenden.

Mit GlusterFS lassen sich günstig große und skalierbare Dateisysteme erstellen. Der softwaredefinierte Ansatz vermeidet den gefürchteten "Forklift Update", bei dem nach Ablauf der Garantiezeit ein altes Speichersystem ausgemustert und dessen Inhalt kompliziert und langwierig auf ein neues umgezogen werden muss. Knotenpaare lassen sich ohne Unterbrechung im laufenden Betrieb hinzufügen oder entfernen. Als verteiltes Dateisystem ohne große Cache-Möglichkeiten kommt GlusterFS weniger gut mit kleinen Write-IOs zurecht. Daher ist das Scale-Out-Dateisystem beispielsweise kein besonders guter Platz für klassische OLTP-Workloads wie SQL-Datenbanken. GlusterFS eignet sich aber besonders gut für große Dateisysteme mit vielen Clients, die bevorzugt über den nativen GlusterFS-Client darauf zugreifen. Selbst große Windows-Dateiserver stemmt das verteilte Dateisystem via geclustertem Samba.