Linux High Availability Cluster mit Corosync, Pacemaker und GlusterFS

HA-PacemakerNach langer Zeit habe ich mal wieder ein High Availability Projekt mit Linux HA auf dem Operationstisch. Diesmal verwende ich Corosync und Pacemaker zur Umsetzung und GlusterFS als distributed Filesystem um die Configs bereitzustellen. Sonst erledigt das DRBD, aber ich wollte halt mal was anderes ausprobieren. Dazu benötigen wir natürlich erst mal zwei Ubuntu Server. Logisch. Für den Anfang wählen wir das einfache Active/Passive Setup.

Zunächst installieren wir auf dem ersten Node das GlusterFS:

Die beiden Memberserver des HA Clusters sollten in der /etc/hosts Datei hinterlegt werden, falls DNS Abfragen nicht möglich sind.

Nun erzeugen wir einen Mountpoint wo GlusterFS seine Daten ablegt. In diesem Verzeichnis darf nichts geschrieben werden! Es wird nur von GlusterFS bedient!

Diese Einstellungen müssen natürlich auch auf dem zweiten Host vorgenommen werden. Nun erstellen wir ein gespiegeltes Volume mit Namen configstore:

Da der Mountpoint im Filesystem liegt muss der Parameter force genutzt werden. Eine kurze Statusabfrage gibt uns alle Infos zum GlusterFS Dateisystem:

Dieses gespiegelte Volume können wir mit dem glusterfs-client einbinden:

Im Ordner /mnt legen wir einen Ordner config an, den wir nachher mit Symlinks als Speicherort für die Konfigurationen nutzen. Dorthin mounten wir das GusterFS Volume:

Jetzt gehts weiter mit dem eigentlichen HA Cluster. Auf beiden Nodes wird „Pacemaker“ installiert. Corosync wird als Abhängigkeit mitinstalliert und dienst als Kommunikationsdienst für Pacemaker der die Clusterressourcen verwaltet:

Die einzige Anpassung für Corosync nehmen wir in der /etc/corosync/corosync.conf vor. Und zwar das Interface auf dem Corosync laufen/hören soll:

Anschliessend „yes“ in der Corosync Default Datei setzen für den Autostart:

Und schon können wir Corosync mit service corosync start starten. Das gleiche wieder auf dem zweiten Node durchführen. Klar, oder? Kurzer Check ob alles läuft mit crm_mon -1. Der Parameter -1 ruft den Status nur einmal auf.

Wie man sieht habe ich jetzt schon etwas vorgegriffen. Der Mailserver „Postfix“ läuft als Dienst auf beiden Nodes und es kommt eine virtuelle shared IP zum Einsatz. Pacemaker als Clusterdienst wird ganz einfach (gegenüber Heartbeat V1)  per CLI konfiguriert. Man nehme crm configure und los gehts:

Der Postfix Dienst muß natürlich aus allen Runleveln entfernt werden. Darum kümmert sich ab jetzt Pacemaker. Die Ressource-Scripte liegen im Ordner /usr/lib/ocf/resource.d/heartbeat. Man sieht schon wie der Syntax in der Config aufgebaut ist: ocf:heartbeat:postfix. In diesem Ordner kann man auch eigene Scripte hinterlegen die man in Pacemaker einbinden kann.

Damit Postfix seine Konfiguration von beiden Knoten aus abrufen kann, setzt man einen symbolischen Link in das GlusterFS Volume:

Nun liegt die Konfiguration zentral im shared Volume unter /mnt/config/etc/postfix und kann bei einem Ausfall des Primärknotens vom Backupknoten aufgerufen werden. Unter /mnt/config/etc/ könnte man nun weitere Konfigurationen für andere Dienste bereitstellen die mit Pacemaker abgesichert sind. Auch Daten wie Webseiten für Apache oder IMAP Maildirs für Mailserver. Bei Datenbanken würde ich dann doch eher zum blockbasierenden  DRBD raten. Ich hoffe das war ein kurzer inspirierender Ausflug in die Welt von High Availability unter Linux. Jetzt gilt es: ausprobieren, ausprobieren und nochmal ausprobieren! So leicht das auch aussieht – man sollte seinen Cluster kennen und im Notfall auch routiniert bedienen können.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*