DRBD-Kochbuch

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

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:

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:

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

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.