Windows-Verwaltung

Einführung in Failoverclustering für Windows Server 2008

Chuck Timon

Auf einen Blick:

• Failovercluster-Verwaltungs-Snap-In
• Neue Features und Verbesserungen
• Sicherungs- und Wiederherstellungsfunktion
• Migrieren von Windows Server 2003

Inhalt

Neue Verwaltungsschnittstelle
Verbesserte Konfigurationsprozesse
Eingebettete Validierungsprozedur
Neues Quorummodell
Verbesserte Sicherheitsfeatures
Erweiterte Netzwerkfunktionen
Höhere Zuverlässigkeit bei Interaktion mit dem Speicher
Integrierte Wiederherstellungsprozesse
Neue Sicherungs- und Wiederherstellungsfunktion
Migrieren von Windows Server 2003-Serverclustern

Seit der Einführung des Clustering in Windows NT 4.0 Enterprise Edition beklagen sich Benutzer darüber, dass es sich nur schwer einrichten und noch schwerer verwalten lässt. Die Verwaltung eines Clusters

erfordert einen Administrator, der über mehr als nur Grundkenntnisse des Clustering verfügt. Der Administrator muss sich außerdem detailliert mit Speichertechnologien auskennen und wissen, wie der Clusterdienst mit verschiedenen Speicherlösungen interagieren würde. In vielen Organisationen gab es nicht genügend Fachleute, die über die erforderlichen umfassenden Fähigkeiten zur Einrichtung und Verwaltung einer Lösung mit hoher Verfügbarkeit verfügten.

Zwar erfuhr Clustering im Laufe der Jahre Verbesserungen, hatte jedoch noch immer erhebliche Mängel, als Microsoft mit der Arbeit an Windows Server® 2008 begann. Vor diesem Hintergrund machte sich das Team an einen Neuentwurf des Clustering mit dem Ziel der Vereinfachung. In Windows Server 2008 erhielten die vollständig überarbeiteten Microsoft®-Clusterdienste (MSCS) auch einen neuen Namen: Failoverclustering.

Allerdings ist Einfachheit nicht die einzige Neuerung, mit denen die neue Failoverclustering-Implementierung aufwartet. Im Laufe der Jahre hat Microsoft viel dazugelernt, nicht zuletzt dank des wertvolles Feedbacks von Organisationen, die ihre Wünsche für eine Clusteringlösung mitteilten. Mit der neuen Failoverclusteringfunktion werden viele der wichtigsten Probleme, die von Benutzern genannt wurden, gelöst. Darüber hinaus gibt es einige interessante neue Features, die sehr vielversprechend klingen. In diesem Artikel möchte ich daher einige der interessanten neuen Features in Windows Server 2008-Failoverclustering vorstellen.

Neue Verwaltungsschnittstelle

Nach der Installation des Failoverclustering können Sie auf die Failovercluster-Verwaltungsschnittstelle über die Option „Verwaltung“ oder durch Ausführung von „Cluadmin.msc“ zugreifen. Das Failovercluster-Verwaltungs-Snap-In ist genau wie andere Verwaltungsschnittstellen in Windows Server 2008 eine Microsoft Management Console (MMC) 3.0. Clusterexperten, die das Failovercluster-Verwaltungs-Snap-In zum ersten Mal öffnen, werden sich ein bisschen wie in einem fremden Land ohne Karte zur Orientierung fühlen.

Die neue Schnittstelle ist in drei verschiedene Bereiche unterteilt, wie in Abbildung 1 gezeigt. Im linken Bereich werden alle Windows Server 2008-Failovercluster in Ihrer Organisation aufgeführt. Im mittleren Bereich finden Sie Details zu dem Teil der Clusterkonfiguration, den Sie im linken Bereich ausgewählt haben, und im rechten Bereich werden die Aktionen angezeigt, die ausgeführt werden können.

Abbildung 1 Failovercluster-Verwaltungs-Snap-In (Zum Vergrößern auf das Bild klicken)

Angenommen, Sie wählen im linken Fensterbereich „Speicher“ aus. Im mittleren Bereich wird dann detailliert aufgeführt, welcher Speicher im Cluster bereitgestellt wurde und welcher Speicher derzeit verfügbar ist (falls zutreffend). Wie Sie in Abbildung 1 sehen, enthält der Cluster eine Speicherkomponente, die einen Zeugendatenträger unterstützt, für einen Dateiserver bereitgestellten Speicher und eine bestimmte Menge verfügbaren Speicher. Im rechten Bereich werden relevante Aktionen aufgeführt, z. B. das Hinzufügen von mehr Speicher. Beachten Sie, dass das Failovercluster-Verwaltungs-Snap-In nicht zur Verwaltung früherer Versionen von Microsoft-Clusterdiensten verwendet werden kann.

Verbesserte Konfigurationsprozesse

Die Konfiguration eines Failoverclusters ist eine ziemlich einfache Aufgabe. Für viele der Aktionen für die Konfiguration, Neukonfiguration und Verwaltung eines Clusters gibt es Assistenten. Dank dieser Assistenten muss sich der Administrator nicht mehr darum kümmern, ob Ressourcen richtig konfiguriert sind oder ob sie in der richtigen Reihenfolge online geschaltet werden.

Abbildung 2 zeigt den Assistenten für hohe Verfügbarkeit. In diesem besonderen Beispiel wurde ein Dateiserver konfiguriert. Auf der linken Seite sehen Sie die Liste der Schritte, durch die der Administrator vom Assistenten geführt wurde. Nach Abschluss des Prozesses wird eine Zusammenfassungsseite angezeigt. Außerdem kann ein Bericht angezeigt werden.

Abbildung 2 Assistent für hohe Verfügbarkeit (Zum Vergrößern auf das Bild klicken)

Eingebettete Validierungsprozedur

In früheren Versionen von Windows Server mussten Hardwarekonfigurationen, um als unterstützte Clusterlösung zu gelten, als Clusterlösung im Windows Server-Katalog aufgeführt werden. Dazu gehörten Multisite-Cluster, die separat unter der Kategorie für geografisch verteilte Sites aufgelistet wurden. Für die Aufnahme in den Katalog mussten die Hardwarehersteller eine Reihe von WHQL-Tests (Windows Hardware Quality Labs) durchführen und die Ergebnisse an Microsoft übermitteln. Dies war eine kostspielige Angelegenheit für Anbieter, und die Datenbank für den Windows Server-Katalog war schwierig zu verwalten.

In Windows Server 2008 ist ein integrierter Validierungsprozess im Failoverclustering inbegriffen. Dieser Prozess besteht aus einer Reihe von Tests, die in vier Hauptkategorien eingeteilt werden, wie in Abbildung 3 gezeigt.

Abbildung 3 Testkategorien für die Failovercluster-Validierung (Zum Vergrößern auf das Bild klicken)

Sie sehen, dass die Netzwerkkategorie erweitert wurde und die ausgeführten Tests anzeigt. Jede Kategorie enthält eine Reihe von Tests. Die Kategorie „Speicher“ (vielleicht die wichtigste der vier Kategorien) enthält Tests, mit denen sichergestellt wird, dass Speicherlösungen den neuen Anforderungen entsprechen, die an Windows Server 2008-Failovercluster gestellt werden.

Insbesondere müssen Hardwarehersteller jetzt Treiber auf Basis des Storport-Treibers von Microsoft verwenden, und sie müssen die permanente SCSI-3-Reservierung unterstützen. Darüber hinaus müssen Multipfadgeräte-spezifische Module (sofern verwendet) auf dem Microsoft-Standard für Multipfadeingabe/-ausgabe basieren.

Mit der Integration des Validierungsprozesses hat sich das Supportmodell geändert. Alle Hardwarekomponenten müssen mit einem Windows Server 2008-Logo versehen sein, und alle Validierungstests müssen bestanden werden. Die einzige Ausnahme bilden Multisite-Cluster mit zwei separaten und unterschiedlichen Speichersystemen (eines an jedem Standort) und die Implementierung der fortlaufenden Clusterreplikation in Exchange Server 2007, die keinen freigegebenen Speicher verwendet.

Neues Quorummodell

Das Quorummodell hat sich im Windows Server 2008-Failoverclustering ebenfalls geändert. In älteren Systemen dachte ein Administrator beim Wort „Quorum“ an einen freigegebenen Datenträger, auf dem sich die Clusterkonfiguration und einige replizierte Dateien befanden. Dies war eine einzelne Fehlerquelle im Cluster. Bei Ausfall des Quorumdatenträgers wurde der Clusterdienst beendet, und die hohe Verfügbarkeit ging verloren.

Windows Server 2003-Servercluster boten einen zweiten Quorumtyp namens Hauptknotensatz-Quorum. Diese Art Quorum wurde in der Regel in Multisite-Clustern implementiert und erforderte keinen freigegebenen Speicher. Das Hauptknotensatz-Quorum bestand aus einer Dateifreigabe, die sich auf dem Systemlaufwerk auf jedem Clusterknoten befand. Die Verbindung zu diesem Quorumtyp wurde über SMB-Verbindungen (Server Message Block) hergestellt. Auch hier musste die Mehrheit der Knoten beteiligt sein, wenn der Cluster funktionieren sollte.

Mit der Einführung der fortlaufenden Clusterreplikation (CCR) in Exchange Server 2007 wurde Windows Server 2003-Serverclustern die Dateifreigabenzeugenfunktion (FSW) hinzugefügt. Damit konnte ein einzelner Exchange 2007-CCR-Clusterknoten (oder jeder Multisite-Cluster) weiterhin Dienste zur Verfügung stellen, solange eine Verbindung zum Dateifreigabenzeugen dazu führte, dass eine Mehrheit erreicht wurde.

In Windows Server 2008-Failoverclustering bedeutet das Konzept des Quorums jetzt wahrhaft Konsens. Quorum oder Konsens wird nun dadurch erreicht, dass genügend Stimmen vorhanden sind, um den Cluster dienstbereit zu machen. Genügend Stimmen können auf verschiedene Weise erlangt werden, je nach der Quorumkonfiguration. Die vier in einem Windows Server 2008-Failovercluster verfügbaren Quorummodi werden in Abbildung 4 gezeigt. Von den vier aufgeführten Modi können nur die ersten beiden („Knotenmehrheit“ und „Knoten- und Datenträgermehrheit“) während des Prozesses der Clustererstellung automatisch ausgewählt werden. Die folgende Logik sollte verwendet werden:

• Bei Konfiguration einer ungeraden Zahl von Knoten im Cluster wählen Sie den Modus „Knotenmehrheit“ aus.
• Wenn eine gerade Zahl von Knoten im Cluster konfiguriert wird und freigegebener Speicher angeschlossen und zugänglich ist, wählen Sie den Modus „Knoten- und Datenträgermehrheit“ aus.

Abbildung 4 Quorummodi im Assistenten zum Konfigurieren des Clusterquorums (Zum Vergrößern auf das Bild klicken)

Um einen Zeugendatenträger aus dem verfügbaren Speicher auszuwählen, wählen Sie den ersten Datenträger aus, der mindestens 500 Megabyte groß ist und auf dem eine NTFS-Partition konfiguriert wurde. Die übrigen Quorummodi können Sie nur manuell auswählen, indem Sie den Assistenten zum Konfigurieren des Clusterquorums ausführen. Die Option „Knoten- und Dateifreigabemehrheit“ wird in der Regel in einer Multisite-Clusterkonfiguration oder in einem Exchange 2007-CCR-Cluster verwendet. Die letzte Option „Keine Mehrheit: Nur Datenträger“ entspricht dem Modell des freigegebenen Quorums in Legacyclustern. Als eine einzelne Fehlerquelle sollte diese Option normalerweise nicht verwendet werden.

Es gibt nur zwei Arten von Zeugenressourcen, einen physikalischen Datenträger und eine Dateifreigabe, die im Cluster konfiguriert werden können, um Konsens zu erreichen.

Ein Zeugendatenträger ist eine Speicherkomponente, die der Clusterdienst online schalten kann. Dieser Datenträger befindet sich in der Gruppe der Clusterkernressourcen, zusammen mit dem Clusternetzwerknamen und den dazugehörigen IP-Adressressourcen. Wenn der Zeugendatenträger konfiguriert wird, werden ein Clusterordner und eine vollständige Kopie der Clusterkonfiguration (eine Clusterstruktur oder ein Replikat) auf dem Datenträger abgelegt.

Ein Dateifreigabenzeuge ist eine Netzwerkfreigabe, die sich idealerweise auf einem Server im Netzwerk befindet, der nicht Teil des Clusters ist. Zum Dateifreigabenzeugen wird eine SMB-Verbindung hergestellt, und der Dateifreigabenzeuge verwaltet eine Kopie der Zeugenprotokolldatei, die Versionsinformationen für die Clusterkonfiguration enthält.

In einem Cluster kann nur eine Zeugenressource konfiguriert werden. Diese Ressource stellt eine zusätzliche Stimme bereit, falls der Cluster diese Stimme benötigt, um das Quorum zu erreichen. Mit anderen Worten: Wenn dem Cluster eine Stimme (und daher ein Knoten) am Konsens fehlt, wird die Zeugenressource online geschaltet, damit das Quorum erreicht werden kann. Wenn dem Cluster mehr als eine Stimme zum Erreichen des Quorums fehlt, bleibt die Zeugenressource unbehelligt. Der Cluster verbleibt in einem inaktiven Zustand und wartet auf den Beitritt eines anderen Clusterknotens.

Verbesserte Sicherheitsfeatures

Failovercluster zeichnen sich durch mehrere neue Sicherheitsverbesserungen aus. Die vielleicht wichtigste besteht darin, dass die Notwendigkeit eines Clusterdienstkontos entfällt. In früheren Versionen des Microsoft-Clusterdiensts war während des Konfigurationsprozesses ein Domänenbenutzerkonto erforderlich. Dieses Konto, das zum Starten des Clusterdiensts verwendet wurde, wurde der lokalen Administratorengruppe an jedem Knoten des Clusters hinzugefügt. Ihm wurden die erforderlichen lokalen Benutzerrechte gewährt, die gewährleisteten, dass der Clusterdienst richtig funktionierte. Als Domänenbenutzerkonto war das Clusterdienstkonto abhängig von verschiedenen Richtlinien auf Domänenebene, die auf Clusterknoten angewendet werden konnten. Diese Richtlinien wirkten sich mitunter negativ auf die hohe Verfügbarkeit aus, indem sie den Ausfall des Clusterdiensts verursachten.

Der Clusterdienst wird jetzt unter einem lokalen Systemkonto mit spezifischen Berechtigungen auf dem lokalen Clusterknoten ausgeführt, die das richtige Funktionieren gewährleisten. Der Sicherheitskontext für den Cluster wurde auf das Clusternamenobjekt übertragen. Dies ist das Computerobjekt, das bei der Erstellung des Clusters standardmäßig im Container „Computer“ in Active Directory® erstellt wird. Wenn ein Cluster erstellt wurde und das Clusternamenobjekt in Active Directory besteht, wird das Benutzerkonto, das zur Installation und Konfiguration des Clusters verwendet wurde, nicht länger benötigt.

Weitere in Active Directory im Container „Computer“ erstellte Computerobjekte werden einem Failovercluster zugeordnet. Diese Objekte, die virtuelle Computerobjekte genannt werden, entsprechen Cluster-Netzwerknamenressourcen, die als Teil von Clientzugriffspunkten im Cluster erstellt werden. Das Clusternamenobjekt, das für die Erstellung aller virtuellen Computerobjekte in einem Cluster verantwortlich ist, wird der Systemzugriff-Steuerungsliste für das Objekt in Active Directory hinzugefügt (siehe Abbildung 5).

Abbildung 5 Sicherheit in einem virtuellen Computerobjekt in Active Directory (Zum Vergrößern auf das Bild klicken)

Das Clusternamenobjekt übernimmt auch die Verantwortung für die Synchronisierung der Domänenkennwörter für alle von ihm erstellten virtuellen Computerobjekte. Dieser Prozess wird gemäß der konfigurierten Domänenrichtlinie für Kennwortrotation ausgeführt. Da das Clusternamenobjekt für die Erstellung aller Computerobjekte für die virtuellen Computerobjekte in einem Cluster verantwortlich ist, muss das Computerkonto auf Domänenebene über die Berechtigung verfügen, Computerobjekte in dem Container zu erstellen, in dem die virtuellen Computerobjekte erstellt werden (standardmäßig ist dies der Container „Computer“).

Eine weitere Änderung besteht darin, dass Kerberos jetzt als Standardauthentifizierungsmethode verwendet wird. Die Existenz von Computerkonten in Active Directory ermöglicht dieses verbesserte Sicherheitsfeature. Der Cluster verfügt jedoch über die Fähigkeit, NT LAN-Manager-Authentifizierung zu verwenden, wenn eine Anwendung, die Kerberos nicht zur Authentifizierung verwenden kann, den Zugriff auf Clusterressourcen erfordert.

Auch die Sicherheit der Kommunikation zwischen Clusterknoten, die direkt mit dem Clusterprozess arbeiten, wurde erhöht. Die interne Clusterkommunikation ist standardmäßig signiert. Mithilfe des Common Language Interface (CLI) für „cluster.exe“ kann diese Clustereigenschaft so geändert werden, dass die Kommunikation zwischen Knoten grundsätzlich verschlüsselt wird, was die Sicherheit zusätzlich erhöht.

Erweiterte Netzwerkfunktionen

Neue Netzwerkfunktionen in Failoverclustern ermöglichen mehr Flexibilität beim Entwerfen von Lösungen für hohe Verfügbarkeit und zur Notfallwiederherstellung. Gleichzeitig sorgen diese Netzwerkverbesserungen für zuverlässigere Konnektivität unter den Knoten im Cluster.

Das wahrscheinlich am häufigsten von Kunden gewünschte Feature war die Fähigkeit, Clusterknoten in separaten Netzwerken zu suchen. Dies ist jetzt möglich. Der Clusternetzwerktreiber wurde vollständig umgeschrieben und bietet nun höchst zuverlässige und fehlertolerante Kommunikation unter Knoten in einem Cluster, vorausgesetzt, jeder Knoten ist mit mindestens zwei separaten und klar gerouteten Netzwerken verbunden.

Der Clusternetzwerktreiber erstellt seine eigene interne Routingtabelle auf der Grundlage der Konnektivitätsinformationen, die er während des Clusterstarts erhält. Diese enthält lokale Konnektivitätsinformationen sowie Informationen aus der Clusterkonfigurationsdatenbank (Clusterregistrierungsstruktur).

Teil des Clustervalidierungsprozesses ist ein Prozess der Ermittlung der Netzwerkkonnektivität. Dank der Fähigkeit, Clusterknoten in verschiedenen, gerouteten Netzwerken ausfindig zu machen, sind die Netzwerkanforderungen für Multisite-Cluster geringer. Damit wird die Bereitstellung für Organisationen einfacher und weniger kostspielig. Außerdem wird die Verwendung von iSCSI-Speicher als Speicherlösung in Failoverclustern attraktiver.

Clusterknoten können zudem IP-Adressinformationen über DHCP (Dynamic Host Configuration-Protokoll) abrufen. Dies kann Netzwerkadministratoren die Arbeit erleichtern, wenn die Verwendung dynamischer Adressierung für die Server in ihrer Umgebung in Frage kommt.

Von der Konfiguration der Netzwerkschnittstellen eines Clusters wird bestimmt, welche Netzwerke statische oder dynamische IP-Adressen verwenden. Auch wenn eine IP-Adressressource in einem Cluster von einem DHCP-Server abgerufen wird, kann sie im Failovercluster-Verwaltungs-Snap-In in eine statische IP-Adresse geändert werden.

In der Vergangenheit wurde für die Clusterkommunikation grundsätzlich UDP-Broadcast verwendet, in einigen Fällen Multicast. Multicastfunktionen stehen nicht länger zur Verfügung, und die Clusterkommunikation verwendet jetzt UDP-Unicast. (Der allgemein von Microsoft-Clustern verwendete Port ist nach wie vor Port 3343.) Viele Netzwerkadministratoren werden froh sein, dass Broadcast nicht mehr verwendet wird. Der wahre Vorteil liegt jedoch in den neuen Messagingprozessen, die dem Clusterdienst eigen sind. (Dies zu erläutern würde jedoch den Rahmen dieses Artikels sprengen.) Die interne Clusterkommunikation verfügt jetzt über Merkmale einer zuverlässigeren TCP-Kommunikation, obgleich UDP als Transportmechanismus verwendet wird.

Höhere Zuverlässigkeit bei Interaktion mit dem Speicher

Die Art und Weise der Interaktion zwischen Failoverclustern und Speicher hat sich radikal geändert. Der Clusterdatenträger (clusdisk.sys) wurde vollständig umgeschrieben und ist jetzt ein echter PnP-Treiber (Plug and Play). Die Interaktion des Clusterdatenträgers mit dem Speicher hat sich ebenfalls geändert.

In Windows Server 2003 war der Clusterdatenträgertreiber in einem direkten Pfad zum Speicher konfiguriert. In Windows Server 2008 jedoch kommuniziert der Clusterdatenträgertreiber mit dem Treiber des Partitions-Managers (partmgr.sys), um mit dem Speicher zu interagieren. Diese beiden Ansätze werden in Abbildung 6 gezeigt.

Abbildung 6 Änderung des Speicherstapels in Windows Server 2008 (Zum Vergrößern auf das Bild klicken)

Der Partitions-Manager trägt die primäre Verantwortung für den Schutz der Clusterdatenträgerressourcen. Alle Datenträger in einem freigegebenen Speicherbus werden bei der ersten Zuordnung zu einem Clusterknoten automatisch in einen Offlinezustand versetzt. Damit ist es möglich, allen Knoten in einem Cluster gleichzeitig Speicher zuzuordnen, noch bevor der Cluster erstellt wird. Es ist nicht mehr notwendig, Knoten einzeln nacheinander zu starten, Datenträger auf einem Knoten vorzubereiten und den Knoten dann herunterzufahren, einen anderen Knoten zu starten, die Datenträgerkonfiguration zu verifizieren und so weiter.

Im Rahmen des Clustervalidierungsprozesses müssen jedoch nach wie vor Speichertests ausgeführt werden. Diese Tests erfordern die Initialisierung der Datenträger. Dies kann auf einem der Knoten des Clusters erfolgen, bevor der Validierungsprozess ausgeführt wird. Nachdem einem Cluster Speicher hinzugefügt wurde, erhalten die Datenträger in der Schnittstelle „Datenträgerverwaltung“ den Status „Reserviert“ und befinden sich nie in einem ungeschützten Zustand.

Eine weitere Änderung betrifft die SCSI-Befehle. In Windows Server 2003 wurden SCSI-2-Befehle zum Reservieren\Freigeben für den Clusterdatenträgertreiber verwendet, der in Sektoren auf dem Datenträger selbst schreibt. In Windows Server 2008 sind SCSI-3-Befehle für permanente Reservierung erforderlich. Clusterknoten müssen registriert werden, bevor sie eine Reservierung im Speicher vornehmen dürfen, und Clusterknoten verteidigen ihre Reservierungen regelmäßig mithilfe des Reservierungs- und Verteidigungsprotokolls.

Mit einem der Speichertests im Validierungsprozess wird diese Funktion überprüft. Wenn eine Speicherlösung keine Unterstützung für SCSI-3-Befehle für permanente Reservierung bietet, kann sie in einem Failovercluster nicht unterstützt werden.

Viele Organisationen verwenden Multipfadsoftware für Redundanz bei der Herstellung einer Verbindung zum Speicher. Dies wird unterstützt und sogar als bewährte Methode eingestuft. Multipfadsoftwarelösungen von Drittanbietern oder gerätespezifische Module müssen jedoch unter Verwendung des Microsoft-Standards für Multipfadeingabe/-ausgabe, der in einem Failovercluster unterstützt werden soll, umgeschrieben werden. Dadurch wird sichergestellt, dass alle SCSI-3-Befehle für permanente Reservierung gleichzeitig auf allen Pfaden zum Speicher gesendet werden, unabhängig davon, ob der Pfad aktiv ist oder nicht. Diese Funktion wird ebenfalls im Rahmen des Validierungsprozesses überprüft.

Weitere Speicherverbesserungen sind ein verbesserter Prozess der Datenträgerüberprüfung (chkdsk.exe), eine integrierte Funktion zur Datenträgerreparatur, die davor Teil des Dienstprogramms für die Clusterserverwiederherstellung war, sowie sich selbst reparierende Datenträger. In Failoverclustern werden die Datenträgersignatur und die LUN-ID zur Identifizierung einer Clusterdatenträgerressource verwendet. Wenn sich eine von beiden ändert, wird die Clusterkonfiguration aktualisiert. Dies bedeutet eine geringere Zahl von Fehlern, da eine Attributsänderung auf einem physikalischen Datenträger zu höherer Verfügbarkeit führt.

Integrierte Wiederherstellungsprozesse

Die bereits erwähnte Datenträgerreparatur ist offensichtlich eine der integrierten Wiederherstellungsfunktionen. Eine weitere ist die Funktion zur Active Directory-Reparatur. Wenn das Computerobjekt, das das Clusternamenobjekt darstellt, gelöscht wird, können Sie keine Computerobjekte mehr erstellen, die Cluster-Clientzugriffspunkten zugeordnet sind. Das erste auftretende Problem besteht jedoch wahrscheinlich darin, dass hoch verfügbare Anwendungen oder Benutzer nicht mehr auf Ressourcen außerhalb des Clusters zugreifen können, da kein Sicherheitstoken abgerufen werden kann.

Die Wiederherstellung eines gelöschten Clusternamenobjekts ist ein zweistufiger Prozess. Zuerst müssen Sie einen Domänenadministrator bitten, das gelöschte Computerobjekt aus dem Container „DeletedObjects“ in Active Directory wiederherzustellen. Nach der Reaktivierung des Objekts führen Sie den Prozess „Active Directory-Objekt reparieren“ im Failovercluster-Verwaltungs-Snap-In aus.

Bei Windows Server 2003-Serverclustern bestand die Möglichkeit, dass die Clusterkonfigurationsdatei im Unterverzeichnis „%systemroot%\cluster“ beschädigt wurde und dann ersetzt werden musste. In Failoverclustern kann die Funktion zur Selbstreparatur helfen. Wenn der Clusterdienst auf einem Knoten startet und die Konfigurationsdatenbank beschädigt ist, wird eine minimale Konfigurationsvorlage unter Verwendung der Informationen im Registrierungsschlüssel „HKLM\System\CCS\Services\ClusSvc\Parameters“ geladen. Der Knoten versucht, einem bereits gebildeten Cluster beizutreten. Wenn dieser Versuch erfolgreich ist, wird eine neue Kopie der Clusterregistrierungsstruktur auf den Knoten übertragen. Kann ein Knoten keinem Cluster beitreten, wird der Clusterdienst beendet.

Neue Sicherungs- und Wiederherstellungsfunktion

Failoverclustering ist mit einem eigenen Volumeschattenkopie-Dienst-Writer ausgestattet. Dies spielt eine wichtige Rolle bei der Sicherung und Wiederherstellung einer Clusterdatenbank und der Daten auf den physikalischen Datenträgerressourcen. Eine Sicherungskopie der Clusterkonfiguration zu erstellen, ist eine ziemlich einfache Aufgabe. Sofern der Systemstatus in die Sicherung einbezogen wird, kann die Clusterkonfiguration wiederhergestellt werden. Beachten Sie jedoch, dass die Sicherung eines Clusters nur dann erfolgen sollte, wenn für den Cluster Quorum besteht. So wird garantiert, dass die neueste Clusterkonfiguration gesichert wird.

Es gibt zwei unterschiedliche Arten der Clusterwiederherstellung: autorisierend und nicht autorisierend. Bei einer nicht autorisierenden Wiederherstellung wird mithilfe der Windows Server-Sicherung oder einer Anwendung eines Drittanbieters eine Wiederherstellung von einer ausgewählten Sicherung ausgeführt. Für eine autorisierende Wiederherstellung eines Clusterknotens hingegen ist die CLI der Windows Server-Sicherung (wbadmin.exe) erforderlich.

Bei einer autorisierenden Wiederherstellung wird die Clusterkonfiguration im Grunde „in die Vergangenheit“ zurückversetzt, an den Zeitpunkt, zu dem die Sicherung durchgeführt wurde. Um eine autorisierende Wiederherstellung durchzuführen, wird der Clusterdienst auf allen Knoten beendet, mit Ausnahme des Knotens, auf dem die Wiederherstellung ausgeführt wird. Wenn die Wiederherstellung abgeschlossen ist und der Clusterdienst auf dem wiederhergestellten Knoten gestartet wurde, wird die wiederhergestellte Konfiguration des Clusters zur endgültigen neuen Clusterkonfiguration. Wenn der Clusterdienst dann auf den übrigen Knoten im Cluster neu gestartet wird, wird die wiederhergestellte Konfiguration während des Beitrittsprozesses übertragen.

In bestimmten Szenarios lassen sich so Zeit und Geld in großem Umfang sparen. Angenommen, Sie arbeiten mit einem Druckcluster, der mehrere Druckerspoolerressourcen hostet, von denen jede 1.500 Drucker unterstützt, und Sie löschen versehentlich eine der Druckerspoolerressourcen. Zahlreiche Benutzer können nun nicht drucken. Anstatt alle diese Drucker der Clusterkonfiguration manuell wieder hinzuzufügen, können Sie in wesentlich kürzerer Zeit eine autorisierende Wiederherstellung der Clusterkonfiguration durchführen. Dies hängt selbstverständlich davon ab, ob eine solide Sicherungs- und Wiederherstellungsstrategie existiert.

Migrieren von Windows Server 2003-Serverclustern

Aufgrund dieser zahlreichen Architekturänderungen in Windows Server 2008-Failoverclustering werden direkte oder parallele Aktualisierungen von Windows Server 2003 nicht unterstützt. Beim Aktualisieren von Windows Server 2000-Clustern auf Windows Server 2003 würden viele Organisationen systematisch jeden Knoten im Cluster entfernen, eine Neuinstallation des Betriebssystems ausführen und dann den Knoten dem Cluster wieder hinzufügen. Dieses Verfahren eignet sich nicht für die Migration zu Windows Server 2008, da Windows Server 2003- und Windows Server 2008-Clusterknoten nicht Teil desselben Clusters sein können.

Glücklicherweise steht ein assistentenbasierter Migrationsprozess zur Verfügung, der die Migration erleichtert. Die Migration zu einem Windows Server 2008-Failovercluster erfordert trotz allem einige Planung. Es gibt drei grundlegende Migrationsszenarios:

• Verwenden derselben Server und Speichersysteme.
• Verwenden derselben Server, jedoch mit neuem Speicher.
• Verwenden neuer Server und neuer Speichersysteme.

Bei allen diesen Szenarios muss sichergestellt werden, dass die Hardware unter dem Windows Server 2008-Logo-Programm zertifiziert wurde, dass der Prozess der Failovercluster-Validierung abeschlossen ist und alle Tests bestanden wurden. Nach Abschluss dieser Schritte kann der Migrationsprozess fortgesetzt werden.

Nicht für alle Ressourcen in einem Windows Server 2003-Servercluster ist eine Migration möglich. Sie können Netzwerknamen, IP-Adressen, physikalische Datenträger, Dateifreigaben, DFS-Stämme, DHCP und WINS migrieren. In begrenztem Umfang lassen sich auch allgemeine Dienste, generische Anwendungen und Ressourcen für allgemeine Skripte migrieren.

Für Anwendungen wie Microsoft Exchange und SQL Server® existieren eigene Verfahren für die Migration zu einem Failovercluster. Drucker können mithilfe des Snap-Ins „Druckverwaltung“ (das mit der Druckserverrolle installiert wird) zu Windows Server 2008 migriert werden, um Drucker zuerst zu exportieren und dann in einen neu konfigurierten Druckserver mit hoher Verfügbarkeit zu importieren. Ressourcentypen von Drittanbietern für die Migration nicht geeignet.

Beim Migrationsprozess werden keine Daten migriert. Dabei werden Clusterkonfigurationseinstellungen von Windows Server 2003 zu Windows Server 2008 migriert.

Alle migrierten Ressourcen befinden sich nach Abschluss des Migrationsprozesses zunächst in einem Offlinezustand. Dies wird deshalb so gehandhabt, weil möglicherweise zusätzliche Schritte erforderlich sind. Deshalb ist es wichtig, den Postmigrationsbericht daraufhin zu überprüfen, welche zusätzlichen Schritte (außer der Datenmigration, wenn zu neuem Speicher migriert wird) erforderlich sind, um den Cluster dienstbereit zu machen. Wenn beispielsweise ein DHCP-Server migriert wird, muss die Funktion des DHCP-Servers auf allen Knoten im Cluster installiert werden. Bei Migration eines WINS-Servers muss das WINS Server-Feature auf allen Knoten im Cluster installiert werden.

Chuck Timon ist Support Escalation Engineer bei Microsoft und unterstützt Cluster- und Installationstechnologien. Er hat das Schulungsmaterial für Windows Server 2008-Failovercluster verfasst und arbeitet momentan an der Hyper-V-Schulung.

© 2008 Microsoft Corporation und CMP Media, LLC. Alle Rechte vorbehalten. Die nicht genehmigte teilweise oder vollständige Vervielfältigung ist nicht zulässig.