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.

Kommentar hinterlassen

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