Hochverfügbarkeit mit Heartbeat Version 2 (Teil IV)

Mathe-Leistungskurs für Heartbeat

In vorherigen Ausgaben der ORDIX News haben wir die Artikelreihe zu Heartbeat 2 anhand eines Kundeneinsatzes begonnen. Bei diesem Einsatz wurden auch OCF-Cluster Start/Stop-Skripte implementiert, die bereits im letzten Teil dieser Reihe [2] genauer beleuchtet wurden. In diesem Teil widmen wir uns nun dem Thema Scoring, was eines der wichtigsten Elemente eines Heartbeat 2 Clusters darstellt. Für den Administrator meist im Verborgenen, bestimmt der Cluster durch Zählen von Punkten, auf welchem Knoten Ressourcen gestartet werden dürfen oder auch nicht. Dieses Zählen kann über Leben oder Tod des Clusters entscheiden.

Zahlenwert 	+ INFINITY = INFINITY -66666 	+ INFINITY = INFINITY
Zahlenwert 	- INFINITY = -INFINITY 3333 	- INFINITY = -INFINITY
INFINITY 		- INFINITY = -INFINITY

<resources>
	<primitive id="resource_Apache" class="lsb" type="apache2"
		 provider="heartbeat">
	  <meta_attributes id="resource_Apache_meta_attrs">
		<attributes>
			<nvpair id="resource_Apache_metaattr_target_role"
				name="target_role" value="started"/>
			<nvpair id="resource_Apache_metaattr_resource_stickiness"
				name="resource_stickiness" value="1000"/>
			<nvpair id="resource_Apache_metaattr_resource_failure_stickiness"
				name="resource_failure_stickiness" value="-334"/>
		</attributes>
	  </meta_attributes>
	  <operations>
		<op id="Apache_Monitor" name="monitor" interval="15" 
			timeout="15" start_delay="15" disabled="false" role="Started"/>
	  </operations>
	</primitive>
</resources>

Resource           Score    Node    Stickiness  #Fail   Fail-Stickiness
resource_Apache    0        sles2   1000         0      -334
resource_Apache    0        sles3   1000         0      -334
resource_Apache    666      sles1   1000         1      -334

showscores.sh

<constraints>
	<rsc_location id="location_Apache_sles1" rsc="resource_Apache">
		<rule id="prefered_location_Apache_sles1" score="2000">
			<expression attribute="#uname" id="exp_location_Apache_sles1" 
				operation="eq" value="sles1"/>
		</rule>
	</rsc_location>
	<rsc_location id="location_Apache_sles2" rsc="resource_Apache">
		<rule id="prefered_location_Apache_sles2" score="3000">
			<expression attribute="#uname" id="exp_location_Apache_sles2" 
				operation="eq" value="sles2"/>
		</rule>
	</rsc_location>
	<rsc_location id="location_Apache_sles3" rsc="resource_Apache">
		<rule id="prefered_location_Apache_sles3" score="-INFINITY">
			<expression attribute="#uname" id="exp_location_Apache_sles3" 
				operation="eq" value="sles3"/>
		</rule>
	</rsc_location>
</constraints>

Mathematik von Anfang an

In Cluster-Umgebungen werden Dienste häufig auf bestimmte Knoten innerhalb des Clusters verteilt. Hierfür gibt es verschiedene Gründe wie beispielsweise:

• Optimalere Ausnutzung der Ressourcen
• Stärkere Be-/Entlastung bestimmter Knoten
• Zur Information des Administrators, wo welcher Dienst gerade läuft

Bei Heartbeat 2 wird mit Zahlenwerten (Scores) bestimmt, auf welchem Knoten eine Ressource gestartet oder möglicherweise ein Failover auf einen besseren Knoten durchgeführt wird. Die Zahlenbereiche wurden von den Entwicklern zwischen -Unendlich (-INFINITY) und +Unendlich (+INFINITY) festgelegt. Der Zahlenwert, der sich in aktuellen Implementierungen hinter +/-Unendlich verbirgt, ist +/-1.000.000. Versucht man einer Ressource einen Wert größer als Unendlich zuzuweisen, nimmt der Cluster für diese Ressource automatisch Unendlich als Wert an. Ressourcen mit negativem Score auf einem Knoten haben immer die Tendenz, einen Failover auf einen besseren Knoten zu machen. Eine Ressource mit einem positiven Wert fühlt sich auf dem Knoten, auf dem sie gerade läuft, wohl. Der Wert 0 veranlasst den Cluster, selbst zu entscheiden, wo er welche Ressource platziert. Hierbei kann es passieren, dass der Dienst auch mal nicht auf demselben Knoten läuft wie die dazugehörige IP-Adresse. Abbildung 1 zeigt die von den Entwicklern festgelegten Definitionen mit Beispielen. Diese Definitionen werden später erläutert.

Der Cluster macht, was er will

Unter Heartbeat Version 1 gab es in der globalen Konfigurationsdatei /etc/ha.d/ha.cf einen Eintrag namens auto_failback. Diesem konnten die Werte on/off als Wert zugewiesen werden. War dieser Wert auf on gestellt und der Knoten, auf dem eine Ressource lief, wurde heruntergefahren, so hat die Ressource, nachdem der Knoten wieder gestartet war, automatisch einen Failover auf den ursprünglichen Knoten durchgeführt. Dieses Verhalten konnte nur global festgelegt werden und galt dann für alle Cluster-Ressourcen oder bei auto_failback off für keine Ressource. Konfiguriert man Heartbeat in der Version 2, wird dieser Schalter unabhängig vom Wert komplett ignoriert. Automatische Failbacks von Ressourcen werden ab der Version 2 in der XML-Konfiguration des CIB (Cluster Information Base) gesteuert. Diese Steuerung kann entweder global für alle Ressourcen oder aber für jede Ressource separat konfiguriert werden.

Das Attribut default-resource-stickiness wurde hierfür definiert und ist von Haus aus mit dem Wert 0 versehen; Der Cluster entscheidet also selbst über die Positionierung der Ressourcen innerhalb des Clusters, was gegebenenfalls auch ein Failback auf einen gerade gestarteten Knoten bedeuten kann. Mit der GUI zur Konfiguration oder dem Befehl crm_attribute -G -n "defaultresource-stickiness" kann der Wert ausgelesen werden. Eine Veränderung kann mit der GUI oder dem Befehl crm_attribute -n "default-resource-stickiness" -v 1000 vorgenommen werden. In diesem Beispiel wird der Wert in den globalen Einstellungen für alle Ressourcen auf 1000 gesetzt, so dass diese dazu neigen, sich auf dem gerade laufenden Cluster-Knoten „wohlzufühlen“ und im Normalfall keinen automatischen Failover durchzuführen.

Ressource du musst weichen

Es gibt noch zwei weitere Operanden, die den Level beim Rechnen noch etwas dynamischer gestalten. Zum einen haben die Entwickler ein weiteres Attribut in der CIB definiert: default-resource-failure-stickiness. Das Attribut besitzt standardmäßig den Wert 0 und kann sowohl global als auch pro Ressource festgelegt werden. Zum anderen gib es einen Fehlerzähler in den Eigenschaften jeder Ressource, in dem der Heartbeat Cluster für jede fehlgeschlagene Aktion auf dem aktuellen Knoten den Zähler um eins addiert.

In Abbildung 2 finden Sie ein Beispiel mit einem Apache Cluster für die Verwendung dieser Attribute. Das verwendete Start/Stop-Skript ist das normale LSB-Skript unter /etc/init.d. Der Apache wird sofort gestartet (target_role), das Attribut resource_stickiness für diese Ressource wurde auf 1000 gesetzt, das Attribut resource_failure_stickiness auf -334. Konfiguriert man die „klebrigen“ (sticky) Einstellungen auf der Ressourcenebene, entfällt das Wort default im Attributnamen. Mit diesen vorgenommenen Einstellungen erreicht man nun Folgendes: Wird der Apache auf einem Knoten gestartet, fühlt sich dieser mit dem Score 1000 pudelwohl. Stellt der Cluster beim Monitoring fest, das Apache nicht mehr läuft, startet er ihn auf dem gleichen Knoten erneut. Gleichzeitig zieht der Cluster vom resource_stickiness (1000) den Wert von resource_failure_stickiness (-334) ab und setzt den Fehlercounter für den gerade aktiven Knoten auf eins.

Hat Heartbeat die Apache-Ressource auf diesem Knoten 3-mal neu starten müssen, wird er beim Berechnen -2 als Ergebnis bekommen. In diesem Fall wird er Apache auf diesem Knoten nicht neu starten, sondern es auf einem anderen Knoten mit einem besseren Score versuchen.

Durch das Setzen einer Stickiness von 1000 und einer Failure Stickiness von -334 konnte erreicht werden, dass der Score nach dreimaligem Neustarten einer Ressource ins Negative (-2) fällt und somit ein automatischer Failover auf einen anderen Clusterknoten stattfindet. Der Fehlerzähler wird nach dem Failover nicht wieder zurückgesetzt, was zur Folge hat, dass der Cluster die Ressource auf diesem Knoten nicht mehr starten kann.

Die GUI bietet in der aktuellen Version keine Möglichkeit, den aktuellen Fehlerzähler anzuzeigen. Ein Rücksetzen des Fehlerzählers ist mit Rechtsklick auf die Ressource und Cleanup Resource möglich. Mit crm_failcount -G -r resource_Apache -U sles1 kann der Wert an der Kommandozeile für einen bestimmten Knoten (sles1) ausgelesen werden und mit crm_failcount -D -r resource_Apache -U sles1 zurückgesetzt werden. Im Fehlerfall muss man hierbei gegebenenfalls alle Ressourcen abfragen und zurücksetzen. Auf der Mailingliste [3] des Linux-HA Projektes [4] wurde ein Skript namens showscores.sh [5] veröffentlicht, mit dessen Hilfe für alle Ressourcen und Knoten die relevanten Werte übersichtlich aufgelistet werden. Abbildung 3 zeigt ein Beispiel für die Ausgabe des Skriptes.

Geplantes Verteilen

Will der Administrator nun bestimmen, auf welchem Knoten eine Ressource laufen darf, werden die Ressourcen mit Hilfe von Location-Regeln einfach mit Scores versehen (siehe Abbildung 4). Auf dem Knoten sles1 bekommt die Ressource resource_Apache einen Score von 2000, auf sles2 einen von 3000 und auf sles3 -INFINITY. Dies sorgt nun dafür, dass die resource_Apache bevorzugt auf sles2 und alternativ auf sles1 läuft und dass sie auf dem Knoten sles3 vom Cluster überhaupt nicht gestartet werden kann.

Auch der Administrator kann rechnen

Aufgrund von Wartungsarbeiten an Clustern kann es erforderlich sein, Ressourcen manuell zu migrieren oder einen Failover auf dem in Wartung befindlichen Knoten zu verhindern. Hierbei sollten nach Möglichkeit nicht noch negative Failcounter berücksichtigt werden müssen. Letztendlich spielt bei der gewollten Migration einer Ressource wieder die Mathematik eine Rolle.

Will der Administrator die resource_Apache auf den Knoten sles1 migrieren, kann er dies mit der GUI oder dem Befehl crm_resource -M -r resource_Apache -H sles1 bewerkstelligen. Cluster-Intern wird beim Ausführen dieses Befehls eine neue, zusätzliche Location-Regel erstellt, die der Ressource resource_Apache auf dem Knoten sles1 einen Score von INFINITY vergibt.

Da sowohl dem Administrator als auch dem Heartbeat Cluster bekannt ist, dass 2000 + INFINITY = INFINITY ist, wird die Ressource resource_Apache auf den Knoten sles1 wechseln.

Mathe-Diplom

Wie in diesem Artikel berichtet, kann man mit etwas Mathematik auf sehr einfache Art und Weise bestimmen, auf welchem Knoten ein Dienst gestartet ist, alternativ gestartet oder nie gestartet werden soll. Leider scheinen die Entwickler ihre Mathematikkenntnisse gerne für sich zu behalten, wodurch Dokumentationen zu diesem Thema spärlich zu finden sind.

Dank dem Shell-Skript showscores.sh bekommt man eine gute Übersicht über die aktuelle Punkteverteilung. Gerne rechnen wir aber mit Ihnen in unserem Seminar „Linux Hochverfügbarkeits-Cluster“ [6] noch einmal das genaue Ergebnis nach.

Seitenanfang

Seite drucken

Seite weiterempfehlen