Corosync/Pacemaker
Um meine Dienste im Docker-Swarm Cluster für alle Clients konsistent über eine IP-Adresse erreichbar zu haben, musste ich die Cluster-Funktionen Corosync und Pacemaker einrichten.
Im wesentlichen habe ich mich an vorhandenen Tutorials lang gehangelt.
Jedoch bin ich auf erwähnenswertes Unerwähntes gestoßen:
- /etc/hosts
Hier müssen beide Cluster-Member auf beiden Systemen eingetragen werden. Einfache Namen, keine Zahlen!
- Die gleichen Namen müssen im corosync.conf verwendet werden.
- /etc/corosync/corosync.conf
- CRM – Die Konsole um den Pacemaker Status abzufragen, muss extra installiert werden:
apt-get install crmsh
Nun kann man den Status des Clusters abfragen:
crm status
Stack: corosync
Current DC: secondary (version 1.1.16-94ff4df) - partition with quorum
Last updated: Sat Oct 19 20:48:05 2019
Last change: Sat Oct 19 20:43:44 2019 by root via crm_attribute on secondary
3 nodes configured
1 resource configured
Online: [ secondary third ]
OFFLINE: [ primary ]
Full list of resources:
virtual_public_ip (ocf::heartbeat:IPaddr2): Started secondary
Man sieht hier, dass etwas mit dem primary Member noch nicht stimmt.
Führt man den Befehl zur Statusabfrage dort direkt aus, kommt die folgende Fehlermeldung:
Connection to cluster failed: Transport endpoint is not connected
Die Ursache war einfach ein manueller Service-Neustart von Corosync.
Corosync muss laufen, damit Pacemaker drauf zugreifen kann. Daher einmal beide Dienste stoppen:
service pacemaker stop
service corosync stop
und in definierter Reihenfolge neu starten:
service corosync start
service pacemaker start
Und zack – sieht alles fein aus:crm status
Stack: corosync
Current DC: secondary (version 1.1.16-94ff4df) - partition with quorum
Last updated: Sat Oct 19 21:23:33 2019
Last change: Sat Oct 19 20:43:44 2019 by root via crm_attribute on secondary
3 nodes configured
1 resource configured
Online: [ primary secondary third ]
Full list of resources:
virtual_public_ip (ocf::heartbeat:IPaddr2): Started secondary
Die Ressource der letzten Zeile wurde auch per crm-Befehl konfiguriert:
crm configure primitive virtual_public_ip ocf:heartbeat:IPaddr2 params ip="10.20.30.17" cidr_netmask="32" op monitor interval="10s" meta migration-threshold="2" failure-timeout="60s" resource-stickiness="100"
Stickiness=“100″ definiert noch, dass die Ressource auf dem Server verbleibt, bis dieser wegfällt. Egal ob der Server wieder verfügbar ist, von dem die Ressource übernommen wurde.