Open Source im professionellen Einsatz
Linux-Magazin 07/2004

Linux-HA-Cluster mit Heartbeat und DRBD

Reservespieler

Ein Hochverfügbarkeits-Cluster unter Linux ist auch mit einfachen Mitteln zu realisieren. Der Einstieg in die Oberliga für Server benötigt nur Standardkomponenten und die beiden freien Programme Heartbeat und DRBD - und schon steht beim Absturz des Mittelstürmers ein Reservespieler bereit.

706

Hohe Ausfallsicherheit ist schon durch Einsatz zweier billiger PCs möglich, auch wenn die Hersteller edler Highend-Hardware dabei mit den Zähnen knirschen. Der häufigste Anwendungsfall für HA-Cluster (High Availability) dieser Art dürften Standarddienste wie Samba, Apache oder eine Datenbankapplikation sein. Diese Art Cluster stellt ein Backup-System (Hot Standby) für Dienste zur Verfügung.

Im Gegensatz zu Computing- oder Load-Balancing-Clustern ist einer der Server in diesem Fall passiv und wird erst tätig, wenn der Arbeitsserver ausfällt. Die von der Anwendung benötigten Daten werden dabei über das Netz gespiegelt, ein gemeinsamer Datenspeicher (Shared Storage) ist nicht nötig: Der Linux HA-Cluster ist ein Share Nothing Cluster. Da beide Rechner komplett ausgestattet sind und sich keine gemeinsamen Ressourcen teilen, fällt ein Single Point of Failure weg. Das sieht zunächst nach höheren Investitionen aus, aber die speziellen SCSI- oder Firewire-Komponenten für Shared Storage Cluster sind teuer, die Share Nothing Cluster kommen mit Standardkomponenten aus.

Komponenten besser redundant

In einer Produktivumgebung ist es zu empfehlen, Komponenten wie Netzteile, Hubs, Switches und Festplatten von guter Qualität einzusetzen und sie redundant auszulegen. Für einfache HA-Cluster genügen jedoch schon zwei einfache PCs mit jeweils zwei Netzwerkkarten, auf denen eine übliche Linux-Distribution läuft, im beschriebenen Beispiel Suse 9.0 Professional.

In ihr sind die zur Clusterbildung benötigten Pakete - Heartbeat und DRBD - bereits enthalten. Der Admin installiert sie über Yast und startet sie über den Runlevel-Editor. Eine neuere Linux-Version einzusetzen ist derzeit nicht ratsam, DRDB in den zu Redaktionsschluss aktuellen Releases 0.6xx arbeitet noch nicht mit Kernel 2.6 zusammen. Von Version 0.7 gibt es nur eine Pre-Release.

Bevor es losgeht

Beide Systeme bekommen die übliche Partitionsaufteilung, am besten möglichst gleichartig, also zum Beispiel »/swap«, »/« und »/boot«. Für die Daten, die der Cluster zur Verfügung stellen soll, ist jeweils noch eine separate Partition notwendig. Sie sollte auf beiden Rechnern etwa gleich groß sein und darf keinen Mountpoint erhalten und nicht beim Systemstart angebunden werden; diese Optionen sind über den Schaltknopf »Fstab-Optionen« im Yast-Menü »Partitionen bearbeiten« zugänglich (siehe Abbildung 1).

Abbildung 1: Die Option »Nicht beim Systemstart mounten« muss aktiviert sein. Das Mounten ist Aufgabe der Clustertools. Als Device wird später die DRBD-Ressource in die Datei »/etc/fstab« eingetragen.

Als Dateisystem ist ein Journaling Filesystem wie Ext 3 oder ReiserFS zu empfehlen. XFS hingegen wird von DRDB erst ab Version 0.7 unterstützt. Die beiden Netzwerkkarten bekommen feste IP-Adressen. Im Beispiel für Karte 1 (»eth0«) die 140.10.0.1 auf dem primären Knoten, auf dem anderen Server bekommt die Karte 1 (»eth0«) die Adresse 140.10.0.2 als sekundärer Knoten. Das sind auch die Adressen, die öffentlich sichtbar sind.

Dabei ist an dieser Stelle eine deutliche Warnung auszusprechen: Die Clustersoftware nimmt tief gehende Manipulationen im Netz vor. Da beide Server abwechselnd mit der gleichen IP-Adresse im Netz sein werden, kann ein Fehler leicht alle aktiven Netzwerkkomponenten lahm legen. Die jeweils zweite Netzwerkkarte (»eth1«) ist für die private, die Heartbeat-Leitung zuständig. Im vorliegenden Beispiel hat Knoten 1 als IP-Adresse 192.168.85.1 und Knoten 2 die 192.168.85.2. Die Ports beider Netzwerkkarten verbindet der Admin mit einem Netzwerk-Crossover-Kabel oder einem separaten Hub (Abbildung 2).

Abbildung 2: Ein einfacher Share Nothing Cluster. Im öffentlichen Netz ist unter der Clusteradresse (140.10.0.10) der aktive Knoten erreichbar. Das Spiegeln der Daten und die Clusterüberwachung per Heartbeat erfolgen über das private Netz.

Howtos schlagen oft ein Nullmodem- Kabel als Heartbeat-Leitung vor, weil Heartbeat dann auch noch mit kaputtem IP-Stack funktioniert. Jedoch ist dieses Argument fragwürdig: Wenn ein Linux-Server seinen IP-Stack verloren hat, ist der Ernstfall eingetreten. Spottbillige 100-MBit-Netzwerkkarten erlauben es heutzutage, außer Heartbeat auch den Datenabgleich über das private Netz laufen zu lassen, also im günstigsten Fall direkt über ein Crossover-Kabel. Das minimiert zum einen die Gefahr eines Angriffs auf die Daten. Zum anderen ist diese Leitung unbelastet vom Zugriffsdatenstrom der Benutzer, die Übertragungskapazität kann so voll ausgeschöpft werden.

Trivial, aber wichtig sind eindeutige Namen für beide Rechner. Es ist eine gute Idee, die Namen für beide, die private und die öffentliche IP-Adresse, jeweils in die »/etc/hosts« einzutragen. Schließlich sollte der sekundäre Server noch seine Zeit per »xntp« mit dem primären Server abgleichen; es ist darauf zu achten, den Zeitunterschied der beiden Server vor der Inbetriebnahme des Clusters auszugleichen.

Linux-Magazin kaufen

Einzelne Ausgabe
 
Abonnements
 
TABLET & SMARTPHONE APPS
Bald erhältlich
Get it on Google Play

Deutschland

Ähnliche Artikel

  • Schrittmacherdienste

    Zero Downtime ist angesichts globaler Zusammenarbeit über Kontinente und Zeitzonen hinweg keine ungewöhnliche Forderung mehr. Daran gebunden ist der Ruf nach Hochverfügbarkeit. Um ihm unter Linux nachzukommen, bietet sich der neue Cluster-Resource-Manager Pacemaker mit weiteren Komponenten an.

  • Frisch gestrichen

    Seit Red Hats Cluster-Suite und Suses Heartbeat-GUI gewinnen mausorientierte Werkzeuge zur Administration hochverfügbarer Linux-Cluster an Kontur. Für DRBD gibt es neuerdings eine Java-basierte grafische Oberfläche, allerdings noch mit Betastatus. Ist sie bereits alltagstauglich?

  • Lastverteiler

    Eine clevere IPtables-Funktion und Linux-HA verwandeln gewöhnliche Server in einen starken Cluster. Dessen Knoten teilen die Last untereinander und springen im Fehlerfall gegenseitig ein - ganz ohne zentrale Steuerung. Hardwarefehler oder Wartungsfenster verlieren ihren Schrecken.

  • Hochverfügbarkeit mit Linux im Wandel

    Hochverfügbarkeit oder High Availability (HA) hat sich in den letzten Jahren vom Nischenthema zum wichtigen Faktor für IT-Entscheider entwickelt. Wenn das Geschäftsmodell ausschließlich auf einer Website oder einem anderen Online-Dienst beruht, kostet ein Ausfall Geld und Nerven.

  • LVM-Unterstützung für DRBD-Management-Console

    Mit der aktuellsten Version der DRBD-Management-Console können Administratoren nun auch logische Volumes verwalten.

comments powered by Disqus

Ausgabe 08/2016

Artikelserien und interessante Workshops aus dem Magazin können Sie hier als Bundle erwerben.