Ausfallsicherer und hochverfügbarer Samba-Server
Einleitung: Hochverfügbarer Samba-Server
Je größer eine Firma bzw. deren Infrastruktur wird, desto unwahrscheinlicher ist es, daß man einen einzelnen Host im laufenden Betrieb updaten oder gar herunter fahren kann. Für den sicheren Systembetrieb ist es aber wesentlich, daß aktive Komponenten regelmässig gewartet bzw. aktualisiert werden können. Im Zuge von Updates und Wartung ist sehr häufig ein Reboot des betroffnene Servers notwendig. Leider geht mit Reboots einher, dass Anwender nicht auf die IT-Dienste des Servers zugreifen können.
In diesem Tutorial werden wir einen Ausfallsicherer Samba-Server mit LVM, Gluster-FS sowie Pacemaker/Corosync einrichten und konfigurieren.
Konzeptioneller Ansatz
Um selbstverständliche Dienste wie Windows-Freigaben (etwa für Team-Laufwerke oder andere Shares) ausfallsicher und mit hoher Verfügbarkeit zu gestalten, braucht es an sich nur 3-4 wesentliche Komponenten:
- 2 identische Hosts
- Ein oder mehrere gespiegelte Dateisysteme sowie einen Mechanismus zur Synchronisierung der Daten
- LVM zur nahtlosen Erweiterung des Storage-Bereichs
- 100%-ige Erreichbarkeit eines der beiden Hosts über eine Cluster-IP-Adresse
- Samba für die Freigabe(n)
Wirklich wichtig für die nahezu 100-prozentige Verfügbarkeit ist, daß die beiden Hosts sich praktisch nichts teilen, was immer online sein muss.
Beispiel: Wenn wir das File-System mit den Freigaben auf eine zentrale Storage (Storage-SAN oder NAS) legen würden, so hätten wir einen Teil des Systems nur einmal vorrätig, so daß beim Fehlen dieses Bestandteils das Gesamt-System nicht mehr funktionieren würde. Das zentrale Storage wäre ein großer (und meist teurer) „Single Point of Failure“ (SPoF)
Daher: Die beiden Hosts werden also als exakte Klone voneinander betrachtet. Sie teilen sich nichts – zumindest nichts physisches. Dieses Prinzip des „shared nothing“ erreichen wir durch den Einsatz der Opensource-Software Gluster-FS, das das Dateisystem spiegelt.
Die einzige Ressource die entweder auf dem einen oder dem anderen Host vorhanden ist, ist die Cluster-IP (oder Service-IP) die mit Pacemaker/Corosync immer auf einem aktiven Host vorhanden ist und sich im Ernstfall binnen Sekunden auf den jeweils anderen Host übertragen läßt
Um das Dateisystem der beiden Hosts später auch im laufenden Betrieb erweitern zu können, legen wir die Partition mit den Dateien mittels LVM (logical volume manager) unter Linux an.
Voraussetzungen
Für alles Folgende setzen wir zwei identische (virtuelle) Server mit CentOS7 voraus. Diese sollten in etwa die gleichen Ressourcen in Bezug auf RAM und CPU haben. In Sachen Festplatten bzw. Partitionen sollten die beiden Hosts identisch sein. Dabei spielt es keine wirkliche Rolle ob die Linux-Hosts physische Server oder wie in unserem Fall virtuelle Server sind.
Für unser Beispiel nehmen wir an, daß die Linux-Server folgendermaßen heißen:
1 2 3 4 5 | 10.51.137.245 gstest01.itsc.local gstest01 10.51.137.246 gstest02.itsc.local gstest02 10.51.137.247 fileserver.itsc.local fileserver |
Diese drei Zeilen kommen in die /etc/hosts Datei.
Vorbereiten der Partitionen
Wir bereiten also 2 identische Hosts mit Minimal-Installation unter Centos 7 jeweils auf /dev/sda vor. Außerdem brauchen die Hosts ein zweites File-system /dev/sdb das in etwa identisch groß sein sollte
Im ersten Schritt legen wir mit „parted“ und „fdisk“
Schritt 1: Mit Parted und fdisk Partition anlegen:
1 2 | parted /dev/sdb mklabel -> gpt |
Anschließend legen wir eine Partition /dev/sdb1 unter /dev/sdb an und wählen als Partitionstyp “LVM”.
1 2 | fdisk /dev/sdb fdisk -> partition anlegen und Typ 31 auswählen |
Schritt 2: Volume Group und LVM anlegen
Wir legen nun zuerst ein „physical volume“ und anschließend eine Volume Group unter LVM an.
Mit dem folgenden Schritt erstellen wir auf der Partition /dev/sdb1 eine Volume Group mit Namen „storagevg“
1 | vgcreate storagevg /dev/sdb1 |
Schritt 3: Das eigentliche Logical Volume anlegen
1 | lvcreate --name storage01 --size 198G storagevg |
Der obige Befehl legt auf der Volume Group “storagevg“ das logische Volume „storage01“ mit 198 GB Speicher an.
Schritt 4: Formatieren und Einbinden des LVM
Unser frisch erstelltest LV heißt nun also „/dev/storagevg/storage01“. Auf diesem erstellen wir nun ein XFS_Dateisystem:
1 | mkfs.<a class="wpil_keyword_link" href="https://www.biteno.com/was-ist-das-xfs-filesystem/" title="xfs" data-wpil-keyword-link="linked">xfs</a> /dev/storagevg/storage01 |
Damit wir das Filesystem später auch nutzen können, legen wir den Mountpoint bzw. das Verzeichnis „/data“ an und mounten das LVM anschließend.
1 2 3 | mkdir /data mount /dev/storagevg/storage01 /data |
Damit das Filesystem auch nach dem nächsten Reboot wieder unter /data eingeängt wird, tragen wir folgenden Zeile in der /etc/fstab ein.
1 | /dev/storagevg/storage01 /data xfs defaults |
Installation von glusterfs unter CentOS 7
Damit wir später unsere identischen Partitionen auch synchron halten können, benötigen wir ein Gluster-Filesystem. Dafür installieren wir die folgenden Pakete unter Centos:
1 2 3 | yum -y install epel-release yum-priorities centos-release-gluster yum -y install glusterfs-server |
Anschließend aktvieren wir den Dienst und starten ihn
1 2 3 | systemctl enable glusterd.service systemctl start glusterd.service |
Zur Sicherheit schauen wir uns den Status an
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | [root@gstest01 ~]# glusterfsd --version <a class="wpil_keyword_link" href="https://www.biteno.com/was-ist-glusterfs/" title="glusterfs" data-wpil-keyword-link="linked">glusterfs</a> 3.12.9 # # status prüfen [root@gstest01 ~]# gluster peer probe gstest02 peer probe: success. # Status teil 2 [root@gstest01 ~]# gluster peer status Number of Peers: 1 Hostname: gstest02 Uuid: b8fb70b5-fa46-4b11-aaf7-c5697ca3d6da State: Peer in Cluster (Connected) |
Gluster-FS Volume erstellen
MIt dem folgenden Befehl erstellen wir nun ein Dateisystem “storage01” innerhalb von Gluster-FS, dass auf den Hosts gstest01 und gestest02 jeweils physisch unter /data liegt. Der Parameter „replica 2“ bedeutet, dass wir faktisch eine Spiegelung erstellen.
1 2 3 | [root@gstest01 ~]# gluster volume create storage01 replica 2 transport tcp gstest01.itsc.local:/data gstest02.itsc.local:/data force volume create: storage01: success: please start the volume to access data |
Das eigentliche Volume unter Gluster-FS muss nun noch auf einem (!) der beiden Hosts gestartet werden. Das erledigt der Befehl:
1 2 3 4 5 6 7 | #gluster volume start [root@gstest01 ~]# gluster volume start storage01 volume start: testvol: success |
[root@gstest01 ~]#
Glusterfs client installieren und mounten
Damit das gerade erstellte Gluster-Filesystem auch nutzbar wird, muss es auf beiden Hosts auch gemountet werden.
Hinweis: Bei der Installation des Gluster-FS- Servers ist der Gluster-FS client bereits mit enthalten.
1 | yum -y install glusterfs-client |
Anschließend legen wir ebenfalls auf beiden Hosts das Verzeichnis “/datastore” als Mountpoint an:
1 | mkdir /datastore |
Nun können wir das angelegte synchronisierte Verzeichnis /datastore auf jedem der Hosts mounten:
1 | mount.glusterfs gstest01:/storage01 /datastore |
Damit der Mount auch wieder nach einem Reboot da ist, nehmen wir den Befehl in die /etc/rc.d/rc.local auf.
1 2 3 4 5 6 7 | vi /etc/rc.d/rc.local #einfügen: /usr/sbin/mount.glusterfs gstest01:/storage01 /datastore chmod +x /etc/rc.d/rc.local systemctl enable rc-local |
Achtung wichtig: Bitte achten Sie unbedingt darauf, daß jeder Host das „eigene“ FileSystem mounted.
Also auf host „gstest01“:
1 | /usr/sbin/mount.glusterfs gstest01:/storage01 /datastore |
… und auf dem Host „gstest02“
1 | /usr/sbin/mount.glusterfs gstest02:/storage01 /datastore |
Zur Sicherheit rebooten wir nacheinander jeden Host einmal. Wenn danach das File-System und der gluster service wieder online sind, dann haben wir erfolgreich ein synchrones Filesystem mit Gluster-FS erstellt
Beim Wechsel bzw. Reboot kommt nun noch ein etwas nerviger Timeout . Während dieser Zeit kommt der verbliebene Host nicht wirklich schnell in die Puschen. Dies kann allerdings mit einem einfachen Einstellen des Timeouts von Gluster-FS erledigt werden.
1 2 3 | gluster volume info storage01 gluster volume set storage01 network.ping-timeout 10 |
Gluster-FileSystem testen
Wenn Sie nun das Gluster-Filesystem testen möchten, so legen Sie auf dem Host gstest01 im Verzeichnis /datastore eine Datei an. Diese sollte nach wenigen Augenblicken auf gstest02:/datastore auftauchen. Änderungen die Sie nun auf gstest02:/datastore an der Datei vornehmen, werden wiederum sofort nach gstest01:/datastore übertragen.
Ausfallsicherheit mit Corosync und pacemaker:
Damit wir von Clients nun noch permanent auf Samba zugreifen können, benötigen wir eine dritte, virtuelle IP-Adresse. Über diese IP bzw. den dazu passenden DNS-Namen greifen später die Benutzer auf das hoch verfügbare Samba-Verzeichnis zu. Dafür erstellen wir mit Corosync und Pacemaker folgende Konfiguration.
Wie auch für Gluster-FS sollten die beiden Hostnamen und IP-Adressen in der jeweiligen /etc/hosts auf beiden Nodes enthalten sein. Das können wir an dieser Stelle überspringen, da wir das schon weiter oben erledigt haben.
Schritt 1: Installation von Corosync und Pacemaker / pcs
Auf beiden Hosts installieren wir nun noch Pacemaker und Corosync:
1 2 3 | yum -y install pacemaker pcs systemctl enable pcsd.service systemctl start pcsd.service |
Während der Installation wird ein neuer User namens „hacluster“ angelegt: Diesem geben wir ein Passwort und merken es uns gut. Am besten gleich in die IT-Dokumentation schreiben….
1 | passwd hacluster |
(auf beiden Hosts – jeweils identisches Passwort…)
Schritt 2: Einrichtung von Pacemaker
Hinweis: Der nachfolgende Linux-Befehl ist nur auf einem der beiden Knoten notwendig. Dazu geben Sie das Passwort des Benutzers „hacluster“ von weiter oben ein
[root@gstest01 ~]# pcs cluster auth gstest01 gstest02
1 2 3 4 5 | pcs cluster auth gstest01 gstest02 Username: hacluster Password: gstest02: Authorized gstest01: Authorized |
1 2 3 4 | [root@gstest01]# pcs cluster setup --name cluster01 gstest01 gstest02 Destroying cluster on nodes: gstest01, gstest02... gstest01: Success gstest02: Success |
Schritt 3: Pacemaker Cluster starten
Als letzten Schritt starten wir nun das Pacemaker Cluster. Auch dies wird nur auf einem der beiden Server erledigt:
1 2 3 | [root@gstest01 ~]# pcs cluster start --all gstest02: Starting Cluster... gstest01: Starting Cluster... |
Schritt 4: Corosync und Pacemaker aktivieren
Damit die Dienste auch nach einem Reboot wieder starten, aktivieren wir sie mit systemctl:
1 2 | systemctl enable corosync.service systemctl enable pacemaker.service |
Schritt 5: Stonith und Quorum deaktivieren
Ein Cluster-Quorum und Stonith machen in der Regel erst ab 3 Hosts Sinn. Für unser 2-Server Setup sind sie nicht hilfreich. Daher deaktivieren wir sie:
1 2 | pcs property set stonith-enabled=false pcs property set no-quorum-policy=ignore |
Schritt 6: Virtuelle Service IP einrichten
Mit dem folgenden Befehl wird die Service-IP-Adresse für das Cluster angelegt. Die Ressource heißt hier “samba-ip” und hat die Adresse 10.51.137.247 (mit der Netzmaske 255.255.254.0)
1 | pcs resource create samba-ip ocf:heartbeat:IPaddr2 ip=10.51.137.247 cidr_netmask=23 op monitor interval=5s |
Schritt 7: Testen und Reboot
Mit “pcs status” können Sie jederzeit auf beiden Hosts ermitteln, wo die Service-IP-Adresse gerade läuft:
pcs status
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 | [root@gestest01 ~]# pcs status Cluster name: cluster Stack: corosync Current DC: gstest02 (version 1.1.18-11.el7_5.3-2b07d5c5a9) - partition with quorum Last updated: Tue Jul 10 16:49:05 2018 Last change: Tue Jul 10 12:56:42 2018 by root via crm_resource on gstest01 2 nodes configured 1 resource configured Online: [gstest01 gstest02] Full list of resources: samba-ip (ocf::heartbeat:IPaddr2): Started - gstest02 Daemon Status: corosync: active/enabled pacemaker: active/enabled pcsd: active/enabled |
Um die Funktion der Cluster-IP-Adresse zu testen, rebooten wir nun den Server, auf dem die aktuelle Cluster-IP sich gerade befindet. Wenn alles richtig konfiguriert wurde, so wird beim Shutdown des aktiven Servers die Service/Cluster-IP automatisch von Pacemaker und Corosync auf den zweiten Host übertragen. Testen können Sie das mit einem „ping“ von einem Windows-Host auf die Cluster-IP:
1 | ping –t 10.51.137.247 |
Installation von Samba
Zu guter Letzt installieren wir noch auf beiden Servern Samba als Dienst.
1 | yum -y install samba samba-client samba-common |
Die Datei /etc/samba/smb.conf passen Sie nun noch an Ihre Bedürfnisse an.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | [global] workgroup = WORKGROUP security = user guest account = nobody map to guest = bad user passdb backend = tdbsam #load printers = yes cups options = raw [datastore] path = /datastore guest ok = yes guest only = yes guest account = nobody browseable = yes |
Wie man für Samba die Datei /etc/samba/smb.conf so anpasst, daß sie mit personalisierten Benutzern zugreifen können, beschreiben wir in einem weiteren Tutorial hier im Blog.
Samba Dienste aktivieren und starten
Die beiden nachfolgenden Befehle aktivieren die für Samba notwendigen Dienste smb und nmb:
1 2 | systemctl enable smb.service systemctl enable nmb.service |
Abschließend starten Sie die beiden Linux-Dienste:
1 2 | systemctl restart smb.service systemctl restart nmb.service |
Firewalld für Samba anpassen
Sofern Sie unter Centos7 den firewalld-Dienst aktiviert haben, so sollten Sie die Zugriffe per SMB-Protkoll erlauben. Das erledigt der folgende Befehl:
1 2 | firewall-cmd --permanent --zone=public --add-service=samba firewall-cmd --reload |
Nun sollte von erlaubten Clients aus bzw. mit dem passenden Passwort der der Zugriff auf \\<hostname>\datastore möglich sein. Wer einen anderen Share-Namen möchte, ändert das entsprechend in der smb.conf.
Damit wir nun noch einen „schönen“ Namen für unsere Service-IP im Share-Namen nutzen können, erstellen wir einen entsprechenden Host-Eintrag im DNS – bspw. „fileserver“ für die Cluster-IP 10.51.137.247 aus unserem Beispiel von oben.
Damit können nun Anwender über den Freigabe-Namen \\fileserver\datastore auf ihre Dateien von nun an mit 99,99% Verfügbarkeit zugreifen.
Weiterführende Links zum Thema
- Dokumentation zu Gluster-FS https://docs.gluster.org/en/v3/
- Dokumentation zu Pacemaker http://clusterlabs.org/pacemaker/doc/
- Samba Dokumentation: https://www.samba.org/samba/docs/
- Lesenswerte (aber auch dickes) Buch zum Thema Hochverfügbarkeit unter Linux: https://www.amazon.de/Linux-Hochverf%C3%BCgbarkeit-Einsatzszenarien-Praxisl%C3%B6sungen-Linux-Server/dp/3836225425/ref=sr_1_1?
Fazit zum hochverfügbaren, ausfallsicheren Samba-Server
Wer die Kosten für die doppelten Ressourcen nicht scheut, kann mit den kostenfreien OpenSource-Produkten Pacemaker, Gluster-FS, LVM und Samba und einer Stunde Arbeit die Verfügbarkeit seiner IT-Services erheblich steigern.
Auch wenn das hier gezeigte Beispiel im echten Leben von Anwendern und IT-Verantwortlichen nicht so kritisch gesehen wird, so bleibt doch immerhin in der obigen Konstellation die Möglichkeit etwa Updates und Wartungsarbeiten während der normalen Arbeits- und Nutzungszeit durch den IT-Administrator durchführen zu lassen – anstatt dafür immer wieder Nachtschichten einlegen zu müssen.
