Mit E-Mail-Diensten muss sich jeder Administrator früher oder später einmal beschäftigen. Das zur CeBIT erscheinende ADMIN 02/2012 gibt dazu Praxis-Tipps und ... (mehr)

Klientel

Das erstellte Volume kann der Client nun mounten. Dazu muss man dort zunächst den Gluster Native Client installieren. Er bindet das Volume über Fuse ein [4], läuft somit vollständig im Userspace und ist Posix-konform. Der Gluster Native Client befindet sich in den gleichen Paketen, die auch die Server-Programme enthalten. Auf dem CentOS-Client installiert man folglich ebenfalls das Trio:

rpm -Uvh glusterfs-core-Version.x86_64.rpm
rpm -Uvh glusterfs-fuse-Version.x86_64.rpm
rpm -ivh glusterfs-geo-replication-Version.x86_64.rpm

Auf den ersten Blick erscheint das etwas zu viel des Guten. In GlusterFS kann jedoch jeder Rechner im Netzwerk gleichzeitig Server und Client spielen. So könnte jeder Rechner im Netz einen Teil seines Speicherplatzes an GlusterFS abgeben und dann selbst den großen Speicherpool anzapfen. Dann darf man allerdings nicht vergessen, auf dem (jetzt ehemaligen) Client auch die entsprechenden Ports zu öffnen.

Das eigentliche Mounten des Volumes funktioniert auf dem Client wie gewohnt. Im Beispiel hängt der Befehl

mount -t glusterfs 192.168.2.101:/Beispielvolume /mnt/glusterfs

das »Beispielvolume« im lokalen Verzeichnis »/mnt/glusterfs« ein. Soll das beim Start automatisch geschehen, hilft der Eintrag

192.168.2.101:/ beispielvolume /mnt/glusterfsglusterfs defaults,_netdev 0 0

in der Datei »/etc/fstab« . Zur Fehlersuche bei Problemen hilft es, das Log-Level hochsetzen:

192.168.2.101:/ beispielvolume /mnt/glusterfs glusterfs defaults,_netdev,loglevel=WARNING 0 0

Welchen Server man beim Mounten angibt, ist übrigens egal. Der Gluster Native Client holt sich von ihm nur die Konfiguration und kommuniziert ab da selbst mit den beteiligten Servern.

Der Gluster Native Client sorgt für eine bestmögliche Nebenläufigkeit und höchstmögliche Schreibgeschwindigkeit. Dummerweise gibt es ihn derzeit ausschließlich für Linux-Systeme. Man kann deshalb das Volume alternativ auch per NFS v3 einbinden. Tests haben die Entwickler aber auch hier nur unter Linux durchgeführt, wer etwa Windows 7 einsetzt, muss unter Umständen mit kleinen Stolperfallen rechnen. Um das Volume auf dem Client per NFS v3 einzubinden, stellt man zunächst sicher, dass alle notwendigen Werkzeuge installiert sind und nutzt dann unter Linux den Befehl:

mount -o mountproto=tcp -t nfs 192.168.2.101:/beispielvolume /mnt/glusterfs

Liefert der nur eine Fehlermeldung, stimmt etwas in der Netzwerkkonfiguration nicht.

Nachdem das Volume unter »/mnt/glusterfs« aufgetaucht ist, kann man es mit Dateien beladen. Diese verteilt GlusterFS nach dem Zufallsprinzip auf die einzelnen Bricks – im Beispiel also in die »/data« -Verzeichnisse der drei Server. Das kann man selbst kontrollieren, indem man sich auf den Servern anmeldet und in besagte Verzeichnisse linst. Mit dieser Arbeitsweise erreicht GlusterFS sehr hohe Schreib- und Lesegeschwindigkeiten. Dummerweise ist diese Methode alles andere als sicher: Fällt einer Server aus, sind auch alle dort gespeicherten Daten verloren. Da das nur selten gewünscht ist, kann GlusterFS neben solchen Distributed Volumes auch noch Volumes mit anderen Arbeitsweisen einrichten (siehe Kasten "Redundant gespeichert").

Redundant gespeichert

Im Gegensatz zu einem Distributed Volume kopiert ein Replicated Volume die angelieferten Dateien auf alle Server. Selbst wenn einer von drei Servern ausfällt, hat man so noch zwei weitere Duplikate der Datei in der Hinterhand. Ein solches Replicated Volume erzeugt man mit dem Befehl:

gluster volume create beispielvolume replica 3 transport tcp 192.168.2.101:/data 192.168.2.102:/data 192.168.2.103:/ data

Der Parameter »replica 3« weist GlusterFS dabei an, die zu speichernde Datei genau dreimal zu replizieren (im Beispiel also auf jedem Server eine Kopie abzulegen). Die GlusterFS-Entwickler empfehlen, diesen Wert auf die Anzahl der Bricks zu setzen, wobei die Bricks am besten auf verschiedenen Servern liegen sollten.

Ein Distributed Replicated Volume arbeitet nach dem gleichen Prinzip, repliziert die Daten aber nur auf einen Teil der Bricks. Im folgenden Beispiel:

gluster volume create beispielvolume replica 2 transport tcp 192.168.2.101:/data 192.168.2.102:/data 192.168.2.103:/data 192.168.2.104:/data

gibt es jede gespeicherte Datei zweimal, die wiederum auf jeweils einem der vier Server liegen. Ein Distributed Replicated Volume bietet folglich einen Kompromiss aus Datensicherheit und Geschwindigkeit. Der »replica« -Wert sollte dabei immer möglichst ein Vielfaches der vorhandenen Bricks sein. Um sicherzugehen, dass die replizierten Daten auch tatsächlich auf verschiedenen Servern landen, sollte man zudem in obigem Befehl zunächst die ersten Bricks eines jeden Servers, dann die zweiten Bricks eines jeden Servers, und so weiter auflisten. GlusterFS bildet dann intern passende Gruppen, die sogenannten Sub-Volumes.

Ein Striped Volume geht noch einen Schritt weiter als das Distributed Volume: Hier zerschneidet GlusterFS im Hintergrund jede angelieferte Datei und verteilt die entstandenen Stücke nach dem Zufallsprinzip auf die einzelnen Bricks. Das ermöglicht zwar sehr hohe Schreib- und Leseraten, fällt jedoch nur ein Server aus, sind sämtliche Daten dahin. Solche Volumes eignen sich folglich nur für große, temporäre Dateien. Erstellt sind sie via:

gluster volume create beispielvolume stripe 3 transport tcp 192.168.2.101:/data 192.168.2.102:/data  192.168.2.103:/data

Auch hier sollte der Wert hinter »stripe« der Anzahl der Bricks entsprechen. Ist das nicht der Fall, erhält man schließlich ein []Distributed Striped Volume, das die Dateistücke auf zwei oder mehr Bricks verteilt. Die Anzahl der Bricks sollte dabei ein Vielfaches des »stripe« -Wertes sein.

Beim derzeitigen Stand der Konfiguration darf jeder beliebige Client aus dem Netzwerk das Volume mounten. Um das zu verhindern, nimmt man auf dem Server die Gluster Management Console zu Hilfe:

gluster volume set beispielvolume auth.allow 192.168.2.*

Bei mehreren Clients hängt man ihre IP-Adressen einfach hintereinander oder nutzt wie hier das Sternchen als Platzhalter. Im Beispiel hätten damit nur noch die Rechner mit dem Präfix »192.168.2.« Zugriff. Alternativ kann man auch einzelnen Clients den Zugriff verbieten:

gluster volume set beispielvolume auth.reject 192.168.2.55 192.168.2.56

Diese beiden Clients können das »beispielvolume« zwar noch mounten, jedoch nicht mehr darauf zugreifen.

Größenwahn

Wenn der Platz im Volume zur Neige geht, kann man jederzeit im laufenden Betrieb einfach einen weiteren Server:

gluster peer probe 192.168.2.105

und ein Brick hinzufügen:

gluster volume add-brick beispielvolume 192.168.2.105:/export

Wer ein Distributed-Replicated- oder ein Distributed-Striped-Volume erweitert, muss ein Vielfaches des »replica« - respektive »stripe« -Wertes an neuen Bricks hinzufügen (siehe Kasten "Redundant gespeichert"). Analog dazu kann man auch während des Betriebs einen Brick abstöpseln:

gluster volume remove-brick beispielvolume192.168.2.103:/data

Das ist beispielsweise nützlich, wenn auf einem der Knoten ein Hardware-Defekt auftritt. GlusterFS entfernt dabei den Brick nur aus seiner Konfiguration. Die im betroffenen Brick gespeicherten Daten bleiben dort weiterhin liegen, sind aber nicht mehr vom Client aus erreichbar. Bei Distributed-Replicated- oder Distributed-Striped-Volumes muss man wieder ein Vielfaches des »replica« - respektive »stripe« -Wertes an Bricks abziehen, die zudem aus derselben Gruppe stammen müssen (siehe den Kasten "Redundant gespeichert").

Wenn man ein Volume vergrößert oder schrumpft, sind die darin gespeicherten Daten sehr wahrscheinlich nicht mehr optimal über die Server beziehungsweise Bricks verteilt. Man sollte daher anschließend immer noch ein Rebalancing durchführen:

gluster volume rebalance beispielvolume start

Dieser Befehl ist eigentlich nur eine Abkürzung für zwei andere Befehle, die der Kasten "Zwei Phasen" vorstellt.

Zwei Phasen

Die Rebalancierung eines Volumes läuft in zwei Phasen ab. Zunächst muss man die Struktur des Volumes anpassen lassen: Hat man einen neuen Brick hinzugefügt und speichert danach Dateien in ein bereits existierendes Verzeichnis, verteilt sie GlusterFS nur über die alten Bricks. Diese "Wissenslücke" schließt der Befehl:

gluster volume rebalance beispielvolume fix-layout start

indem er die Struktur des Volumes in den Konfigurationsdateien entsprechend anpasst. Die eigentlichen Daten bleiben dabei noch an ihren alten Positionen unangetastet liegen.

Die kann man nun in einem zweiten Schritt umschichten beziehungsweise migrieren:

gluster volume rebalance beispielvolume migrate-data start

Wie lange die Rebalancierung dauert, hängt in erster Linie von der Anzahl der gespeicherten Dateien in den Bricks ab. Den Fortschritt kann man sich via

gluster volume rebalance beispielvolume status

anschauen. Den gesamten Vorgang kann man auch per:

gluster volume rebalance beispielvolume stop

anhalten. Startet man ihn dann wieder mit dem obigen »start« -Kommando, setzt GlusterFS automatisch die Arbeit fort, beginnt also nicht nochmal von vorne.

comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2021