Nach mehreren Anfragen an die Pacemaker-Mailingliste, div. äußerst hilfreichen Blogbeiträgen und etlichen Tests, möchte ich meine
Erkenntnisse zur Score-Berechnung hier festhalten.
Es dreht sich alles um Zahlen.
Alle Clusterknoten sind per default gleichwertig. Das heißt, eine Ressource wird abwechselnd auf die Knoten verteilt. Ohne bevorzugte
Präferenz.
Die Entscheidung, auf welchem Knoten eine Ressource laufen kann, basiert auf Punktständen. Der Knoten, der die höchste Punktzahl
erreicht, wird der aktive Knoten.
Der Cluster pflegt selbst eine interne Liste, welche Ressource auf welchem Knoten, welche Punktzahl erreicht.
Bei einer Ressource und zwei Knoten sieht das intern VOR DER ENTSCHEIDUNG so aus:
Ressource|Knoten|Punktzahl
—————————–
vip_eth0|node1|0
vip_eth0|node2|0
Nun entscheidet sich der Cluster, welcher der beiden Knoten die Ressource übernimmt.
NACH DER ENTSCHEIDUNG sehen die Punktzahlen folgendermaßen aus:
Ressource|Knoten|Punktzahl
—————————–
vip_eth0|node1|0
vip_eth0|node2|-INFINITY
Da jetzt die Entscheidung für Node1 gefallen ist, erhält node2 den Wert -INFINITY – (hoher negativer Wert – soviel wie -1000000)
Das heißt, die Ressource darf jetzt auf keinen Fall auf node2 laufen – macht Sinn, läuft ja bereits auf Node1.
Häufig möchte man nicht, dass nach einer Clusterumschaltung, wieder ein Zurückschaltung erfolgt, wenn der ursprüngliche aktive Knoten
wieder verfügbar ist. Hierzu definiert man eine stickiness – also eine gewisse Verbundenheit bzw. Haftung an einen Knoten.
Da dies die Punktzahl natürlich verändert, sollte man hier darauf achten, dass man einen eher geringen Wert Wählt, um eventuelle
Entscheidungen nicht zu großzügig zu beeinflussen.
resource-stickiness=“5″ kommt in unserem Test zum Einsatz.
Am obigen Beispiel NACH DER ENTSCHEIDUNG sieht der Punktestand folgendermaßen aus:
Ressource|Knoten|Punktzahl
—————————–
vip_eth0|node1|5
vip_eth0|node2|-INFINITY
Der Wert 5 ergibt sich aus dem stickiness-Wert von 5.
Um die Konnektivität seiner Knoten im Lan/Wan zu prüfen, wird häufig mit ocf:pacemaker:ping gearbeitet:
Dies pinged unterschiedliche Hosts und je nach Ergebnis, wird wieder ein Wert vergeben.
Um die Ressource immer auf dem Knoten laufen zu lassen, welcher die beste Verfügbarkeit hat, reicht:
primitive p_ping ocf:pacemaker:ping
params host_list=“1.2.3.4 5.6.7.8″ multiplier=1000″ dampen=“30s“
op monitor interval=“10″ timeout=“60″
clone pingclone p_ping
location beste_verbindung vip_eth0 pingd: defined pingd
Jetzt zum interessanten Teil, wie sehen die Punkte aus:
Erreicht ein node einen Host per Ping, ergibt dies den multiplier-Wert.
Erreicht ein node einen Host nicht, gibt es 0 Punkte.
Erreicht ein node beide Hosts, ergibt dies den multiplier-Wert x 2.
Debugging-Werkzeuge:
showscores.sh
crm_simulate -s -L
crm_mon -A
Danke an Michael Schwartzkopff und Simon Meggle für die Infos.