© Volodymyr Melnyk / 123RF.com

Der klassische HA-Stack unter Linux besteht aus Corosync und dem wenig beliebten Pacemaker. Wer virtuelle Instanzen mit repliziertem Speicher braucht, greift stattdessen zu DRBD 9 und dem DRBD Reactor. Das führt zu vergleichbaren Ergebnissen, ist aber leichter zu bedienen.

In der modernen IT muss alles skalieren: Höher, besser, weiter lautet das Motto. Das bedeutet aber nicht, dass klassische Hochverfügbarkeit in Form von Zwei-Knoten-Clustern der Vergangenheit angehört. Ganz im Gegenteil: Sogar bei einer OpenStack-Cloud gibt es diverse Dienste, die hochverfügbar ausgelegt sein müssen. OpenStack selbst bietet dafür ab Werk allerdings keine Betriebsmöglichkeiten.

Letztlich springt dann wieder ein konventioneller HA-Cluster in die Bresche. Er sorgt dafür, dass zentrale Dienste, die für den Betrieb der Plattform nötig sind, Ausfälle und andere Probleme überleben. Dafür gibt es verschiedene Spielarten: Manchmal laufen die nötigen Dienste direkt in einem Linux auf eigener Hardware. Weitaus üblicher ist es heute aber, sie in virtuelle Instanzen zu packen und von einem Clustermanager verwalten zu lassen.

Das Gespann aus DRBD, Pacemaker und KVM unter Verwendung von Libvirt gilt dabei als etabliert und zuverlässig. Sonderlich beliebt ist es allerdings nicht. Das liegt vor allem am Linux-HA-Stack. DRBD ist für die meisten Admins eine bequeme Alternative. Vielerorts kommt mittlerweile DRBD 9 statt DRBD 8 zum Einsatz. Die neuere Version lässt sich in der Grundkonfiguration ebenso leicht nutzen und konfigurieren.

Beim Linux-HA-Stack liegen die Dinge anders. Das hat historische Gründe. Vor 15 Jahren sah die Welt im Hinblick auf Linux und Cluster schließlich noch ganz anders aus. Heartbeat 1, maßgeblich von Alan Robertson bei IBM entwickelt, war nicht viel mehr als ein Verhau aus Shell-Skripten, die bei einem Ausfall eines Servers Dienste auf einem anderen neu starten konnten.

Dann geriet der Stack allerdings in den Fokus der großen Distributoren. Zunächst beauftragte SUSE Andrew Beekhoff damit, Heartbeat [1] zu einem vollwertigen Cluster-Manager zu entwickeln, der bald unter der Bezeichnung Heartbeat 2 fungierte. Dann heuerte Beekhoff bei Red Hat an und bekam dort die Aufgabe, diverse Funktionen in Heartbeat zu integrieren, die den Betrieb von Clustern mit mehr als zwei Knoten möglich machten. Bald änderte das Projekt seinen Namen in Pacemaker.

Es ist seither immer komplexer geworden. Nicht nur, dass es unter der Haube noch immer auf eine Konfigurationsdatei setzt, die in XML daherkommt und entsprechend kompliziert in der Handhabung ist. Mittlerweile ist der Cluster-Stack auch in etliche Komponenten zersplittert. Zunächst teilte man die Schicht für die Cluster-Kommunikation vom eigentlichen Cluster-Manager ab, fortan firmierte sie unter der Bezeichnung Corosync [2]. Mancher genervte Admin nennt die Komponente auch Horrorsync.

Später spaltete man Corosync noch einmal auf. Während Corosync sich heute vor allem um den Austausch von Daten zwischen verschiedenen Systemen eines Clusters kümmert, sorgt Kronosnet [3] dafür, dass die Informationen auf korrektem Weg über das Netz gehen und auf der Gegenseite richtig ankommen. Mittlerweile gibt es auch einen Management-Daemon für Pacemaker namens Pcsd [4] (Abbildung 1). All das hat Pacemaker noch komplexer gemacht als es ohnehin bereits war.

Abbildung 1: Der Linux-HA-Stack wurde in den vergangenen Jahren immer komplexer, etwa durch die Einführung eines Management-Daemons für die Pacemaker Control Shell PCS (Pcsd).

Die Krux dabei: Noch immer ist das Zwei-Knoten-Szenario eines der häufigsten, in denen Pacemaker zum Einsatz kommt. Viele Admins benötigen lediglich einen Dienst, der in bester Heartbeat-1-Manier ein Failover initiieren kann, sobald ein System ausfällt. Vom Gros der Komplexität in Pacemaker profitieren viele Setups also gar nicht, haben sie aber trotzdem am Bein.

Firmen wie Linbit [5], die sich auf Consulting rund um Linux-HA spezialisiert haben, merken das laut eigener Aussage deutlich. Sie treffen immer wieder auf Setups mit fehlerhaften Pacemaker-Konfigurationen. Deren Debugging frisst viel Zeit und ist entsprechend teuer. Vor einiger Zeit hat Linbit deshalb eine Alternative zu Pacemaker gebaut, die auf die Handhabung einfacher Use Cases spezialisiert ist: den DRBD Reactor [6].

Die Dinge einfach halten

Man wird Linbit zu Recht unterstellen, dass eine Motivation hinter der Entwicklung von Reactor sicher war, Kunden die Verwendung des eigenen Kernprodukts DRBD schmackhaft zu machen. Das RAID 1 über das Netz ist gerade in kleineren Installationen ohnehin schon eine gute Alternative zu teuren NAS- oder SAN-Storages.

Es punktet obendrein damit, dass Linbit DRBD unter den Bedingungen der GPL und mithin unter einer freien Lizenz veröffentlicht. Unternehmen können DRBD so deutlich einfacher durch eine alternative Lösung ersetzen, als es bei proprietären NAS- oder SAN-Appliances der Fall ist. Einen großen Hemmschuh für den Vertrieb von DRBD hat man bei Linbit aber offensichtlich in Pacemaker ausgemacht. Das halte Kunden wegen seiner Komplexität davon ab, überhaupt HA-Lösungen auf Grundlage von Linux-HA zu bauen, heißt es. Reactor ist der Versuch des Wiener Unternehmens, Pacemaker dort, wo es möglich ist, durch eine weniger komplexe Lösung zu ersetzen.

Linbit weist ausdrücklich darauf hin, dass es sich bei Reactor um eine eigenständige Komponente handelt, die auch ohne DRBD funktioniert. Wollte der Kunde DRBD Reactor also ohne DRBD nutzen, könnte er alternativ ein iSCSI-Volume oder ein NVMe-over-Fabric-Target nutzen, um geteilten Speicher an seine Zielsysteme anzubinden, betonen die Österreicher. Der von Linbit standardmäßig vorgesehene Use Case dürfte aber das Gespann von DRBD 9 und Reactor sein. Dafür sind beide Komponenten ausgelegt, und dieses Beispiel betrachtet dieser Artikel auch im weiteren Verlauf als Standardszenario.

Einfacher Einstieg

Zum Standard wurde die Kombination DRBD und Reactor aus mehreren Gründen: Bis heute ist DRBD eine der einfachsten Methoden, geteilten Speicher im Rechenzentrum zu realisieren. Externe Zusatzgeräte wie NAS- oder SAN-Speicher muss man erst anschaffen und einrichten, sie sind im Normalfall auch viel teurer. Während für ein paar Terabyte replizierten Speicher schnell Zehntausende Euro an Kosten anfallen, lässt sich dasselbe in kleinerem Maßstab mit DRBD oft über einen RAID-Controller und entsprechend große NVMes in jenen Maschinen realisieren, die ohnehin den HA-Cluster bilden.

Deshalb liegt die Einstiegshürde bei DRBD auch niedriger als bei Ceph. Das wäre immerhin auch eine Open-Source-basierte Lösung, käme also auch ohne den gefürchteten Vendor-Lock-in aus. Dafür hat Ceph wegen seiner impliziten Latenz oft aber Probleme in HA-Setups, die flotten Speicher für Dateien oder virtuelle Instanzen anbieten sollen. DRBD ist unter der Haube vergleichsweise simpel. Komplexe Algorithmen sucht man hier vergebens, anders als bei Ceph, wo CRUSH [7] den Ton angibt.

In Summe sind die Einstiegshürden für DRBD also so niedrig wie bei praktisch keiner anderen Speicherlösung. Hinzu kommt, dass DRBD in der aktuellen Version 9 heute für die meisten Distributionen in Paketform zur Verfügung steht, auch vom Hersteller Linbit selbst. Es ist also leicht, aus zwei Standardservern von der Stange mit entsprechenden Speicherlaufwerken einen DRBD-Cluster zu bauen, der auch virtuelle Instanzen betreiben kann.

Zudem ist DRBD bestens mit gängigen IT-Lösungen integriert. Eine native Schnittstelle zu Kubernetes existiert ebenso wie eine Anbindung an OpenStack. Dazu setzt Linbit auf Drbdmanage, das eigens für DRBD 9 gebaute Management-Framework. Auch das steht in einer Community-Edition ohne größere Einschränkungen kostenfrei in Paketform für alle gängigen Distributionen zur Verfügung.

Im Folgenden beschreibt dieser Artikel, wie sich unter Verwendung von DRBD und dem DRBD Reactor ein hochverfügbarer Cluster für den Betrieb virtueller Maschinen mit KVM und Libvirt realisieren lässt. Der Linux-HA-Stack bleibt dabei weitgehend außen vor. Lediglich an einer Stelle greift DRBD Reactor auf Bestandssoftware aus dem Stack zurück: Bei der Verwaltung der virtuellen Maschinen aus Reactor heraus kommen die Resource Agents nach OCF-Standard zum Einsatz [8].

Installation der Pakete

Gegeben seien zunächst zwei frisch installierte Systeme mit Ubuntu 24.04. Dabei spielt es keine Rolle, ob die Installation händisch oder mittels Bare Metal Lifecycle Management und Automation erfolgt ist. Wichtig ist lediglich, dass beide Systeme über die jeweils aktuellste Software verfügen: Nur dann lässt sich das Community-Verzeichnis [9] für DRBD 9 von Linbit in das System integrieren. Die dafür nötigen Schritte entsprechen der Standardvorgehensweise für die Integration externer Paketquellen in Ubuntu.

Zunächst hinterlegen Sie das Community-Verzeichnis des Herstellers auf dem System und aktivieren es (Listing 1, erste zwei Zeilen). Danach holen Sie die Pakete für DRBD 9 auf das System (dritte Zeile). Weil der Hersteller DRBD 9 in Form eines DKMS-Paketes zur Verfügung stellt, erstellt DKMS das nötige Kernel-Modul automatisch. Je nach Konfiguration kann es nötig sein, »modprobe drbd« auf der Kommandozeile auszuführen. Dmesg sollte im Anschluss die Meldung präsentieren, dass das DRBD-Modul nun geladen ist. Der Apt-Befehl hat neben DRBD noch dessen Verwaltungswerkzeuge sowie Drbdmanage auf das System geholt; DRBD Reactor ist ebenfalls installiert.

$ sudo add-apt-repository ppa:linbit/linbit-drbd9-stack
$ sudo apt update
$ sudo apt install drbd-dkms drbd-utils python-drbdmanage drbd-reactor

DRBD-Ressource einrichten

Ein Kernel-Modul macht noch keinen Frühling. Der Administrator muss mittels dieses Moduls ein repliziertes Speicherlaufwerk einrichten. Das Beispiel geht davon aus, dass auf beiden Systemen des künftigen HA-Clusters (Alice und Bob) ein Speicherlaufwerk »/dev/sdb/« existiert, das die Grundlage des künftigen HA-Clusters darstellt. Unter der Haube kann das beispielsweise das beschriebene RAID-Laufwerk sein, ein RAID 5 oder RAID 6 aus mehreren NVMes.

Eine Herausforderung bei dieser Art des Setups besteht darin, dass die Laufwerke dann vermutlich etliche Terabyte groß sind, meist aber eine einzelne VM nicht so viel Speicherplatz nutzen soll. Umgehen lässt sich das Problem mithilfe von LVM [10]. Wichtig ist dann, dass als Backend-Laufwerk für DRBD das jeweilige Logical Volume (LV) zum Einsatz kommt und die Replikation auch auf Grundlage dieser LVs stattfindet. Das Setup weicht von der Standardvorgehensweise der Vergangenheit etwas ab. Früher war es durchaus üblich, LVM selbst zur Cluster-Ressource zu machen und mit Pacemaker zu verwalten. Das ist aber komplizierter als nötig.

Der nächste Schritt besteht folglich darin, zunächst die Datenträger für DRBD einzurichten. Das gelingt, sofern das Paket lvm installiert ist, unter Ubuntu 24.04 mit »pvcreate /dev/sdb« und »vgcreate drbd /dev/sdb«. Der erste Befehl legt die für LVM nötigen Metadaten auf dem Laufwerk an. Das zweite Kommando erzeugt auf beiden Systemen eine Volume Group namens »drbd« und fügt ihr das gerade angelegte Physical Volume hinzu.

Dann entsteht das erste Logical Volume: Auf beiden Systemen erledigt das Kommando »lvcreate -L100G -n proxy drbd« alles Nötige. Im Beispiel entsteht ein 100 Gigabyte großes Volume namens »proxy« für die spätere Verwendung als Speicher einer VM, die einen Squid-Proxyserver betreibt. Dann erfolgt das Setup der DRBD-Ressource. Die Konfigurationsdatei aus Listing 2 passt zum Beispiel in diesem Artikel, lässt sich darüber hinaus aber gut für lokale Einsatzzwecke abwandeln.

Wichtig: Sollten die Ubuntu-Systeme mit aktiver Firewall, etwa in Form von Ufw, ausgerollt sein, so ist der genannte Port – im Beispiel 7789 – entsprechend zu öffnen. Dann erfolgt das Anlegen der Metadaten für die Ressource auf beiden Systemen mittels »drbdadm create-md proxy« sowie »drbdadm up proxy«. Schließlich erklärt der Administrator eines der Laufwerke zur kanonischen Quelle für die Richtigkeit der Daten. Weil die Laufwerke ohnehin leer sind, ist hier egal, ob das Kommando »drbdadm primary proxy –force« auf Alice oder Bob läuft.

# vi /etc/drbd.d/proxy.res
resource proxy {
  device drbd0;
  disk /dev/drbd/proxy;
  meta-disk internal;
  on alice {
    address 10.42.0.100:7789;
    node-id 0;
  }
  on bob {
    address 10.42.0.101:7789;
    node-id 1;
  }
  connection-mesh {
    hosts alice bob;
  }
  options {
    auto-promote no;
    quorum majority;
    on-suspended-primary-outdated force-secondary;
    # for the default drbd-reactor
    # on-quorum-loss policy (i.e. Shutdown)
    on-no-quorum io-error;
    # always set this to the value of on-no-quorum!
    on-no-data-accessible io-error;
  }
  net {
    protocol C;
    after-sb-0pri discard-zero-changes;
    after-sb-1pri discard-secondary;
    after-sb-2pri disconnect;
  }
}

Virtuelle Instanz einrichten

Der nächste Schritt ist aus Admin-Sicht klassisches Brot-und-Butter-Geschäft und hat mit DRBD wenig zu tun: Es steht die Installation der virtuellen Instanz auf dem Plan. Dazu genügt es, auf beiden Systemen KVM und Qemu zu installieren, im BIOS die VT/SVM-Flags für die jeweilige CPU zu aktivieren und die Libvirt zu installieren, die die Verwaltung der Instanzen übernimmt. Dann ist es an der Zeit, auf dem Knoten, auf dem die DRBD-Ressource zuvor in den Primary-Modus gezwungen worden ist, mittels des Kommandos aus Listing 3 die virtuelle Instanz auszurollen.

$ virt-install \
  --name ubuntu2404 \
  --ram 4096 \
  --disk path=/dev/drbd/proxy \
  --vcpus 2 \
  --os-variant ubuntu24.04 \
  --network bridge=br0 \
  --graphics none \
  --console pty,target_type=serial \
  --location /tmp/ubuntu-24.04-live-server-amd64.iso, \
    kernel=casper/vmlinuz,initrd=casper/initrd \
  --extra-args 'console=ttyS0,115200n8'

Das Kommando ist als Beispiel zu verstehen. Es setzt voraus, dass auf dem System eine Netzwerkbrücke »br0« eingerichtet ist und in »/tmp« ein ISO-Abbild von Ubuntu 24.04 Server liegt. Obendrein enthält das Beispiel die Anweisung, eine virtuelle serielle Konsole an die Instanz anzuhängen, deren Inhalte gleich im lokalen Terminal aufscheinen.

Abbildung 2: Virt-install ermöglicht die Installation einer virtuellen Instanz von der Kommandozeile aus. Virter von Linbit ist eine mögliche Alternative. Quelle: Debian Handbook, CC BY-SA 3.0

Hier ist es sinnvoll, die Option Continue in basic mode auszuwählen und dann wie üblich mit der Installation fortzufahren. Nach erfolgreichem Abschluss der Arbeiten enthält »/dev/drbd/proxy/« eine komplette Installation von Ubuntu 24.04, die auf den jeweiligen Cluster-Partner gespiegelt ist.

Wichtig ist dann allerdings noch, die nun entstandene Konfigurationsdatei der Instanz (»/etc/libvirt/qemu/ubuntu2404.xml«) an dieselbe Stelle des anderen Cluster-Systems zu kopieren und im Nachgang dort mittels »systemctl restart libvirt-bin« Libvirt neu zu starten. Linbit bietet selbst übrigens ein Werkzeug namens Virter an, das Libvirt-VMS per CLI anlegen und klonen kann [11].

Schnellstart

DRBD Reactor selbst ist streng genommen kein klassischer Cluster-Manager. Einen großen Teil der Funktionen, die Pacemaker aus Corosync und Kronosnet entnimmt, sucht man in Reactor vergebens. Die entsprechenden Funktionen fehlen deshalb allerdings nicht. Stattdessen verlässt DRBD Reactor sich auf ohnehin bereits vorhandene Funktionalität in Systemd und DRBD. Scherzhaft bezeichnet Linbit selbst DRBD Promoter als “extravagantes Werkzeug, um Systemd-Units anzulegen”. Genau darin besteht nämlich der größte Teil der Leistung von DRBD Promoter: Es richtet die Systemd-Konfiguration so ein, dass das Tool beim Auftreten bestimmter Ereignisse eine programmierte Reaktion zeigt.

Dazu belauscht DRBD Reactor vor allem den Systembus und schreibt die dort aufgezeichneten Ereignisse mit. Tickert ein Event durch den Systembus, für das eine DRBD-Reactor-Regel angelegt ist, versetzt Reactor bei entsprechender Konfiguration die jeweilige DRBD-Ressource in den gewünschten Zustand und lässt Systemd im Anschluss den größten Teil der übrigen Arbeit erledigen. Deshalb ist die nötige Konfiguration für DRBD Reactor im Beispiel auch recht übersichtlich.

Die Datei aus Listing 4 hinterlegen Sie in »/etc/drbd-reactor.d/proxy.toml«. Danach sorgt »systemctl restart drbd-reactor« dafür, dass der Dienst die neue Konfiguration nutzt. Bemerkenswert ist dabei, wie viel weniger komplex diese Einstellung im Vergleich mit Pacemaker ist (Abbildung 3).

[[promoter]]
[promoter.resources.proxy]
start = ["ocf:heartbeat:VirtualDomain p_kvm-proxy config=/etc/libvirt/qemu/proxy.xml"]

Abbildung 3: In Pacemaker wäre die hier gezeigte Konfiguration notwendig, um denselben Effekt zu erzielen, für den DRBD Reactor mit der Konfiguration aus Listing 4 sorgt.

Unter der Haube

Wer sich bereits früher mit DRBD befasst hat, stellt sich hier wohl die Frage, wie die beschriebenen Automatismen im Hinblick auf DRBD selbst funktionieren. Hat man DRBD schon einmal im Gespann mit Pacemaker eingerichtet, weiß man, dass das nicht ganz trivial ist. Pacemaker muss sich je nach Setup nicht nur um die eigentliche DRBD-Ressource kümmern, sondern stets auch um anliegende Ressourcen. Soll DRBD als Grundlage für einen Samba-Server dienen, muss Pacemaker beispielsweise dafür sorgen, dass zusammen mit der Primary-Rolle der DRBD-Ressource die jeweilige Cluster-IP umschwenkt, ebenso der Einhängepunkt des Dateisystems der DRBD-Ressource.

Zu diesem Zweck gibt es den OCF-Resource-Agent »ocf:heartbeat:Filesystem«. Nicht zu vergessen ist die DRBD-Ressource selbst: In der Grundkonfiguration lässt sie sich nur dort verwenden, wo sie eben im Primary-Modus ist. Dieser Teil des Setups trägt in Pacemaker nochmals erheblich zur Komplexität der Konfiguration bei. Pacemaker hat ja ein eigenes Konstrukt für Dienste, die verteilt im Cluster laufen und dabei in den verschiedenen Instanzen clusterweit unterschiedliche Zustände kennen.

Bei DRBD ist das der Fall: Dort, wo die Ressource genutzt wird, ist sie im Primary-Modus. Dort, wo der jeweilige Knoten nur Updates empfängt, ist sie stattdessen im Secondary-Modus und auf dem System selbst nicht nutzbar. Einen Zugriffsversuch würde das DRBD-Kernel-Modul mit einer Fehlermeldung quittieren.

In DRBD 9 ist die Situation im Hinblick auf Pacemaker zudem noch komplexer, es unterstützt nativ mehr als zwei Knoten. Pacemaker kennt für Mehrknotendienste Promoted-Unpromoted-Zustände. Die Funktion kann Admins gehörig nerven, denn die Setups, die früher auch unter dem Namen Master-Slave (Abbildung 4) firmierten, sind kompliziert einzurichten. Das gilt bereits für zwei Knoten und noch mehr für Multi-Knoten-Installationen. Linbit gibt an, dass ein erheblicher Teil der im Alltag von DRBD-Kunden produzierten Probleme mit ebendiesen Konfigurationsanweisungen zu tun hat.

Abbildung 4: Master-Slave-Sets dürften Pacemaker-geplagten Admins noch ein Begriff sein. Sie verwalten im Cluster Ressourcen wie DRBD, heißen mittlerweile aber Promoted-Unpromoted.

Linbit hat sich deshalb bereits vor einiger Zeit des Themas angenommen und in DRBD 9 eine Funktion eingerichtet, die das automatische Aktivieren des Primary-Modus für eine Ressource dort erlaubt, wo auf sie zugegriffen werden soll. Das Konstrukt ist mit Sicherheitsmaßnahmen versehen: So probiert DRBD 9 nicht, eine Ressource automatisch in den aktiven Modus zu schalten, wenn sie anderswo im Cluster bereits aktiv ist. Das ist wichtig, um Split-Brain-Situationen zu vermeiden. DRBD Reactor profitiert von dem automatischen Umschalten in den Master-Modus allerdings massiv, denn das Feature ist zentraler Baustein für seine Funktionalität.

Weitere Überlegungen

Wer DRBD 9 mittels Linstor [12] verwalten möchte, der SDS-Anwendung von Linbit unter freier Lizenz, kann auch das tun. Die Dienste sind miteinander integriert und harmonieren gut. Linstor (Abbildung 5) löst zudem ein Problem, um das der Administrator sich ansonsten anderweitig kümmern müsste: Es implementiert ein Quorum. Das ist ein heikles Thema bei Zwei-Knoten-Clustern. Es ist zwingend nötig, wenn die beiden Cluster-Knoten ihre Verbindung zueinander verlieren, um zu vermeiden, dass beide sich für den jeweils verbliebenen aktiven Knoten halten und alle Dienste scharfschalten.

Abbildung 5: Die Linstor-GUI verwaltet DRBD-Cluster auf Wunsch auch grafisch und kümmert sich durch das Deployment eines Arbiter-Knotens um das aus Admin-Sicht leidige Thema des Quorums. Quelle: Linbit

Pacemaker unternimmt mittels IPMI und STONITH (“Shoot the other node in the head”) etliche Verrenkungen, um einen solchen Zustand zu vermeiden. In Zwei-Knoten-Clustern ist Quorum aber immer ein Kompromiss. In Linstor lässt sich deshalb ein Arbiter-Knoten einrichten, auch als Quorum Tie Breaker bekannt. Er überwacht beide Systeme und ist für die Schaffung eines Quorums zuständig, wenn die beiden Cluster-Server einander nicht mehr sehen. Die Hardwareanforderungen an einen solchen Arbiter sind dabei gering, ein Raspberry Pi reicht im Regelfall aus. Wer also noch einen Port im Rack freihat, fährt mit dieser Option deutlich besser als mit den ansonsten üblichen Pacemaker-Basteleien.

Fazit

Weder DRBD Reactor noch dieser Artikel haben zum Ziel, dem Linux-HA-Stack oder Pacemaker die Qualität oder die Praxistauglichkeit abzusprechen. Ganz im Gegenteil: Andrew Beekhof und das Team der Entwickler, die an den verschiedenen Linux-HA-Komponenten arbeiten, haben in der vergangenen Dekade aus einer Bastellösung einen Enterprise-fähigen Cluster-Manager geschaffen. Heute gelten Cluster unter Linux nicht mehr als Bastellösung. Wo Linux-Admins früher fast schon neidisch in Richtung AIX oder HP-UX blickten, die frühzeitig umfassende Cluster-Manager an Bord hatten, ist die Situation heute oft umgekehrt. Wie so oft hat die Open-Source-Community auch in Sachen Clustering ganze Arbeit geleistet.

Allerdings ist Pacemaker mittlerweile so vielseitig und so komplex, dass Administratoren damit vielerorts schlicht überfordert sind. Gerade bei vermeintlich einfachen Setups wie einem Zwei-Knoten-Cluster für den Betrieb weniger Instanzen ist oft auch die Bereitschaft nicht ausgeprägt, sich in ein komplexes Thema wie Pacemaker umfassend einzuarbeiten. Stattdessen soll die Software funktionieren und von sich aus das Richtige tun. Mittels DRBD Reactor versucht man in Wien bei Linbit genau das zu erreichen.

DRBD Reactor ist viel weniger komplex als Pacemaker. Hier gibt es nicht etliche Komponenten, die virtuos zusammenspielen müssen. Man hat es auch nicht mit verschiedenen CLI-Werkzeugen zu tun, die abhängig von der genutzten Distribution (Pcs auf Red Hat, Crm auf Suse) zu verwenden und zueinander inkompatibel sind. Stattdessen genügt es, eine DRBD-Ressource anzulegen und sie über eine einfache Konfigurationsdatei an DRBD Reactor anzubinden. Letzteres erfolgt indirekt über den Umweg einer virtuellen Instanz. Das ist merklich einfacher als der Pacemaker-Weg, führt letztlich aber zu vergleichbaren Ergebnissen.

Berührungsängste müssen Admins dabei keine haben. Alle vorgestellten Komponenten stehen kostenlos im Netz zur Verfügung und arbeiten unter Ubuntu 24.04 bestens. Sie sind zudem unter einer freien Lizenz veröffentlicht. Den Vendor-Lock-in erspart man sich bei einer Lösung wie der skizzierten also ebenfalls. Es muss nicht immer Pacemaker sein, und manchmal ist weniger mehr. DRBD Reactor belegt das. (jcb)