Das verteilte Dateisystem GlusterFS erzeugt riesige Speicherverbände. Diese sind arbeiten schnell und ausfallsicher und basieren dabei lediglich simpler Hardware.

Max Lessel

Im Teil 4 der Serie »NAS im Eigenbau« stand noch, dass Cluster-Szenarien recht komplex ausfallen können, was in der Zwischenzeit nicht mehr ganz korrekt ist. »Gluster FS« ist ein so genanntes »Distributed Replicated Scale Out NAS«-Filesystem. Gluster verteilt Daten über mehrere Nodes (distributed) und erreicht dadurch eine enorme Performance. Die Kommunikation zwischen den Nodes erfolgt über ein reguläres IP-LAN oder Infiniband. Gluster unterstützt zudem Datenspiegelung (replicated) für ausfallsichere Szenarien. Beide Betriebsmodi lassen sich koppeln (distributed replicated).

Um die maximale Leistung zu erreichen, greifen Applikations-Server mit Hilfe des Gluster-Clients auf ein Dateisystem zu. So verteilen sich die IOs vom Client aus direkt auf alle Nodes. Einen »Head- oder »Control«-Node braucht Cluster nicht. Jeder Node im Cluster-Verband – egal ob Client oder Server – kennt den Hash-Algorhytmus zur Dateiverteilung und weiß daher, welche Datei oder welcher Block auf welchem Node liegt. Alternativ verfügt GlusterFS über einen integrierten NFS-Server. Auch die Freigabe eines Gluster-Volumes über SMB/CIFS ist möglich. Die Verteilung der Daten erfolgt auf File-Ebene, was bei kleineren Dateien sehr gut funktioniert. Wer mit großen Dateien arbeitet, kann einen Stripe-Modus verwenden, bei dem GlusterFS die Daten blockweise auf die Nodes verteilt.

Einsatzgebiet

Mit Gluster lässt sich im Prinzip ein nahezu endlos skalierbarer (bis 72 Brontobyte) Fileserver einrichten. Als Storage-Nodes genügen simple Linux-Server mit RAID-Controllern und SATA-Laufwerken. Gluster-Lösungen kommen daher schon jetzt verstärkt in Backup- und Archivarchitekturen und als skalierender Fileserver im Linux-Umfeld zum Einsatz. Auch Cloud-Dienste wie Dropbox-ähnliche Lösungen lassen sich mit Gluster gut abbilden.

Red Hat wird Gluster (kommerziell: Red hat Storage Server) zudem im Bereich der Virtualisierung verwenden. Hypervisor-Nodes mit lokalen Platten und dem verteiltem Dateisystem sorgen dabei für ausfallsichere virtuelle Maschinen ohne teures SAN.

Gluster-Setup

Für einen Test des Gluster-Dateisystems hat speicherguide.de ein simples Test-Szenario mit virtuellen Maschinen aufgebaut, dass jeder Interessierte problemlos nachstellen kann. Die Basis ist ein PC/Server mit mindestens acht GByte RAM und einer Virtualiserungslösung. Das kann sowohl eine Vmware Workstation als auch »Virtualbox«, »KVM« oder »Xen« sein. Im Labor nutzt speicherguide.de einen Quad-Core-Server mit 24 GByte RAM unter »Red Hat Enterprise Linux 6.4«, der virtuelle Maschinen über KVM/Libvirt verwaltet.

Für die Gluster-Nodes richten wir insgesamt vier virtuelle Centos-6.4-Server (Basic-Setup) ein, mit je vier GByte RAM (1 GByte reicht zum Testen auch), ein vCPU, Bridging-Network und erst einmal einer virtuellen acht GByte großen Platte. Wichtig dabei: Die vier Systeme werden alle neu installiert (via CentOS-Paketdateien auf einem Web-Server und Kickstart-File für die automatisierte Installation). Für dieses Szenario darf der Verwalter nicht eine Maschine einrichten und drei Mal klonen.

Jedes System verfügt über eine Unique System ID. Diese verwendet Gluster, um die Nodes zu identifizieren. VM-Klone übernehmen die ID des Originals und das Gluster-Setup misslingt. Ein hilfreiches Tool ist hier übrigens »ClusterSSH«, das die Eingaben von einem Terminal auf alle vier Systeme übertragen kann.

Jedes System bekommt einen per DNS auflösbaren Namen und eine statische IP-Adresse. Nach dem Basis-Setup erhält jedes System zur Boot-Disk ein weiteres Laufwerk (gleiche Größe für alle Nodes). Dieses wird später den eigentlichen Datenbereich des Gluster-Volumes stellen.

Um Kommunikationsprobleme unter den Nodes zu vermeiden, schalten wir in den VMs sowohl SE-Linux (Security Enhanced Linux) als auch die Firewall aus:

Dazu gibt es folgende Änderungen. In der Datei: /etc/selinux/config

Den Eintrag SELINUX=enforcing auf SELINUX=permissive stellen. Die Firewall lässt sich wie folgt abschalten:
service iptables stop
chkconfig iptables off

Anschließend empfiehlt es sich, die Distribution auf den aktuellen Stand anzuheben, gefolgt von einem Neustart (der nötig ist um SE-Linux abzuschalten).
yum update

Die Gluster-Binarys lassen sich nicht über das Standard-Repository von Centos herunterladen. Das Fedora-Project offeriert hierfür ein eigenes Repository: »Extra Packages for Enterprise Linux« (EPEL):
rpm -i
http://download.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm

Aktuell liegt EPEL in der Version 6.8 vor. Nach einem Update wird der Link nicht mehr funktionieren. Also vor der Installation bitte auf:
http://download.fedoraproject.org/pub/epel/6/86_64

Nach dem Paket epel-release suchen und die Versionsnummer entsprechend anpassen. Jetzt lässt sich der Gluster-FS-Server einrichten:
yum install glusterfs-server

Sollen Gluster-Volumes über NFS erreichbar sein, müssen die nfs-utils eingerichtet werden:
yum install nfs-utils

Jetzt starten Sie die Daemons vom RPC-Service und vom Gluster-Server und aktivieren den Autostart der Dienste:
service rpcbind start
chkconfig rpcbind on
service glusterd start
chkconfig glusterd on

Dann werden die jeweiligen Datenplatten der vier Nodes eingerichtet. Je nach Virtualisierung heißt das zweite Laufwerk /dev/sdb, /dev/vdb oder /dev/hdb. Erstellen Sie über fdisk eine Partition, welche das komplette Laufwerk belegt und formatieren diese. Red Hat empfiehlt XFS als physisches Dateisystem (dazu muss man zuvor noch die xfsprogs nachinstallieren). Für das simple Test-Setup genügt aber auch ext4. Binden Sie das Dateisystem unter /brick/ ein und passen Sie /etc/fstab entsprechend an:
/dev/vdb1 /brick ext4 defaults 0 0

Wenn das erledigt ist (und hier hilft ClusterSSH ungemein) kann das eigentliche Gluster-Setup erfolgen:

Partnervermittlung

Auf dem ersten Node (node1.local) des Verbands fügt der Verwalter die Nodes hinzu:
gluster peer probe node2.local
gluster peer probe node3.local
gluster peer probe node4.local

Diese Kommandos müssen ohne Fehler ablaufen und den jeweiligen Node-Namen via DNS auflösen können. Steht der Cluster, lässt sich das Gluster-Volume als Stiped-Replicated erstellen:
gluster volume create vol01 replica 2 transport tcp node1:/brick node2:/brick node3:/brick node4:/brick

Sobald das Volume zur Verfügung steht, können Sie es starten:
gluster volume start vol01

Linux-Clients im Netzwerk, welche den Gluster Client installiert haben (clusterfs, glusterfs-fuse und fuse) können nun auf das Volume zugreifen:
mount -t glusterfs node1:/vol01 /mnt

Clients ohne Gluster-Client können auch NFS-verwenden.
mount -t nfs -o vers=3 /node1:/vol01 /mnt

NFS verteilt den Client-Traffic nicht dynamisch auf alle Nodes. Sollten viele NFS-Clients zum Einsatz kommen, sollten diese ihre NFS-Mounts statisch auf alle vier Nodes verteilen.

Um SMB/CIFS nutzen zu können, muss auf einem der Nodes das /vol01-Verzeichnis via Samba freigegeben werden. Etwas komplexer ist das Cluster-Setup von Samba. Dabei muss der Verwalter die »triviale Datenbank« von Samba »TDB« gegen das clusterfähige Pendant CTDB austauschen und entsprechend konfigurieren. Dann können alle vier Nodes als SMB/CIFS-Cluster arbeiten.