Pacemaker - HA

Die Hochverfügbarkeit mit pacemaker

Pacemaker - corosync Parameter für zwei Knoten Cluster

Bei einem Zwei-Knoten Cluster mit pacemaker und corosync wissen wir dass der Cluster mit einem ausgefallenen Knoten keine Entscheidungsmehrheit bilden kann (no quorum). Wir wissen auch dass in der Cluster Konfiguration der no-quorum-policy Parameter gesetzt werden kann um diese Situation "berücksichtigen" zu lassen z.B.: durch "ignore".

no-quorum-policy="ignore"

  • ignore: continue all resource management
  • freeze: continue resource management, but don’t recover resources from nodes not in the affected partition
  • stop: stop all resources in the affected cluster partition
  • suicide: fence all nodes in the affected cluster partition

Bei SUSE war es bis SLES 11 notwendig bei einem Zwei-Knoten Cluster diesen Parameter in der Pacemaker Cluster Konfiguration als Global-Option zu setzen. Dieser Parameter ist ab SLES12 nicht mehr notwendig bzw. soll nicht mehr verwendet werden weil die Mehrheitsentscheidungsaufgabe voll und ganz der Corosync Cluster Engine überlassen wird. Ich setze voraus dass Euch klar ist was eine corosync ist.

In der corosync.conf Datei gibt es den Parameter die standardmässig bei einem zwei-Knoten Cluster gesetzt werden soll:

quorum {

                provider: corosync_votequorum

                expected_votes: 2

                two_node: 1

}


Dieser Parameter two_node setzt die quorum künstlich auf 1 und besagt dass eine Mehrheit immer gegeben ist. "The special two_node mode allows each of the two nodes to retain quorum if the other fails."

Aber mit diesem Parameter ist im Hintergrund ein zweiter Parameter automatisch eingeschaltet: wait_for_all: 1

Der wait_for_all wiederum besagt dass der Cluster abwartet bis alle Knoten online sind und erst dann werden die konfigurierten Ressourcen wie z.B.: Virtual IP, Storage etc. gestartet. "Online" bedeutet dass der Dienst pacemaker.service gestartet ist.

systemctl start pacemaker.service

In der Praxis sieht das Verhalten im Normalfall so aus: Wenn beide Knoten, in unserem Fall zwei Knoten Cluster, ausgeschaltet sind (down) und ein Knoten gestartet wird dann startet zwar der pacemaker aber keine Ressourcen. Erst wenn alle Cluster Mitgliedsknoten, also beide Knoten in unserem Fall, den Dienst pacemaker und corosync gestartet haben, erst dann werden die Cluster Ressourcen gestartet. 

So weit so gut. Lange Zeit war mir der Parameter two_node nicht bekannt weil ich nie das Problem hatte dass keine Cluster Ressourcen bei einem Zwei-Knoten-Cluster nicht gestartet werden. Warum?

Des Rätsels Lösung ist der Cluster Konfig Parameter  no-quorum-policy="ignore" der trotz des aktivierten wait_for_all im corosync die Cluster Ressourcen das Starten erlaubt und somit die Funktion wait_for_all überlistet. Der Parameter no-quorum-policy="ignore" gibt es im SLES12 weiterhin und kann benützt werden, auch wenn in der offiziellen Dokumentation von SUSE ausdrücklich abgeraten wird.

So weit so gut in der Theorie. In der Praxis eines zwei Kloten Clusters, insbesonders bei SAP HANA System Replication Scale Up oder SAP Netweaver ASCS ERS besteht der Cluster aus zwei Knoten (Systemen), sehen wir dass der Parameter two_node: 1 im corosync.conf manchmal störend sein kann.

Bei einem Fail-over wird der "kaputte" Knoten gefenced und die Ressourcen auf den zweiten Knoten automatisch "geschwenkt" (fail-over). Der Cluster besteht jetzt nur noch aus einem Knoten und läuft weiter. Tritt jedoch auch auf diesem letzten Knoten ein Problem auf und der Server muss neu gestartet werden dann kommt es zu einem Phänomem das viele Admins nicht weiter wissen.

Denn wenn aus der Situation beide Knoten down ein System wieder der pacemaker gestartet wird dann wird zwar der pacemaker Dienst gestartet jedoch nicht die Ressourcen. Der Cluster Resource Manager (crm) wartet auf ein OK von Mehrheitsentscheider corosync ab bis alle im Cluster-Verbund zugehörigen Knoten den pacemaker gestartet haben und erst dann werden die Ressourcen wie Virtual IP, SAPInstances, Filesystems gestartet. Dieses Verhalten ist durch den Parameter wait_for_all gesteuert. Default ist 0, aber bei Nutzung von two_node: 1 wird wait_for_all auf 1 gesetzt bzw. eingeschaltet, auch wenn dieser Parameter nicht in der corosync.conf steht.

Mit anderen Worten wenn ein Admin zum Zeitpunkt des pacemaker Starts noch nicht alle Knoten fertig repariert hat aber zumindest einen Knoten und die Ressourcen bereitstellen will damit die User und die Produktion nicht zu lange auf sich warten lässt dann sollte man den Parameter wait_for_all: auf 0 setzen.

Nebeneffekt: Die Ressourcen werden auf einem Knoten gestartet aber der Cluster sieht nicht den zweiten Knoten und wird gemäss Konfiguration den "noch-nicht" verfügbaren Knoten fencen. Beim Start des pacemaker von "noch-nicht" verfügbaren Knoten zu einem späteren Zeitpunkt wird bei Verwendung von SBD als stonith Device der Knoten gefenced oder man hat vor dem pacemaker Start die "reset" oder "exit" message für den betroffenen Knoten vorher gesäubert. Was SBD und stonith device ist werde ich in einem separaten Artikel erklären.

Wichtige Links zu offiziellen Informationsquellen:

https://www.suse.com/documentation/sle-ha-12/book_sleha/data/sec_ha_config_basics_global.html

https://www.suse.com/de-de/support/kb/doc/?id=7012110

https://www.systutorials.com/docs/linux/man/5-votequorum/

https://de.wikipedia.org/wiki/Corosync_Cluster_Engine

Diese Webseite verwendet Cookies. Durch die weitere Nutzung stimmen Sie der Verwendung von Cookies zu.
Einverstanden