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

Von Jörg Seubert

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. Auch die Funktionsweise der verschiedenen Linux-Dateisysteme wird erklärt.

• Sprache: Deutsch
• Herausgeber: epubli
• Erscheinungsdatum: 24. Feb. 2022
• ISBN: 9783754954133

Buchvorschau

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