Aufsetzen der Gluster-Server

Diese Seite dient derzeit dazu, das Vorgehen beim initialen Aufsetzen des Gluster-Servers zu dokumentieren (Frühjahr 2020).

Update Feb 2023: Seiet wird aktualisiert für gluster{5,6}.

Server-Maschinen

Wir nutzen derzeit sechs identische Maschinen (identische Hardware, Software und Konfiguration). Zwei stehen im Server-Raum, zwei im Durchgang zum Heizungskeller und zwei im Stützpunkt U4. Wir peilen Redundanz vom Grad 3 an, je drei der Server enthalten also die selben Daten (Spiegelung). Vorzugsweise sollten die Spiegelserver nicht im gleichen Raum stehen, so dass wir eine gewisse Sicherheit gegen Unfälle wie z.B. Feuer oder Stromausfall haben.

Alle Server haben

• eine 120GB SSD für das Betriebsystem (/boot, /root, /swap). Dabei ist /root eine eigene Partition /dev/sda1. /root und /swap sind LVM-Volumes die in der VG auf /dev/sda5 liegen. (Hinweis: Das Setup wirkt anachronistisch! eine Boot-Partition außerhalb von LVM wurde vor 20 Jahren noch zuweilen empfohlen, doch inzwischen ist LVM in GRUB2 implementiert – warum nutzen wir dieses Setup?)
• zwei 1TB SSDs (sdb, sdc)
• zwei 4TB rotierende Medien (sdd, sde) Wir werden zwei verschiedenen Gluster-Filesysteme nutzen: Die schnellen SSDs sollen die Homeverzeichnisse der Nutzer enthalten. Die langsameren aber größeren rotierenden Platten sollen die Tauschverzeichnisse und alles andere enthalten.

Schrittweise Dokumentation

Das Vorgehen folgt i.W. dem offiziellen Gluster-Installation-Guide ​https://docs.gluster.org/en/latest/Install-Guide/Overview/.

Referenz in Trac

​http://paedml.kg-fds.de/trac/milestone/Gluster%3A%20Gluster-Cluster%20ist%20eingerichtet

Betriebsystem

Die sechs Maschinen laufen unter Debian Linux 11 (Bullseye).

Maschinen vorbereiten

IPs

Die Server hören auf die IPs 10.3.0.{1,2,3,4,5,6}.

/etc/hostname

Individuell auf den vier Maschinen setzen: gluster{1,2,3,4,5,6} passend zu den IPs.

/etc/hosts

Auf allen Servern in /etc/hosts hinzufügen:

10.3.0.1 gluster1.kg-fds.de gluster1
10.3.0.2 gluster2.kg-fds.de gluster2
10.3.0.3 gluster3.kg-fds.de gluster3
10.3.0.4 gluster4.kg-fds.de gluster4
10.3.0.5 gluster5.kg-fds.de gluster5
10.3.0.6 gluster6.kg-fds.de gluster6

(ACHTUNG: Der Debian-Installer schreibt in /etc/hosts auch einen Eintrag für 127.0.1.1, der auf den lokalen Hostnamen verweist. Darauf achten, falls die hosts-Datei per rsync zwischen den Rechnern kopiert wird!)

Die gleichen Daten liegt auf dem paedml und später auf allen Clients, die auf das GlusterFS zugreifen sollen.

Hinweis

Das Gluster-Manual empfiehlt ausdrücklich DNS!

NTP

Die Server brauchen synchrone Uhren. Wir nutzen NTP über systemd (timedatectl).

In /etc/systemd/timesyncd.conf unter [Time] eintragen:

NTP=ntp1.belwue.de ntp2.belwue.de ntp3.belwue.de

Funktion prüfen mit timedatectl status.

BIOS-Einstellungen

Nachholen

​https://docs.gluster.org/en/latest/Install-Guide/Setup-Bare-metal/

APT

Nötig??? Ist auskommentiert??

/etc/apt/apt.conf

#Acquire::http::Proxy "​http://proxysw.kg-fds.de:3128";

PPA einrichten

# apt install gnupg

(Scheint unter Debian bereits vorinstalliert zu sein.)

Dann siehe ​https://docs.gluster.org/en/latest/Install-Guide/Install/.

Einige nützliche Pakete

# apt install emacs parted

Trusted Pool einrichten

(nachtragen wie im Manual beschrieben)

Bricks einrichten

An der Stelle stellt sich die Frage: LVM oder nicht? Das etwas neuere Snapshot-Feature von Gluster nutzt die Snapshot-Eigenschaft von LVM. Soll dieses Feature genutzt werden, muss pro Brick ein „thin provisioned“ LVM volume eingerichtet werden.

Will man das Feature nicht nutzen (z.B. weil man seine Snapshots mit einem anderen Mechnismus macht, so wie wir derzeit), dann kann man sich LVM komplett sparen und die einzelnen Bricks direkt mit einem Filesystem formatieren.

Hinweis

Wird das Snapshot-Feature nicht benöigt, geht es direkt im Kapitel #Dateisysteme weiter!

Ich vermute wir werden die Gluster-Snapshots nicht nutzen, doch weil ich das zum jetzigen Zeitpunkt nicht sicher beurteilen kann, mache ich mal das „volle Programm“ und richte die Thin-Volumes ein. Das macht das Setup zwar unübersichtlicher, lässt uns aber alle Möglichkeiten offen.

In unserem Debian fehlt dafür ein empfohlenes Paket, daher:

Auf allen Servern:

# apt install thin-provisioning-tools

Ich orientiere mich an der Beschreibung hier: ​https://www.linuxsysadmins.com/create-thinly-provisioned-logical-volume/

Die Beschreibung im Gluster-Admin-Manual scheint nicht mehr ganz aktuell, man kann die Thin-Pools inzwischen in einem Schritt einrichten (ohne Daten- und Metadata-Volumes getrennt einrichten zu müssen).

Mögliche alte LVM-Labels löschen

Falls die eingesetzten Platten früher schon Teil eines LVM-Verbunds waren, beschwert sich LVM in den nächsten Schritten möglicherweise mit einem „Device X excluded by a filter“. Da wir alle unsere Platten komplett neu beschreiben wollen, löschen wir vorsorglich alle eventuell existierenden LVM-Labels darauf:

wipefs -a /dev/sdb
wipefs -a /dev/sdc
wipefs -a /dev/sdd
wipefs -a /dev/sde

LVM physical volumes

Die geplanten Platten für LVM verfügbar machen:

Auf allen Servern:

# pvcreate /dev/sdb
  Physical volume "/dev/sdb" successfully created.
# pvcreate /dev/sdc
  Physical volume "/dev/sdc" successfully created.
# pvcreate /dev/sdd
  Physical volume "/dev/sdd" successfully created.
# pvcreate /dev/sde
  Physical volume "/dev/sde" successfully created.

LVM volume groups

Hinweis aus dem Manual

"It is recommended that only one VG must be created from one storage device."

Auf allen Servern:

# vgcreate gfs_vg_b /dev/sdb
# vgcreate gfs_vg_c /dev/sdc
# vgcreate gfs_vg_d /dev/sdd
# vgcreate gfs_vg_e /dev/sde

LVM thin pools

Auf jeder VG wird ein Thin Pool einge richtet, von dem später der Speicherplatz für die Thin-Volumes und mögliche Snapshots genommen werden.

Auf allen Servern:

# lvcreate -l 100%FREE --thinpool gfs_thinpool_b gfs_vg_b
# lvcreate -l 100%FREE --thinpool gfs_thinpool_c gfs_vg_c
# lvcreate -l 100%FREE --thinpool gfs_thinpool_d gfs_vg_d
# lvcreate -l 100%FREE --thinpool gfs_thinpool_e gfs_vg_e

LVM wählt hier selbst eine Größe für die Metadata-Daten, ich hätte eh keinen Anhaltspunkt, wie man die besser wählen sollte. Gleiches gilt für die Größe der Extents, die sich an der Plattengröße orientiert.

Eine Maßnahme ist aber, das „Zeroing“ abzuschalten, so dass die Extents schneller bereitgestellt werden können:

Auf allen Servern:

# lvchange --zero n gfs_vg_b/gfs_thinpool_b
# lvchange --zero n gfs_vg_c/gfs_thinpool_c
# lvchange --zero n gfs_vg_d/gfs_thinpool_d
# lvchange --zero n gfs_vg_e/gfs_thinpool_e

Hinweis: Ob Zeroing ein- oder ausgeschaltet ist, ist beim Output von lvs am "z"-Flag sichtbar.

LVM thin volumes

Nun wird pro „thin pool“ ein “thin volume“ eingerichtet, die dann endlich die Volumes sind, auf denen die Bricks aufgesetzt werden.

Wir könnten hier beliebige Größen angeben, da die ja nur virtuell sind (z.B. 1TB für die Homes und 4TB für share – oder auch doppelt so viel). Stichwort: Overprovisioning. Da wir damit gerade erst Erfahrungen machen, hätte ich aber gerne den Speicherplatz, den wir anpreisen, auch wirklich verfügbar. Daher machen wir die LVs nur so groß, dass sie sicher in die Pools (und damit in die VGs und damit in die PVs) passen.

Die Größe der LVs werden bei Thin-Volumes mit der Option „-Vvirtualsize“ angegeben. Leider ist die „%“-Notation dabei nicht implementiert, wir müssen also absolute Größen angeben.

(Nebenbemerkung: Eine Alternative ist, die Thin-Pools zunächst nicht so groß wie die VGs zu machen und "auto-extend" in der lvm.conf zu aktivieren. Das ist aber auch nur dann sinnvoll, wenn wir beim auto-extend einen Warnhinweis erhalten, etwa per Mail. Hier hoffe ich stattdessen auf CheckMK …)

Da wir den verfügbaren Speicherplatz nicht überschreiten wollen, schauen wir mittels lvs nach dem verfügbaren Speicherplatz in unseren Pools. Hier zum Beispiel:

# lvs
root@gluster1:~# lvs
  LV             VG          Attr       LSize    Pool           Origin Data%  Me
  gfs_thinpool_b gfs_vg_b    twi-aot--- <931,28g                       0,00   10
  gfs_thinpool_c gfs_vg_c    twi-aot--- <931,28g                       0,00   10
  gfs_thinpool_d gfs_vg_d    twi-aot---   <3,64t                       0,00   10
  gfs_thinpool_e gfs_vg_e    twi-aot---   <3,64t                       0,00   10

Das erste, was auffällt ist, dass je ca. 10% unserer 1TB/4TB beim Thin Provisioning für die Bürokratie draufgehen – ein weiterer Hinweis, LVM eher nicht zu verwenden, wenn wir das Snapshot-Feature nicht brauchen.

Ruft man lvcreate mit den angegebenen (ungefähren) Größen auf, so rundet es auf ganze Extents auf, so dass man doch wieder Warnungen wegen Overprovisioning enthält. Wir reduzieren daher bei der letzten Nachkommastelle um 1. In unserem Beispiel also:

Auf allen Servern:

# lvcreate -V 931,27g --thin gfs_vg_b/gfs_thinpool_b -n gfs_lv_b
# lvcreate -V 931,27g --thin gfs_vg_c/gfs_thinpool_c -n gfs_lv_c
# lvcreate -V 3,63t   --thin gfs_vg_d/gfs_thinpool_d -n gfs_lv_d
# lvcreate -V 3,63t   --thin gfs_vg_e/gfs_thinpool_e -n gfs_lv_e

Hier gibt es keine Fehlermeldung und wir dürften so gut wie 100% des freien Speicherplatzes getroffen haben.

Damit haben wir endlich die Volumes, in denen wir die Dateisysteme unserer Bricks einrichten können!

Dateisysteme

Wir richten nun für jede Brick ein XFS-Dateisystem ein. (Entweder im LVM thin volume, oder, wenn wir auf LVM verzichtet haben, direkt in den /dev/sdX-Devices):

Auf allen Servern:

# mkfs.xfs  -f -i size=512 -n size=8192  /dev/mapper/gfs_vg_b-gfs_lv_b
# mkfs.xfs  -f -i size=512 -n size=8192  /dev/mapper/gfs_vg_c-gfs_lv_c
# mkfs.xfs  -f -i size=512 -n size=8192  /dev/mapper/gfs_vg_d-gfs_lv_d
# mkfs.xfs  -f -i size=512 -n size=8192  /dev/mapper/gfs_vg_e-gfs_lv_e

• Die Option -f sorgt dafür, dass ein eventuell schon bestehendes Dateisystem auf den Bricks übeschrieben wird.
• Zur Option -i laut Manual: „The inode size is set to 512 bytes to accommodate for the extended attributes used by GlusterFS.“
• Zur Option -n schweigt sich das Manual aus, lauf Information von ​hier: „An XFS file system allows to select a logical block size for the file system directory that is greater than the logical block size of the file system. Increasing the logical block size for the directories from the default 4 K, decreases the directory I/O, which in turn improves the performance of directory operations.“
• Das Gluster-Manual empfiehlt noch die -d-Option, um Striping-Parameter zu setzen. Die sind aber laut ​der Quelle oben aber nur nötig, falls unter den Bricks ein RAID liegt.

Mountpoints

Auf allen Servern:

# mkdir -p /mnt/gluster/{b,c,d,e}

Unsere Dateisysteme hängen wir nun ein.

Auf allen Servern in /etc/fstab hinzufügen:

/dev/mapper/gfs_vg_b-gfs_lv_b /mnt/gluster/b  xfs rw,inode64,noatime,nouuid,nofail  0 1  
/dev/mapper/gfs_vg_c-gfs_lv_c /mnt/gluster/c  xfs rw,inode64,noatime,nouuid,nofail  0 1
/dev/mapper/gfs_vg_d-gfs_lv_d /mnt/gluster/d  xfs rw,inode64,noatime,nouuid,nofail  0 1
/dev/mapper/gfs_vg_e-gfs_lv_e /mnt/gluster/e  xfs rw,inode64,noatime,nouuid,nofail  0 1

• Die nouuid-Option ist nötig, weil die Snapshots offenbar die selbe UID haben wie das Original.
• Inode64 ist nötig, um die Inodes in der Nähe der Daten zu halten. Das ist bei den rotierenden Medien wichtig. Laut der Quelle oben: „With inode64 mount option inodes would be replaced near to the data which would be minimize the disk seeks.“
• nofail sorgt dafür, dass der Boot-Prozess durchläuft, auch wenn beim Mounten etwas schief läuft – so dass das Problem über ssh gelöst werden kann.
• 0 2 steht wie immer für "kein Dump im Fehlerfall" und "Filesystem-Check im zweiten Durchlauf". Letzteres kann beim Boot zu Verzögerungen führen, eventuell auch abschalten.

Achtung

Im Gluster-Admin-Handbuch folgt nun ein Kapitel über das Einschalten von POSIX-ACLs. Das ist offenbar obsolet! ACLs sind in den neueren Kernels defaultmäßig auch für XFS aktiviert. Das Hinzufügen der Option acl in der fstab führt sogar zu einem Mount-Fehler, der den Boot verhindern kann.

Dann mount -a und sicherstellen, dass dabei keine Fehler auftreten. Ev. auch Reboot, um sicher zu gehen, dass es auch nach dem nächsten Neustart noch klappt.

Aufgrund einer Sicherheitsbedingung (falls ein Brick-Volume nicht gemountet ist, soll es einen Fehler geben und nicht versehentlich der „nackte Mountpoint“ beschrieben werden) dürfen die Einsprungpunkte für die Bricks nicht direkt in einem Mountpoint liegen, sondern nur in einem Verzeichnis unterhalb. Daher:

Auf allen Servern:

# mkdir -p /mnt/gluster/{b,c,d,e}/brick/

Die Dateisysteme unserer Bricks sind nun erreichbar unter /mnt/gluster/{b,c,d,e}/brick.

GlusterFS aufsetzen

Mangels Erfahrung mit GlusterFS haben wir entschieden, unserer 4 Server halbe/halbe aufzuteilen: gluster1&3 sollen Spiegelserver werden, gluster 2&4 ebenfalls Spiegelserver. Sie sorgen für Redundanz. Die beiden 1&3 bzw. 2&4-Spiegel zusammen sorgen für mehr und schnelleren Speicherplatz.

Hinweis

Diese Variante verteilt jeweils komplette Dateien auf die verschiedenen Server. Die Gluster-Variante „dispersed“, die Dateifragmente über die Serverver verteilt, haben wir dabei bislang außer Acht gelassen.

Hinweis 2 (Split-Brain)

Level-2-Replicas sind anfällig für das „Split-Brain“-Szenario. Entsprechende Warnungen erhält man im nächsten Schritt. Das Split-Brain-Szenario: Die linken werden von den rechten Servern getrennt, laufen aber beide weiter, ohne koordiniert zu sein. Beide Server glauben, der jeweils andere sei down.

Dateizugriffe gehen unkontrollierbar zum einen oder anderen Cluster und erzeugen zwei Welten des Dateisystems, die sich nicht mehr zusammenführen lassen.

Bewertung: Da bei unserem Setup die linken/rechten Server jeweils in verschiedenen Räumen stehen, ist dieses Szenario durchaus real. Wir könnten es reduzieren, indem wir die Replicas jeweils im selben Raum machen, damit wird aber vielleicht der Performance-Gewinn kleiner ausfallen.

Ich bleibe erst mal bei dem geplanten Setup. Eine naheliegende Lösung ist, noch zwei identische Gluster-Server aufzustellen und die Replicas auf 3 zu erhöhen.

Gluster-Volumes

Wir bauen nun die Gluster-Volumes aus den Bricks zusammen. Wie geplant sind jeweils korrespondierende Bricks auf gluster1/3 (Serverraum) bzw. gluster2/4 (Heizungskeller) Spiegelserver. Das macht ein Split-Brain-Szenario sehr unwahrscheinich.

Wir weichen nun von der b/c/d/e-Notation ab und benennen die beiden Gluster-Volumes logisch „fast-storage“ (für die schnellen SSDs /dev/sd{b,c}) und „slow-storage“ (für die langsamen rotierenden Medien /dev/sd{d,e}).

Nur auf einem Server (z.B. gluster1):

# gluster volume create fast-storage replica 2 gluster1:/mnt/gluster/b/brick gluster3:/mnt/gluster/b/brick gluster1:/mnt/gluster/c/brick gluster3:/mnt/gluster/c/brick gluster2:/mnt/gluster/b/brick gluster4:/mnt/gluster/b/brick gluster2:/mnt/gluster/c/brick gluster4:/mnt/gluster/c/brick

# gluster volume create slow-storage replica 2 gluster1:/mnt/gluster/d/brick gluster3:/mnt/gluster/d/brick gluster1:/mnt/gluster/e/brick gluster3:/mnt/gluster/e/brick gluster2:/mnt/gluster/d/brick gluster4:/mnt/gluster/d/brick gluster2:/mnt/gluster/e/brick gluster4:/mnt/gluster/e/brick

Ab jetzt sind gluster1&3 bzw. gluster2&4 Spiegelserver, ansprechbar von außen über die GlusterFS „fast storage“ und „slow-storage“.

Die Dateien werden gleichmäßig auf gluster1 und 3 bzw. gluster 2 und 4 verteilt.

Prüfen mittels gluster volume info auf allen Servern. Insbesondere auf die Reihenfolge der Bricks achten! (Je zwei aufeinanderfolgende sind die Spiegel.)

Bleibt nur noch, die Volumes zu starten.

Auf *einem Server*:

# gluster volume start fast-storage
# gluster volume start slow-storage

Prüfen mittels gluster volume status.

---

Die Inhalte dieser Wiki-Seite erscheinen, (wo anwendbar und nicht anderweitig angegeben), unter einer Creative-Commons-Lizenz CC BY NC SA 3.0 Germany. Urheber: Dr. R. Kupper.