Veritas Cluster Server

Der Veritas Cluster Server (VCS) ist einer der renommiertesten auf dem Markt. Ein guter Grund, sich mit der Architektur dieses Produkts einmal näher vertraut zu machen.

Ein Cluster ist ein vernetzter Verbund von mehreren Maschinen, die sich einen gemeinsamen Speicher („shared storage") von Applikationen und deren Daten teilen. Dadurch können die Dienste und Applikationen, die der Verbund zur Verfügung stellt, auf jeder der beteiligten Maschinen laufen.

Das Herzstück ist die Cluster Software. Sie steuert, welche Dienste auf welchem System laufen. Bei dem Ausfall einer Maschine sorgt sie z. B. dafür, dass die ausgefallenen Dienste auf einem anderen System wieder gestartet werden.

Die Steuerung des Verbunds erfolgt an zentraler Stelle durch die Clusterkonsole. Ist eine Maschine Mitglied eines Clusters, bezeichnet man sie auch als Node. Im Falle des VCS sind 2 bis 32 Nodes innerhalb des Clusters möglich. Die Nodes besitzen alle eine Kopie der Cluster Software, die auf ihnen läuft.

Ausfallsicher?

Der Begriff Cluster wird meist in einem Atemzug mit den Begriffen Hochverfügbarkeit und fälschlicherweise auch Ausfallsicherheit genannt. Letzteres ist nicht ganz korrekt, da ein Cluster, wie oben erklärt, eine Applikation nicht durch komplett redundant ausgelegte Systeme vor einem Ausfall schützt. Durch Automatisierung verkürzt er lediglich die Zeit, die benötigt wird, um die Applikationen des abgestürzten Systems auf einem anderen System zu starten.

Die Ausfallzeit einer Applikation bzw. eines Dienstes verringert sich durch die Automatisierung immens, weshalb man von Hochverfügbarkeit, nicht jedoch von Ausfallsicherheit spricht.

Das Netzwerk

Die VCS Nodes können untereinander über das Heartbeat Netzwerk (auch private Network genannt) kommunizieren. Es steht exklusiv für die im Cluster anfallende Kommunikation zur Verfügung. Dieses Netzwerk ist nicht öffentlich und kann nur von den Maschinen des Verbunds verwendet werden. Die Mindestanforderung für ein solches Netzwerk sind zwei Kanäle mit separater Infrastruktur, also z. B. zwei Netzwerkkarten (nicht etwa zwei Ports auf einer Karte). Generell gilt es, das Heartbeat Netzwerk komplett redundant auszulegen. Dadurch wird verhindert, dass der Ausfall einer Komponente den kompletten Betrieb blockiert („Single Point of Failure").

Zusätzlich gibt es die Möglichkeit, den Cluster auf einen Ausfall des private Network vorzubereiten. Dazu wird eine öffentliche Netzwerkschnittstelle („normales" LAN) als niedrig priorisierter Link im Cluster konfiguriert. Über diesen Link werden im Normalbetrieb lediglich Heartbeats bei niedrigerer Frequenz als im private Network versendet. Kommt es zu einem Ausfall des private Network, kann dieser Link temporär das private Network ersetzen.

GAB / LLT

Als Protokolle kommen bei VCS „GAB / LLT" (zwei Eigenentwicklungen aus dem Hause Veritas) über Ethernet zum Einsatz. Unterstützung für diese Protokolle werden direkt im Kernel als Modul eingebunden. Low Latency Transport (LLT) zeichnet sich durch kurze Latenzzeiten aus.

Ein weiterer Vorteil ist sein geringer Overhead. Dieser wird aber dadurch „erkauft", dass von einer persistenten Netzverbindung zwischen allen beteiligten Systemen ausgegangen wird.

Um diese Vorteile bei der Kernel-zu-Kernel-Kommunikation zu garantieren, dürfen nur passive Komponenten im Heartbeat-Netzwerk zum Einsatz
kommen. Konkret dürfen nur Hubs oder Switches ohne „Store und Forward" auf der Netzstrecke zwischen den Nodes vorhanden sein. LLT ist somit auch nicht routingfähig.

Group Membership Services/Atomic Broadcast (GAB) wird als Protokoll für die eigentliche Kommunikation zwischen den VCS Installationen der einzelnen Nodes verwendet. Es ist ein reines Broadcast Protokoll und stellt sicher, dass alle Nodes eine identische Konfiguration und Sicht auf den Status des Clusters haben. Des weiteren kontrolliert es beim Start einer Node dessen Mitgliedschaft im Cluster.

Die Engine

Kernstück des Veritas Clusters ist die VCS Engine in Form des „High Availability Daemon" (had). Der Daemon steuert jeweils eine Node und erledigt auch die über GAB anfallende Kommunikation mit den anderen Cluster-Mitgliedern. Ein zusätzlicher Prozess „hashadow" überwacht den „had" und startet ihn bei Ausfall neu.

Die vom Cluster verwalteten Applikationen werden in Servicegruppen eingeteilt. Eine Servicegruppe definiert eine bestimmte Menge von Komponenten, die in ihrer Gesamtheit eine Applikation bzw. einen Dienst zur Verfügung stellen. Hard- und Software-Komponenten werden in VCS als Ressourcen dargestellt. Diese sind immer von einem bestimmten Typ (z. B. Disk, NFS-Share, IP-Adresse, Datenbank, Prozess) und definieren sich durch einen eindeutigen Namen sowie durch spezifische Attribute.

Klassen von Servicegruppen

Es gibt zwei Klassen von Servicegruppen: Den Failover- und den Parallel-Typ. Der Failover-Typ kann zu jedem Zeitpunkt auf nur genau einer Node laufen. Eine Servicegruppe fällt aus, wenn eine oder mehrere ihrer Ressourcen nicht mehr verfügbar sind, sie also als „failed" erkannt werden. In einem solchen Fall versucht der „had", die Servicegruppe auf ein anderes System im Cluster zu schwenken. Dazu werden alle zugehörigen Ressourcen, die noch laufen, zunächst gestoppt, und danach auf einem anderen System wieder gestartet. Diesen Vorgang bezeichnet man als Failover.

Beim Ausfall einer Servicegruppe vom Parallel-Typ erfolgt kein Failover, weil diese Art von Gruppe auch auf mehreren Nodes zur gleichen Zeit betrieben werden kann. Durch die Redundanz ist dafür
gesorgt, dass die Applikation auch beim Ausfall einer Node immer noch zur Verfügung steht. Ein typisches Beispiel ist ein Webserver, bzw. generell jegliche Art von „read-only" Diensten.

Es gibt aber auch Applikationen, die „cluster-aware" sind. Diese sind in der Lage, mit den konkurrierenden Schreibzugriffen auf den Shared Storage umzugehen. Ein Beispiel hierfür ist der Oracle Parallel Server.

Damit eine Applikation auf einer Node gestartet werden kann, müssen auf dieser alle Ressourcen für die entsprechende Gruppe zur Verfügung stehen. Das Verteilen einer Servicegruppe auf mehrere Nodes ist nicht möglich.

Zusätzlich ist hierbei die mögliche Abhängigkeit der Servicegruppen bzw. Ressourcen untereinander
zu beachten. Zum Beispiel könnte die Konstellation eintreten, dass ohne eine Datenbank-Servicegruppe u. U. die Gruppe einer Webapplikation nicht gestartet
werden kann.

Ebenso macht es wenig Sinn, eine NFS-Freigabe zu starten, wenn das darunter liegende Filesystem nicht zur Verfügung steht. Man spricht auch von Parent- und Child-Ressourcen, wobei im obigen Beispiel die NFS-Freigabe eine Parent- und das Filesystem eine Child-Ressource wäre.

Über den Einsatz eines Agenten erfährt der „had", ob eine Ressource gestartet ist. Agenten sind immer vom Typ der Ressource, die sie auch verwalten. Pro Ressource-Typ wird genau ein Agent gestartet, der dann alle Instanzen seines Typs betreut. Agenten haben die Aufgabe, eine Ressource zu starten (online), zu stoppen (offline) und zu überwachen (monitor/probe) und bei Änderungen des Status diese Information an die VCS Engine weiterzuleiten.

Es ist möglich, neue Agenten einzubinden, die somit den Funktionsumfang von VCS erweitern. Fertige Agenten für große Standardanwendungen sind bereits erhältlich, eine Übersicht dazu finden Sie unter http://www.veritas.com/de/produkte/cluster/cserver_opt.html.

Fazit

Abschließend ergibt sich nun folgende Übersicht eines Veritas Clusters.

Übersicht über die VCS-Architektur.

Jede Cluster Node betreibt VCS Agenten, die den Status der Ressourcen überwachen. Die Agenten geben diese Information an den „had" weiter. Dieser verteilt die Statusinformationen bzgl. der lokalen Ressourcen per GAB an die anderen Verbundsmitglieder. GAB verwendet LLT, um über das private Network mit den anderen Systemen zu kommunizieren.

Alle diese Mechanismen sorgen miteinander dafür, dass alle Mitglieder des Clusters eine identische Kopie der Konfiguration in ihrem lokalen Speicher haben.

Michael Heß (info@ordix.de).

Seitenanfang

Seite drucken

Seite weiterempfehlen