Jörg Seubert - DRBD-Kochbuch

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.1wurde 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 12verwiesen.

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.

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.

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.

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:~ #

„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….