DRBD-Kochbuch

3.2 Auswahl der Filesysteme

Im Prinzip könnte ein DRBD auch als RAW-Gerät verwendet werden. Ob und welches Dateisystem auf dem DRBD-Gerät „läuft“, spielt eigentlich keine Rolle. Dennoch möchte ich die unterschiedlichen Arbeitsweisen der verwendeten Dateisysteme näher beleuchten, um Ihnen die Entscheidung zu erleichtern. Alle Dateisysteme haben ihre spezifischen Vor- und Nachteile, die auf ihrer Arbeitsweise beruhen.

Aus vielleicht verständlichen Gründen werde ich an dieser Stelle nicht näher auf Baumstrukturen oder Ähnliches eingehen. Wenn Sie sich für diese speziellen Punkte interessieren, sollten Sie die einschlägige Fachliteratur oder https://www.wikipedia.com zu Rate ziehen.

3.2.1 UFS / ext2

Das gute alte „UNIX File System“ - denn dafür steht UFS - wurde in den frühen 1980er Jahren entwickelt und war bis Anfang der 1990er Jahre das Standard-Dateisystem für alle UNIX-Derivate. Heute wird es jedoch nur noch in Einzelfällen verwendet.

Das Grundkonzept wurde jedoch an die folgenden Dateisystemgenerationen weitergegeben:

 Alle Daten werden in Blöcken auf der Festplatte gespeichert und

 um zu einem Datenblock zu gelangen, wird die Adresse des Speicherblocks in einem „Superblock“ genannten Bereich gespeichert, auf den das Betriebssystem zuerst zugreift.

Auf diese Weise erhält man eine Baumstruktur, da jeder gespeicherten Datei eine bestimmte „Inode-Nummer“ zugewiesen wird.

Wird nach einer bestimmten Datei innerhalb des Dateisystems gesucht, muss immer der gesamte Dateibaum durchsucht werden, was bei größeren Dateibäumen mit vielen Unterstrukturen vergleichsweise lange dauern kann.

Das „zweite erweiterte Dateisystem“ („second extended filesystem“ ext2) übernimmt im Wesentlichen diese Struktur, doch können so genannte „Plugins“ - d. h. Erweiterungen - hinzugefügt werden, um die Fragmentierung, Komprimierung und Wiederherstellung gelöschter Daten zu ermöglichen.

3.2.2 ext3 / ext4

Die Dateisysteme ext3 und ext4 haben sich aus dem Dateisystem ext2 weiterentwickelt, indem ein so genanntes journal hinzugefügt wurde und die Möglichkeit besteht, die Größe des Dateisystems zu ändern, während das Dateisystem in Gebrauch ist.

In einem Journaling-Dateisystem werden alle Änderungen in einem speziellen Speicherbereich namens journal aufgezeichnet, bevor der eigentliche Schreibvorgang in den ausgewählten Block stattfindet. Dies erleichtert die Rekonstruktion der Schreibvorgänge, wenn z. B. das System abstürzt oder der Strom während des Schreibvorgangs ausfällt.

Ein weiterer Punkt der Verbesserung von ext3 bzw. ext4 gegenüber ext2 war die Erhöhung der verwendbaren Dateisystempartitionen von 16 TB auf 32 TB für ext3 und 1 EB (= Exabyte) für ext4. Solche Gerätegrößen konnte man sich bei der Entwicklung des UFS noch gar nicht vorstellen.

Hinzu kommen die Erweiterungen hinsichtlich der Anzahl der Dateien und Verzeichnisse sowie der Größe der einzelnen Dateien, die bei ext2 noch auf 2 TB begrenzt war, bei ext3 zwischen 16 GB und 2 TB liegen konnte und bei ext4 schließlich nur durch die Größe der Festplattenpartition begrenzt ist.

3.2.3 xfs

Das Dateisystem xfs, ursprünglich von Silicon Graphics (SGI) exklusiv für das hauseigene UNIX-System ÏRIXëntwickelt, ist eines der ältesten Dateisysteme. Aber nur weil etwas in die Jahre gekommen ist, heißt das nicht, dass es „schlecht“ sein muss. Mit Maximalwerten von 16 EB pro Dateisystem, einer maximalen Anzahl von 263 Dateien und einer Größe pro Datei von 8 EB setzt es Maßstäbe.

Es hat auch deutliche Vorteile gegenüber ext3 und BtrFS, insbesondere in Bezug auf die Geschwindigkeit.

Vor einiger Zeit hatte ich einen Fall, bei dem etwa 100 GB von einem Host auf einen anderen kopiert werden mussten. Das Quelldateisystem war ein BtrFS und die Kopie lief - um LAN-Ressourcen zu sparen - über ein TAR, das auf dem Quellrechner komprimiert, durch einen SSH-Tunnel geschoben und auf dem Zielrechner wieder dekomprimiert wurde.

Diese Arbeit hat etwas mehr als eine Stunde gedauert - wahrscheinlich, weil das Dateisystem viele Unterverzeichnisse hatte.

Nachdem die Arbeiten am Quelldateisystem abgeschlossen waren, u.a. wurde es auf 200 GB vergrößert, entschied ich mich spontan für xfs als neues Dateisystem.

Die Wiederherstellungszeit betrug 20 Minuten!

Natürlich bin ich seither ein bekennender Fan dieses Dateisystems, zumal sich der Durchsatz im Normalbetrieb bestätigt hat.

3.2.4 BtrFS

Das BtrFS - buchstabiert B-Tree-Filesystem und nicht „Better FS“ oder gar „Butter FS“ - verfolgt einen völlig anderen Ansatz als die bisher im Linux-Umfeld verfügbaren Dateisysteme. Es basiert teilweise auf den Überlegungen des ZFS, das etwa sieben Jahre zuvor ebenfalls von Sun Microsystems entwickelt wurde (inzwischen in ORACLE aufgegangen). Es verfügt über integriertes RAID, Volume Management, prüfsummenbasierten Schutz vor Datenübertragungsfehlern und verwendet copy-on-write.

copy-on-write ist eine Methode, bei der eine Kopie erst dann real ist, wenn sie von einer der Parteien geändert wird. Solange alle Beteiligten ihre Kopie nicht geändert haben, genügt es, das Original einmal zu speichern - im jeweiligen Dateisystem. Das integrierte RAID-System unterscheidet zwischen belegten und freien Datenblöcken, so dass beim Wiederaufbau eines ausgefallenen RAID-Volumes nur der belegte Speicherplatz gespiegelt werden muss, was eine enorme Zeitersparnis bedeutet. Darüber hinaus arbeitet dieses RAID mit größeren Datenblöcken als bei klassischen RAID-Verfahren. Bei einem RAID1 werden nicht alle Datenblöcke eines Datenträgers gespiegelt - unabhängig davon, ob sie belegt sind oder nicht -, sondern nur die belegten Blöcke werden auf alle verfügbaren Datenträger verteilt. Auf diese Weise kann ein RAID1 aus einer ungeraden Anzahl von Festplatten mit unterschiedlichen Kapazitäten gebildet werden, ohne dass Speicherplatz verloren geht.

Die „B-Baum-Struktur“ - nach der das Dateisystem benannt ist - stammt von dem zentralen Konzept von xfs.

BtrFS wird nun von SuSE als Dateisystem der Zukunft verwendet, während RedHat im August 2017 ankündigte, dass es die langfristige Unterstützung für BtrFS in RHEL einzustellen. Wobei es bisher bei dieser Ankündigung geblieben ist und z.B. fedora¹ ganz automatisch BtrFS verwendet, wenn bei der Installation nichts anderes gewählt wird. Zusätzlich zu den oben beschriebenen Erfahrungen sollten die folgenden Überlegungen im Hinblick auf die Verwendung von BtrFS auf Produktionsservern in Verbindung mit DRBD angestellt werden:

1 Die meisten Linux-Server, die als 19-Zoll-Geräte gekauft werden, sind mit einem Hardware-RAID-Controller ausgestattet. Das bedeutet, dass die RAID-Funktionalität von BtrFS hier nicht benötigt wird, da die an den RAID-Verbund angeschlossenen Festplatten ohnehin die gleiche Kapazität haben, da sonst der Hardware-RAID-Controller nicht richtig funktioniert oder der Speicherplatz nicht genutzt werden kann.

2 Die oben erläuterte copy-on-write-Funktionalität fügt eine zusätzliche Virtualisierungsschicht hinzu, die bereits durch die Verteilung der Daten auf mehrere Clusterknoten mit DRBD erreicht wird. Allerdings wird ein BtrFS Array über mehrere Clusterknoten nicht unterstützt.

3 In bestimmten Fällen ist die Verwendung von BtrFS auf einem DRBD-Gerät durchaus sinnvoll, wenn Sie nicht auf die vielfältigen Funktionen von BtrFS verzichten möchten.

Ein Beispiel ist die Möglichkeit, einen Schnappschuss des Dateisystems zu erstellen. Sie sollten jedoch vorsichtig sein, bevor Sie solche Schnappschüsse automatisch erstellen, da dadurch schnell Speicherplatz verbraucht wird, den Sie für andere Zwecke benötigen könnten.

3.2.5 OCFS2

Das Oracle Cluster File System 2 ist ein von Oracle für Open-Source-Cluster entwickeltes Dateisystem, das den gleichzeitigen Zugriff von mehreren Clusterknoten auf ein Plattengerät in einem Cluster-Array ermöglicht (Concurrent Access / konkurrierender Zugriff). Die Koordination funktioniert über den Distributed Lock Manager.

Die erforderlichen Pakete sind ab SLES 11 SP3 enthalten.

3.2.6 Fazit

Auch bei den grundsätzlichen Überlegungen zur Einrichtung eines Clusters sollten Sie sich sehr genau überlegen, welches Dateisystem Sie verwenden wollen. Haben Sie die falsche Entscheidung getroffen, ist ein Wechsel des Dateisystems nur mit erhöhtem Aufwand möglich. In diesem Buch zeige ich ein „Rezept“ (vgl. Textnummer 8 - ohne Vergrößerung des LVM-Volumes), wie Sie sich hier helfen können. Allerdings müssen Sie sich darüber im Klaren sein, dass dies nur mit einer Downtime des Cluster-Arrays möglich ist. Wenn Sie die hier gezeigten Dateisysteme vergleichen und die speziellen Funktionen von OCFS2 oder BtrFS nicht benötigen, ist xfs das Mittel der Wahl.

4 Grundlegende Konfiguration für einen Zwei-Knoten-Cluster

Als Grundlage für alle weiteren Schritte betrachten wir zunächst die Konfiguration für einen Aktiv-Passiv-Cluster, der aus zwei Clusterknoten besteht. Als Clusterdienst wird Apache verwendet.

Ein klassisches Beispiel!

4.1 SSH-Konfiguration

Bevor wir uns um die eigentliche Konfiguration des DRBD kümmern können, müssen wir dafür sorgen, dass die vorhandenen Clusterknoten ungestört miteinander „plaudern“ können, was uns die Arbeit ebenfalls ein wenig erleichtert.

4.1.1 SSH-Key-Typen

Es sollte allgemein bekannt sein, dass die Fähigkeiten der Remote Shell (rsh) durch die wesentlich sicherere Secure-Shell (ssh) abgedeckt werden können. Die Secure Shell funktioniert durch den Austausch von „Schlüsseln“, die wie ein Fingerabdruck des jeweiligen Servers und des jeweiligen Benutzers verwendet werden. Stimmt der Schlüssel überein, werden die Anfragen des jeweiligen „fremden“ Servers zugelassen, stimmt der Schlüssel nicht überein, werden sie abgewiesen.

Die Verschlüsselungsalgorithmen RSA, DSA, ECDSA und Ed25519 können hier verwendet werden, welchen Sie bevorzugen, bleibt Ihnen überlassen.

Für die Verwendung eines anderen Verschlüsselungsalgorithmus als RSA gibt es bei SLE/OpenSuSE 15 eine Kleinigkeit zu beachten, auf die ich in Anhang 13 näher eingehen werde.

4.1.2 Rezept: Erstellen und Verteilen von SSH-Schlüsseln

Damit unsere Clusterknoten pluto und charon später miteinander „reden“ können, ist es notwendig, eine passwortlose Kommunikation auf root level zu ermöglichen.

Erstellen wir also zunächst einen SSH-RSA-Schlüssel auf Clusterknoten 1 (pluto) mit der Kennung root:

pluto:~ # ssh-keygen -t rsa

Generating public/private rsa key pair.

Enter file in which to save the key (/root/.ssh/id_rsa):

Enter passphrase (empty for no passphrase):

Enter same passphrase again:

Your identification has been saved in /root/.ssh/id_rsa.

Your public key has been saved in /root/.ssh/id_rsa.pub.

The key fingerprint is:

SHA256:******************************************* root@pluto

The key’s randomart image is:

+---[RSA 2048]----+

~ snip ~

+----[SHA256]-----+

pluto:~ #

Die Eingabe für die Passphrase wird logischerweise weggelassen, da die beiden Server ohne Passwort kommunizieren sollen.

Wie Sie verstehen werden, veröffentliche ich hier nicht den Schlüssel meiner root-id, daher sind die entsprechenden Bereiche in der Bildschirmausgabe etwas anders. Ihre Bildschirmausgabe sollte ähnlich, aber nicht genau gleich aussehen.

Zur Kontrolle:

pluto:~ # cd /root/.ssh

pluto:~/.ssh # ll

total 8

-rw------- 1 root root 1373 Dec 31 19:25 id_rsa

-rw-r--r-- 1 root root 600 Dec 31 19:25 id_rsa.pub

pluto:~/.ssh #

Im Endeffekt haben wir den Befehl ssh-keygen -t rsa verwendet, um zwei Dateien zu erstellen, die den nicht-öffentlichen Schlüssel (id_rsa) und den öffentlichen Schlüssel (id_rsa.pub) einmal enthalten. Die Option „-t“ steht für den Schlüsseltyp, d.h. „rsa“, „dsa“, „ecdsa“ oder „ed25519“.

Diesen öffentlichen Schlüssel müssen wir nun unserem zweiten Clusterknoten bekannt machen.

Klassisch:

pluto:~/.ssh # scp id_rsa.pub charon:/root/.ssh/pluto_root.pub

The authenticity of host ’charon (192.168.178.201)’ can’t be established.

ECDSA key fingerprint is SHA256:*******************************************.

Are you sure you want to continue connecting (yes/no)? yes

Warning: Permanently added ’charon,192.168.178.201’ (RSA) to the list of known hosts.

Password:

pluto:~/.ssh # scp id_rsa.pub charon:/root/.ssh/pluto_root.pub

Password:

id_rsa.pub 100% 600 350.5KB/s 00:00

pluto:~/.ssh # ssh charon ’cat /root/.ssh/pluto_root.pub >> /root/.ssh/authorized_keys’

Password:

pluto:~/.ssh # ssh charon ’uname -n’

charon

…oder mit einem Kommando:

pluto:~/.ssh # ssh-copy-id -i ./id_rsa.pub root@charon

/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "./id_rsa.pub"

/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed

/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys

Password:

Number of key(s) added: 1

Now try logging into the machine, with: "ssh␣’root@charon’"

and check to make sure that only the key(s) you wanted were added.

pluto:~/.ssh # ssh root@charon "uname -n"

charon

Damit wir einen echten Dialog zwischen den Clusterknoten haben, müssen diese Schritte natürlich auf allen Clusterknoten durchgeführt werden, für alle Clusterknoten.

Also die gleiche Prozedur noch einmal von der anderen Seite:

charon:~/.ssh # ssh-keygen -t rsa

Generating public/private rsa key pair.

Enter file in which to save the key (/root/.ssh/id_rsa):

Enter passphrase (empty for no passphrase):

Enter same passphrase again:

Your identification has been saved in /root/.ssh/id_rsa.

Your public key has been saved in /root/.ssh/id_rsa.pub.

The key fingerprint is:

SHA256:******************************************* root@pluto

The key’s randomart image is:

+---[RSA 2048]----+

~ snip ~

+----[SHA256]-----+

…oder …

charon:~/.ssh # ssh-copy-id -i ./id_rsa.pub root@pluto

/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: ./id_rsa.pub

/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed

/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys

Password:

Number of key(s) added: 1

Now try logging into the machine, with: ssh ’root@pluto’

and check to make sure that only the key(s) you wanted were added.

charon:~/.ssh # ssh root@pluto ’uname -n’

pluto

charon:~/.ssh #

4.2 Konfiguration der lokalen Plattenlaufwerke

Schauen wir uns die aktuelle Festplattenpartitionierung des Servers pluto an, der Einfachheit halber auf SuSE über YaST.

Um die Übersicht aus Abbildung 4.1 zu erhalten, geben Sie in der Shell yast2 ein und wählen den Abschnitt partitions im Ordner system aus.

Wie in Abbildung 4.2 zu sehen ist, wurde während der Installation bereits eine Volume-Gruppe mit dem Namen vg00 erstellt und mehrere Partitionen darunter angelegt. Nachdem in dieser Volume-Group noch 22 GB verfügbar sind, erstellen wir unsere DRBD-Partition hier - vorläufig mit dem YaST. Die Grundlagen zur Erstellung einer Volume-Group sind dem Anhang 14 zu entnehmen.

4.2.1 Rezept: Erstellen eines LVM-Volumes mit den YaST

Nachdem wir das YaST-Menü gerade offen haben, erstellen wir hiermit auch gleich die Partition (siehe 4.3)

Da wir die Daten eines Apache-Web-Servers von einem Cluster-Knoten zu seinem Partner spiegeln wollen, nennen wir das logische Volume: apache (vergleiche 4.3).

Für das hier benutzte Beispiel sollten 5 GB ausreichend sein (siehe 4.4).

Das Menü (4.5) dient zur Festlegung, wie die erstellte Partionen in Zukunft verwendet werden soll. Da wir zuerst das DRBD-Device erstellen und später ein Filesystem darauf installieren wollen, wird die Partition zunächst als Raw-Device („rohes Laufwerk“) definiert (raw-volume 4.6).

Dementsprechend wird das Laufwerk nicht „montiert“.

Um die erledigte Arbeit abzuspeichern, muss der Menüpunkt continue ausgewählt werden (4.7). Auf Systemebene kann diese Partition nun unter „/dev/vg00/apache“ verwendet werden, worauf bei der DRBD-Konfiguration nochmals näher eingegangen wird.

4.2.2 Rezept: Ein LVM-Volume über die Shell erstellen

Mit dem Kommando lvm hat der Shell-Benutzer alle Möglichkeiten, die das YaST-Menü bietet.

Verwendet man das Kommando „lvm vgdisplay“ erhält man einen Überblick über alle erstellten Volume-Groups:

charon:~ # lvm vgdisplay

--- Volume group -----

VG Name vg00

System ID

Format lvm2

Metadata Areas 1

Metadata Sequence No5

VG Access read/write

VG Status resizable

MAX LV 0

Cur LV 4

Open LV 4

Max PV 0

Cur PV 1

Act PV 1

VG Size 72.99 GiB

PE Size 4.00 MiB

Total PE 18685

Alloc PE / Size 12800 / 50.00 GiB

Free PE / Size 5885 / 22.99 GiB

VG UUID eQ9tnQ-7hWv-7DPv-LzFO-PGMc-fn6W-MW8Yfb

charon:~ #

Wie auf dem Partner-System pluto, wurde bereits bei der Systeminstallation eine Volume-Group vg00 mit 4 Volumes erstellt, bei der noch 22,99 GB an Plattenplatz frei sind.

Diesen Plattenbereich nutzen wir nun zur Erstellung eines logischen Volumes namens apache mit der Größe von 5 GB.

Wie eine Volume-Group über die Shell erstellt werden kann, erfahren Sie im Anhang 14.

charon:~ # lvcreate --name apache --size 5GB vg00

Logical volume "apache" created.

Um einen Überblick über die logischen Volumes zu erhalten wird das Kommando lvdisplay verwendet:

charon:~ # lvm lvdisplay

--- Logical volume ---

LV Path /dev/vg00/apache

LV Name apache

VG Name vg00

LV UUID YGtshV-MtDK-hpTP-mdu5-z84g-cRev-WRqxAV

LV Write Access read/write

LV Creation host, time charon, 2020-01-05 21:25:35 +0100

LV Status available

# open 0

LV Size 5.00 GiB

Current LE 1280

Segments 1

Allocation inherit

Read ahead sectors auto

- currently set to 1024

Block device 254:4

Der für uns im weiteren Verlauf wichtige Wert ist LV Path /dev/vg00/apache, der dazu verwendet werden kann, das Gerät im System als Laufwerk zu adressieren.

Nachdem das Kommando lvm lvdisplay alle logischen Volumes einer Volume-Group ausgibt, habe ich mir die Freiheit genommen die Ausgabe auf die entscheidenden Zeilen zu reduzieren.