Open Source-Software findet in immer mehr Unternehmen und Behörden ihren Einsatz. Im Juli widmet IT-Administrator daher seinen Heftschwerpunkt der quelloffenen ... (mehr)

Konfiguration des Gluster-Clients

Um das Volume nutzen zu können, muss der Gluster-Client installiert sein. Dabei sollten Sie darauf achten, dass die Client-Version identisch mit der Version des Servers ist. Die einzelnen Versionen von Gluster sind untereinander nicht kompatibel. Wenn das Volume auf dem Gluster-Server gemountet werden soll, muss auch hier der Gluster-Client installiert sein.

Das Mounten des Volumes findet im Userspace statt. Dafür benötigen wir das Kernel-Module "fuse". Das Modul lädt beim Starten des Clients automatisch. Da wir später auf denselben Systemen CTDB einrichten wollen, mounten wir das Volume lokal auf beiden Knoten. Folgende Befehle sind zur Einbindung des Volumes nötig:

root@samba42-fs1:~# mkdir /glusterfs
root@samba42-fs1:~# mount -t glusterfs samba42-1:/gv0 /glusterfs
 
root@samba42-fs1:~# mount
 
samba42-1:/gv0 on /glusterfs type fuse.glusterfs 
(rw,relatime,user_id=0,group_id=0,allow_other,max_read=131072)
root@samba42-fs1:~# echo samba42-1:/gv0 /glusterfs glusterfs 
defaults,_netdev,acl 0 0 > /etc/fstab

Welchen der beiden Knoten Sie beim Mounten angeben, spielt keine Rolle. Der GlusterFS-Client holt sich von ihm nur die Konfiguration und kommuniziert ab dem Zeitpunkt selbst mit den beteiligten Knoten. So kann der Client beim Ausfall eines Knotens automatisch auf einen anderen Knoten aus dem Cluster schwenken.

Nachdem das Volume auf allen Knoten gemountet wurde, können jetzt das erste Mal Daten auf das Volume geschrieben werden. Nach dem Schreiben sollten die abgelegten Daten auf beiden Knoten vorhanden sein. Erst wenn dies gelingt, können wir mit der Konfiguration von CTDB beginnen.

Einrichten von CTDB

CTDB verfolgt den Zweck, mehrere Samba-Fileserver wie einen einzigen Server als Cluster im Netz bereitzustellen. Die Clients nutzen nur noch den Cluster und nicht mehr die einzelnen Server. Sollte einer der Server kurzzeitig nicht erreichbar sein oder gar ganz ausfallen, merkt dieses der Client nicht. Ein Client, der gerade mit dem ausgefallenen Server verbunden ist, wird sich automatisch mit einem anderen Knoten des Clusters verbinden. Voraussetzung dafür ist, dass alle IP-Adressen des Clusters über DNS auf denselben Hostnamen auflösbar sind. Auch soll beim Ausfall eines der Knoten der andere noch aktive Knoten die IP-Adressen des ausgefallenen Knotens übernehmen. Die Weiterleitung der Clients und das Schwenken der IP-Adressen ist die Aufgabe von CTDB.

Mit der Version 4.2 ist CTDB ein Bestandteil von Samba 4.2 geworden. Zur Zeit gibt es aber noch keine Distribution, die Samba 4.2 in den Repositories bereitstellt. Lediglich im Portal der Firma SerNet sind die Pakte für alle gängigen Distributionen erhältlich. Wir verwenden hier diese Pakete. Aus diesem Grund habe sämtliche Dienste immer das Präfix "sernet-samba".

Nachdem Sie die Repositories eingebunden haben, müssen Sie die Pakete sernet-samba-winbind, sernet-samba, sernet-samba-ctdb, libpam-heimdal, ethtool und gawk installieren. Da Samba die Authentifizierung zusammen mit Kerberos durchführt, ist es besonders wichtig, dass die Uhrzeit auf allen Systemen identisch ist. Deshalb sollte auf jeden Fall auf allen Systemen der Domäne "ntpd" installiert sein.

Jetzt tragen wir auf alle Knoten die Konfiguration von CTDB in die Datei »/etc/ default/sernet-samba-ctdb« ein. An dieser Stelle dürfen die Samba-Dienste noch nicht von CTDB verwaltet werden. Erst wenn CTDB läuft, kann CTDB die Kontrolle über die Dienste übernehmen. Listing 3 zeigt die Anpassungen in der Datei.

 Listing 3: Anpassungen in /etc/default/sernet-samba-ctdb

 # Do NOT run CTDB without a recovery lock file unless you know exactly 
 # what you are doing. 
 CTDB_RECOVERY_LOCK=/glusterfs/ctdb.lock 
 
 # List of nodes in the cluster. Default is below. 
  CTDB_NODES=/etc/ctdb/nodes 
 
 # List of public addresses for providing NAS services. No default. 
 CTDB_PUBLIC_ADDRESSES=/etc/ctdb/public_addresses 

Bei »/glusterfs/ctdb.lock« handelt es sich um die Datei, über die die Knoten des Clusters das Filelocking realisieren. Diese Datei muss zwingend im Clusterdateisystem liegen. In der Datei »/etc/ctdb/nodes« werden die IP-Adressen aller Knoten des Clusters eingetragen. Für die Kommunikation der Knoten untereinander ist es sinnvoll ein eigenes Netz zu verwenden, das nicht mit dem Produktivnetz verbunden ist. Der Inhalt der Datei – die auf allen Knoten des Clusters identisch sein muss – könnte in unserem Fall etwa lauten:

192.168.56.122
192.168.56.123

In der Datei »/etc/ctdb/public_addresses « tragen wir die virtuellen IP-Adressen mit der Subnetzmaske und den Schnittstellen ein, die auf die Knoten von CTDB verteilt werden sollen. Dies könnte so aussehen:

192.168.123.125/24 eth1
192.168.123.126/24 eth1

Diese Datei kann auf den einzelnen Knoten unterschiedlich sein, da sich die Knoten in unterschiedlichen Subnetzen des Produktivnetzwerks befinden können.

Bevor sich der Cluster starten lässt, müssen wir noch alle IP-Adressen des Clusters im DNS eintragen, damit später die Clients auch auf den Cluster zugreifen können. Die Einträge erstellen Sie entweder über das DNS-Verwaltungstool von Windows oder die Kommandozeile des Samba 4-ADDC.

Jetzt starten wir CTDB mit dem Kommando »service sernet-samba-ctdb start« auf allen Knoten. Nach dem Start des Dienstes auf allen Knoten überprüfen wir den Dienst mit folgendem Befehl:

root@samba42-fs1:~# ctdb status

Listing 4 zeigt das Ergebnis dieser Überprüfung an. Dabei kann es einige Zeit dauern, bis alle Knoten den Status "OK" haben. Erst wenn dies bei allen Knoten der Fall ist, können wir mit der Konfiguration von Samba beginnen.

 Listing 4: Ausgabe des CTDB-Status

 Number of nodes:2 
 pnn:0 192.168.56.122 OK (THIS NODE) 
 pnn:1 192.168.56.123 OK 
 Generation:446598079 
 Size:2 
 hash:0 lmaster:0 
 hash:1 lmaster:1 
 Recovery mode:NORMAL (0) 
 Recovery master:1 

Ähnliche Artikel

comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2021