[[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.

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. 

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
}}}


















----

[[CC_BY_NC_SA(Dr. R. Kupper)]]