Dieser Fragestellung widmet sich folgender umfangreiche TechNet Artikel:

» http://technet.microsoft.com/(…)cc731002.aspx

Auch wenn ein Cluster Service Account (CSA) ab Windows Server 2008 nicht mehr nötig ist, benötigt man einen Active Directory Account für die zentrale Administration eines Clusters und dessen Nodes. Cluster Name Accounts (CNO) behalten weiterhin Ihre Rolle für die Erstellung virtueller Netzwerk-Namen und werden ebenfalls behandelt.

Für Windows Server 2003 sind zudem Rechte für den CSA nötig:
» http://www.cluadmin.de/index.php?p=111
Diese betreffen Windows Server 2008 und 2008 R2 nicht mehr

Fehlende Rechte oder eine ungenaue Umsetzung der Active Directory Rechte führen oft erst sehr spät zu einem Fehlerbild, das erfahrungsgemäß schwer zu analysieren ist.
Daher ist es ratsam, den TechNet How-To Artikel abzuarbeiten, um unangenehme Spätfolgen zu vermeiden.

Stay tuned,
N.Own

In den meisten Fällen hilft einem der Cluster Migration Wizard.
Folgender aktuelle TechNet Artikel zeigt die Möglichkeiten aufgeschlüsselt nach Diensten und Applikationen im Detail:
» http://technet.microsoft.com/(…)ee791924.aspx

Es werden neben den gängigen Diensten wie File, Print, DHCP etc. auch Applikationen wie SQL & Exchange betrachtet.

Stay tuned,
N.Own

Unter Windows Server 2008 / 2008 R2 gibt es ein neues Tool neben der PMC GUI, das sich für diese Zwecke anbietet: PrintBRM.exe (Print Backup Restore Manager).

» http://support.microsoft.com/kb/938923/en-us

Es wird im Gegensatz zum PrintMig unter x64 Systemen supported:

Weiterführende Informationen zu PrintBRM sind u.a. hier zu finden.

» AskPerf: Why PrintMig 3.1 is Retired

» AskPer: PRINTBRM and the Configuration File

Wie erwähnt kann auch der Printer Migration Wizard der Print Management Console (PMC) über die GUI genutzt werden. PrintBRM kann über den Switch -c parametrisiert und zB. für eine regelmäßige Sicherung mittels Script genutzt werden.

Stay tuned,
N.Own

» http://edge.technet.com/Media/Desktop-to-Datacenter(…)

Der ausführliche Webcast zeigt schön das Zusammenspiel der Hyper-V Role und dem Failover Cluster Feature.

Stay tuned,
N.Own

Mit Einführung von Windows Server 2008 wurden wieder neue Quorum Typen eingeführt, so daß es mittlerweile vier Quorum Models zur Auswahl gibt:

» Node Majority
» Node and Disk Majority
» Node and File Share Majority
» No Majority: Disk Only

Die neuen Typen verfolgen einen Vote-basierten Ansatz, bei dem eine Mehrheit an Stimmen den Ausschlag geben. Einige Quorum Typen sind für den Einsatz von Clustern mit gerader Anzahl an Nodes geeignet, andere zur Verwendung bei einer ungerade Anzahl an Nodes. Auch die Storage spielt eine Rolle: Falls keine Shared Storage eingesetzt wird, sind nur zwei der Quorum Models sinnvoll. Als drittes Kriterium nennt Microsoft Multi-Site Cluster, ehemals Geo-Cluster.

Node Majority
Dieses Quorum Model bietet sich an für den Einsatz einer ungerade Anzahl an Nodes. Die Cluster- und Quorumdaten werden auf den lokalen Disks der einzelnen Nodes vorgehalten. Da die Daten auf den jeweiligen Nodes direkt abgelegt werden, hat jeder Node eine Voting Stimme – damit muss eine Mehrheit der Nodes online sein (N/2 + 1).
Daher ist es nicht sinnvoll diesen Quorum Typ bei gerader Anzahl an Nodes auszuwählen. Es wird keine Shared Storage vorausgesetzt.

Node and Disk Majority
Der Quorum Typ Node and Disk Majority wird für eine gerade Anzahl an Nodes empfohlen, da die Cluster Konfiguration zusätzlich noch auf einer Witness Disk abgelegt wird – im Gegensatz zu einer reinen File Share Witness. Damit erhält man für die Witness Disk eine weitere Voting Stimme.
Solange die Witness Disk online bleibt, kann die Hälfte der Nodes ausfallen (N/2). Dieses Quorum Model wird bei einer gerade Anzahl an Nodes standardmäßig ausgewählt, eine Shared Storage ist Voraussetzung.

Node and File Share Majority
Dieser Quorum Typ ist sehr ähnlich zu “Node and Disk Majority”, mit dem Unterschied, daß keine Disk als Voting Stimme zum Einsatz kommt, sondern eine beliebige Freigabe auf einem Server. Die Cluster Konfiguration wird dabei nicht auf dem File Share abgelegt – nur die Information darüber, welcher Node eine aktuelle Version bereithält. Falls ein Node bei einem Two Node Cluster ausfällt und der aktive keine aktuelle Daten bereithält, bleibt der Cluster offline.
Da die beiden Knoten einen identische Datenbestand aufweisen müssen für einen fehlerfreien Betrieb des Clusters, kann es bei diesem Typ zu einer “Partition in Time”, sprich: Inkonsistenzen, kommen.
Daher ist dieses Quorum Model nur in Einzelfällen einzusetzen.

No Majority: Disk Only
Der vierte Quorum Typ ist der bei Windows 2000 Server und Windows Server 2003 favorisierte und erfordert eine Shared Storage. Es können N-1 Nodes ausfallen.
Da die Storage ein SPoF darstellt, ist dieses Quorum Model inzwischen überholt: Mit Windows Server 2008 wird beim Einsatz einer Shared Storage ein Quorum vom Typ “Node and Disk Majority” empfohlen.

Folgende TechNet Artikel bieten weiterführende Informationen:
» Understanding Quorum Configurations in a Failover Cluster
» Additional Information About Quorum Modes
» Guide: Configuring the Quorum in a Failover Cluster
» Details of How Quorum Works in a Failover Cluster

Die Wahl des Quorums will wohl überlegt sein, dabei sind die Artikel sehr hilfreich.

Stay tuned,
N.Own

» Recommended hotfixes for Windows Server 2008-based server clusters

Für Windows Server 2003:
» http://www.cluadmin.de/recommended(…)p137/ (SP2)
» http://www.cluadmin.de/empfohlene-hotfixe(…)p34/ (SP0/SP1)

Stay tuned,
N.Own

» Increased functionality and virtual … (KB 951308)

Der QFE Hotfix bietet “Increased functionality and virtual machine control in the Windows Server 2008 Failover Cluster Management console for the Hyper-V role”, er ändert hauptsächlich die Failover Cluster Management console Cluadmin.msc.

Weiterhin ist im August ein Hyper-V Planning und Deployment Guide erschienen, der die Installationsvoraussetzungen, die unterstützten Gastsysteme sowie Details zum Installationsvorgang beschreibt:

http://download.microsoft.com/…/HyperV_Deploy.doc (MS Word)

Stay tuned,
N.Own

IPSec

» TechNet: IPSec in Cluster Networking
(Stand: January 01, 2003)

IPSec was not designed for failover situations and we recommend that you do NOT use IPSec for applications in a Server cluster.

Grund für diese Empfehlung ist die Art und Weise, wie die Sicherheitszuordnungen (SAs) des IPSec Internet Key Exchange (IKE) gespeichert werden – nämlich in einer lokalen und damit Nodes-pezifischen Datenbank.

Bei einem Failover müssen daher alle IPSec Verbindungen neu initiiert werden, um eine neue IKE SA auszuhandeln. Dieser Prozess dauert bei einem Windows 2000 Server Cluster per default 6 Minuten: 5 Minuten für den IPSec Idle Timeout, 1 Minute für das Re-initiieren durch den IKE (siehe » KB306677).
Das erhöht die Failoverzeit beträchtlich und senkt die potentielle Uptime…

Auf einem Windows Server 2003 Cluster kann diese Zeit per Registry immerhin auf 2 Minuten gedrückt werden, daher hat sich die ursprüngliche Empfehlung von Microsoft inzwischen wieder etwas relativiert.
Im Falle von Exchange 2003 ist ein Cluster Setup im Zusammenhang mit IPSec auch supported:

» How to Configure IPSec on an Exchange … Cluster

Mit der Hilfe des Registry-Keys NLBSFlags=1 kann in einer Multi-Tier Umgebung mit zB. NLB Frontendserver die IPSec idle time von 5 auf eine Minute gesenkt werden. Zusammen mit der IKE Re-initiierung (+1 Minute) kommt man dann auf die erwähnten 2 Minuten. Der Key ist in folgendem Zweig zu finden:
HKLM\SYSTEM\CurrentControlSet\Services
    \PolicyAgentOakley

Alles in allem muss abgewägt werden, ob man mit der zusätzlichen Verzögerung bei einem Failover leben kann bzw. ob dies die jeweiligen SLAs erlauben.

Für Windows Server 2008 Cluster hat sich das geändert, in Verbindung mit Windows Vista ist IPSec nicht mehr abhängig von Timeouts und kann bei einem Failover sofort eine neue SA aushandeln.

Stay tuned,
N.Own

» http://www.microsoft.com/hyper-v

Interessanterweise läuft die Microsoft Website bereits seit Anfang Juni komplett unter Hyper-V – natürlich in einem Windows Server Cluster
Interessante Daten und Zahlen sowie Uptime charts gibt es im Windows Server Division Weblog:
» Microsoft.com Powered by Hyper-V

Zum Download: » Holt Euch das update zur RTM

Stay tuned,
N.Own

Der Fehler tritt auf, wenn bereits ein Computerkonto für den virtuellen Namen des Clusters im Active Directory angelegt ist: Cluster Name Object (CNO). Da mir das bereits in meiner Testumgebung passiert ist, poste ich das Thema mal hier.

Das Computerkonto kann dann entweder manuell im AD entfernt werden oder über folgenden Befehl:

cluster /destroy [/Y] [/Cleanup[ActiveDirectory]]

Quelle:
» Event ID: 5936 is recorded when you try to create a new cluster

Stay tuned,
N.Own