Für Windows Server 2008 R2 gibt es nun auch einen KB Artikel der empfohlenen Hotfixe für Windows Server Failover Clustering. Microsoft empfiehlt diese Hotfixe ggf. zu installieren.

» Recommended hotfixes for 2008 R2-based server clusters

Eine generelle Empfehlung gibt es momentan nicht, bei Einsatz eines Print Clusters sollte man aber das Stability Update KB 976571 installieren.

Empfohlene Hotfixe für Windows Server 2008:
» http://www.cluadmin.de/index.php?p=137
Für Windows Server 2003 SP2:
» http://www.cluadmin.de/index.php?p=297

Stay tuned,
N.Own

In der letzten Zeit wurde ich desöfteren gefragt: Wie aufwändig ist es eigentlich IP Adressen im Cluster zu wechseln?
Das kommt auf die Applikation an, die der Cluster hostet

Bei einem reinen File & Printcluster ist das Vorgehen an sich trivial:
1. Verbinden der Clusterverwaltung mit LPC
2. Wechseln der IPs nach KB Artikel 230356:
» http://support.microsoft.com/kb/230356/en-us
3. Nachdem Ändern der IPs ist je Node ein Reboot nötig

Für einen SQL Server 7.0/2000/2005 gelten folgende Besonderheiten:
» http://support.microsoft.com/kb/241828/en-us

Für Exchange Server gilt folgender TechNet Artikel:
» http://technet.microsoft.com/(…)EXCHG.65%29.aspx

Um einen Cluster nicht nur in einen anderen IP Bereich zu verschieben, sondern in eine andere Domäne umzuziehen, ist dieses Vorgehen anzuraten:
» http://support.microsoft.com/kb/269196/en-us

MS selbst empfiehlt die beschrieben Schritte nicht für eine Produktivumgebung.
Meiner Erfahrung nach klappt das bei einem reinen File & Print-Cluster problemlos. Bei einem Applikations-Cluster mit geclusterteten Anwendungen, die auf eine Domäne angewiesen sind, ist ein Neu-Aufsetzen des Clusters eher ratsam und meistens auch schneller erledigt…

Hinweis: Wichtig ist bei Änderungen an Netzwerkverbindungseinstellungen ein Ansprechen des Clusters mit Hilfe der Clusterverwaltung ohne RPC (Remote Procedure Call), sondern via LPC (Local Procedure Call), also dem schlichten Punkt: “.” im Verbindungsdialog:
» http://www.cluadmin.de/index.php?p=375

Folgende KB Artikel helfen bei spezifischen Fehlern, die auftreten können beim Wechseln der IP oder des Subnets:
» Changing the IP Address May Result in Failover
» Cluster Does Not Start After You Change the Subnet Mask

Stay tuned,
N.Own

Welche Rollen & Ressourcen können mit einem Windows Server 2008 R2 Failover Cluster hochverfügbar gehalten werden?
Bereits Windows Server 2008 ermöglichte neue Clusterfähige Rollen wie DFS-N oder iSNS und nicht zuletzt Hyper-V.

Windows Server 2008 R2 bietet zwei weitere Ressourcentypen an, zum einen den Remote Desktop Connection Broker (RDCB), ehemals Terminal Services Session Broker, sowie DFS Replicated Folders (DFS-R) zur Erweiterung der File Services.

Folgende Cluster-Ressourcentypen stehen somit unter 2008 R2 zur Verfügung:

• DFS Namespace Server (DFS-N)
• Dynamic Host Configuration Protocol Server (DHCP)
• Distributed Transaction Coordinator (DTC)
• File Server
• Generic Application
• Generic Script
• Generic Service
• Internet Storage Name Service (iSNS) Server
• Message Queuing (MSMQ)
• Other Server (3rd Party)
• Print Server
• Virtual Machine (Hyper-V VM)
• WINS Server
• Remote Desktop Connection Broker (RDCB)
• DFS Replicated Folders (DFS-R)

Die meisten Ressourcentypen können mittels Cluster Migration Wizard von 2003 oder 2008 auf 2008 R2 migriert werden. Zur Migration von File Servern steht zudem das File Server Migration Toolkit (FSMT) zur Verfügung, das neben den reinen Shares auch Daten und NTFS Rechte übernimmt. Zur Migration von Print Servern steht der Printer Migration Wizard und das Kommandozeilentool PrintBRM.exe zur Verfügung.
Aktuelle Migrationspfade im Detail habe ich bereits hier gebloggt: » http://www.cluadmin.de/index.php?p=704

Stay tuned,
N.Own

Cluster Validation wurde in der Version 2008 R2 weiter ausgebaut. Validation Tests sind eine gute Möglichkeit, um schnell und vor allem einfach herauszufinden, ob die Hardware- und Softwarekomponenten die Voraussetzungen für Failover Clustering erfüllen.

Windows Server 2008 R2 bietet nun durch die Validierung der Cluster Konfiguration zusätzlich die Möglichkeit einen laufenden Cluster hinsichtlich der getroffenen Einstellungen zu überprüfen.
Es können damit also nicht nur die Voraussetzungen vor einer Installation geprüft, sondern auch die aktuellen Settings der Ressourcen, Volumes, und des Quorums etc. – ideal zum Troubleshooting und für Dokumentationszwecke.

Validation Reports bestehen aus *.mht Dateien, die man mit einem Webbrowser öffnen kann.

Weiterführende Informationen zu den Validation Reports unter 2008 R2 im Detail:
http://technet.microsoft.com/en-us/library/cc726064.aspx

Aktuell umfasst die R2 Failover Cluster Validation die folgenden Punkte: Inventory tests, Storage tests, Network tests, System Configuration tests, Cluster Configuration tests

Stay tuned,
N.Own

Mit dem Erscheinen von » Exchange 2010 Anfang des Monats häufen sich die Fragen ‘rund um das Exchange Clustering und den neuen Exchange DAG (“Database Availability Groups”).

Mit den Database Availability Groups wurde die Exchange Architektur hinsichlich Clustering weiterhin verbessert, die Installation und Verwendung der Failover Cluster Komponenten geschieht nun weitestgehend im Hintergrund, ebenso die Konfiguration.

Wie steht es um die bisherigen und neuen Cluster Möglichkeiten?
Die schlechte Nachricht: LCR (“Local Continuous Replication”) und SCR (“Single Copy Cluster”) sind mit Exchange 2010 passé.

Die gute Nachricht: Exchange Hochverfügbarkeit wird einfacher, CCR (“Cluster Continuous Replication”) und SCR (“Standby Continuous Replication”) wurden konsequent fortgeführt und zu DAG zusammengefasst.

Das Limit für DAG liegt bei 16 Exchange Nodes, die über verschiedene Sites verteilt sein dürfen.

Welche Quorum Modelle werden verwendet?
Database Availability Groups verwendet nach wie vor ein Subset von Windows Server Failover Cluster Komponenten und bietet folgende Quorum Möglichkeiten:
Node Majority
Bei einer ungeraden Anzahl an Servern (Nodes) kommt dieses Model zur Verwendung. Eine Mehrheit an Votes ist über die Nodes gegeben.
Node & File Share Majority
Bei einer geraden Anzahl an Nodes wird ein File Share Witness eingerichtet, damit eine Mehrheit an Votes besteht.
Die Auswahl des passenden Quorum Models geschieht ebenfalls im Hintergrund.

Weitere Informationen zu den Failover Cluster Quorum Modellen:
» http://www.cluadmin.de/index.php?p=500

Weiterführende Informationen zu den Exchange 2010 Database Availability Groups:
» http://technet.microsoft.com/en-us/library/dd298065.aspx

Exchange 2010 bringt interessante Möglichkeiten zum Thema Hochverfügbarkeit mit und vereinfacht den Einsatz von Exchange Clustering immens.

Stay tuned,
N.Own

Für den Zugriff auf die Clusterverwaltung eines Windows Server 2003 Failover Clusters benötigt man administrative Rechte.

Standardmäßig ist in der Clusterverwaltung die lokale Gruppe der Administratoren auf dem Cluster mit Vollzugriff eingerichtet (Reiter – Sicherheit/Security).

Hier kann einem Benutzer oder einer Benutzergruppe das administrative Recht ‘Vollzugriff’ vergeben werden:

Clusterverwaltung Sicherheitseinstellungen

Siehe: » http://technet.microsoft.com/en-us/library/(…).aspx

Eine Einschränkung auf Bereiche innerhalb der Clusterverwaltung oder Rechte für einzelne Aktionen ist nicht möglich – ein Admin ist ein Admin.

Ab Windows Server 2008 R2 wird es eine » Read-Only API geben, um einen rein lesenden Zugriff auf die Clusterverwaltung zu implementieren.

Stay tuned,
N.Own

Windows Server 2008 R2 bringt ein neues Feature mit, das Print Cluster Administratoren zu schätzen wissen werden: Printer Driver Isolation – Sandboxing für Druckertreiber.

Damit ist es möglich einzelne Druckertreiber in eigenen Prozessen laufen zu lassen, ohne das der Spooler bei Absturz dieser davon betroffen ist. Die Druckjobs sowie andere Druckprozesse bleiben davon ebenfalls unberührt.

Es gibt dazu drei Modi, die für einzelne Druckertreiber ausgewählt werden können:

• None
• Shared
• Isolated

None entspricht der Einstellung unter Windows Server 2003: Der Druckertreiber läuft im Kontext des Spoolers. Im Shared Modus laufen die Druckertreiber unabhängig vom Spooler Prozess in einem eigenen Prozess (PrintIsolationHost.exe), die Treiber teilen sich einen Host Prozess.
Im Isolated Modus können einzelne Druckertreiber in eigenen Prozessen ausgeführt werden – sowohl unabhängig vom Spooler als auch von den Host Prozessen der anderen Druckertreiber. Letzteres bietet sich für vor allem für problembehaftete Druckertreiber mit bekannten Problemen an.

Mittels Printer Driver Isolation unter R2 kann ein fehlerhafter Druckertreiber nicht mehr die Verfügbarkeit des Print Clusters an sich beeinträchtigen.

Siehe auch:
» http://msdn.microsoft.com/en-us/library/dd568151.aspx

Stay tuned,
N.Own

Der Print Migrator war das Tool der Wahl zum Backup & Restore sowie zur Migration von Druckern auf Windows Servern und Windows Print Clustern.

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

Auf TechNet Edge ist letzte Woche ein Webcast zum Thema “Hyper-V Failover Clustering” von Matt McSpirit [MSFT] erschienen:

» 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

Der erste TechNet Artikel zum Thema Hyper-V Live Migration mit Windows Server 2008 R2 ist erschienen:

» http://technet.microsoft.com/en-us/library/dd446679.aspx

Der Artikel beschreibt in einer Schritt-für-Schritt Anleitung die Einrichtung und Besonderheiten beim Failover Clustering der Hyper-V Rolle. Das neue feature Cluster Shared Volumes wird ebenfalls angesprochen.

Stay tuned,
N.Own

Es gibt inzwischen einen KB Artikel zum Thema Single Instance Store auf einem Cluster – danke an H.V. für den Hinweis. In einem früheren Artikel habe ich bereits die Besonderheiten beim Einsatz von SIS auf einem Cluster Volume angesprochen, nun gibt es in einem aktuellen KB Artikel die Empfehlung den Groveler über ein VBS Skript (Sisclusr.vbs) einzubinden:

» KB 947266: Single Instance Store on a Cluster (sisclusr.vbs)

Das Skript wird über den Ressourcentyp ‘Generic Script’ in der Cluster Verwaltung angelegt, ähnlich wie das bei dem Skript clusweb.vbs zum Clustern eines IIS der Fall ist.

Single Instance Store ist ein feature, daß ursprünglich aus dem Exchange Umfeld kommt und zur Datendeduplizierung verwendet wird. Es bietet einem echte Deduplizierung von File System Daten über Pointer, den sog. SIS Links: So wird eine Datei immer nur einmal auf einem Volume abgelegt, die Kopien zeigen via SIS Links auf diese originäre Datei.

Für den Einsatz von Single Instance Store benötigt man einen Windows Storage Server oder Windows Unified Data Storage Server.

Weiterführende Informationen zu dem Thema Single Instance Store bietet das SIS Technical White Paper (Word DOC).

Stay tuned,
N.Own

Es gibt auf » MCSEboard.de immer wieder Fragen zu den Quorum Typen, die mit einem Windows Server Failover Cluster realisierbar sind. Mit Windows Server 2003 wurde ein neues Quorum Model eingeführt: Majority Node Set (MNS) und auch für Windows Server 2003 SP1 zog mit File Share Witness ein neues cluster feature ein.

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

Wie patcht man einen Cluster oder wie installiert man ein Service Pack auf einem Cluster? In der Regel geht man genauso vor, wie auf einem Single Server. Man sollte allerdings darauf achten, zuerst den passiven Node zu patchen und ggf. zu booten. Vor der Installation eines Hotfix oder eines Service Packs auf dem aktiven Node sind die Ressourcen auf den passiven, bereits aktualisierten, Node zu verschieben.

Generell sollte man folgende Hotfixe unterscheiden:
» Security Patche (mit und ohne Reboot)
» Service Packs
» Exchange Hotfixe

Security Patche mit Reboot können wie bei einem alleinstehenden Server via WSUS verteilt werden, ein Reboot über die entsprechende GPO ist kein Problem, solange ein Zeitversatz für die Nodes eingerechnet wird. Idealerweise booten die DCs und die einzelnen Nodes zu unterschiedlichen Zeiten. Das betrifft auch Security Patche ohne Reboot.
Genauso wie bei Single Servern sollte man Patche immer in einer Testumgebung bzw. Testservern vorab installieren, um Imkompabilitäten und Probleme mit Treibern, Anti-Viren-Software oder weiterer Drittanbietersoftware auszuschließen.

Um ein Service Pack auf einem Cluster zu installieren, sollte man den Knoten anhalten, bevor man das Setup aufruft (Pause Node). Das Prozedere ist im folgenden KB Artikel detailliert beschrieben:

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

Die Service Pack Installation ist wie bei einem Patch abwechselnd möglich, man verfährt hier wie bei einem Rolling Upgrade. Sollte eine Installation tatsächlich nicht klappen, hat man bei einem Cluster noch den aktiven Node und kann ohne Downtime mittels eines Restores des passiven, defekten Nodes wieder zum ursprünglichen Stand zurückkehren.

Eine Besonderheit stellen Exchange 2003 Hotfixe und Service Packs dar, diese können i.d.R. nicht installiert werden, solange der Cluster Service noch läuft.
Man geht zur Installation ähnlich vor wie bei einem regulären Cluster, abgesehen davon, daß vor einem Aufruf des Setups der Cluster Dienst auf dem passiven Node gestoppt wird. Eine Downtime ist dafür ebenso nicht nötig. Im folgenden KB Artikel sind die einzelnen Schritte ausführlich beschrieben (Sektion ‘Clustered server’):

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

Solange man die KB Artikel beherzigt und die Punkte Schritt für Schritt abarbeitet, geht einem die Installation von Service Packs oder Exchange Hotfixes auf einem Cluster recht einfach von der Hand.

Der Vorteil eines Clustersystems ist die Gewissheit zu jedem Zeitpunkt noch einen aktiven, funktionierenden Node online zu haben und der Wegfall des Zeitdrucks, den eine Downtime auf einem Single Server mit sich bringt.

Stay tuned,
N.Own

Windows Server 2008 R2, codename Windows 7 Server, wird das erste Windows Server Release sein, welches Failover Cluster PowerShell Commandlets bereitstellt.
Die PowerShell Befehle lösen cluster.exe als Scripting Schnittstelle ab. Cluster.exe wird zu Migrationszwecken noch in R2 enthalten sein, danach soll es entfernt werden.

Die PowerShell wird auch bei einem Server Core Cluster zur Verfügung stehen.
Auch NLB Cluster sind demnächst via PowerShell administrierbar.

Windows 7 ist momentan in der Betaphase, es wird bald eine Public Beta geben. PowerShell Scripting sowie Cluster Shared Volumes in Verbindung mit Hyper-V sind nur zwei der spannenden neuen Failover Cluster Features, für die sich der Umstieg auf Windows 7 Server sicherlich lohnt.

Quelle: http://blogs.msdn.com/clustering(…)9243367.aspx

Stay tuned,
N.Own

Um eine DHCP Server Datenbank von einem Cluster zu einem anderen Cluster zu migrieren, ist der Kommandozeilenbefehl netsh sehr hilfreich:

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

Bei einer Migration von W2K auf W2K3 ist eine andere Syntax notwendig als von W2K3 auf W2K3.

So stößt man einen Export unter Windows 2000 Server an:

C:>netsh dhcp dump >dhcptext_bak.txt

Dieser Befehl erzeugt eine lesbare Textdatei, die mittels folgendem Befehl wieder einlesbar ist:

C:>netsh exec dhcptext_bak.txt

Zu Beachten ist bei einem Dump, daß die Textdatei die IP Adresse des Servers mehrfach enthält. Dazu muss ggf. die Textdatei geändert werden, um die korrekte IP des neuen Servers wiederzuspiegeln.
Dies ist unter Windows Server 2003 nicht mehr nötig, da hier kein dump erfolgen sollte, sondern ein export.

So führt man ein Export unter Windows Server 2003 aus:

C:>netsh dhcp server export dhcp_bak.txt all

Der Import wird mit folgendem Kommando auf dem Zielserver ausgelöst:

C:>netsh dhcp server import dhcp_bak.txt all

Im Gegensatz zu netsh dhcp dump enthält ein netsh dhcp export nicht die fixe IP des DHCP Servers. Es sind also keine manuellen Eingriffe in die erzeugte Backupdatei nötig, daher ist ein export immer einem dump vorzuziehen.

Um sich alle authorisierten DHCP Server einer Domäne anzeigen zu lassen kann ebenfalls netsh genutzt werden:

C:>netsh dhcp show server

Siehe dazu KB303351:
» http://support.microsoft.com/kb/303351/en-us

Folgende TechNet Dokumente enthalten Informationen zu den Besonderheiten eines DHCP Server Clusters:
%

Bis dato basierte Windows Server Failover Clustering (WSFC), ehemals MSCS, auf der Shared Nothing Architektur. Das bedeutet unter anderem, daß kein Volume gleichzeitig von zwei Nodes im Zugriff sein darf.

Das wird sich mit Windows Server 2008 R2, codename Windows 7 Server, ändern.
Das Feature dazu heißt:

Cluster Shared Volumes (CSV)

· Cluster Shared Volumes erlauben gleichzeitigen Zugriff auf CSV Disks von jedem Node aus

· Man spricht in dem Fall von “Distributed File Access for Hyper-V”

· Volumes werden nicht mehr dismounted und remounted

· VMs bleiben online während eines Failovers (!)

· Ein Coordinator Node hält die Disk Ressource und regelt den Zugriff auf die CSV Disk

· Single Name Space für den Zugriff auf die CSV Disk: %windir%\ClusterStorage\…

· Keine spezielle Storage, keine Agenteninstallation, kein neues Filesystem nötig

· Der File System mini-filter CSVFilter.sys ermöglicht die neue Funktionalität

· CSV in R2 wird nach derzeitigem Stand nur in Verbindung mit Hyper-V unterstützt

In Verbindung mit Hyper-V wird es dank CSV Disks sehr spannende Clustering-Möglichkeiten geben. So kann eine VM zwischen den Nodes in einem Windows Server 2008 R2 Cluster ohne Downtime verschoben werden. Der Failover geschieht ohne, daß der client dies bemerkt. Offene TCP Verbindungen werden dabei erhalten, es kommt zu keinem Abbruch der Verbindung oder einer Session.  Die ersten Demos sehen sehr vielversprechend aus.

Cluster Shared Volumes können über die GUI oder mit Hilfe der Powershell erstellt werden.

Stay tuned,
N.Own

Standardmäßig verbindet sich die Clusterverwaltung auf einem Windows Server 2003 mit dem Cluster mit dem man sich zuletzt verbunden hat. Ist dieser nicht erreichbar oder nicht über RPC erreichbar, hat man noch die Möglichkeit sich über LPC zu verbinden – wenn man dazu die Chance hätte…

Folgenden “Ausweg” gibt es dazu: Cluster Administrator mit dem Schalter -noreconnect aufrufen und dann über den Punkt: ‘.’ direkt (LPC – Local Procedure Call) mit dem Node verbinden. Ist der lokale Knoten noch online bzw. verfügbar klappt das auch in den allermeisten Fällen:

cluadmin -noreconnect

Recht hilfreich, falls der RPC Dienst ein Problem hat oder der zuletzt verbundene Cluster nicht online ist und man trotzdem an die Clusterverwaltung gelangen will. Folgenden KB Artikel gibt es dazu von MS:

» Cluster Administrator Switches for Connecting to a Cluster

Stay tuned,
N.Own

Es gab unter Windows 2000 die Möglichkeit den Internet Information Service direkt zu clustern, diese Möglichkeit gibt es seit Windows Server 2003 nur noch über ein Generic Script. Die Cluster Ressource für den IIS wurde entfernt, da es generell geschickter ist eine Stateless Application über NLB redundant vorzuhalten:

» http://technet.microsoft.com/en-us/library/cc781308.aspx

Aus Kompatibilitätsgründen oder auch zu Migrationszwecken (Rolling Upgrade), besteht die Möglichkeit den IIS über die mitgelieferten Script clusweb.vbs (http, https) und clusftp.vbs (ftp) als ‘Generic Script’/'Allgemeines Script’ Ressource einzurichten. Die IIS Einstellungen auf den Nodes müssen synchron gehalten werden, dazu gibt es das script iiscnfg.vbs[1][2]. Der Befehl IISSync steht mit Windows Server 2003 dazu nicht mehr zur Verfügung.
Das Vorgehen für Windows Server 2000 ist in KB Artikel 887417 beschrieben:

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

Dieses Vorgehen ist nur für Notlösungen, Migrationen oder Sonderfälle gedacht bei denen kurzfristig ein IIS zur Verfügung gestellt werden muss, produktiv sollte ein IIS wie gesagt auf einem NLB Cluster redundant gehalten werden.

Stay tuned,
N.Own

Cluster.exe erlaubt es einem Cluster per Batch zu scripten. Folgender Befehl liest zB. den Status einer Clustergruppe aus und zeigt an, auf welchem Node diese aktiv ist:

cluster CLUSTER01 group CLUSTERGRUPPE01 /status

Folgender Befehl listet alle verfügbaren Nodes eines Clusters und zeigt an, in welchen Status sich die Nodes befinden:

cluster CLUSTER01 node /status

Aber auch Node-spezifische Informationen kann man auslesen, zB. den Service Pack Level der Nodes:

cluster CLUSTER01 node /prop|find /i "CSDVersion"

Der Befehl cluster.exe arbeitet sehr schnell, dies kommt einem beim Administrieren einer großen Anzahl an Clustern zugute. In meinen Tests dauert ein Auslesen solcher Informationen auf über 80 Two-Node Clustern unter einer Minute bis maximal 2 Minuten – je nach Netz: Ideal zum schnellen Auslesen des aktuellen Status von mehreren Clustern.

Das Ändern einer Cluster Konfiguration ist ebenso möglich. Folgender Befehl ändert den ‘Bevorzugten Besitzer’/'Preferred Owner’ einer Cluster-Gruppe:

cluster CLUSTER01 group CLUSTERGROUP01 /SetOwners:CLUSTERNODE02

Grundsätzlich ist jede Aktion, die über die GUI konfigurierbar ist, auch über die Kommandozeile mittels cluster.exe durchführbar.

Diese Befehle können natürlich auch in einer Schleife genutzt werden:
@echo %date% %time%: Starting
for /f %%i in (clusserver.txt) do cluster %%i group %%i /stat >> groupstat.txt 2>&1
@echo %date% %time%: Finished

Das Code-beispiel sollte in einer .BAT oder .CMD Datei separat abgespeichert werden. Die Datei clusserver.txt listet die Clusternamen untereinander, die FOR Schleife arbeitet einen Namen nach dem anderen ab und speichert die Ausgabe (STDOUT und STDERR) in die Datei groupstat.txt.

Referenz:

http://technet.microsoft.com/en-us/library/cc779044.aspx

Stay tuned,
N.Own

Gestern erreichte mich eine Email, daß die Liste der empfohlenen Hotfixe für Windows Server 2008 Failover Cluster inzwischen bereitsteht. Microsoft empfiehlt diese Hotfixe zu installieren. Wie dies bereits schon für die Liste der Recommended Cluster Hotfixe zu Windows 2000 Server und Windows Server 2003 galt, sollte man diesen regelmäßig aktualisierten KB Artikel im Auge behalten und die Nodes zeitnah patchen:

» 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