In der Welt von "Cloud-Ready-Applikationen" und skalierbaren Lösungen spielt ein Begriff kaum mehr eine Rolle, der früher von großer Wichtigkeit war: Hochverfügbarkeit. Moderne Anwendungen, besonders wenn sie den Prinzipien der "Cloud-Ready-Architektur" folgen, sind üblicherweise implizit redundant: Sie sind in viele Mikrokomponenten gespalten und von jeder davon kann es innerhalb der Applikation beliebig viele Instanzen geben. Das Prinzip des Skalierens in die Breite bietet eben nicht nur den Vorteil, quasi beliebig viele Ressourcen nachzurüsten falls nötig. Es sorgt implizit auch dafür, dass der Ausfall einzelner Komponenten nicht ins Gewicht fällt, weil die verbliebenen Instanzen desselben Diensts die Aufgaben der ausgefallenen Instanz übernehmen. So hat sich das Konzept an verschiedenen Stellen durchgesetzt und zum Teil entstehen sogar Lösungen, um konventionelle Applikationen um Cluster-Fähigkeiten zu erweitern. Erinnert sei etwa an Galera für MariaDB und MySQL, das beide um einen Modus für den Multi-Master-Betrieb erweitert.

Andere Anwendungen beherrschen das Skalieren in die Breite hingegen nicht. Will der Admin für diese Dienste Hochverfügbarkeit implementieren, steht er vor einem Problem: Welche Instanz kümmert sich darum, dass die Aufgaben ausgefallener Instanzen auf andere Instanzen verteilt werden? Spätestens wenn der IT-Verantwortliche sich diese Frage stellt, ist er beim Thema Hochverfügbarkeits-Cluster angekommen – und damit implizit natürlich auch bei Cluster-Managern.

Aus Cloudsicht wirken Cluster-Manager wie aus der Zeit gefallen: Sie legen sich in einem Verbund aus mehreren Servern wie eine Art Wachhund auf die Lauer und prüfen regelmäßig, ob alles wie gewünscht funktioniert. Fällt dann beispielsweise ein Server aus, initiieren sie einen so genannten Failover: Dabei startet der Clustermanager die Dienste, die auf dem nun nicht mehr verfügbaren Knoten gelaufen sind, auf einem anderen Knoten in exakt derselben Konfiguration neu. Anwender merken davon nicht viel und der Admin muss nachts nicht zwingend aufstehen, weil der benötigte Dienst weiterhin verfügbar ist.

Dass die modernen Applikationsarchitekturen für den Cloudbetrieb Cluster-Manager altmodisch wirken lassen, sollte den Administrator übrigens nicht dazu verleiten, diese per se für überflüssig zu halten. Große Umgebungen wie etwa OpenStack und viele konventionelle Programme sind im Innern bis heute auf klassisches Cluster-Management angewiesen, weil sie alle Dienste nutzen, die nicht implizit redundant sind. Für den Betrieb von Cloud-Workloads ist damit ironischerweise eine Komponente notwendig, von der Cloud-Workloads gerne behaupten, sie sei obsolet und konzeptionell abwegig.

Das Thema Cluster-Management unter Linux ist freilich nicht neu. Zwar waren andere Betriebssysteme Linux ein Stück weit voraus, für HP-UX etwa gab es bereits einen funktionalen Cluster-Manager, als Linux noch in den Babyschuhen steckte. Doch auch auf Linux steht seit den frühen 2000er-Jahren leistungsstarke Software für das Management von Hochverfügbarkeits-Clustern zur Verfügung. Alan Robertson begann kurz nach Anfang des neuen Jahrtausends mit der Arbeit an einer Software namens Heartbeat, die in ihrer ersten Version kaum mehr als eine Sammlung von verschiedenen Shell-Skripten war. Heartbeat in der Version 1 konnte, wenn es auf zwei Servern lief, im Wesentlichen diese sich gegenseitig überwachen lassen und zuvor definierte Programme auf dem einen oder dem anderen Knoten des Clusters starten. In Summe war sein Funktionsumfang also eher überschaubar, und trotzdem erfreute Heartbeat 1 sich lange großer Beliebtheit bei Admins, die eine schnelle HA-Lösung für Linux benötigten.

Diese Beliebtheit hat sicher auch mit dem Nachfolger zu tun: Heartbeat 2 entstand seinerzeit unter Federführung von SUSE und fußte auf einem komplett neu ent­wickelten technischen Fundament. Der Australier Andrew Beekhof als leitender Entwickler trennte zunächst die Kommunikationsschicht, die den Nachrichtenaustausch zwischen den Cluster-Knoten möglich macht, vom Management der Cluster-Ressourcen. Fortan hatten Admins es einerseits mit dem "Cluster Communication Management" (CCMd) und dem "Cluster Resource Management Daemon" (CRMd) zu tun – zwei Begriffe, die im Pacemaker-Kontext bis heute eine wichtige Rolle spielen. Beide Schichten wurden praktisch komplett neu entwickelt und als Namen für den CRMd etablierte sich bald "Pacemaker". Der CCMd hingegen firmiert bis heute unter der Bezeichnung "Corosync". Im Gespann waren Corosync und Pacemaker freilich viel mächtiger als Heartbeat 1, aber auch deutlich komplexer. Dies ist schon an der Tatsache zu erkennen, dass Pacemaker seine zu verwaltenden Ressourcen in einer internen XML-Datei verwaltet, statt diese Information wie Heartbeat 1 aus einer Datei im Dateisystem zu beziehen. Die XML-Datei heißt übrigens "Cluster Information Base" (CIB).

Heute gilt Pacemaker [1] mit Corosync als Goldstandard für Cluster-Management unter Linux. Wer mit dem Werkzeug bisher nicht gearbeitet hat, tut sich beim Einstieg jedoch schwer. Es existiert heute viel Dokumentation zu Pacemaker, die unterschiedlichen Distributionen gehen für die Pacemaker-Einrichtung jedoch verschiedene Wege. Dieser Artikel gibt anhand des Beispiels CentOS 8 einen Einblick in die Einrichtung eines Clusters mit Pacemaker, der eine MariaDB-Datenbank hochverfügbar und ohne Galera betreibt.

Vorab jedoch noch eine Information hinsichtlich der verschiedenen Linux-Distributionen: Red Hat und SUSE verteilen Pacemaker als Teil des "High Availability Repositories" (Red Hat) oder der "High Availability Extension" (SUSE) in separaten Verzeichnissen, für die eigene Subskriptionen notwendig sind. Bei Ubuntu liegt Pacemaker ohne Aufpreis bei, allerdings in einer nicht mehr ganz taufrischen Version, Gleiches gilt für Debian. Die besten Karten haben Admins im Moment deshalb mit CentOS 8, denn aktuelle Pakete sowohl von Pacemaker als auch von den benötigten Zusatzwerkzeugen sind Teil des ELRepo und der dortigen HA-Erweiterung. Kommerziellen Support gibt es dafür aber nicht – wer darauf besteht, muss zu Red Hat greifen. Die Konfiguration von Pacemaker geschieht auf RHEL mit Ausnahme der unterschiedlichen Repository-Konfiguration aber analog zur in diesem Artikel beschriebenen Vorgehensweise bei CentOS. Diese Anleitung ist auf RHEL 8 daher übertragbar.

MariaDB per Pacemaker hochverfügbar aufzusetzen, klingt im ersten Augenblick einfacher, als es in der Praxis ist. Denn damit am Ende ein stimmiges Gesamtbild entsteht, braucht es nicht nur die Datenbank selbst. Ein Failover muss zusätzlich für Clients stets transparent sein. Geht ein MariaDB-Server in die Knie, startet Pacemaker diesen bei richtiger Konfiguration auf einem anderen Host erneut. Müsste der Admin nun aber bei allen Datenbankclients eine neue IP-Adresse konfigurieren, wäre das viel Aufwand und mit einer langen Downtime verbunden. Es muss stattdessen die IP-Adresse zusammen mit der MariaDB-Instanz umziehen.

Freilich hilft eine hochverfügbare Maria-DB auch nicht weiter, wenn der Datensatz, den die Datenbank servieren soll, nicht auf allen Knoten des HA-Clusters identisch ist. Das heißt im Klartext, dass der Admin es mit Shared Storage zu tun bekommt: Irgendwie muss er die Daten in ihrer aktuellsten Version auf beiden Systemen verfügbar halten. Das geht wahlweise mit

einem Storage Volume, das sich zum Beispiel per iSCSI einbinden lässt, oder mit einer Replikationslösung wie DRBD. Beide Ansätze bedingen allerdings in Pacemaker Zusatzkonfiguration. Kommt iSCSI zum Einsatz, muss die iSCSI-LUN in Pacemaker konfiguriert sein, sodass dieser sie aktiviert und in das Dateisystem einhängt, bevor MariaDB startet.

Bei DRBD muss Pacemaker vor dem MariaDB-Start die Ressource auf dem richtigen Host in den "Primary"-Modus versetzen, damit sie dort nutzbar wird. Danach ist die DRBD-Ressource ebenfalls in das lokale Dateisystem einzuhängen. Diese Schritte sind in Pacemaker separat zu konfigurieren – und zwar so, dass sie in der richtigen Reihenfolge ablaufen. Der erste Schritt auf dem Weg dorthin ist freilich die Installation der Pacemaker- und Corosync-Pakete. Um das Beispiel komplett zu machen, gehen wir in diesem Workshop zudem davon aus, dass DRBD für die Replikation der Daten zum Einsatz kommt.

Die folgende Anleitung lässt sich in virtuellen Maschinen gut durchspielen. Möchten Sie ein Setup für den produktiven Einsatz betreiben, orientiert sich die Wahl der Hardware an den Anforderungen des betreibenden Diensts. Steht MariaDB regelmäßig unter hoher Last, wird sich die DB etwa über starke CPUs und viel RAM freuen. Für DRBD kann es sich unter Umständen außerdem lohnen, eine separate Netzwerkkarte mit hoher Bandbreite zu ver­­bauen, die die – im Beispiel zwei – Cluster-Knoten direkt verbindet. So können Sie auch ohne 25-, 50- oder 100-GBit-Infratruktur im RZ trotzdem von hoher Geschwindigkeit bei der Replikation profitieren. Obgleich es offensichtlich ist, sei zudem ausdrücklich erwähnt: Das Beispiel im Artikel bedingt zwei separate Server.

Die Installation der benötigten Pakete auf CentOS 8 setzt voraus, dass Sie das High-Availability-Repository für diesen Zweck aktivieren:

Danach holt der Befehl

automatisch alle benötigten Pakete auf die Systeme. Der Eintrag "pcs" ist dabei wichtig: Es handelt sich um die "Pacemaker Control Shell", die in CentOS und Red Hat die Konfiguration von Pacemaker erledigt.

Wer sein Setup lieber auf SUSE-Basis baut, sei gewarnt: Dort kommt standardseitig ein anderes Werkzeug zum Einsatz, um Pacemaker zu konfigurieren – die "crmsh", also die CRM-Shell. Im Zweifel hilft ein Blick in die Dokumentation beider Werkzeuge, um die Unterschiede zu erkennen und sich im jeweils anderen Tool zurechtzufinden.

Nach der Installation der Pacemaker-Pakete gilt es, Pacemaker und darunter Corosync so zu konfigurieren, dass die Pacemaker-Instanzen auf beiden Systemen einander sehen und miteinander kommunizieren können. Auf RHEL und CentOS ist ab Werk Firewalld aktiviert, das über "nftables" die Systeme weitgehend von der Außenwelt abschottet. Corosync muss, um Pacemaker die Kommunikation zu ermöglichen, aber freilich offene Ports auf dem jeweils anderen System finden. Die drei Befehle

erledigen das, denn ein Profil namens "high-availability" ist in Firewalld praktischerweise vorangelegt.

Bei der Installation von Pacemaker legt das dazugehörige RPM-Paket automatisch den Benutzer "hacluster" auf beiden Systemen an. Per passwd hacluster setzen Sie auf allen Systemen im nächsten Schritt das Passwort für diesen Benutzer. Es darf sich um jedes beliebige, valide Linux-Passwort handeln. Es ist jedoch sinnvoll, auf den beiden Knoten im Beispiel dasselbe Passwort auf allen Hosts zu nutzen. Entsprechend sollten Sie ein langes Passwort generieren. Ist dieser Schritt erledigt, starten Sie den "PCS Daemon", der nun die Pacemaker-Konfiguration erledigt:

Wichtig: Damit die Pacemaker-Verbindung zwischen den Hosts klappt, müssen die Hostnamen beider Systeme auf beiden Systemen auflösbar sein. Betreiben Sie keinen DNS für lokale Domains, helfen die passenden Einträge in "/etc/hosts".

Weil PCSd zum Einsatz kommt, ist das Deployment des Clusters im nächsten Schritt das Ziel. Der Befehl

ruft einen Assistenten auf, der zunächst nach dem Benutzernamen fragt. Die beiden Systemnamen müssen Sie durch die kompletten Hostnamen der beiden Systeme ersetzen. Der Benutzername ist "hacluster", das Passwort haben Sie im vorhergehenden Schritt generiert. Läuft der Befehl ohne Fehler durch, können die PCSd-Instanzen auf beiden System miteinander kommunizieren. Dann folgt das Setup von Pacemaker selbst mittels

Mit pcs cluster enable --all schalten Sie Pacemaker danach schließlich scharf. Der Befehl pcs cluster status sollte Ihnen für die beiden Cluster-Knoten den Status "online" liefern. Der Aufruf von pcs status zeigt die vollständige Übersicht über alle Pacemaker-Details an, ist aktuell aber noch leer, denn Ressourcen sind in Pacemaker noch nicht konfiguriert.

Im weiteren Verlauf beschreiben wir die Einrichtung einer DRBD-Ressource, auf der Daten für MySQL liegen. Shared-Storage-Ansätze bergen immer die Gefahr von Datenverlust, besonders dann, wenn beide Cluster-Knoten grundsätzlich noch arbeiten, aber ihre Verbindung zueinander verlieren. Beide Knoten sehen dann den jeweiligen Cluster-Partner nicht und gehen davon aus, dass dieser nicht länger verfügbar ist – sie starten die jeweiligen Dienste dann so, wie es sein soll, bei sich neu. Sind beide Knoten weiter online, führt das letztlich dazu, dass der geteilte Speicher von beiden Cluster-Knoten aus unkoordiniert schreibend verändert wird, es entsteht eine so genannte Split-Brain-Situation.

Hier kommt das Fencing ins Spiel. Das Prinzip besagt: Bevor ein Knoten selbst aktiv wird, stellt er sicher, dass der andere Knoten sicher defekt ist und nicht dasselbe versucht. Das geht zum Beispiel über Fencing per Remote-Management: Bevor Knoten 1 die Dienste aktiviert, schaltet er per IPMI den anderen aus. Die dazu benötigten Ressourcen sind in Pacemaker separat anzulegen. Dem Admin begegnet dabei auch die Abkürzung "STONITH" für das wenig romantische "Shoot the other node in the head". Unter der Annahme, dass die IPMI-Schnittstellen den Benutzernamen und das Passwort "admin" nutzen und unter 10.42.0.10 und 10.42.0.11 zu erreichen sind, lassen sich die STONITH-Ressourcen wie folgt anlegen:

Die folgenden Befehle (auf Constraints gehen wir später noch im Detail ein) sorgen dafür, dass die STONITH-Ressourcen nur auf dem jeweils anderen Knoten laufen:

Pacemaker ist ab Werk darauf ausgelegt, den Cluster möglichst ausbalanciert zu halten. Das führt zu einem kuriosen und im Alltag oft unerwünschten Effekt: Kommt ein Knoten nach einem Ausfall wieder hoch, würde Pacemaker Ressourcen automatisch auf diesen migrieren. Das sorgt mindestens für eine kurze Downtime, die de facto unnötig ist. Es empfiehlt sich aus Sicht des Admins deshalb, den Befehl

zu nutzen, um das Verhalten zu unterbinden. Intern arbeitet Pacemaker mit einem komplexen Punktesystem, um zu entscheiden, welche Ressource wo im Cluster läuft. Setzen Sie den Parameter "Resource Stickiness" auf einen Wert größer als "0", unterbleibt der lästige Fail-Back-Vorgang.

Wie eingangs erwähnt, setzen wir auf die Replikationslösung DRBD, um den Datensatz der MariaDB auf beiden Systemen synchron zu halten. Dazu benötigen wir zunächst DRBD auf dem System. Dieses kommt aus dem ELRepo-Verzeichnis, das Sie mit den Befehlen

aktivieren. Danach holt der Befehl

sämtliche notwendigen Pakete auf das System. Die Grundkonfiguration erledigen Sie in der Datei "/etc/drbd.d/global_ common.conf", die aussehen sollte wie in Listing 1.

Danach gilt es, auf beiden Systemen die DRBD-Ressource zu konfigurieren und die initiale Synchronisierung anzustoßen. Das Beispiel geht davon aus, dass auf beiden Systemen LVM zum Einsatz kommt, um den vorhandenen Speicherplatz zu verwalten. Die vom CentOS-Installer angelegte Volume-Group heißt "cl_system". Mittels

legen Sie ein 50 GByte großes LVM-Vol-ume an, das anschließend unter "/dev/ cl_system/mariadb" verfügbar ist. Unter der Annahme, dass System 1 den Hostnamen "system1.domain" und die IP-Adresse "192.168.122.10" und System 2 den Hostnamen "system2.domain" und die IP-Adresse "182.168.122.11" hat, definieren Sie unter "/etc/drbd.d/mariadb.res" anschließend auf beiden Systemen für jede DRBD-Ressource die Konfiguration.

Das Beispiel aus Listing 2 ist auf genau dieses Setup angepasst, lokal abweichende Konfigurationen sind entsprechend zu beachten. Wichtig: DRBD erwartet bei der Angabe der Hostnamen nur den Hostnamen ohne Domain. Es verhält sich hier also exakt andersherum als bei Pacemaker, zumindest unter RHEL 8 und CentOS 8.

Auf beiden Systemen erzeugen Sie danach die Metadaten der DRBD-Ressource mittels

Danach geben Sie in der Firewall den Port 7789 frei, damit die DRBD-Ressourcen miteinander kommunizieren können. Das geschieht mittels

Der Befehl drbdadm up mariadb startet die Ressource danach auf beiden Servern. Auf einem der beiden Knoten vollziehen Sie schließlich den Beginn der ersten Synchronisierung mittels

Anschließend zeigt drbdadm status die Ressource an, die im Status "SyncSource" oder "SyncTarget" sein sollte. Ist der Vorgang abgeschlossen, ändert der Status der Ressource sich auf "UpToDate" und DRBD ist nutzbar. Auf dem System, wo die Ressource sich im "Primary"-Modus befindet, legt der Befehl mkfs.xfs /dev/drbd0 ein Dateisystem auf ihr an. Dieses ist später nötig, um die Daten für MariaDB auf der DRBD-Ressource zu lagern.

Im nächsten Schritt installieren Sie MariaDB. Über

holen Sie die nötigen Pakete auf das System: Per systemctl start mariadb starten Sie den Dienst im Anschluss. Dieser Befehl ist vorerst aber nur auf dem System nötig, auf dem sich die DRBD-Ressource gerade im "Primary"-Modus befindet. Dort hängen Sie eben jene DRBD-Ressource nun temporär nach "/mnt" ein (mount /dev/drbd0 /mnt).

Danach stoppen Sie MariaDB per systemctl stop mariadb wieder und kopieren sämtliche Inhalte von "/var/lib/mysql" nach "/mnt". Am leichtesten geht das per Rsync mittels

Anschließend hängt umount /mnt die DRBD-Ressource wieder aus. Wichtig ist, dass der Benutzer "mysql" und die Gruppe "mysql" auf beiden Systemen dieselben UIDs und GIDs haben, sonst kommt es später zu Problemen beim Hin- und Herschwenken der Ressource in Pacemaker. Ein letzter Schritt fehlt noch: Per

 

geben Sie den MariaDB-Port in der Systemkonfiguration frei. Damit sind alle Ressourcen für den Einsatz in Pacemaker vorbereitet.

Den Auftakt zum großen Finale in Pacemaker macht die IP-Adresse, über die MariaDB später erreichbar sein soll. Im Beispiel lautet sie 192.168.122.12. Pacemaker verwaltet seine Ressourcen intern über so genannte "Resource Agents", die sich in unterschiedliche Klassen aufteilen. Empfohlen sind Resource-Agenten, die den Vorgaben des "Open Cluster Framework" (OCF) folgen. Der Resource-Agent, der IP-Adressen in Pacemaker verwaltet, heißt "IPaddr2", kommt vom Heartbeat-Projekt und folgt eben jener Spezifikation. Sie sprechen ihn in Pacemaker deshalb als "ocf:heartbeat:IPaddr2" an.

Für das Beispiel nutzen wir eine so genannte "Shadow-CIB", also eine Textdatei, die die gesamte Konfiguration sammelt, um sie später zusammen in Pacemaker hochzuladen. Der Befehl

legt diese in der Datei "drbd_cfg" an. Und

fügt der Datei danach die Ressource für die IP-Adresse hinzu.

DRBD-Ressourcen bestehen in Pacemaker aus zwei Teilen: Der eigentlichen Basisressource und einer "Promotable Clone"-Regel. Die ist nötig, weil DRBD auf den Servern nicht nur die Zustände "funktioniert" und "funktioniert nicht" kennt, sondern auch "funktioniert oder funktioniert nicht in primären oder sekundären Modus." Entsprechend sind zwei Befehle nötig, um die Ressourcen anzulegen:

 

Dann folgt das Dateisystem:

Pacemaker kann das Dateisystem nur dort einhängen, wo die DRBD-Ressource im "Primary"-Modus aktiv ist. Das bedingt eine räumliche Abhängigkeit der Ressourcen, die in Pacemaker über einen "Colocation Constraint" abgebildet ist, ebenso wie eine zeitliche Abhängigkeit, die in Form eines "Order-Constraints" zum Ausdruck kommt:

Die IP-Adresse soll nur dort gestartet werden, wo das DRBD-Dateisystem aktiv ist, weil MariaDB dort sonst läuft. Auch dafür gibt es einen Colocation- und einen Order-Constraint:

Dann folgt die Ressource für MariaDB selbst, die auf CentOS bevorzugt per Systemd verwaltet wird und sich so auch in Pacemaker einbinden lässt:

Ist die Konfiguration wie gewünscht in der Datei hinterlegt, lässt sich ihr Inhalt mittels

in Pacemaker übernehmen. Der Befehl pcs status zeigt anschließend die konfigurierten Ressourcen an. Befindet sich MariaDB im Status "Running", sollte es obendrein möglich sein, sich von einem beliebigen Host im Netzwerk aus per "mysql"-Client mit der Datenbank zu verbinden. Ob der HA-Mechanismus funktioniert, lässt sich danach relativ simpel testen: Auf dem Knoten, auf dem die Datenbank gerade läuft, führt reboot -f zum harten Neustart des Systems. Der andere Server sollte dann erst ein STONITH-Ereignis auslösen und im Anschluss die Dienste bei sich selbst neu starten. Via pcs status sollten Sie anschließend zudem "failed resources" erhalten. Diese lassen sich, wenn der andere Knoten wieder online ist, mittels pcs resource cleanup beseitigen.

Hochverfügbarkeit und Cluster-Manager sind keineswegs IT-Anachronismen, sondern sichern nach wie vor wichtige Dienste wie Datenbanken zuverlässig gegen Ausfall und Datenverluste. IT-Verantwortliche sollten sich also nicht der Illusion hingeben, dass im Cloudzeitalter alle Dienste stets unbeeinträchtigt laufen, sondern sich nach wie vor mit Werkzeugen wie Pacemaker beschäftigen, das als freies Werkzeug mit ein wenig Handarbeit Workloads zuverlässig schützt.