Neue Leistungsmerkmale bei Heartbeat Version 2

Linux-HA Release 2: Neue Herzschläge

In vorherigen Ausgaben der ORDIX News berichteten wir des öfteren schon von der Open Source Software des Linux High Availability Projekts (Linux-HA), mit der sich ausgesprochen kostengünstige Hochverfügbarkeitslösungen implementieren lassen.

Nach mehr als einem Jahr Entwicklungszeit wurde Ende Juli 2005 die erste, als stabil bezeichnete Version des Releases 2 der Cluster Software veröffentlicht. Wir stellen Ihnen die neuen Möglichkeiten dieses Releases vor.

Mehr als zwei Knoten

Bisher war ein Linux-HA Cluster auf zwei Knoten beschränkt. In der neuen Version gibt es zumindest theoretisch keine Beschränkung mehr hinsichtlich der Anzahl der beteiligten Systeme. Getestet wurden bisher Cluster mit bis zu 16 Knoten, was im Normalfall jedoch mehr als ausreichend sein sollte.

Neue Architektur

Die Unterstützung für mehr als zwei Knoten macht weit reichende Veränderungen an der Architektur der Software notwendig. Bisher lief jeweils nur ein zentraler Prozess auf beiden Knoten, welcher für den Versand und Empfang der Heartbeat-Meldungen sowie für den Start und Stopp von Ressourcen zuständig war. Nun
besteht die Software aus einer Reihe unterschiedlicher Module, die miteinander
kommunizieren.

Die wesentlichen Komponenten werden in den nächsten drei Abschnitten vorgestellt.

Cluster Information Base

Die Cluster Information Base (CIB) stellt die zentrale Informationsstelle des Clusters dar. Sie besteht aus einem XML-Datensatz, der alle Informationen über den aktuellen Status des Clusters und der einzelnen Knoten sowie der vom Cluster verwalteten Ressourcen beinhaltet.

Manuelle Änderungen an der Cluster Information Base werden auf einem dedizierten System durchgeführt, dem "Designated Coordinator" (DC), und anschließend automatisch auf die übrigen Knoten repliziert.

Das Grundgerüst der CIB zeigt Abbildung 1.

<cib>
   <configuration>
      <crm_config>
         <!-- Basiskonfiguration des Clusters -->
      </crm_config>
      <nodes>
	<!-- Die beteiligten Knoten -->
      </nodes>
      <resources>
	<!-- Vom Cluster verwaltete Ressourcen -->
      </resources>
      <constraints>
	<!-- Abhaengigkeiten von Ressourcen -->
      </constraints>
   </configuration>
<status>
 <!-- Statusinformationen ueber Knoten und Ressourcen -->
 <!-- Wird NICHT manuell gepflegt, sondern vom CRM verwaltet -->
</status>
</cib>

Die vom Cluster verwalteten Dienste und die dazugehörigen Ressourcen werden ebenfalls in der CIB gepflegt.

Abbildung 2 zeigt ein Beispiel für die Definition zweier Ressourcen − einer IP Adresse sowie einen Apache Webserver Dienst.

<resources>

 <primitive id="Apache_IP" class="ocf" type="IPaddr" provider="heartbeat">
    <instance_attributes>
    <attributes>
          <nvpair name="ip" value="192.168.1.100"/>
    </attributes>
    </instance_attributes>
 </primitive>

 <primitive id="Apache_Process" class="ocf" type="Apache" provider="heartbeat"/>

</resources>

Bei der Ressource "Apache_IP" wird die IP-Adresse als zusätzliches Attribut innerhalb des Resource-Objekts definiert.

Cluster Resource Manager

Der Cluster Resource Manager (CRM) ist die Komponente des Clusters, welche den Status der beteiligten Ressourcen verwaltet. Auf jedem Knoten läuft zu diesem Zweck ein Cluster Resource Manager Dämonprozess (crmd), der die Informationen aus der Cluster Information Base verarbeitet bzw. bereitstellt.

Soll beispielsweise ein Dienst von einem Knoten auf einen anderen verschoben werden, wird diese Information über den Cluster Resource Manager an die Knoten verteilt, welche wiederum dafür zuständig sind, die notwendigen Aktionen einzuleiten und den Erfolg oder Misserfolg zu melden.

Local Resource Manager

Der Local Resource Manager (LRM) sorgt für den eigentlichen Start und Stopp der Dienste auf einem Knoten. Er empfängt Befehle zur Änderung oder Überwachung des Status einer Ressource vom CRM und gibt entsprechende Meldungen zurück.

Resource Monitoring

Nachdem die Überwachung von laufenden Ressourcen bisher nur durch die Einbindung externer Tools möglich war, unterstützt das Release 2 nun ein integriertes Resource Monitoring.

Zu diesem Zweck werden Skripte zum Start und Stopp einer Ressource nach den Vorgaben des Open Cluster Frameworks (OCF) erstellt, welche eine Monitor Operation vorsehen. Der Local Resource Manager nutzt diese, um in zu definierenden Abständen den Status der Ressource zu erfragen.

Im Fehlerfall wird je nach Konfiguration zunächst versucht, die Ressource lokal neu zu starten oder direkt ein Failover eingeleitet.

Abhängigkeiten zwischen Ressourcen

Mit dem neuen Release gibt es nun sehr gute Möglichkeiten, um Abhängigkeiten für Ressourcen zu definieren. So ist es z. B. möglich, zu bestimmen, auf welchen Knoten ein Dienst bevorzugt, nur im Fehlerfall oder auch auf gar keinen Fall laufen sollte.

Zu diesem Zweck werden innerhalb der CIB Einschränkungen ("Constraints") definiert, die wiederum Punkte ("Scores") für bestimmte Bedingungen vergeben. Die Anzahl der Punkte entscheidet darüber, auf welchem Knoten eine Ressource läuft.

Die Schlüsselwörter "INFINITY" bzw."-INFINITY" bestimmen dabei, dass eine Bedingung "auf jeden Fall" beziehungsweise "auf keinen Fall" erfüllt sein muss.

Abbildung 3 zeigt einen Auszug aus der cib. xml, welcher ein typisches Constraint-Objekt für einen Webserver-Dienst beinhaltet.

<constraints>

 <!-- Ressource "Apache_IP" soll praeferiert auf dem Knoten "node1" laufen -->
 <rsc_location id="Apache" rsc="Apache_IP">
  <rule id="" score="100">
  <expression attribute="#uname" operation="eq" value="node1"/>
  </rule>
 </rsc_location>

 <!-- Ressource "Apache_Process" muss immer zusammen mit "Apache_IP" laufen -->
 <rsc_colocation id="Apache_IP_Process"
from="Apache_IP" to="Apache_Process" score="INFINITY"/>

 <!-- Ressource "Apache_IP" darf niemals auf Knoten "node3" laufen -->
 <rsc_location id="Apache_IP_not_on_node3" rsc="Apache_IP">
  <rule id="" score="-INFINITY">
  <expression attribute="#uname" operation="eq" value="node3"/>
  </rule>
 </rsc_location>

</constraints>

Mit solchen Constraints lassen sich nahezu beliebige Bedingungen konstruieren. So ist es z. B. möglich, dafür zu sorgen, dass ein Dienst immer auf einem Knoten läuft, der beispielsweise

• eine bestimmte Hauptspeichergröße zur Verfügung hat,
• Anschluss an ein externes Storage-Gerät hat,
• eine bestimmte Kernel-Version hat, u.s.w.

Administration

Die Änderungen an der Architektur haben auch Auswirkungen auf die Administration des Clusters. Standardparameter, wie z. B. die Konfiguration der Heartbeat- Leitungen oder das Logging, werden nach wie vor in der bekannten Datei "ha.cf" gepflegt.

Die vom Cluster verwalteten Ressourcen werden nun allerdings in der CIB definiert, welche damit die "haresources" Datei abgelöst hat. In diesem Zusammenhang sind eine Reihe von Kommandozeilenwerkzeugen entwickelt worden, die an dieser Stelle nicht im Einzelnen angesprochen werden können.

Unser Eindruck

In unseren ersten Tests machte das neue Release einen positiven Eindruck. Die Software läuft stabil und die neuen Features machen den Cluster um ein Vielfaches leistungsfähiger.

Die neue Architektur sorgt allerdings auch für eine deutlich höhere Komplexität, was sich zwangsweise auch auf die Administration auswirkt.

Konzeption und Betrieb eines Clusters dieser "neuen Generation" erfordert zumindest anfangs mehr Aufwand als dies bei der "alten" Version der Fall war.

Ausblick

Die Roadmap des Projekts verspricht auch weiterhin interessante Neuerungen. Neben einer Reihe von technischen Verbesserungen lässt vor allem die Ankündigung einer grafischen Administrationsoberfläche hoffen, dass sich die Software zukünftig noch größerer Beliebtheit erfreuen wird.

Fazit

Mit dem neuen Release ist die Entwicklergemeinschaft des Linux High Availability Projects vielen Wünschen und Anregungen der Anwender nachgekommen und hat vor allem im Vergleich zu etablierten, kommerziellen Clusterlösungen einiges an Boden gut gemacht.

Die Beschränkung auf zwei Knoten sowie das fehlende, integrierte Resource Monitoring waren bisher die größten Nachteile gegenüber kommerziellen Alternativen. Die potenziellen Einsatzgebiete sind damit zahlreicher geworden.

Für den produktiven Einsatz ist es auf Grund fehlender Erfahrungswerte vielleicht noch etwas zu früh, aber in einigen Monaten sollte dem nichts mehr im Wege stehen.

Christof Amelunxen (info@ordix.de).

Seitenanfang

Seite drucken

Seite weiterempfehlen