Читать книгу DRBD-Kochbuch - Jörg Seubert - Страница 3

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.