[[PageOutline]] = 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: Seite 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 }}} ==== Check-MK-Client einrichten - aus Check-MK herunterladen - per rsync auf die Server - mit `dpkg -i` installieren === Trusted Pool einrichten (nachtragen wie im Manual beschrieben: https://docs.gluster.org/en/latest/Administrator-Guide/Storage-Pools/) === 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. Auf allen Servern: {{{ # apt install lvm2 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 „-V|--virtualsize“ 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 [https://rajeshjoseph.gitbooks.io/test-guide/content/cluster/chap-Configuring_Gluster_for_Enhancing_Performance.html 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 [https://rajeshjoseph.gitbooks.io/test-guide/content/cluster/chap-Configuring_Gluster_for_Enhancing_Performance.html 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`. ---- [[CC_BY_NC_SA(Dr. R. Kupper)]]