Hochverfügbare Fileserver auf Samba Basis

In einem typischen Firmennetz haben wir Standard Dienste, wie DHCP, DNS, Domänen-Controller und eine Fileserver. Auf dem Fileserver werden im Laufe des Arbeitstages ständig Dateien geschrieben. Sollte der Fileserver ausfallen, haben wir ein kleines Problem. Meistens befinden sich große Datenmengen auf dem Server. Die Wiederherstellung kann Stunden dauern.
Aus diesem Grund wünschen sich einiger Unternehmer hochverfügbaren Fileserver. Beim Ausfall eines Servers können die Mitarbeiter weiter arbeiten.

Hier wird beschrieben, wie man eine Hochverfügbaren Fileserver auf Samba Basis aufsetzt. Es ist auch unerheblich, ob in Netz sich eine DC auf Windows Basis oder auf Linux Basis befindet. Wir können selbstverständlich nicht nur 2 Knoten (Server) aber auch 3 Knoten einsetzen.

Unser Netzwerk (Ausgangssituation)

Firmen-Netzwerk: 172.16.0.0/22
Domänen-Controller: dc1 (IP: 172.16.0.10)
Gateway: 172.16.0.1 (Die IP-Adresse der Firewall (Router))
DNS: IP-Adresse des DNS-Servers, z.B. des DC: 172.16.0.10

Daten zum Server1
Name: brick1deb
Domain: mono.plan
IP: 172.16.0.101/22
Gateway: 172.16.0.1
DNS: 172.16.0.10
Zweite Festplatte: /dev/sdb1

Daten zum Server2
Name: brick2deb
Domain: mono.plan
IP: 172.16.0.102/22
Gateway: 172.16.0.1
DNS: 172.16.0.10
Zweite Festplatte: /dev/sdb1

Floating-IP: 172.16.0.100

Gewünschte Name des Fileservers: FS1

Gebraucht wird noch eine IP-Adresse, wir nennen die Floating-IP: 172.16.0.100
Die IP-Adresse wird den Ort wechseln, abhängig von dem Status der Bricks, bedeutet, es kann auf dem Brick1deb oder auch auf dem Brick2deb sein.

Jeder Server besitzt mindestens 2 Festplatten. Die zweite Festplatte nutzen wir für den Fileserver. Hier werden die Mitarbeiter die Daten in der entsprechenden Freigabe speichern.
Auf beiden Servern wird eine Partition /dev/sdb1 erstellt. Danach bitte die Partitionen formatieren.

root@brick1deb:~# cfdisk /dev/sdb
root@brick1deb:~# mkfs.ext4 /dev/sdb1

root@brick2deb:~# cfdisk /dev/sdb
root@brick2deb:~# mkfs.ext4 /dev/sdb1

Auf beiden Servern wird ein Ordner /data und ein Ordner /datastore erstellt.

root@brick1deb:~# mkdir /data
root@brick1deb:~# mkdir /datastore

root@brick2deb:~# mkdir /data
root@brick2deb:~# mkdir /datastore

Auf beiden Servern wird die Datei /etc/fstab bearbeitet. Die Partition /dev/sdb1 sollte beim Neustart gemountet werden. Wir starten den Server neu bzw. den folgenden Befehl führen wir aus, mount -a

/dev/sdb1 /data ext4 defaults 0 0

Auf beiden Servern wird noch die Datei /etc/hosts bearbeitet. Die Namen der Bricks werden eingetragen, und zwar für die Replikation. Die Replikation wird im internen Netz stattfinden.

172.16.0.101 brick1deb.mono.plan brick1deb
172.16.0.102 brick2deb.mono.plan brick2deb

Auf beiden Servern im Ordner /data erstellen wir noch zusätzlich ein Unterordner, am besten so wie die Server heißen, aber das ist jedem selbst überlassen.

root@brick1deb:~# mkdir /data/brick1deb

root@brick2deb:~# mkdir /data/brick2deb

Gluster Installation und Konfiguration

Auf beiden Servern installieren wir Gluster Pakete. Danach aktivieren und starten wir diesen Dienst

root@brick1deb:~# apt install glusterfs-server
root@brick1deb:~# systemctl enable glusterd.service
root@brick1deb:~# systemctl start glusterd.service

root@brick2deb:~# apt install glusterfs-server
root@brick2deb:~# systemctl enable glusterd.service
root@brick2deb:~# systemctl start glusterd.service

Auf einem Server. Es wird folgender Befehl, in unserem Fall auf dem Server brick1deb ausgeführt. Es wird davon ausgegangen, dass die Firewall ausgeschaltet ist, bzw. bestimmte Ports geöffnet sind.

root@brick1deb:~# gluster peer probe brick2deb

Auf beiden Servern. Wir können gleich den Status überprüfen.

root@brick1deb:~# gluster peer status

Auf einem Server. Ein Volume mit dem Namen vol1 wird angelegt und danach auch gestartet, in unserem Fall machen wir das auf dem Server brick1deb.

root@brick1deb:~# gluster volume create vol1 replica 2 brick1deb:/data/brick1deb brick2deb:/data/brick2deb

Wir bekommen auch eine Warnung. Der Grund ist, dass Hochverfügbarkeit mit 2 Knoten kann unter bestimmten Umständen zu Split-Brain führen. Im Grunde genommen sollte man mindestens 3 Bricks nutzen, um sicherzugehen. Bei 2 Bricks muss man noch zusätzlich bestimmte Parameter setzen. Das wird später noch beschrieben.

Sollten Probleme bei der Erstellung des Volumes vol1 entstehen, kann man den Befehl mit dem Parameter --force nutzen.

root@brick1deb:~# gluster volume create vol1 replica 2 brick1deb:/data/brick1deb brick2deb:/data/brick2deb --force
root@brick1deb:~# gluster volume list
root@brick1deb:~# gluster volume start vol1

Gluster hat viele Aufrufparameter, mit diesen 3 erhalten Sie ein paar Informationen.

# gluster volume list
# gluster volume status
# gluster volume info

Auf beiden Servern mounten wir das vol1 mit glusterfs

root@brick1deb:~# mount -t glusterfs -o acl brick1deb:/vol1 /datastore/

root@brick2deb:~# mount -t glusterfs -o acl brick2deb:/vol1 /datastore/

Wir können jetzt die Funktion des Dienstes gluster testen. Es wird auf einem Server unter /datastore ein Ordner bzw. eine Datei erstellen. Auf dem anderen müssten der Ordner und die Datei sichtbar sein.

root@brick1deb:/datastore# mkdir Ordner
root@brick1deb:/datastore# touch Testdatei.txt

root@brick2deb:/datastore# ls -l

Auf beiden Servern wird noch einmal die Datei /etc/fstab bearbeitet. Das vol1 sollte gleich beim Start des Servers gemountet werden. Auf dem ersten Server machen wir in der /etc/fstab in der letzten Zeile folgender Eintrag.

brick1deb:/vol1 /datastore glusterfs defaults,_netdev,acl 0 0

Auf dem zweiten Server in der letzten Zeile

brick2deb:/vol1 /datastore glusterfs defaults,_netdev,acl 0 0

Mögliche Probleme: Wenn beide Server offline sind und nur ein Server gestartet wird, wird das vol1 nicht gemountet. Es gibt mehrere Möglichkeiten, um das Problem zu beseitigen. In unserem Fall reicht es, wenn wir das Paket network-manager installieren. Danach dauert das Booten länger, aber es wird gemountet.

# apt --no-install-recommends install network-manager

Oder, die mount Einträge (In der letzten Zeile der /etc/fstab Datei) werden kommentiert und eine /etc/rc.local Datei wird erstellt, wenn noch nicht existiert. Die Datei wird dann so aussehen und nicht vergessen, die Rechte der Datei anzupassen.

#!/bin/sh -e
sleep 20
mount -t glusterfs -o acl brick1deb:/vol1 /datastore/
exit 0

# chmod 757 /etc/rc.local

Entsprechend muss man das auch auf dem anderem Server machen.

Installation und Konfiguration von pacemaker

Auf beiden Servern werden Pacmaker und dazugehörige Pakete installiert

root@brick1deb:~# apt install pcs pacemaker resource-agents fence-agents

root@brick2deb:~# apt install pcs pacemaker resource-agents fence-agents

Auf beiden Servern. Wenn Dienste nicht aktiviert, dann aktivieren und starten. Standardmäßig sind die aktiv.

# systemctl enable pcsd.service
# systemctl start pcsd.service
# systemctl enable corosync.service
# systemctl start corosync.service
# systemctl enable pacemaker.service
# systemctl start pacemaker.service

Auf beiden Servern. Sollte aus irgendeinem Grund SELinux installiert sein, dann bitte die Konfiguration wie folgt anpassen, sonst einfach die zwei Befehle überspringen

# setenforce 0
# sed -i 's/SELINUX=enforcing/SELINUX=disabled/g' /etc/selinux/config

Auf einem Server.

# pcs cluster auth

Auf einem Server. Der folgende Befehl authentifiziert die Knoten

# pcs host auth brick1deb brick2deb

Es sollte so ähnliche Ausgabe kommen

Username: hacluster
Password:
brick2deb: Authorized
brick1deb: Authorized

Auf einem Server. Ein Cluster wird erstellt.

root@brick1deb:~# pcs cluster setup mycluster brick1deb brick2deb --force

Bei älteren Softwareversionen

root@brick1deb:~# pcs cluster setup --name mycluster brick1deb brick2deb --force

Sollte man Probleme bei der Erstellung des Clusters haben, können Ihnen vielleicht dieser Befehl helfen
# pcs cluster destroy
Vorsicht: Alle Cluster werden gelöscht und die Dienste werden gestoppt.

Auf einem Server. Wir starten den Cluster.

root@brick1deb:~# pcs cluster start --all

Auf einem Server. Eine Resource mit dem Namen samba-ip witrd erstellt.

root@brick1deb:~# pcs resource create samba-ip ocf:heartbeat:IPaddr2 ip=172.16.0.100 cidr_netmask=22 op monitor interval=5s

Ein paar pcs Befehle. Mit pcs resource move .... kann man die Resource (IP-Adresse) gezielt verschieben.

# pcs status
# pcs config
# pcs resource status
# pcs resource move samba-ip <Ziel-Brick> // z.B. brick2deb oder brick1deb

Auf einem Server. Aus dem Grund, dass wir nur zwei Knoten (Bricks) haben müssen wir noch einige Einstellungen anpassen. Stonith und Quorum deaktivieren. Ein Cluster-Quorum und Stonith machen in der Regel erst ab 3 Hosts Sinn. Bei der Konfiguration mit 3 Knoten bitte diesen Punkt überspringen. Die Eigenschaften, die hier deaktiviert sind, bitte nicht anwenden.

root@brick1deb:~# pcs property set stonith-enabled=false
root@brick1deb:~# pcs property set no-quorum-policy=ignore
root@brick1deb:~# crm_verify -L

Warnung: Cluster mit 2 Knoten ist nicht unbedingt 100 % sicher, deshalb für wichtige Daten sollte man schon 3 Knoten nutzen.

Samba als Mitglied der Domäne installieren

Auf beiden Servern. Samba Pakete werden installiert.

root@brick1deb:~# apt-get install krb5-user libpam-krb5 winbind samba smbclient libnss-winbind libpam-winbind

root@brick2deb:~# apt-get install krb5-user libpam-krb5 winbind samba smbclient libnss-winbind libpam-winbind

Auf beiden Servern. Samba wird als Mitglied der Domäne konfiguriert. Dabei nutzen wir als Ablageort unsere /datastore, Cluster Bereich. Zuerst müssen wir die /ets/samba/smb.conf Datei anpassen. Auf dem ersten Server.

[global]
workgroup = MONO
realm = MONO.PLAN
netbios name = FS101
server string = Fileserver
security = ADS
idmap config * : backend = tdb
idmap config * : range = 3000-7999
idmap config MONO: backend = rid
idmap config MONO: range = 10000-999999
idmap config MONO: schema_mode = rfc2307
idmap config MONO: unix_nss_info = yes

template shell = /bin/bash
# template homedir = /home/%U
domain master = no
winbind nss info = rfc2307
winbind use default domain = Yes

# oplocks auf no, sonnst bei Profilen nach dem Abmelden kann passieren, dass
# die Datei ntusers.dat und ntusers.ini auf dem Server in Benutzung bleibt.
# Bei nächsten Anmeldung kommen dann Probleme mit den Profilen.
oplocks = no

vfs objects = acl_xattr
map acl inherit = yes
store dos attributes = yes
# admin users = Administrator

[Marktplatz]
path = /datastore/marktplatz
comment =
read only = no
browseable = yes

Auf dem zweiten Server

[global]
workgroup = MONO
realm = MONO.PLAN
netbios name = FS102
server string = Fileserver
security = ADS
idmap config * : backend = tdb
idmap config * : range = 3000-7999
idmap config MONO: backend = rid
idmap config MONO: range = 10000-999999
idmap config MONO: schema_mode = rfc2307
idmap config MONO: unix_nss_info = yes

template shell = /bin/bash
# template homedir = /home/%U
domain master = no
winbind nss info = rfc2307
winbind use default domain = Yes

# oplocks auf no, sonnst bei Profilen nach dem Abmelden kann passieren, dass
# die Datei ntusers.dat und ntusers.ini auf dem Server in Benutzung bleibt.
# Bei nächsten Anmeldung kommen dann Probleme mit den Profilen.
oplocks = no

vfs objects = acl_xattr
map acl inherit = yes
store dos attributes = yes
# admin users = Administrator

[Marktplatz]
path = /datastore/marktplatz
comment =
read only = no
browseable = yes

Auf einem Server. Es wird Ordner marktplatz unter /datastore erstellt. Auf dem anderen wird der Ordner repliziert. Die Rechte werden auf 777 gesetzt. Der Domänen-Administrator sollte dann von einem Windows Rechner in der Domäne die Rechte anpassen.

root@brick1deb:~# mkdir -p /datastore/marktplatz
root@brick1deb:~# chmod 777 /datastore/marktplatz

Auf beiden Servern. Es wird die Datei /etc/krb5.conf zu unseren Bedürfnissen angepasst. Den vorhandenen Inhalt löschen wir und ersetzten mit unserem.

[libdefaults]
default_realm = MONO.PLAN
dns_lookup_realm = false
dns_lookup_kdc = true

[realms]
MONO.PLAN = {
kdc = dc1.mono.plan
master_kdc = dc1.mono.plan
admin_server = dc1.mono.plan
}

[domain_realm]
.dc1.mono.plan = MONO.PLAN
dc1.mono.plan = MONO.PLAN

[logging]
kdc = FILE:/var/log/krb5/krb5kdc.log
admin_server = FILE:/var/log/krb5/kadmind.log
default = SYSLOG:NOTICE:DAEMON

Auf beiden Servern. Wir müssen noch die Einträge in der Datei /etc/nsswitch.conf anpassen. Die Einträge bei paswd und group werden von files auf compat winbind geändert.

passwd: compat winbind
group: compat winbind
shadow: files
gshadow: files

Auf beiden Servern. Als Nächstes testen wir, ob Kerberos funktioniert, indem wir uns als Administrator authentifizieren.

# kinit Administrator

Auf beiden Servern. Domäne beitreten

# net ads join -U Administrator

Auf beiden Servern. Mit den folgenden Befehlen kann man die Freigaben auflisten, Benutzer und Gruppen in der Domäne auflisten und den Status der Dienste anzeigen lassen.

# smbclient -L localhost -U%
# systemctl restart winbind
# wbinfo -u
# wbinfo -g
# systemctl status smbd
# systemctl status smbd
# systemctl status winbind
# wbinfo --online-status

Auf beiden Servern. Nach Bedarf können wir die Samba-Dienste neu starten.

# systemctl restart smbd.service
# systemctl restart nmbd.service
# systemctl restart winbind.service

Wir machen einen DNS-Eintrag auf dem DNS-Server, dem Namen FS1 wird die IP: 172.16.0.100 zugewiesen. Danach können wir auf einem beliebigen PC, der sich in der Domäne befindet, im Windows Explorer unter der Adresse den Fileserver-Namen \\FS1 angeben. Nach Bestätigung mit der Enter-Taste sehen wir die Freigaben. Der Administrator sollte es zuvor die Freigaberechte anpassen.

Sollte ein Server ausfallen, bleibt die Freigabe immer noch vorhanden. Wenn der Server, der gerade die Ressource besitzt, also die IP-Adresse 172.16.0.100, ausfällt, wird die Ressource auf den anderen Server übertragen.