Erhalten Sie Zugang zu diesem und mehr als 300000 Büchern ab EUR 5,99 monatlich.
- Herausgeber: epubli
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Deutsch
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.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 111
Veröffentlichungsjahr: 2022
Das E-Book (TTS) können Sie hören im Abo „Legimi Premium” in Legimi-Apps auf:
Ähnliche
DRBD-Kochbuch
Hochverfügbarkeitslösungen selbst erstellen - ohne SAN oder NAS!
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 Handelsmarkender 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 Amerikaund anderen Ländern.Die Begriffe SLES®, SUSE®, YAST®und openSUSE®sind registrierte Handelsmarken derSUSE 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ällenauf die entsprechende Kennzeichnung im Dokument zu verzichten.HerausgeberJörg Christian Seubert, 91227 Leinburg-Diepersdorf, [email protected], ein Service der neopubli GmbH, BerlinGedruckt in DeutschlandTexterstellung und Satz mitLATEX, KOMA-Script und pdfLATEXBibliographische 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
1Einfü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.1Syntax dieses Buches
Um die Tastatureingaben und Bildschirmausgaben von den Erläuterungen zu unterscheiden, werden die Befehle und Bildschirmausgaben wie folgt dargestellt:
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.2Eingebaute 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.3Hostnamen
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.
2Installation
2.1Software
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):
2.2Systemvoraussetzungen
„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.
3Vorü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.1Festplattenlaufwerke – 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.
