Tutorial

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.xfs /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 0 0

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

glusterfs 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 <volume-name>

&nbsp;

[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

 

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.