| Version 19 (modified by , 5 years ago) ( diff ) |
|---|
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
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.
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 einrichten
Nun wird pro „thin pool“ ein “thin volume“ eingerichtet, die dann endlich die Volumes sind, auf denen die Bricks aufgesetzt werden.
Auf allen Servern:
#
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.
