Probleme beim Failover Clustering vermeiden

Mit dem Failover Clustering bringt Microsoft Hochverfügbarkeit ins Spiel, um bei geplanten Wartungsarbeiten oder bei Hardware-Ausfällen die Unterbrechungen für die Applikationen oder Dienste auf ein Minimum zu beschränken. Doch das Failover-Clustering muss mit einem Image-Problem kämpfen: Aus technischer Sicht funktioniert diese Technik sehr gut, doch die Komplexität bei der Konfiguration und bei der zugehörigen Systemwartung schrecken viele potenzielle Anwender ab. Ab dem Server-Betriebssystem Windows Server 2008 ist der Umgang mit dem Failover Clusterung deutlich vereinfacht.

Das Failover Clustering lässt sich nur sehr schwer einrichten – dieses Feedback hört man aus Administratorkreisen nur zu häufig. Diese Einschätzung stammt aus den Tagen vor Windows Server 2008 (und R2). In diesen früheren Server-Betriebssystemversionen war ein sehr aufwändiger Prozess nötig, bei dem eine Vielzahl von Dialogen im entsprechenden Assistenten zu absolvieren waren und wobei eine Menge von Details einzugeben war.

Vor Windows Server 2008: Cluster-Konfiguration benötigt Experten

Anders ausgesprochen: Das Clustering konnte nur von absoluten Experten aufgesetzt werden. Und wem es gelungen war, ein Clustering zu aktivieren, der stand vor der nächsten Herausforderung: Denn auch für die Wartungsarbeiten an einem Cluster musste man einen entsprechenden Experten zur Hand haben. Und zudem bedurfte es noch einer Hardware-Ausstattung, die auf der einschlägigen Microsoft-Liste stand, in der alle unterstützten Systeme aufgeführt waren.

Aus diesem Grund hatte man bei Microsoft ab dem Windows Server 2008 in Bezug auf das Clustering einen Neuanfang vollzogen. Viele Elemente aus dem Benutzer-Interface – wie das Management und das Anlegen von Clustern – wurden komplett neu entwickelt. Zudem wurden die Anforderungen an die Hardware reduziert – um den Einsatz von Clustern für ein weiter gefasstes Zielpublikum zu erlauben.

Bei Windows Server 2003 gab es noch eine Vielzahl von Quorum-Modellen, um für verschiedene Einsatzbereiche (wie etwa „File Share Witness“, das für Cluster ohne gemeinsamen Speicher nötig war) gerüstet zu sein. Die „File Share Witness“ waren ursprünglich für die CCR (Cluster Continuous Replication) im Exchange-Umfeld vorgesehen. Damit wurde bei Windows Server 2008 aufgeräumt: Alle verschiedenen Quorum-Modelle wurde in ein einziges Modell integriert – das allerdings in verschiedenen Modi laufen kann. Damit vereinfacht sich das Verständnis der gesamten Angelegenheit.

Wer unter Windows Server 2008 einen Cluster erzeugen will, der muss nur den entsprechenden Assistenten (den Cluster Creation Wizard) aufrufen und angeben, welche Server alle in diesem Cluster verbunden werden sollen. Dazu muss man aber über ein Konto als Domänenbenutzer mit den nötigen Berechtigungen angemeldet sein.

Dann ist noch die Bezeichnung für den neuen Cluster nötig und die Angabe einer IP-Adresse (falls das Dynamic Host Configuration Protocol, DHCP) nicht für die Netzwerkkarten aktiviert ist. Damit ergibt sich in Summe eine Anzahl von nur mehr drei Dialogen.

Im Zuge der Cluster-Erzeugung wird eine Analyse der Server ausgeführt, die zum Cluster gehören sollen. Zudem wird die Verfügbarkeit eines gemeinsamen Speichers geprüft und dann noch das passende Quorum-Modell – je nach Speicher und Anzahl der Knoten im Cluster – festgelegt. Dann werden alle Knoten in einem Rutsch konfiguriert.

Cluster-Knoten in einem Rutsch konfigurieren

Damit entfällt die Aufgabe, jeden Knoten im Cluster einzeln einzustellen. Zudem gibt es am Anfang des Vorgangs eine Validierungsstufe, in der beim Anlegen des Clusters die Hardware und die zugehörige Konfiguration geprüft werden. Ist dieser Test erfolgreich absolviert – das wird bei Systemen mit derselben Prozessorarchitektur, der gleichen Windows-Version und so weiter üblicherweise der Fall sein – dann wird der Cluster von Microsoft unterstützt.

Eine zusätzliche Überprüfung etwa mit Hilfe der „Microsoft Hardware Certification List“ für den Cluster oder die Server-Hardware entfällt.
Die anschließende Verwaltung des Clusters erweist sich als genauso einfach. Bei jeder Änderung am Setup helfen einem passende Assistenten. Tritt mal ein Problem auf, hilft einem in den meisten Fällen die Validierungssoftware weiter und führt einen auf die richtige Fährte zur Ursache für das Problem.

Noch besser ist die Angelegenheit beim Release 2 des Windows Server 2008 gelöst. Denn ab dieser Betriebssystemversion ist die komplette Verwaltung der Cluster mit der Powershell möglich.

Ausfälle trotz Cluster-Einsatz

Viele Anwender können zwei Dinge nicht eindeutig unterscheiden: Fehlertoleranz und Hochverfügbarkeit sind nicht dasselbe. Ein Failover Cluster bietet für sich eine hochverfügbare Konfiguration. Wer dagegen komplette Fehlertoleranz haben will, der muss auf zusätzliche Funktionsblöcke zurückgreifen. Da wird ein Failover-Cluster immer nur ein Teil des gesamten Bildes sein.

Er stellt dazu praktisch ein Rahmenwerk zur Verfügung, auf das Dienste oder Applikationen auf verschiedene Arten nutzen können. Auf der untersten Ebene wirft der Failover Cluster ein Auge auf alle Knoten im Cluster-Verbund. Ist ein Knoten nicht mehr verfügbar, verschiebt die Cluster-Software die Dienste und die abhängigen Ressourcen von dem nicht mehr aktiven – sprich ausgefallenen – Knoten auf den restlichen Cluster, also die noch verbleibenden, aktiven Knoten.

Mit diesem grundlegenden Failover-Cluster-Modell wird immer eine gewisse Ausfallzeit auftreten, wenn der Knoten, der eine Dienst oder eine Applikation beherbergt, ausfällt. Denn dieser Ausfall muss erkannt werden und danach müssen die Ressourcen, die der ausgefallene Knoten gemoutet hat (wie etwa eine LUN), auf einem der verbleibenden Knoten neu gemoutet werden. Danach muss die Applikation oder der Dienst wieder gestartet werden.

All diese Schritte erfordern eine gewisse Zeit. Und in dieser Zeit wird der Service oder die Anwendung nicht verfügbar sein. Das kann bei einem Printserver oder Dateiserver sein aber auch bei einem Dienst wie ihn der Exchange Server 2007 darstellt oder der Exchange 2003 Single Copy Cluster.

Die wichtigste Aussage in diesem Zusammenhang aber lautet: Die Technik hinter dem Failover Cluster wird den Dienst neu starten und wieder verfügbar machen und zwar so schnell es geht. Damit wird eine Hochverfügbarkeit erzielt. Doch eine hundertprozentige Verfügbarkeit – auch als Fehlertoleranter Betrieb bekannt – lässt sich damit allein nicht realisieren.

Fehlertoleranz erfordert mehr als Failover Clustering

Spricht man dagegen von Fehlertoleranz, ist eine Konfiguration gemeint, die einen Ausfall einer Ressource verkraften kann, ohne dass ein Dienst oder eine Applikation – für den Endanwender bemerkbar – ausfällt. Eine derartige Vorgabe verlangt in der Regel eine aufwändigere Konfiguration als beim reinen Failover Clustering. Denn dabei müssen die Dienste/Applikationen von vorneherein auf mehreren Knoten gleichzeitig laufen.

Zudem ist Aufwand nötig, damit die Anwendungen auch synchron bleiben und vor allem dass die Daten entsprechend auf dem identischen Stand sind. Fällt dann einer der Knoten aus, tritt eine Ausfallzeit auf – doch die ist dann so gering, dass es weder die Applikation noch die Anwender bemerken. Das Failover Clustering von Windows 2008 Server (und R2) ist nicht in der Lage, diese Anforderungen für Dienste und Anwendungen bereitzustellen. Dazu sind die verschiedenen Applikationen zu unterschiedlich, als dass die Funktionalität von Windows ausreicht.

Dagegen eignet sich das Failover Clustering sehr wohl als eine Basis, auf der Applikationen oder Dienste aufsetzen können, um mit zusätzlichen Komponenten eine Fehlertoleranz im engeren Sinn zu erzielen. Umgekehrt sind auch einige Dienste fehlertolerant, wenn sie nicht auf dem Failover Clustering aufsetzen. Ein Beispiel dazu sind das Active Directory und IIS-Farmen (Internet Informationsdienste), die das NLB (Network Load Balacing, Netzwerklastenausgleich) verwenden.

In diesem Zusammenhang stellen die DAGs (Database Availability Groups) von Exchange 2010 Server ein interessantes Beispiel dar. Die DAGs verwenden das Failover Clustering und stellen damit – sozusagen im Hintergrund – für bestimmte Bereiche die Verfügbarkeit von Ressourcen sicher. Dann kommen noch weitere Techniken dazu, etwa um die Daten in den Postfachspeichern (Informationsspeichern) auf mehrere Server zu replizieren. Zudem stellen sie für die Clients die Kommunikations-Anlaufpunkte zur Verfügung (in Form der CAS, Client Access Server). Diese CAS stellen den Clients die Daten von den Postfachservern zur Verfügung. Wenn kurze Zeiten der Dienst ausfällt, wenn ein Knoten ausfällt, dann bereitet das eher kein Problem.

Nur mit teurer Netzwerktechnik überspannen Cluster
mehr als einen Standort

Die Cluster-fähigen Dienste verfügen üblicherweise über eine Vielzahl von Ressourcen – einschließlich einer IP-Adresse. In einem einzelnen Standort dürfen mehrere Knoten im selben Netzwerk-Segment liegen – zumindest aber können die Netzwerksegmente im selben IP-Subnetz liegen. Das hat zur Folge, dass die IP-Adresse für den Dienst auf jedem der Knoten im Cluster liegen kann – denn sie verfügen alle über dieselben Netzwerk-Fähigkeiten.

Angenommen man möchte eine Cluster mit Knoten in verschiedenen Standorten betreiben. Das würde bedeuten, dass die Knoten zu verschiedenen Netzwerksegmenten und IP-Subnetzen gehören. Damit ergibt sich ein Problem, denn eine IP-Adresse wie 192.168.1.10 einer Cluster-Ressource darf nicht in einem Standort liegen, bei dem die Subnetzadresse 192.168.10.0 lautet. In diesem Falle würde das Routing nicht funktionieren.

Eine Lösung für dieses Problem wäre das Ausdehnen der Subnetze über mehrere Standorte. Dazu sind in der Regel recht teure Netzwerk-Infrastrukturen nötig. Deswegen sind kleinere und mittlere Unternehmen üblicherweise nicht in der Lage, auf diese Art ein Multisite-Clustering aufzusetzen.

Beim Windows Server 2008 kam hier allerdings eine wesentliche Verbesserung ins Spiel. Sie lässt sich mit einem kurzen Begriff kennzeichnen: OR – sprich die Oder-Verknüpfung. Vor Windows Server 2008 konnte man einem Dienst oder einer Applikation mehrere IP-Adressen als Teil der Ressourcengruppe zuweisen. Doch alle IP-Adressen mussten „vorliegen“ – sprich sie mussten präsent sein. Das bedeutet, sie mussten alle auf allen Knoten im Cluster „in Betrieb“ sein.

Beim Windows Server 2008 kommt nun die OR-Funktionalität ins Spiel. Das bedeutet, dass man erneut mehrere IP-Adressen einem Dienst oder einer Applikation zuweisen kann und dass man zudem noch die OR-Beziehung angeben darf. Mit dieser Beziehung kann man mehrere IP-Adressen zuweisen und so die verschiedenen IP-Subnetze, auf denen der Dienst an mehreren Standorten laufen kann, damit ausstatten. Dabei wird die IP-Adresse, die zu dem Standort passt, an dem der Service aktuell läuft, für die Client-Zugriffe verwendet. Damit lässt sich auch ohne den Einsatz teurer Netzwerk-Hardware ein Multisite-Clustering erzielen.

Doch nur weil man mit der OR-Beziehung mehrere IP-Adressen zuweisen kann, sind noch nicht alle Multisite-bezogenen Probleme gelöst. Wenn man nur eine IP-Adresse für einen Service verwendet, kennen die Clients immer diese eine Adresse, um mit dem Dienst zu kommunizieren. Verfügt man dagegen über mehrere IP-Adressen für einen Dienst, wird die Sache schon wieder komplizierter.

Es sind weitere Dienste – wie zum Beispiel das DNS (Domain Name System) nötig, bei dem noch dazu mit kurzen „Time to Live“-Werten für die Hostname-Einträge gearbeitet wird. Nur so lässt sich sicherstellen, dass die Clients in ihrem DNS-zwischenspeichern nicht alte IP-Adressen verwenden. Eine andere Möglichkeit besteht darin, alle IP-Provider einzutragen, so dass alle IP-Adressen im DNS vorliegen. Aber wahrscheinlich wird man eine Art Zwischen-Kommunikationsschicht für die Clients einrichten – so wie das zum Beispiel Client Access Server Rolle von Exchange Server 2010 der Fall ist.

Auf welcher Ebene soll Hochverfügbarkeit ansetzen?

Oft stellt sich die Frage, ob man die Hochverfügbarkeit auf der Ebene der Applikationen oder aber im Virtualisierungsumfeld sicherstellen soll. Heutzutage liegt das Virtualisieren von möglichst allen Ressourcen voll im Trend. Die gängigen Virtualisierungslösungen verfügen auch über Hochverfügbarkeits-Dienste, die für die Reduzierung der geplanten aber auch der ungeplanten Ausfallzeiten herangezogen werden können.

Ist eine geplante Ausfallzeit nötig, etwa weil ein Patch für den Hyper-V-Server eingespielt werden muss, bei dem anschließend ein Neustart nötig ist, dann kann man darauf reagieren: Mit Hilfe der Live Migration des Hyper-V werden die Inhalte des Arbeitsspeichers und der Systemstatus der laufenden virtuellen Maschinen auf einen anderen Hyper-V-Server kopiert. Damit laufen die VMs auf dem anderen System weiter, ohne dass die Anwender eine Ausfallzeit bemerken.

Schwieriger wird es im ungeplanten Fall – wenn zum Beispiel ein Server ausfällt und kein Zeit mehr bleibt, um die Arbeitsspeicherinhalte und den Systemstatus der VMs auf einen anderen Server kopiert werden kann. Das bedeutet, man muss die virtuellen Maschinen auf einem anderen System neu starten. Damit sind die Applikationen oder Dienste in der VM nicht verfügbar bis das jeweilige Gastbetriebssystem durchgestartet ist und die Dienste hochgefahren wurden. Damit besteht bei der Hochverfügbarkeit auf Ebene der Virtualisierungsplattform die Möglichkeit einer Hochverfügbarkeit im planbaren Fall aber auch eine Ausfallzeit im ungeplanten Fall.

Eine Alternative ist das Aktivieren von Hochverfügbarkeit innerhalb des Gastbetriebssystems mit traditionellen Techniken – etwa dem Failover Clustering – für die Anwendungen. Das bedeutet aber auch, dass die Applikationen Cluster-fähig sind, sprich sie müssen das Failover Clustering unterstützen. Ist das der Fall, bekommt man eine geringere Ausfallzeit als es der Fall beim kompletten Neustart des Betriebssystems der Fall ist.

Angenommen ein Exchange-Postfach-Server ist auf der Virtualisierungsebene und ein anderer hochverfügbar innerhalb des Gastbetriebssystems. Bei der Hochverfügbarkeit auf der Virtualisierungsebene installiert man eine Instanz der Exchange-Postfach-Serverrolle in einer VM, zusammen mit der seiner Konfiguration und den virtuellen Festplatten auf dem gemeinsamen Speicher (Shared Storage).

Die VM wird dann durch die Virtualisierungsfunktionalitäten hochverfügbar gemacht – im Falle des Hyper-V ist das Failover Clustering bereits auf den Hyper-V-Hosts aktiviert. Wenn nun der Server, auf dem die VM läuft, ausfällt, wird ein anderer Server die VM in genau derselben Art neustarten, als es bei einem physischen System nach einem Ausfall üblich ist. Damit besteht die Möglichkeit, dass die Festplatten oder die Datenbanken wegen des harten Systemstopps korrumpiert sind. Daher kann es dazu kommen, dass entsprechende Prüfprogramm starten und zuerst in Integritätsprüfungen ausführen. Das kann unter Umständen sehr lange dauern.

Verwendet man dagegen die Hochverfügbarkeits-Features von Exchange (wie etwa das Failover Clustering bei den Gastbetriebssystemen), dann laufen zwei Instanzen der Exchange-Postfach-Server-Rolle (bei Exchange Server 2010 kann man bis zu 16 in einem Cluster oder einer DAG betreiben). Dabei ist es wichtig, dass jede Instanz auf einem anderen Server läuft – man gewinnt in Bezug auf die Ausfallsicherheit nicht viel, wenn beide Instanzen auf demselben physischen System laufen. Man kann sogar entsprechende Regel vorgeben, dass nicht beide Instanzen auf derselben Hardware laufen. Allerdings ist dabei kein gemeinsamer Speicher nötig.

Eine jede Instanz verwendet die Exchange-Software. Die Protokolldateien werden von der aktiven Kopie der Datenbank auf die passive Kopie gespielt und dort erneut gespielt. Damit bleiben die Datenbanken synchron. Wenn dann der Server mit der aktiven Kopie ausfällt, erkennt das Gastbetriebssystem, dass der aktive Exchange-Postfach-Server nicht mehr antwortet und wird dann die IP-Adresse und die zugehörigen Namen-Ressourcen des Postfach-Servers übernehmen.

Dann wird versucht, alle fehlenden Transaktionen aus den Protokolldateien zu kopieren, dann erfolgt die Überprüfung mit dem Hub-Transport-Server (damit wird sichergestellt, dass keine Nachrichten verloren gegangen sind) und dann werden die Postfachdienste von der eigenen Kopie der Datenbank angeboten. Dies ist wesentlich schneller und auch ein sauberes Vorgehen als die Lösung auf der Virtualisierungsebene es darstellt.

Allgemein kann man sagen: Wenn eine Applikation selbst die Hochverfügbarkeit unterstützt, wie das zum Beispiel bei Exchange oder dem SQL Server der Fall ist, ist man besser beraten, die Hochverfügbarkeit auf Applikationsebene innerhalb des Gastbetriebssystems zu aktivieren. Unterstützt eine Applikation dagegen den Hochverfügbarkeitsansatz nicht, ist der Ansatz auf der Virtualisierungsebene die nächst beste Lösung.

John Savill/rhh