Nach 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:
|
1 2 |
apt-get update apt-get install glusterfs-server |
Die beiden Memberserver des HA Clusters sollten in der /etc/hosts Datei hinterlegt werden, falls DNS Abfragen nicht möglich sind.
|
1 2 3 |
root@glusterfs1:~ > cat /etc/hosts 10.1.1.109 glusterfs1.domain.com glusterfs1 10.1.1.142 glusterfs2.domain.com glusterfs2 |
Nun erzeugen wir einen Mountpoint wo GlusterFS seine Daten ablegt. In diesem Verzeichnis darf nichts geschrieben werden! Es wird nur von GlusterFS bedient!
|
1 |
mkdir -p /mnt/glusterfs |
Diese Einstellungen müssen natürlich auch auf dem zweiten Host vorgenommen werden. Nun erstellen wir ein gespiegeltes Volume mit Namen configstore:
|
1 |
gluster volume create configstore replica 2 transport tcp glusterfs1:/mnt/glusterfs glusterfs2:/mnt/glusterfs force |
Da der Mountpoint im Filesystem liegt muss der Parameter force genutzt werden. Eine kurze Statusabfrage gibt uns alle Infos zum GlusterFS Dateisystem:
|
1 2 3 4 5 6 7 8 9 10 |
root@glusterfs1:/ > gluster volume status Status of volume: configstore Gluster process Port Online Pid ------------------------------------------------------------------------------ Brick glusterfs1:/mnt/glusterfs 49152 Y 949 Brick glusterfs2:/mnt/glusterfs 49152 Y 951 NFS Server on localhost 2049 Y 954 Self-heal Daemon on localhost N/A Y 960 NFS Server on 10.1.1.142 2049 Y 956 Self-heal Daemon on 10.1.1.142 N/A Y 961 |
Dieses gespiegelte Volume können wir mit dem glusterfs-client einbinden:
|
1 |
apt-get install glusterfs-client |
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:
|
1 2 |
mkdir -p /mnt/config mount -t glusterfs glusterfs1:configstore /mnt/config |
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:
|
1 |
apt-get install pacemaker |
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:
|
1 2 3 4 5 6 7 |
interface { # The following values need to be set based on your environment ringnumber: 0 bindnetaddr: 10.1.1.109 mcastaddr: 226.94.1.1 mcastport: 5405 } |
Anschliessend „yes“ in der Corosync Default Datei setzen für den Autostart:
|
1 2 3 |
root@glusterfs1:~ > cat /etc/default/corosync # start corosync at boot [yes|no] START=yes |
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.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
root@glusterfs1:/ > crm_mon -1 Last updated: Tue Mar 17 14:54:46 2015 Last change: Tue Mar 10 15:30:01 2015 via crm_resource on glusterfs2 Stack: corosync Current DC: glusterfs2 (167838094) - partition with quorum Version: 1.1.10-42f2063 2 Nodes configured 2 Resources configured Online: [ glusterfs1 glusterfs2 ] postfix (ocf::heartbeat:postfix): Started glusterfs1 virtual-ip (ocf::heartbeat:IPaddr2): Started glusterfs1 |
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:
|
1 2 3 4 5 6 |
primitive postfix ocf:heartbeat:postfix meta target-role="Started" primitive virtual-ip ocf:heartbeat:IPaddr2 params ip="10.1.1.251" nic="eth0" cidr_netmask="24" op monitor interval="10s" meta is-managed="true" property stonith-enabled=false no-quorum-policy="ignore" |
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:
|
1 2 3 |
cd /etc/ mv postfix postfix-original ln -s /mnt/config/etc/postfix . |
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.