DRBD-Kochbuch

Hochverfügbarkeitslösungen selbst erstellen - ohne SAN oder NAS!

Jörg Christian Seubert

2. korrigierte Auflage

Das Buch…

Einen Cluster unter Linux zu erstellen, muss nicht kompliziert und teuer sein. Dieses Buch gibt Ihnen eine Hilfestellung für das rechnerübergreifende RAID1-System DRBD der Firma LinBit und hilft Ihnen, Ihr spezielles eigenes Clustersystem zu erstellen.
In Form von ’Listings’ - praktischen Beispielsessions, die Fehler, Fehlermeldungen und Problembehebungen enthalten können - zeigt der Autor, wie man mit DRBD Schritt für Schritt einen einfachen und funktionierenden Linux-Cluster erstellen kann.
Da die DRBD-Software und die Konfigurationsdateien auch unter Windows nutzbar sind, können die gezeigten Beispiele auch auf diesem System laufen!
In einem eigenen Kapitel wird gezeigt, wie DRBD in einen Veritas-Cluster eingebunden wird.
Nützliche Informationen für die Systemadministration von Linux-Systemen werden in drei Kapiteln gegeben (13, 14, 15). Auch die Funktionsweise der verschiedenen Linux-Dateisysteme wird erklärt (3.2).

Der Autor…

Jörg Christian Seubert, geboren 1974 in Würzburg, ist seit 1992 in Nürnberg in einem Rechenzentrum für Finanzdienstleistungen tätig. Seit 1994 ist er als Systemadministrator für UNIX und Linux tätig. Im Rahmen dieser Tätigkeit sammelte er Erfahrungen mit SINIX, Solaris sowie SuSE, RedHat und Debian Linux. Außerdem richtete er Veritas-Cluster-Systeme ein. Insbesondere war er für die Datensicherung der "offenen Welt" (Windows & UNIX), SAN und Computerhärtung zuständig. Er gab auch UNIX/Linux-Einsteigerkurse.
Derzeit arbeitet er im Monitoringteam, wo er speziell für die Überwachung von UNIX/Linux-Systemen zuständig ist und unter anderem selbst Überwachungsskripte erstellt, die in Perl, Python und BASH geschrieben sind. Außerdem schult er Perl-Anfänger.
Er lebt mit seiner Familie in der Nähe von Nürnberg.

Impressum:

Text und Umschlag:
©by Jörg Christian Seubert, 1. Auflage 2020 und 2. korrigierte Auflage 2022.

Die übrigen Rechte für Übersetzungen und Veröffentlichungen liegen beim Autor.

Die Begriffe LINSTOR®, DRBD®, LINBIT®und die Logos LINSTOR®, DRBD®und LINBIT®sind Handelsmarken oder registrierte Handelsmarken

der Firma LINBIT in Österreich, den Vereinigten Staaten von Amerika und anderen Ländern.

Der Begriff Windows®ist eine registrierte Handelsmarke der Microsoft Cooperation in den Vereinigten Staaten und anderen Ländern.

Die Begriffe RHEL®, Red Hat®und Fedora®sind registrierte Handelsmarken der Red Hat Inc. in Irland, den Vereinigten Staaten von Amerika

und anderen Ländern.

Die Begriffe SLES®, SUSE®, YAST®und openSUSE®sind registrierte Handelsmarken der

SUSE Software Solutions Germany / Deutschland GmbH in Deutschland und anderen Ländern.

Der Begriff VeritasTMist eine registrierte Handelsmarke der Veritas Technologies LLC oder angeschlossener Firmen in den Vereinigten Staaten von Amerika und anderen Ländern.

Nachdem manche der hier aufgelisteten Firmennamen und Handelsmarken in Kommandos, Verzeichnis- und Dateinamen Verwendung finden, war es notwendig in einigen Fällen

auf die entsprechende Kennzeichnung im Dokument zu verzichten.

Herausgeber
Jörg Christian Seubert, 91227 Leinburg-Diepersdorf, joerg.seubert@gmx.net

Druck
epubli, ein Service der neopubli GmbH, Berlin

Gedruckt in Deutschland

Texterstellung und Satz mit
LATEX, KOMA-Script und pdfLATEX

Bibliographische informationen der Deutschen National Bibliothek:
Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der deutschen Nationalbibliographie: detaillierte bibliographische Daten sind im Internet über https://www.dnb.de abrufbar.

Inhaltsverzeichnis

1  Einführung
 1.1  Syntax dieses Buches
 1.2  Eingebaute Fehler
 1.3  Hostnamen
2  Installation
 2.1  Software
 2.2  Systemvoraussetzungen
3  Vorüberlegungen
 3.1  Festplattenlaufwerke – physikalisch im Vergleich zu LVM
 3.2  Auswahl der Filesysteme
  3.2.1  UFS / ext2
  3.2.2  ext3 / ext4
  3.2.3  xfs
  3.2.4  BtrFS
  3.2.5  OCFS2
  3.2.6  Fazit
4  Grundlegende Konfiguration für einen Zwei-Knoten-Cluster
 4.1  SSH-Konfiguration
  4.1.1  SSH-Key-Typen
  4.1.2  Rezept: Erstellen und Verteilen von SSH-Schlüsseln
 4.2  Konfiguration der lokalen Plattenlaufwerke
  4.2.1  Rezept: Erstellen eines LVM-Volumes mit den YaST
  4.2.2  Rezept: Ein LVM-Volume über die Shell erstellen
 4.3  DRBD Konfiguration
  4.3.1  Performance
  4.3.2  /etc/drbd.conf
  4.3.3  /etc/drbd.d/global_common.conf
  4.3.4  Resourcekonfiguration
  4.3.5  Resourcenbeschreibung:
  4.3.6  Alternative Schreibweise
  4.3.7  Ports
  4.3.8  Rezept: Kommandosequenz für die Basis-Konfiguration
5  Datenübertragung über das Backbone-LAN
 5.1  Rezept: Einsatz eines Backbone-LAN in der DRBD-Konfiguration
6  Multi-node cluster
 6.1  Stacking-Device
  6.1.1  Rezept:Inbetriebnahme eines Stacking-Device mit DRBD8 unter SLES11 SP4
  6.1.2  Rezept: Inbetriebnahme eines Stacking-Device mit DRBD9 unter OpenSuSE 15.1
 6.2  RAID1 über mindestens drei Knoten
7  Gehärtete Cluster
 7.1  Prüfung des Status der Firewall
 7.2  Firewall-Zonen
 7.3  Erstellen eines neuen Firewall-Serive
 7.4  Erstellen einer neuen Zone
 7.5  Grundlagen eines zweistufigen Härtungskonzepts
  7.5.1  Härtung mit der Firewall
  7.5.2  Härtung mit Secure-Shell-Optionen
8  Vergrößern und Verkleinern eines DRBD-Devices
 8.1  Inoffizielle Methode
  8.1.1  Konzept
  8.1.2  Befehlssatz
 8.2  Die offizielle Methode
9  Programmieren einer eigenen Cluster-Lösung
 9.1  Konfigurationsdatei
  9.1.1  Inhalt der Konfigurationsdatei
 9.2  Virtuelle IP-Adresse
  9.2.1  Skriptbeschreibung für my_virt_ip.pl:
 9.3  Datenbasis „schaltbar“ machen
  9.3.1  Skriptbeschreibung für my_dev_switch.pl:
 9.4  Kommunikation zwischen den Cluster-Knoten - der Horcher
  9.4.1  Skriptbeschreibung für my_horcher.pl:
 9.5  Steuerungsskript
  9.5.1  Skriptbeschreibung für my_control.pl:
 9.6  Dienst-Kontroll-Skripte für systemd
  9.6.1  Erläuterung für mycluster_horcher.service:
  9.6.2  Erläuterung für mycluster_control.service:
 9.7  Initialisierungsskript für den Cluster Controller
  9.7.1  Erläuterung für my_service.pl:
 9.8  Wartungsarbeiten
 9.9  Grundsätzliche Informationen bezüglich der Skripte
10  DRBD in einen Veritas-Cluster integrieren
 10.1  Einbinden des DRBD als Veritas-Agent
 10.2  Vergrößern oder verkleinern eines DRBD-Laufwerks, das in einen Veritas-Cluster integriert wurde
11  DRBD und Docker
 11.1  Vorbereitung und erster Start des Containers
 11.2  Arbeiten mit dem Container
12  Win-DRBD
13  SSH-Configuration on SLE 15 / OpenSuSE Leap 15.x
14  Erstellen einer LVM-Volume-Group
 14.1  YaST
 14.2  Shell
15  Stoppen, starten, enablen und disablen von Systemdiensten - ein kleines Tutorial
 15.1  Dienstdateien kopieren
 15.2  Konfiguriere Dienste über YaST
 15.3  Bearbeite die Dienste mit systemctl
16  Quellenverzeichnis und Haftungsausschluss
 16.1  Quellenverzeichnis
  16.1.1  Internet
  16.1.2  Bücher
 16.2  Haftungsausschluss:
  Index
  Abbildungsverzeichnis
  Tabellenverzeichnis

1  Einführung

Wenn man einen Cluster aufbauen will, steht man früher oder später vor dem Problem, dass die Daten auf allen beteiligten Servern nutzbar sein müssen. Dieses Problem kann dadurch gelöst werden, dass die Daten einmal pro Minute vom aktiven Clusterknoten zum passiven Clusterknoten transportiert werden.
Was aber, wenn dieser „Kopierjob“ länger als eine Minute dauert?
In diesem Fall haben Sie entweder die Situation, dass sich die Kopieraufträge gegenseitig überholen und nie enden, weil der betreffende Clusterknoten nichts anderes tut als „kopieren“ - und „nichts anderes“ bedeutet „nichts anderes“ - oder die Daten sind jedes Mal veraltet.
Beides macht keinen Sinn und ist nicht wünschenswert.
Wenn dann noch hinzukommt, dass alle Clusterknoten die Daten nicht nur lesen, sondern auch gleichzeitig verändern müssen, macht das ëinfache Kopieren"überhaupt keinen Sinn mehr.
Normalerweise wird dieses Problem mit dem Einsatz eines SAN (Storage Area Network) oder NAS (Network Attached Storage) gelöst.
In einem Rechenzentrum, in dem in der Regel mehr als zwei Maschinen mit 24*7-Betriebszeit laufen, ist es kein Problem, eine weitere Maschine pro Clustergruppe zu betreiben - dies kann ein „Festplattentopf“ sein, bekannt als ein echtes SAN, oder es kann ein Netzwerk-Datenserver (Networkfileserver/NFS) sein, bekannt als NAS.
Kleine Unternehmen oder Privatanwender stehen jedoch vor dem Problem, dass ein SAN oder NAS auch bezahlt werden muss.
Die ist der Punkt, an dem das Distributed Replicated Block Device (kurz DRBD) der Firma LINBIT (https://www.linbit.com) ins Spiel kommt.
DRBD verschafft dem Anwender die Möglichkeit zwei oder mehr Clusterknoten miteinander zu verbinden, ohne ein SAN oder NAS als Datenträger einzusetzen. DRBD funktioniert dabei wie ein lokaler RAID-Controler, der ein „Mirror-Device“ (RAID1) erstellt - allerdings mit „lokalen Festplatten“, deren Rechner über das LAN verbunden sind.
Diese Variante ist auch in einem großen Rechenzentrum vorstellbar, wenn der Cluster unabhängig von einem SAN oder NAS betrieben werden muss. Stellen Sie sich zum Beispiel einen Monitoringserver vor, der das SAN oder NAS überwacht und auch dann noch zur Verfügung stehen muss, wenn das SAN oder NAS nicht läuft.
Dieses Kochbuch vermittelt die Grundlagen eines DRBD-Aktiv-Passiv-Clusters, erweitert um weitere Möglichkeiten (Drei-Knoten-Cluster, Backbone-LAN, Einbindung von DRBD auf einem Veritas-Cluster, Erstellung eines eigenen Clusters über PERL, Cluster-Konfiguration bei gehärteten Systemen u.v.m.) und demonstriert die Vorgehensweisen in Form von ’Listings’.
Alle Beispiel basieren auf einer Testkonfiguration mit openSUSE Leap 15.1 (mit Ausnahme von 6.1.1) und kann - mit dem notwendigen Hintergrundwissen - auf andere Linux-Distributionen übertragen werden.
Bei der Textziffer 6.1.1 wurde das Listing mit einem SLES 11 SP 4 ausgeführt, um die unterschiedlichen Kommandos und Bildschirmausgaben der DRBD-Version 8 im Vergleich zur DRBD-Version 9 aufzuzeigen, da es hier einige Unterschiede gibt.
Für die Verwendung von DRBD auf Windows-Servern sei auf das Kapitel 12 verwiesen.

1.1  Syntax dieses Buches

Um die Tastatureingaben und Bildschirmausgaben von den Erläuterungen zu unterscheiden, werden die Befehle und Bildschirmausgaben wie folgt dargestellt:

Listing 1.1:
Beispielssitzung

hostname:~ # echo "Das ist ein Beispiel!" 
Das ist ein Beispiel!

In den Skripten sind die einzelnen Zeilen fortlaufend nummeriert und werden im anschließenden Text kurz tabellarisch erläutert.
Das bedeutet, dass die Befehle der „Rezepte“ auf der Shell, wie in den Beispielen gezeigt, eingegeben werden können. Die Bildschirmausgabe sollte so ähnlich sein, wie gezeigt. Auf den Haftungsausschluss (16.2) wird hier jedoch ausdrücklich hingewiesen, denn Ihre Systeme werden kaum mit meinen übereinstimmen.

1.2  Eingebaute Fehler

Während der Erstellung dieses Buches, bei der Ausarbeitung der Rezepte, sind mir verschiedene Fehler unterlaufen, wie sie im Rahmen der praktischen Arbeit einfach passieren können.
Nach reiflicher Überlegung habe ich diese Fehler in den Rezepten belassen.
Im weiteren Verlauf der jeweiligen Rezepte, habe ich die aufgelaufenen Fehler wieder korrigiert - auch um zeigen, wie man die Situation retten kann und welche Faktoren - die vielleicht nicht sofort erkannt werden können, bei der jeweiligen Fehlersituation eine Rolle gespielt haben.
Auf diese Weise können Sie aus meinen Fehlern lernen und diese bei Ihren Systemen vermeiden.

1.3  Hostnamen

In einem alten Siemens-Nixdorf-UNIX-Handbuch wurden die Planetennamen Jupiter und Saturn als beispielhafte Hostnamen verwendet.
Da das Zwergplanetenpaar Pluto und Charon (Charon ist der größte Begleiter der Zwergplaneten Pluto) sein gemeinsames Gravitationszentrum außerhalb ihrer jeweiligen Planetenkörper hat, bot sich die Verwendung dieser Namen für einen Cluster geradezu an. Konsequenterweise bildet der zweitgrößte Pluto-Mond „Nix“ den dritten Host bei der Drei-Cluster-Knoten-Umgebung.

2  Installation

2.1  Software

Die DRBD-Software wird für die Server- oder Enterprise-Editionen ab den folgenden Linux-Distributionen bereitgestellt und entsprechend aktualisiert (Stand Sommer 2020):

Red Hat Enterprise Linux (RHEL), Versionen 6, 7 and 8

SUSE Linux Enterprise Server (SLES), Versionen 11 SP4, 12 and 15

Debian GNU/Linux, 8 (jessie), und 9 (stretch)

Ubuntu Server Edition LTS 14.04 (Trusty Tahr), LTS 16.04 (Xenial Xerus), und LTS 18.04 (Bionic Beaver)

Bei openSUSE werden die DRBD-Pakete ab der Version Leap 42.1 bereitgestellt.
Bei Verwendung des Kommandos zypper ergibt sich folgendes Bild (die ausgegebenen Zeilen habe ich verkürzt, da der Typ immer package ist):

Listing 2.1:
zypper search drbd

pluto:~ # zypper search drbd 
Loading repository data... 
Reading installed packages... 

S | Name                      | Summary                                                    | 
--+---------------------------+------------------------------------------------------------+- 
  | drbd                      | Linux driver for the "Distributed␣Replicated␣Block␣Device" | 
  | drbd-formula              | DRBD deployment salt formula                               | 
  | drbd-kmp-default          | Kernel driver                                              | 
  | drbd-kmp-preempt          | Kernel driver                                              | 
  | drbd-utils                | Distributed Replicated Block Device                        | 
  | drbdmanage                | DRBD distributed resource management utility               | 
  | yast2-drbd                | YaST2 - DRBD Configuration                                 | 
pluto:~ #

2.2  Systemvoraussetzungen

„Das System muss laufen!“’

Zugegebenermaßen ist das, besonders für eine Fachbuch, ein reichlich dummer Satz. Tatsache ist jedoch, dass die DRBD-Software keine expliziten, minimalen Systemvoraussetzungen hat, was darauf zurückzuführen ist, dass die DRBD-Funktionalität in den Linux-Kernel integriert wurde.
Rüsten Sie Ihre Clusterknoten entsprechend Ihren Anforderungen aus und stellen Sie sicher, dass die Hochverfügbarkeitsanwendung auf der bereitgestellten Plattform ordnungsgemäß läuft. In Bezug auf die Synchronisierung gibt es noch ein paar weitere Hinweise.
Um dieses Buch zu erstellen, habe ich zwei virtuelle Maschinen auf einem Laptop installiert, der den „großen“ Arbeitsspeicher von 4 GB hatte und mit einem Quadprozessor mit 2.16 GHz lief.
Dies mag für eine Workstation, ein Laptop oder Desktop geradeso reichen. Für einen Server oder Host ist diese Ausstattung „ein bisschen dünn“.
Die beiden „VMs“ auf diesem Laptop hatten jeweils 1 CPU und 1 GB RAM.
Die LAN-Connectivity wurde über einen einfachen LAN-Adapter mit der Geschwindigkeit von 10 Mb/s aufgebaut - für zu Hause reicht das gerade, für einen Server …naja….
Mein Sohn hat sich vor Kurzem beklagt, dass sein Laptop für HomeSchooling mit 8 GB-RAM etwas „schwachbrüstig“ ausgestattet wäre.
Für eine Serverumgebung, die lediglich die Aufgabe hat über apache „it works“ auszugeben, mag diese Hardwareausstattung als mager gelten. Aber um zu zeigen, dass die Grundfunktionen von DRBD arbeiten, ist diese Konfiguration immer noch ausreichend.
Je nach Größe der Festplattenpartitionen, die Sie in dieses RAID 1 einbeziehen möchten, sollten Sie die Einrichtung eines separaten LAN für die Festplattensynchronisierung (Backend-LAN) in Betracht ziehen. Sie sollten jedoch auf die Geschwindigkeit der Synchronisierung achten, da Ihre Computer sonst nur mit der Festplattensynchronisierung beschäftigt sein werden. Aber dazu später mehr.
Ich möchte hier auch keine Abhandlung über die Minimalanforderungen von Hosts schreiben, das haben andere vor mir getan und ich weiß auch, dass für manchen Privatanwendern 10 Mb/s eindeutig zu langsam für das heimatliche Netzwerk sind.
Was ich dagegen zeigen will, ist dass DRBD mit einer wirklich minimalen Ausstattung sauber arbeitet, was uns wieder zurück auf den Punkt der Kosteneinsparung, speziell bei kleineren Unternehmen bringt.

3  Vorüberlegungen

Bevor wir uns die Grundkonfiguration eines Zwei-Knoten-Clusters genauer ansehen, gibt es einige grundlegende Überlegungen.
Wenn Sie Ihre Auswahl bereits getroffen haben oder spezielle Anforderungen haben, können Sie dieses Kapitel getrost überspringen - allerdings auf eigene Gefahr.
Ich lese mir selbst nicht gerne endlose Einführungen durch, und ich kenne Kollegen, die die Einführungen sehr sorgfältig gelesen haben und dann nicht wussten, was sie tun sollten, wenn es an die Umsetzung ging.
Wichtig bei den Vorüberlegungen ist für mich, unnötige Arbeit zu vermeiden, damit man am Ende eines Testlaufs oder auch in einem laufenden, produktiven Cluster keine Ausfallzeiten hat.
Und nichts ist tödlicher für einen Cluster als nicht verfügbar zu sein.
Deshalb gilt auch hier das alte Heimwerker-Motto:

Erst messen - dann schneiden!

3.1  Festplattenlaufwerke – physikalisch im Vergleich zu LVM

Werfen wir also zunächst einen Blick darauf, wie das Laufwerk „konzipiert“ werden sollte.
Nehmen wir zunächst ein „physisches Festplattengerät“, d.h. eine zusätzliche Festplattenpartition, zusätzlich zu den „klassischen“ Partitionen wie swap, root (/) und /home.
Diese Lösung hat den Vorteil, dass es keine zusätzliche „Virtualisierungsschicht“ gibt, die die Verarbeitungsvorgänge aufhält, was im Zweifelsfall zu Leistungseinbußen führen könnte.
Der Nachteil ist, dass eine nachträgliche Vergrößerung oder Verkleinerung nur mit erhöhtem Aufwand durchgeführt werden kann, wenn tatsächlich Hardware ausgetauscht werden muss.
Die Verwendung von Logical Volume Manager, kurz LVM, verschafft mehr Spielraum, fügt aber eine Virtualisierungsschicht hinzu, was auf sehr engen Systemen zu den oben erwähnten Leistungseinbußen führen kann.
DRBD kann mit beiden Varianten arbeiten!
In den Systemen, die ich eingerichtet habe, verwende ich in der Regel den Logical Volume Manager, da der Vorteil des nachträglichen Hinzufügens von Festplatten den Nachteil der Leistungsverschlechterung überwiegt.

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:

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.

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.

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:

Listing 4.1:
erstelle einen SSH-Schlüssel

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:

Listing 4.2:
Kontrolle des erstellten SSH-Schlüssels

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:

Listing 4.3:
SSH-Schlüssel kopieren und in die Datei authorized_keys eintragen

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:

Listing 4.4:
SSH-Schlüssel kopieren - Alternative

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:

Listing 4.5:
Austausch der SSH-Schlüssel

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 …

Listing 4.6:
Austausch der SSH-Schlüssel - Alternative

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.

Abbildung 4.1:
YaST2 am Server pluto - Überblick

Abbildung 4.2:
YaST2 am Server pluto - Partitionsüberblick

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)

Abbildung 4.3:
YaST2 am Server pluto - erstelle und benenne ein logisches Volume

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).

Abbildung 4.4:
YaST2 am Server pluto - erstelle ein logisches Volume und definiere die Größe

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

Abbildung 4.5:
YaST2 am Server pluto - erstelle ein logisches Volume - definiere den Partitionstyp

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).

Abbildung 4.6:
YaST2 am Server pluto - erstelle ein logisches Volume - nicht formatieren / nicht mounten

Dementsprechend wird das Laufwerk nicht „montiert“.

Abbildung 4.7:
YaST2 am Server pluto - erstelle ein logisches Volume - Abschluß

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:

Listing 4.7:
vgdisplay

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.

Listing 4.8:
lvcreate

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:

Listing 4.9:
lvdisplay

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.

4.3  DRBD Konfiguration

DRBD hat ein zentrales Dateiverzeichnis, in dem die Konfigurationsdateien abgelegt werden. Diese Konfigurationsdateien müssen auf allen Cluster-Knoten vorhanden sein.
Um sich die Arbeit zu vereinfachen ist es sinnvoll die Konfigurationsdateien zunächst auf einem Cluster-Knoten zu erstellen und sie dann auf die anderen Cluster-Knoten zu verteilen.
„Die anderen Cluster-Knoten?“ höre ich Sie fragen.
Selbstverständlich, denn DRBD ist nicht auf zwei Cluster-Knoten begrenzt. Aber mehr dazu später! (Vergleiche Textziffer 6!)

4.3.1  Performance

Bevor ich an dieser Stelle näher auf die einzelnen Konfigurationsparameter eingehe, möchte ich noch ein paar Worte zur Serverleistung sagen:
In der Textziffer 4.3.5 werden verschiedene Synchronisationsmöglichkeiten beschrieben (Protokolle).
Es gibt Möglichkeiten die „Performance“ dieser Synchronisation zu beeinflussen, aber ich rate dringend davon ab!
Die Synchronisationsperformance ist - von Haus aus - auf Ihr System zugeschnitten. Wenn Sie an dieser Stelle eingreifen, besteht die Möglichkeit, dass Sie ihr System „ausbremsen“ weil es nur noch mit der Synchronisation beschäftigt ist!

4.3.2  /etc/drbd.conf

Die zentrale Konfigurationsdatei ist die Datei /etc/drbd.conf. Das Schlüsselwort include bindet die aktuellen Konfigurationsdateien in den DRBD-Service ein.
Die Datei sollte in etwa so aussehen:

Listing 4.10:
/etc/drbd.conf

pluto:~ # cat /etc/drbd.conf 
# You can find an example in  /usr/share/doc/drbd/drbd.conf.example 
include "drbd.d/global_common.conf"; 
include "drbd.d/*.res";

Eine Beispielsdatei ist unter dem folgenden Pfad zu finden:

/usr/share/doc/packages/drbd-utils/drbd.conf.example.

Der Eintrag include „drbd.d/*.res“ bindet automatische alle Dateien ein, die im Verzeichnis /etc/drbd.d/ enthalten sind und den Suffix .res im Namen tragen.
Diese Konfiguration kann sehr nützlich sein, weil sie die Arbeit vereinfacht.
Ist man aber noch in einer „Experimentierungsphase“ kann es auch sinnvoll sein, die zu verwendenden Konfigurationsdateien einzeln anzugeben.

4.3.3  /etc/drbd.d/global_common.conf

Die Datei /etc/drbd.d/global_common.conf setzt allgemeine Parameter, die sich auf alle DRBD-Resourcen auswirken.
Da es an dieser Stelle zu tiefgreifend wäre, auf diese individuellen Punkte einzugehen, geben wir uns an dieser Stelle damit zufrieden, dass die Datei existiert und gehen nach dem Motto:

„Never change an running system!“

4.3.4  Resourcekonfiguration

Überlegen wir uns zunächst, wie wir unsere Ressource nennen wollen. Da wir hier eine Apache-Website clustern wollen, nennen wir unsere Ressource einfach „apache“ und erstellen die folgende Datei:

/etc/drbd.d/apache.res:

Listing 4.11:
/etc/drbd.d/apache.res

pluto:/etc/drbd.d # cat apache.res 
resource apache { 
        protocol      C; 
        startup { 
                wfc-timeout          15; 
                degr-wfc-timeout      60; 
                become-primary-on      pluto; 
        } 
        disk { 
                on-io-error    pass_on; 
        } 
        on pluto { 
                meta-disk      internal; 
                disk        /dev/vg00/apache; 
                device      /dev/drbd0; 
                address      192.168.178.200:7751; 
        } 
        on charon { 
                meta-disk      internal; 
                disk        /dev/vg00/apache; 
                device      /dev/drbd0; 
                address      192.168.178.201:7752; 
        } 
}

Da die einzelnen Punkte näher beschrieben werden müssen, folgt die Beschreibung auf den folgenden Seiten. (Siehe 4.3.5)

4.3.5  Resourcenbeschreibung:

Schlüsselwort

Beschreibung

resource

Dieser Ausdruck wird verwendet, um die drbd-Ressource in den jeweiligen Befehlen zu erkennen oder anzusprechen.

Der Name sollte so „sprechend“ wie möglich sein.

protocol

Es gibt drei „Protokoll-Typen“: A, B und C

"Protocol A"

Protokoll A steht für „Asynchrones Replikationsprotokoll“, d. h. ein Schreibvorgang wird auf dem Primärsystem abgeschlossen, wenn der physische Schreibvorgang auf dem lokalen Festplattengerät erfolgreich abgeschlossen ist, und das Replikationsdatenpaket wird im lokalen TCP-Sendepuffer auf diesem Knoten erstellt. Das Paket wird einfach nicht sofort gesendet!

→ Im Falle eines Ausfalls kann dies zu Dateninkonsistenzen führen, da möglicherweise noch nicht alle Daten auf dem Sekundärserver angekommen sind! Andererseits wird der Schreibvorgang sehr schnell äbgeschlossenünd das Gerät kann den nächsten Befehl ausführen.

"Protocol B"

beschreibt das sogenannte „speichersynchrone (halbsynchrone) Replikationsprotokoll“. Der lokale Schreibvorgang auf dem primären Server gilt als abgeschlossen, wenn der physische Schreibvorgang auf der lokalen Festplatte beendet ist und das Replikationsdatenpaket den sekundären Knoten erreicht hat.

→ Diese Variante ist etwas langsamer als die Variante A, aber es gibt in der Regel keinen Datenverlust im Falle eines Failover.

"Protocol C"

steht für „Synchrones Replikationsprotokoll“. Hier steht die Sicherheit an erster Stelle! Lokale Schreibvorgänge auf dem primären Knoten gelten als abgeschlossen, wenn der physische Schreibvorgang auf dem lokalen Gerät und auf dem Gerät des sekundären Knotens erfolgreich abgeschlossen wurde.

→ Die Latenzzeit ist die langsamste im Vergleich zu „A“ und „B“, aber ein Datenverlust ist vollständig ausgeschlossen.

device

definiert den Namen des DRBD-Laufwerks, mit dem es im System angesprochen werden kann - zum Beispiel bei einem mount.

disk

definiert den Namen des Raw-Devices - siehe „Volumeerstellung“

meta-disk-internal

Legt fest, dass die Metadaten im DRBD-Laufwerk enthalten sein müssen.

wfc-timeout / degr-wfc-timeout

Die Zeitüberschreitung wait-for-connection ist die Zeit in Sekunden, die auf die andere Seite gewartet wird, wenn das System hochfährt, was bedeutet, dass das DRBD-Boot-Skript so lange pausiert wird. Der Wert ist standardmäßig auf 15 Sekunden eingestellt.

¹Die „offene Variante“ von RHEL.

¹Kommentar von Gil Grissom, CSI: Las Vegas

¹Das Werkzeug zur Überprüfung eines entfernten Hosts auf offene Ports ist nmap. Die Ausgabe ist klar und unmissverständlich. nmap ist auch für Windows mit der GUI Zenmap verfügbar (https://nmap.org/zenmap).

¹Variablentyp bei Perl