[[PageOutline]] = Aufsetzen der Gluster-Server = Diese Seite dient derzeit dazu, das Vorgehen beim initialen Aufsetzen des Gluster-Servers zu dokumentieren (Frühjahr 2020). == Server-Maschinen == Wir nutzen derzeit vier identische Maschinen (identische Hardware, Software und Konfiguration). Zwei stehen im Server-Raum und zwei im Durchgang zum Heizungskeller. Wir peilen Redundanz vom Grad 2 an, je zwei 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 vier Maschinen laufen unter Debian Linux 10 (Buster). === Maschinen vorbereiten ==== IPs Die vier Server hören auf die IPs 10.3.0.{1,2,3,4}. ==== /etc/hostname Individuell auf den vier Maschinen setzen: `gluster{1,2,3,4}` passend zu den IPs. ==== /etc/hosts Identisch auf allen Servern: {{{ 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 }}} Die gleiche Datei 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`). Todo:: Einrichtung nachtragen ==== 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 }}} Dann siehe https://docs.gluster.org/en/latest/Install-Guide/Install/. === 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/sda wipefs -a /dev/sdb wipefs -a /dev/sdc wipefs -a /dev/sdd }}} ==== 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 }}} ==== 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. ==== Mountpoint Aufgrund einer Sicherheitsbedingung(???) 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/ }}} 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 /dev/mapper/gfs_vg_c-gfs_lv_c /mnt/gluster/c xfs rw,inode64,noatime,nouuid /dev/mapper/gfs_vg_d-gfs_lv_d /mnt/gluster/d xfs rw,inode64,noatime,nouuid /dev/mapper/gfs_vg_e-gfs_lv_e /mnt/gluster/e xfs rw,inode64,noatime,nouuid }}} (Die nouuid-Option ist nötig, weil die Snapshots offenbar die selbe UID haben wie das Original. Inode64 ist nötig, wenn die Bricks sehr groß werden.) Dann `mount -a` oder besser Reboot, um sicher zu gehen, dass es auch nach dem nächsten Neustart noch klappt. 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. Dateizugriffe gehen unkontrollierbar zum einen oder anderen Cluster und erzeuen zwei Welten des Dateisystems, die sich nicht mehr zusammenführen lassen. Bewertung: Da bei unserem Setup die linken/rechten Server nicht in verschiedenen Räumen stehen, sondern Replicas jeweils in beiden Räumen, ist dieses Szenario extrem unwahrscheinlich. Wir dürfen die Warnungen ignorieren. ==== 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 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 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. ---- [[CC_BY_NC_SA(Dr. R. Kupper)]]