Hochverfügbarkeit ist eines der häufig verwendeten Schlagwörter im Wortschatz von ORDIX und unserer Kunden. In der ORDIX News 2/2008 [1] haben wir bereits ein Kundenprojekt vorgestellt, in dem insgesamt drei Heartbeat Cluster für einen 7x24-Stunden-Betrieb einzurichten waren. Im ersten Teil berichteten wir über die zwei Cluster, auf denen verschiedene Web-Dienste hochverfügbar eingerichtet wurden. In diesem Teil geht es um den dritten Cluster, der vorwiegend als Hostsystem für VMware-Gäste und MySQL-Datenbanken verwendet wird.

Administrator, was soll ich tun?

Der dritte Cluster besteht aus insgesamt drei Cluster-Knoten, auf denen jeweils SuSE Linux Enterprise Server 10 SP1 mit Heartbeat in der Version 2.0.8 installiert ist. Heartbeat wurde in der Version 2 konfiguriert, denn nur hiermit ist es möglich, einen Cluster mit mehr als zwei Knoten zu erstellen. Die hochverfügbar ausgelegten Dienste auf diesem System sind MySQL, Samba und VMware-Gäste.

<constraints>
<rsc_location id="location_Vmware1" rsc="resource_Vmware1">
<rule id="prefered_location_Vmware1" score="100" boolean_op="or">
<expression attribute="#uname" operation="eq" value="sles1"/>
<expression attribute="#uname" operation="eq" value="sles2"/>
</rule>
</rsc_location>
</constraints>

starten: /usr/bin/vmware-cmd /vmware/configs/Vmware1.vmx start
stoppen: /usr/bin/vmware-cmd /vmware/configs/Vmware1.vmx stop
monitor: /usr/bin/vmware-cmd /vmware/configs/Vmware1.vmx getstate

<master_slave id="DRBD1">
<meta_attributes id="DRBD1_meta_attrs">
  <attributes>
    <nvpair id="DRBD1_metaattr_clone_max"
			  name="clone_max" value="2"/>
	<nvpair id="DRBD1_metaattr_clone_node_max"
		 	  name="clone_node_max" value="1"/>
	<nvpair id="DRBD1_metaattr_master_max"
			  name="master_max" value="1"/>
	<nvpair id="DRBD1_metaattr_master_node_max"
		 	  name="master_node_max" value="1"/>
	<nvpair id="DRBD1_metaattr_notify"
	     	  name="notify" value="true"/>
	<nvpair id="DRBD1_metaattr_globally_unique"
	        name="globally_unique" value="false"/>
  </attributes>
</meta_attributes>
<primitive id="DRBD_CLONE1" class="ocf" type="drbd" provider="heartbeat">
  <instance_attributes id="DRBD_CLONE1_instance_attrs">
    <attributes>
      <nvpair name="drbd_resource" value="vmware1"/>
    </attributes>
  </instance_attributes>
  <meta_attributes id="DRBD_CLONE1:0_meta_attrs">
    <attributes>
      <nvpair id="DRBD_CLONE1:0_metaattr_target_role"
			    name="target_role" value="started"/>
    </attributes>
  </meta_attributes>
</primitive>
</master_slave>

<clone id="STONITH_SLES1">
  <instance_attributes>
    <attributes>
      <nvpair name="clone_max" value="2"/>
      <nvpair name="clone_node_max" value="1"/>
    </attributes>
  </instance_attributes>
  <primitive id="child_do_fencing_sles1" class="stonith"
             type="apcmaster">
    <operations>
      <op name="monitor" interval="10s"
          timeout="30s" prereq="nothing"/>
      <op name="start" timeout="20s" prereq="nothing"/>
    </operations>
    <instance_attributes>
      <attributes>
        <nvpair id="STONITH_ip_SLES1"
                name="ipaddr" value="10.10.10.10"/>
        <nvpair id="STONITH_user_SLES1"
                name="login" value="sles1"/>
        <nvpair id="STONITH_pass_SLES1"
                name="passwd" value="sles1pw"/>
      </attributes>
    </instance_attributes>
  </primitive>
</clone>

MEM_FREE=$(grep MemFree /proc/meminfo | awk ‚{ print $2 }‘);
/usr/sbin/attrd_updater -n mem_free -v ${MEM_FREE}

<constraints>
  <rsc_location id="location_Vmware1" rsc="resource_Vmware1">
    <rule id="prefered_location_Vmware1" score="100">
      <expression attribute="mem_free" operation="gte"
                  value="2000000" type="number"/>
    </rule>
  </rsc_location>
</constraints>

<cluster_property_set id="every_sunday" score="100">
  <rule id="my_vmware1:failover" boolean_op="and">
    <date_expression id="my_vmware1:days" operation="date_spec">
      <date_spec id="my_vmware1:days" weekdays="7"/>
    </date_expression>
  </rule>
</cluster_property_set>

Als gemeinsamer Speicher wurde für jede Ressource ein DRBD-Device erstellt (siehe ORDIX News 4/2008 [2]), so dass die Ressourcen unabhängig voneinander kontrolliert werden konnten. Die Nutzung von DRBD führte aber auch dazu, dass die Ressourcen immer nur auf 2 der 3 Knoten lauffähig waren. So mussten für jede Ressource Abhängigkeiten erstellt werden, wo definiert wird, auf welchem System die Ressource laufen darf. Die Konfiguration der Ressourcen wurde jeweils in XML-Dateien geschrieben und mit Kommandozeilenbefehlen auf den Cluster angewendet. Abbildung 1 bildet ein Beispiel für eine der verwendeten Abhängigkeiten ab.

CIB, das Herz von Heartbeat 2

Richtet man Heartbeat in der Version 2 ein, werden alle Ressourcen mit Hilfe von XML-Dateien konfiguriert. Der größte Vorteil gegenüber der alten Konfiguration ist, dass die Änderungen auf jedem Knoten nach dem Einlesen der XML-Datei in den Cluster sofort zur Verfügung stehen. Ein Verteilen der Konfiguration und Neustarten der Dienste, wie es noch in Version 1 notwendig war, entfällt. Es gibt aber auch weiterhin die Konfigurationsdatei /etc/ha.d/ha.cf, in der die Konfiguration des Cluster Interconnect stattfindet. Hier ist nach Änderungen weiterhin ein Neustart der Dienste notwendig.

Die in Abbildung 1 dargestellte Konfiguration zeigt, dass die Ressource Vmware1 nur auf den Knoten sles1 und sles2 laufen darf. Der Cluster wurde so konfiguriert, dass nur Ressourcen gestartet werden, solange zwei Knoten verfügbar sind und für die Ressource eine Location angegeben wurde. Dieses wurde mit den globalen Einstellungen name="symmetric-cluster" value="false" und name="no-quorumpolicy" value="stop" in der CIB festgelegt. Die Datei in Abbildung 1 wurde mit dem Befehl cibadmin -C -o constraints -x datei.xml auf die CIB angewendet.

VMware - die Gäste treffen ein

Um möglichst flexibel zu sein, wurde für jeden VMware-Gast ein eigenes DRBD-Device eingerichtet, so dass die Gäste auf unterschiedlichen Knoten laufen können. Die VMware-Dienste /etc/init.d/vmware starten beim Booten der Cluster-Knoten automatisch. Nun musste eine Möglichkeit gefunden werden, wie die VMware-Gäste durch den Heartbeat Cluster gestartet, überwacht und gestoppt werden können. Dies wurde mit einem eigenen OCF-Skript namens vmware-gast realisiert. Diesem Skript werden vom Cluster die Argumente start, stop und monitor übergeben. Der VMware-Gastname wird mit Hilfe einer Umgebungsvariablen übergeben, so dass es nur ein Skript für alle Gäste gibt. Die Variable selbst wird durch den Cluster gesetzt. Mit Hilfe des Monitoring kann der Status des Gastes abgefragt werden. Mit den anderen beiden Parametern wird er vom Cluster gestartet bzw. gestoppt. In Abbildung 2 sind die verwendeten VMware-Befehle aus dem Skript dargestellt.

Datenspeicherung mit DRBD

Um bei einem Umzug der Ressourcen auf einen anderen Knoten die Daten sofort verfügbar zu haben, wurde die Open Source Software DRBD gewählt. Somit konnte auf teure Lösungen wie SAN oder Infiniband verzichtet werden. Da hier sehr viele DRBD-Devices gleichzeitig eingesetzt wurden, musste gewährleistet werden, dass die Netzwerkkarte nicht zum Flaschenhals wird. Um dies zu vermeiden, sind die Cluster-Systeme mit ausreichend Netzwerkkarten bestückt und die DRBD-Verbindungen auf die Karten verteilt. In den Cluster sind die DRBD-Devices als Master/Slave-Ressource eingebunden. Die auch als Multi-State bezeichneten Ressourcen sind Ressourcen, die entweder den Status Master oder Slave haben. Ein Master/Master-Status, wie es z. B. bei Cluster-Dateisystemen benötigt wird, ist in der aktuellen Heartbeat-Version noch nicht berücksichtigt.

In Abbildung 3 ist die XML-Konfiguration einer DRBD-Master/Slave-Ressource dargestellt. Nach dieser Konfiguration läuft eine Master/ Slave-Ressource auf mehreren Knoten gleichzeitig (name="clone_max" value="2"). Auf jedem System läuft die Ressource maximal 1 Mal (name="clone_node_max" value="1") und es gibt nur einen Master (name="master_node_max" value="1"). Der Name des DRBD-Devices ist vmware1 und wird in der DRBD-Konfigurationsdatei /etc/drbd.conf festgelegt. Leider hat die Konfiguration der Master/Slave-Ressourcen auch einen Nachteil: Sie lassen sich nicht in einer Cluster-Ressourcengruppe anwenden, sondern können immer nur als "native" Ressource konfiguriert werden. Während bei einer Ressourcengruppe eine implizite Reihenfolge beim Starten bzw. Stoppen der Ressourcen besteht, müsste diese bei nativen Ressourcen explizit angegeben werden, was bei einem größeren Cluster zu zusätzlichen Konfigurationen von Abhängigkeiten führt.

STONITH

Da bei diesem VMware-Cluster sehr viel mit gesharten Dateisystemen gearbeitet wird, besteht immer die Gefahr von Korruption bei einem Split-Brain-Zustand. Hier bieten Cluster-Hersteller unterschiedliche Arten des Korruptionsschutzes an. Unter Linux gibt es das so genannte STONITH (Shot the other node in the head). Hierzu werden schaltbare Steckdosenleisten angeschlossen, mit deren Hilfe der eine Cluster-Knoten in einer Split-Brain-Situation den anderen stromlos schalten kann. Unter Heartbeat Version 2 kann die STONITH-Konfiguration auf zwei Arten gelöst werden:

1. Wie in der Version 1 1. üblich, über einen Eintrag in der Datei /etc/ha.d/ha.cf.

2. Mit Hilfe der XML-Konfiguration.

Hier wurde die modernere Variante gewählt, in der die Ressource als so genannter "Clone" konfiguriert wird. Ein Clone ist eine Ressource, die n-Mal innerhalb des Clusters läuft. Voraussetzung ist, dass in den globalen Einstellungen der Schalter name="stonith-enabled" value="true" aktiviert wurde. Auch ein Clone hat den Nachteil, dass er nicht innerhalb einer Ressourcengruppe konfiguriert werden kann. In Abbildung 4 ist die Konfiguration des STONITH Clones dargestellt.

Aber bitte nicht den Cluster lahm legen

Lässt man den Cluster beim Starten der VMware-Gäste entscheiden, auf welchem Knoten der Gast gestartet wird, ist dies vergleichbar mit Russischem Roulette. Normalerweise verteilt der Cluster die Ressourcen gleichmäßig auf die Cluster-Knoten. Dies wäre bei einer Apache- oder FTP-Ressource kein Problem, da diese normalerweise sowieso nur 1-mal auf einem Knoten laufen. Bei diesem Cluster ist es aber gewünscht, dass auch mehrere VMware-Gäste auf demselben Knoten laufen. Da diesen aber unterschiedliche Mengen an Arbeitsspeicher zugewiesen werden, besteht die Gefahr, dass die VMware-Gäste einen Cluster-Knoten lahm legen. Hier bietet Heartbeat die Möglichkeit, dynamisch zu entscheiden, auf welchem Knoten eine Ressource gestartet werden soll.

Dies kann z. B. mit Hilfe der mitgelieferten Ressource "SysInfo" geschehen. SysInfo wird als Clone auf allen beteiligten Knoten gestartet und schreibt regelmäßig die aktuellen Werte von Arbeitsspeicherauslastung, Swap- Auslastung etc. in die CIB. Leider waren die übermittelten Werte in der eingesetzten Heartbeat-Version nicht sehr zuverlässig, so dass auf dieses Verfahren verzichtet wurde.

Heartbeat bietet aber auch die Möglichkeit, eigene Daten in die CIB zu schreiben. Mit Hilfe des in Abbildung 5 gezeigten Cron-Jobs wurde der aktuelle freie Arbeitsspeicher alle 5 Minuten ausgelesen und in die CIB eingetragen. Die Information findet sich dann in den Statusinformationen des entsprechenden Hosts.

Abbildung 6 zeigt, wie die geschriebenen Informationen dann ausgewertet werden. In diesem Beispiel wird Vmware1 auf einem Knoten gestartet, der mindestens 2 GB Arbeitsspeicher frei hat. Bei der hier beschriebenen Implementierung wurde der Arbeitsspeicherverbrauch des Gastes vor dessen Starten per Skript aus der VMware-Konfigurationsdatei ausgelesen und dynamisch in value eingetragen.

Immer wieder sonntags

Während der Implementierungsphase des Clusters kam der Wunsch des Kunden auf, zu bestimmen, dass eine Ressource sonntags immer auf einem bestimmten Cluster-Knoten laufen soll. Auch dies ist mit Heartbeat Cluster-Bordmitteln durchführbar. Zum einen gibt es die Möglichkeit, eine Ressource per Cron-Job auf einen bestimmten Knoten zu switchen (crm_resource -M -r Vmware1 -f -H sles1). Heartbeat bietet aber auch selbst die Möglichkeit, per Location-Regel zeitbasierte Regeln festzulegen. In Abbildung 7 ist ein Beispiel der eingesetzten Regeln abgebildet. Zu beachten ist hierbei, dass die zeitbasierten Regeln nicht mit jeder Heartbeat-Version funktionieren.

MySQL und Samba

Die Konfiguration der Ressourcen MySQL und Samba wurde im Verhältnis zur VMware-Konfiguration zur Nebensache. Die MySQL-Datenbanken wurden auf ein DRBD-Device verlagert. Dessen Dateisystem wird auf einem Knoten eingebunden und danach der MySQL-Dienst gestartet. Bei Samba wurde ähnlich vorgegangen, mit dem kleinen Unterschied, dass hierbei während der Laufzeit Statusinformationen anfallen, z. B. welche Clients gerade mit einem Share verbunden sind. Hier wurde dafür gesorgt, dass die Statusinformationen auf dem DRBD-Device abgelegt werden und auf den Cluster-Knoten jeweils per symbolischen Links auf das DRBD-Device verwiesen wird. Alternativ gibt es hier auch wieder eine Open Source Software-Lösung namens drbdlinks, die für eine dynamische Verlinkung beim Aktivieren der Ressourcen sorgt.

Fazit

Während dieses Kundenprojektes hat sich wieder einmal gezeigt, wie flexibel sich die Heartbeat-Cluster-Lösung einsetzen lässt. Wird mal ein Skript nicht mitgeliefert, kann sehr schnell ein eigenes Skript eingebunden werden. Auch die Zusammenarbeit mit anderen Open Source Tools ist beliebig kombinierbar. In neueren Versionen hat sich auch der SysInfo-Ressourcenagent als zuverlässiger erwiesen. Und in zukünftigen Versionen werden uns die Heartbeat-Entwickler bestimmt mit weiteren, neuen Funktionen überraschen. Schon in einer der nächsten ORDIX News möchten wir von fortgeschrittenen Heartbeat-Eigenschaften berichten, wie z. B. dem Aufbau von OCF-Ressourcenskripten oder die Score-Berechnung innerhalb des Cluster.

Christian Fertsch (info@ordix.de).

Seitenanfang

Seite drucken

Seite weiterempfehlen