Von: DIRK PELZER
Mit Produkten wie dem "Microsoft Cluster Service" (MSCS) lässt sich die Verfügbarkeit von Diensten sicherstellen, zum Beispiel eines File- oder Datenbankservers. Um einen Cluster aufzubauen, sind mindestens zwei und höchstens vier physikalisch voneinander unabhängige Rechnersysteme erforderlich, die als Cluster-Knoten bezeichnet werden. Fällt ein Knoten aus, übernimmt einer der überlebenden seine Funktion und stellt die unterbrochenen Dienste wieder zur Verfügung. Die Cluster-Konten überwachen sich gegenseitig mit einem "Cluster-Interconnect", über den sie in periodischen Abständen so genannte Heartbeat-Signale austauschen. Client-Systeme, die mit dem Cluster verbunden sind, merken außer einer kurzen Verzögerung beim Übernahmeprozess in der Regel nichts von dem Ausfall.
Um diesen simplen Ansatz in die Praxis umzusetzen, sind jedoch teilweise recht komplexe Techniken und vor allem ein Verständnis der im Cluster verwendeten Terminologien notwendig. Betrachtet man zunächst einmal die Kommunikation zwischen Client-Systemen und dem Cluster, so muss sichergestellt werden, dass diese durch den Ausfall eines Knotens nicht beeinträchtigt wird. Insbesondere sollte nach einer Übernahme - dem so genannten "Failover" - die Verbindung zwischen Client und Server ohne Änderungen an der Konfiguration des Clients aufrecht erhalten werden. Der Cluster-Server bedient sich dazu des Konzeptes der virtuellen IP-Adressen. Dabei verfügt ein Cluster-Knoten neben der eigenen physikalischen IP-Adresse über eine oder mehrere weitere virtuelle IP-Adressen. Diese können zwischen den Knoten eines Clusters dynamisch hin- und herwandern. Die ClientSysteme ihrerseits werden so konfiguriert, dass sie ausschließlich über die virtuellen IP-Adressen mit dem Cluster kommunizieren. Somit ist gewährleistet, dass die Client-Kommunikation unabhängig vom jeweiligen physikalischen Cluster-Knoten ist. Solange einer der Knoten die virtuelle IP-Adresse bereitstellt, sind die Clients in der Lage, mit dem Cluster zu kommunizieren.
Ressourcen
Mit der IP-Adresse alleine ist es allerdings nicht getan. Für einen sinnvollen Einsatz des Microsoft Cluster Service sind in der Regel noch weitere als Ressourcen bezeichnete Elemente erforderlich. Diese sind ebenfalls virtuell und lassen sich zusammen mit der IP-Adresse dynamisch zwischen den Cluster-Knoten verschieben. Da zwischen den verschiedenen Ressourcen eines Dienstes eine Abhängigkeit besteht, muss der Systemverwalter diese innerhalb des Microsoft Cluster Service zu einer so genannten Failover-Gruppe zusammenfassen. Alle Ressourcen zusammen definieren einen geclusterten Dienst und wandern beim Ausfall eines Cluster-Knotens als Einheit auf das überlebende System, auf dem sie wieder online gebracht werden. Wenn beispielsweise ein Fileserver und die auf ihm freigegebenen Verzeichnisse hochverfügbar ausgelegt werden sollen, so sind neben der IP-Ressource noch folgende weitere Ressourcen erforderlich:
- Physical Disk: Laufwerksbuchstabe der physikalischen Festplatte, die den File Share beheimatet.
- Network Name: Virtueller Netbios-Name, über den Clients auf ein freigegebenes Verzeichnis zugreifen.
- File Share: Name des Freigabeverzeichnisses, auf das die Clients über den virtuellen Netbios-Namen zugreifen.
Der Administrator ist in der Lage, jede Ressource innerhalb einer Gruppe online oder offline zu schalten. So kann er zum Beispiel über die Cluster-Administrator-GUI die File-Share-Ressource offline nehmen. Dadurch verschwindet zwar die Verzeichnisfreigabe, der Network-Name und die IP-Adresse bleiben aber verfügbar. Dies ist ein probates Mittel, um etwa bei Wartungsarbeiten den Zugriff auf einzelne File Shares zu sperren, ohne den ganzen Fileserver-Dienst deaktivieren zu müssen.
Darüber hinaus existieren zwischen den Ressourcen Abhängigkeiten, welche die Reihenfolge beeinflussen, in der sie sich online bringen lassen. Um die File-Share-Ressource verfügbar zu machen, muss zunächst die Network-Name-Ressource online sein. Dies wiederum ist erst möglich, wenn die IP-Ressource, also die virtuelle IP-Adresse des Dienstes, verfügbar ist. Die Basis des gesamten Dienstes bildet wiederum die Physical-Disk-Ressource, denn ohne diese sind alle anderen Ressourcen nutzlos. Damit können die einzelnen Ressourcen in folgender Reihenfolge online gebracht werden:
- Physical Disk
- IP-Adresse
- Network Name
- File Share
Beim Einrichten einer Failover-Gruppe muss der Systemverwalter diese Abhängigkeiten kennen und sie entsprechend konfigurieren. Dies gilt nicht nur für Filedienste, sondern auch für die meisten anderen Dienste. Abhängig vom geclusterten Dienst kann beispielsweise der Network Name entfallen, dafür kommen andere Ressourcen hinzu.
Wie bereits angesprochen, kommt der Physical-Disk-Ressource eine besondere Bedeutung zu. Dabei handelt es sich um eine Festplatte, die beide Cluster-Knoten über eine gemeinsame SCSI- beziehungsweise Fibre-Channel-Verbindung nutzen. Um einem gleichzeitigen Zugriff und damit der Gefahr einer Beschädigung von Daten vorzubeugen, ist eine Funktion implementiert, mit der einer der beiden Knoten einen exklusiven Zugriff auf eine physikalische Platte reservieren kann. Der MSCS verwendet hierfür das RESERVE-Kommando des SCSI-Protokolls. Derjenige Knoten, der den zu clusternden Dienst bereitstellt, hat dabei den exklusiven Zugriff auf die physikalische Platte. Es ist wichtig, dass der MSCS bei einem Failover immer eine physikalische Platte als Ganzes von einem Knoten auf einen anderen verschiebt. Falls die Platte in verschiedene Partitionen mit unterschiedlichen Laufwerksbuchstaben unterteilt ist, wandern diese ebenfalls mit. Der MSCS unterstützt darüber hinaus keine Software-Raids, die mit dem in Windows 2000 mitgelieferten "Logical Disk Manager" aufgebaut wurden. Wer Software-Raid einsetzen möchte, muss dazu auf den "Veritas Volume Manager" zurückgreifen. Trotz dieser Einschränkung ist der Microsoft Cluster Service eine leistungsfähige Komponente zum Aufbau von Hochverfügbarkeitslösungen unter Windows 2000. Mit der Data Center Edition von Windows 2000 skaliert er darüber hinaus bis zu vier Cluster-Knoten. (cl)
Zur Person
DIPL.-ING. DIRK PELZER
ist freiberuflicher Consultant und Journalist in München. Er beschäftigt sich unter anderem mit Speichernetzwerken und hochverfügbaren Rechnersystemen.