[[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}. Update Jun 2024: Seite wird aktualisiert nachdem die Root-Platte von gluster1 gestorben war. == 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 haben Redundanz vom Grad 3, 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. Das ist erfüllt: Spiegelserver sind gluster1,3,5 sowie gluster2,4,6. Je einer steht im Heizungskeller, einer im Serverraum und einer um Stützpunkt U4. Alle Server haben - eine 120GB oder 240GB SSD für das Betriebsystem (/boot, ev. /root, /swap). Bei gluster2-4 ist /boot eine eigene Partition auf der Rootplatte. / und /swap sind LVM-Volumes die in der VG auf /dev/sda5 liegen. Bei gluster5,6 und dem neu aufgesetzten gluster1 liegt / direkt auf der Platte ohne LVM und ohne separate /boot-Partition. - zwei 1TB SSDs (sdb, sdc) - zwei 4TB rotierende Medien (sdd, sde) Wir nutzen zwei verschiedenen Gluster-Filesysteme: Die schnellen SSDs halten derzeit die Homeverzeichnisse der Nutzer und das data-Verzeichnis von Nextcloud. Die langsameren aber größeren rotierenden Platten halten derzeit die Tauschverzeichnisse. == 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 GNU/Linux. ==== Grundsystem installieren Den aktuellen Debian-Netinstaller herunterladen und starten. Bei der Installation alles abwählen, das mit Desktop zu tun hat. Nur SSH-Server und Systemwerkzeuge auswählen. ==== System aktualisieren Nach dem Boot: {{{ # apt update # apt full-upgrade }}} === Maschinen vorbereiten === Einige nützliche Pakete {{{ # apt install emacs parted }}} ==== 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 Einträge liegen 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"; ==== apt-repository für aktuelles glusterfs einrichten {{{ # apt install gnupg }}} Dann siehe https://docs.gluster.org/en/latest/Install-Guide/Install/. ==== Check-MK-Client einrichten - aus Check-MK herunterladen oder von einem anderen Server rüberkopieren. - 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 -i size=512 -n size=8192 /dev/mapper/gfs_vg_b-gfs_lv_b # mkfs.xfs -i size=512 -n size=8192 /dev/mapper/gfs_vg_c-gfs_lv_c # mkfs.xfs -i size=512 -n size=8192 /dev/mapper/gfs_vg_d-gfs_lv_d # mkfs.xfs -i size=512 -n size=8192 /dev/mapper/gfs_vg_e-gfs_lv_e }}} - Falls ein schon bestehendes Dateisystem auf den Bricks überschrieben werden soll, die Option `-f` hinzufügen.) - 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: {{{ # Gluster bricks: /dev/mapper/gfs_vg_b-gfs_lv_b /mnt/gluster/b xfs rw,inode64,noatime,nouuid,nofail 0 2 /dev/mapper/gfs_vg_c-gfs_lv_c /mnt/gluster/c xfs rw,inode64,noatime,nouuid,nofail 0 2 /dev/mapper/gfs_vg_d-gfs_lv_d /mnt/gluster/d xfs rw,inode64,noatime,nouuid,nofail 0 2 /dev/mapper/gfs_vg_e-gfs_lv_e /mnt/gluster/e xfs rw,inode64,noatime,nouuid,nofail 0 2 }}} - Die nouuid-Option ist nötig, weil die Snapshots offenbar die selbe UID haben wie das Original. - Inode64 ist XFS-spezifisch und erlaubt (viel) größere INode-Nummern. Das verhindert erstens, dass komische "Disk-Full-Fehler" auftreten, obwohl noch genügend Platz ist (nur weil die Zahl der INodes erschöpft ist) und außerdem können so die Inodes in der Nähe der Daten gehalten werden. 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 Unsere 6 Server fahren ein „distribute 2, replicate 3“-Setup. Die Daten sind über gluster1&2 verteilt, was für mehr Speicherplatz und schnellere Zugriffe sorgt, da die Last auf zwei Server verteilt ist. Gluster1,3,5 sowie gluster2,4,6 sind Spiegelserver. Sie sorgen für Redundanz und damit für Datensicherheit. Lesezugriffe müssten dadurch ebenfalls beschleunigt werden, Schreibzugriffe aber verlangsamt, da die Daten zwischen den drei Spiegelservern abgeglichen werden müssen. 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. ==== 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)]]