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

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

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

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:
%

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

Dieser Tage kam die Frage im MCSEboard.de auf, ob denn der File Server Resource Manager (FSRM) mit gesetzten Quotas auf einem Windows Server 2003 R2 Cluster läuft: Ja, absolut.
Die Einstellungen die für ein Volume gesetzt sind, werden auf dem Laufwerk selbst im ordner “System Volume Information” gespeichert [» 1]. Bei einem Failover wandert also die Konfiguration mit dem Volume auf den jeweils aktiven Node.

Informationen wie die Quota Templates werden in der Registry gespeichert und sind auf einem Cluster in folgendem Hive zu finden: HKLM\Cluster\SRM

Um Quotas und File Screens zu konfigurieren verbindet man sich nicht mit dem virtuellen Namen des File Server Clusters, sondern mit dem aktiven Node [» 2].
Um ein Backup der FSRM Konfiguration durchzuführen siehe folgenden TechNet Artikel:
» http://technet.microsoft.com/en-us/library/cc771319.aspx [3]

Hier ein Screenshot von einem 2-Node Cluster, bei den Nodes handelt es sich um Windows Storage Server 2003 R2 x64 mit aktivem FSRM:

FSRM auf einem Cluster

Stay tuned,
N.Own

Kürzlich wurde ich gefragt, ob man denn EFS (Encrypting File System auf NTFS Datenträgern) auf einem Windows Cluster nutzen kann – Klar, seit Windows Server 2003 funktioniert das tadellos:

» Storage Features in Windows Server 2003 and Clustering

Damit die EFS Verschlüsselung klappt muss lediglich darauf geachtet werden, daß beim virtuellen Server Kerberos aktiviert ist, dazu setzt man in den Eigenschaften der Ressource des Netzwerknamens den Haken “Kerberos-Authentifizierung aktivieren”. Bevor man diesen Schritt unternimmt, sollten einige caveats beachtet werden:

» Applying Kerberos Authentication in a Clustered Environment

Einmal aktiviert, sollte man die Kerberos Authentifizierung nicht mehr leichtfertig deaktivieren…

Stay tuned,
N.Own

IPSec war von Microsoft mit Erscheinen von Windows Server 2003 ursprünglich als not recomended für den Clusterbetrieb eingestuft:

» 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

Im Prinzip benötigt ein reiner Windows Server 2003 Cluster keine NetBIOS Funktionalität mehr, allerdings gängige Applikationen, die ein Cluster bereitstellt – daher ist die Frage mit einem klaren “Jein” zu beantworten.
Technisch ist es machbar, mit gewissen Einschränkungen:

» TechNet: NetBIOS in Cluster Networking

Zudem kann folgender Fehler bei der Namensauflösung vorkommen:

\\<FQDN>
You were not connected because a duplicate name exists on the network. Go to System in Control Panel to change the computer name and try again.

Dieser kann über den Registry Eintrag DisableStrictNameChecking gelöst werden, mehr dazu unter folgendem KB Artikel (KB914056):
» You may receive error messages if you disable NetBIOS…

Auch wenn es technisch machbar ist für den reinen Cluster Betrieb, so kommt doch nicht jede Applikation damit zurecht – so zum Beispiel Exchange:
» Exchange Server 2003 require NetBIOS name resolution…

Zu dem Thema NetBIOS und speziell Exchange hat MVP Kollege Russ Kaufmann einen Blog Artikel verfasst:
» Russ Kaufmann: WINS is a Friend of Mine

Fazit: In einem LAN, in dem man Applikationen wie Exchange 2003 sowie Windows XP clients inkl. third party software etc. findet, sollte man lieber ein, zwei WINS Server bereithalten. Diese schränken die unangenehmen NetBIOS Broadcasts ein und stellen sicher, daß auch legacy Apps noch laufen.

Wer sich im Detail für die Namensauflösung und deren Wege in einem LAN interessiert, findet in diesem TechNet Artikel detaillierte Informationen nebst passender Schaubilder zum Thema Name Resolution aus dem Windows XP Professional Resource Kit:
» Configuring IP Addressing and Name Resolution

Stay tuned,
N.Own

Gestern erreichte mich eine Mail mit der Information, daß der Resource Monitor bei einem Windows Server 2003 Cluster mit SP2 sporadisch abstürzen könnte. Der Crash tritt nur mit installiertem SP2 oder Hotfix 921181 (File Share Witness) auf.

Es gibt für diesen Fall einen Hotfix:
» http://support.microsoft.com/kb/948701/en-us
Der Hotfix kann direkt per Weblink angefordert werden:
» http://support.microsoft.com/hotfix/KBHotfix…

Eine Suche nach der Crashdump Datei des Resource Monitor (resrcmon.dmp) im %SYSTEMROOT%\Cluster gibt Aufschluss über einen vorhergehenden Absturz.
Der passende Eintrag im cluster.log ist in o.g. KB Artikel aufgeführt. Der gefixte resrcmon.exe trägt die Version 5.2.3790.4250

Stay tuned,
N.Own

Wer auf mehreren Clustern Freigaben für Home-, Profil- und Ablagelaufwerk anlegen muss, kann dies auch über Batchdatei erledigen.
Hier ein Beispiel:

REM Freigaben für Standort im Cluster anlegen
REM
REM %1 = Virtueller Name des Clusters (Clustergruppe), %2 = Standortinfo 1 , %3 = Standortinfo 2, %4=File Server Clustergruppe
REM Sample: ‘cluShares.bat CLU01MUC015N Aussenstelle Musterstadt CLU01MUC020N’
REM Just change the pathvar and everyone variable to your File Share and Everyone identifier
REM v 0.5, 04.08.07 – n.own @ mvps.org

REM @echo off
SET pathvar=F:\Kunde
SET everyone=Jeder
SET diskres=Disk F:

IF EXIST “%pathvar%\%2″ goto Process

rocess
cluster %1 res “Freigabe Home %2 %3″ /create /group:”%4″ /type:”File Share”
cluster %1 res “Freigabe Home %2 %3″ /priv path=”%pathvar%\%2\Home %2 %3″
cluster %1 res “Freigabe Home %2 %3″ /priv Sharename=”Home %2 %3″
cluster %1 res “Freigabe Home %2 %3″ /priv Remark=”Freigabe für %2 %3″
cluster %1 res “Freigabe Home %2 %3″ /prop Description=”Freigabe für %2 %3″
cluster %1 res “Freigabe Home %2 %3″ /priv security=%everyone%,grant,f:security
cluster %1 res “Freigabe Home %2 %3″ /priv ShareSubDirs=0
cluster %1 res “Freigabe Home %2 %3″ /AddDep:”%diskres%”
cluster %1 res “Freigabe Home %2 %3″ /AddDep:”%4 Name”
REM cluster %1 res “Freigabe Home %2 %3″ /on

cluster %1 res “Freigabe Profiles %2 %3″ /create /group:”%4″ /type:”File Share”
cluster %1 res “Freigabe Profiles %2 %3″ /priv path=”%pathvar%\%2\Profiles %2 %3″
cluster %1 res “Freigabe Profiles %2 %3″ /priv Sharename=”Profiles %2 %3″
cluster %1 res “Freigabe Profiles %2 %3″ /priv Remark=”Freigabe für %2 %3″
cluster %1 res “Freigabe Profiles %2 %3″ /prop Description=”Freigabe für %2 %3″
cluster %1 res “Freigabe Profiles Profiles Memmingen” /priv security=%everyone%,grant,f:security
cluster %1 res “Freigabe Profiles %2 %3″ /priv ShareSubDirs=0
cluster %1 res “Freigabe Profiles %2 %3″ /AddDep:”%diskres%”
cluster %1 res “Freigabe Profiles %2 %3″ /AddDep:”%4 Name”
REM cluster %1 res “Freigabe Profiles %2 %3″ /on

:END
echo End of batch

Das Script muss noch vor der Nutzung an die eigene Umgebung angepasst werden, unter pathvar gehört der lokale Pfad der Daten, der Everyone identifier lautet je nach OS Sprache ‘Jeder’ oder ‘Everyone’. ‘Disk F:’ steht stellvertretend für die Bezeichnung der Physical Disk Resource.

Das script kann leicht durch Hinzufügen des jeweiligen cluster.exe blocks zum Anlegen weiterer Freigaben erweitert werden. Zur Automatisierung und Einhaltung einer Konformität finde ich das Script sehr praktisch.

Das Batchfile steht hier auch zum Download bereit:
cluShares.bat

Stay tuned,
N.Own

Das Quorum Drive ist ein systemkritisches Volume eines Windows Server Failover Clusters. Sollte es Probleme mit dem Quorum geben, so daß ein Wechsel des Quorums nötig ist, kann der Cluster mit folgendem Kommando dazu gebracht werden ohne Quorum zu starten:

clussvc /debug /fixquorum

Die weiteren Nodes sollten dabei ausgeschaltet bleiben. Der Schalter sollte nur für den Zeitraum eines Quorumwechsels oder für Troubleshootingzwecke genutzt werden.
Um Probleme mit dem Quorum auszuschließen, kann der Schalter auch verwendet werden, da einem der Aufruf aus einer cmd.exe heraus mit dem Schalter /debug weiterführende Informationen zum Status des Clusters gibt.

Folgender TechNet Artikel beschreibt den Wechsel des Quorum Drives:
» KB280353: How to Change the Quorum Disk Designation

Falls das Quorum Drive aufgrund eines Defekts nicht mehr erreichbar ist, kann es zum EventID 1034 kommen. Auch wenn sich die Signatur der Disk ändert, wird das Volume nicht mehr vom ClusDisk Treiber als das ursprüngliche Drive erkannt.

In beiden Fällen kann mit dem Tool ClusterRecovery oder dumpcfg gearbeitet werden, um eine Disk zu tauschen:
» KB305793: How to replace a disk on a Windows server cluster
Das Tool dumpfg.exe gehört zum Windows 2000 Resource Kit und ist nicht als Download verfügbar, ich empfehle den Einsatz des aktuelleren Cluster Server Recovery Utility (ClusterRecovery.exe).
Dieses ist hier als Download verfügbar:
» Cluster Server Recovery Utility (ClusterRecovery.exe)
Das Tool clusterrecovery.exe gehört zum Windows Server 2003 Resource Kit und läuft auf Windows 2000 und Windows 2003 Server Clustern.
Weitere Informationen zu dem Thema findet man in folgendem TechNet Artikel:
» Troubleshooting Quorum Resource Problems

Um die Disk Signature zu sichern, kann das Tool confdisk.exe verwendet werden, es gehört zum Windows Server 2003 Resource Kit ist und hier als Download verfügbar:
Windows Server 2003 Resource Kit Tools

Mit folgendem Befehl kann man die Disk Configuration speichern:

confdisk /save c:\disks.sif

Die Disk Signatur kann man mit dumpcfg.exe einsehen, alternativ dazu kann man cluster.exe oder diskpart nutzen:

cluster resource <Datenträgerbezeichnung> /priv

oder

diskpart
list disk
select disk <id>
detail disk

Es empfiehlt sich eine freie LUN auf der Storage als Ersatz für das Quorum Laufwerk verfügbar zu halten. Jeweils ein GB für Quorum und Ersatzquorum ist bei den heutigen Diskgrößen kein Thema mehr und erleichtert einem die Fehlerbehebung im Falle eines Quorum-Ausfalls.

Stay tuned,
N.Own

Ein Print Cluster bietet einem eine gute Möglichkeit erhöhte Ausfallsicherheit für Druckdienste zu erreichen. Dabei kann auch einiges schiefgehen, wenn die Druckertreiber nicht standardkonform sind oder Komponenten wie der Print Prozessor oder Print Monitor des Druckertreiberherstellers Probleme bereiten.

Auch wenn der Cluster sauber arbeitet ist eine Überprüfung des Spooler lohnenswert, beim Troubleshooting hat man die Infos schneller zur Hand und weiß sofort wo man hingreifen muss.

Interessant auf einem Standalone Server (ohne Cluster) sind die folgenden Speicherorte von Druckertreibern:
Registry: HKLM\SYSTEM\CurrentControlSet\Control\Print
File: %SYSTEMROOT%\system32\spool (default)

Registry: Bei einem Print Cluster ist der Registryzweig hier zu finden:
HKLM\Cluster\Resources\<GUID>\Parameters
Die Zuordnung der GUIDs zu den entsprechenden Ressourcen sind in folgendem Zweig hinterlegt:
HKLM\Cluster\Resources

Die Print Spooler Files befindet sich auf dem SharedDevice im Verzeichnis Spool, dieser Speicherort ist frei wählbar. Die Daten liegen ebenso im lokalen Spoolerverzeichnis des Nodes unter:%SYSTEMROOT%\system32\spool\drivers\<GUID>

In den Verzeichnissen Monitors, PRTPROCS sind die entsprechenden Print Monitore und Print Prozessoren des Treibers abgelegt.

Generell sollte man darauf achten auf einem Windows Server 2003 System nur Level-3 Druckertreiber einzusetzen, da es sich hierbei um User Mode Treiber handelt. Level-2 Druckertreiber sind Kernel Mode Treiber, die bei einem Problem das gesamte System zum Absturz bringen können.
Soweit möglich sind Inbox Treiber den Druckertreibern der jeweiligen Hersteller vorzuziehen.

Weiterführende Links:
» KB278455: How to set up a clustered print server
» KB302539: How to Troubleshoot Printing Issues on a Cluster

Stay tuned,
N.Own

Was ist eigentlich die maximale Anzahl an Nodes in einem Windows Cluster?

Dazu gibt es einen KB Artikel, der auch die unterstützte Anbindung an die Storage nach Betriebssystemversion auflistet:

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

Gelistet ist aktuell Windows NT Server bis Windows Server 2008. Mit Windows Server 2008 stieg die Anzahl der Nodes von vorher 8 auf 16 bei Verwendung eines 64 Bit Systems.
Shared SCSI wird abgelöst von SAS, seit Windows Server 2003 hinzugekommen sind iSCSI Targets als Shared Device möglich. Parallel SCSI wird mit Windows Server 2008 nicht mehr unterstützt.

Stay tuned,
N.Own

Im Gegensatz zu Windows 2000 Server spielt Media Sensing für Clusterverbindungen unter Windows Server 2003 eine eher untergeordnete Rolle.
Bei Windows 2000 Server wurde der TCP/IP Stack entladen und die Einstellungen auf default zurückgesetzt, falls die Netzwerkkabel entfernt wurden oder media sensing/link status verloren ging. Daher gehörte es zu Best Practise dieses feature per Registry Key zu deaktivieren:

» Microsoft TechNet: Cluster Networking Best Practices

Der Registry Key DisableDHCPMediaSense hat unter Windows Server 2003 keine Wirkung, außer man erzwingt eine Wirksamkeit über einen weiteren Registry Key: DisableClusSvcMediaSense (ab W2K3 SP1). Media Sensing ist bei Windows Server 2003 Clustern standardmäßig abgeschaltet:

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

Die Konfiguration geht auch bei einem Verlust der Netzwerkverbindung nicht mehr verloren.

Bei Windows 2000 Server sollte man also den Registry Key überprüfen und ggf auf ’1′ stellen (Off), bei Windows Server 2003 ist keine Aktion nötig.

Stay tuned,
N.Own

In Foren und Newsgroup Postings geistert immer wieder die Frage umher, ob man DCs clustern könne – was ein absolutes NoGo ist.

Domain Controller, die ein Active Directory bereitstellen, werden über einen anderen Mechanismus redundant vorgehalten: Replikation. Es besteht schlichtweg keine Notwendigkeit DCs zu clustern.

Möglich ist der Aufbau eines Clusters auf einem DC, falls man keine separaten, dedizierten Domain Controller nutzen kann. Keinesfalls ist es möglich die Funktion Domain Controller zu clustern.
Man sollte sich weiterhin bei einem solchen Setup über folgende Einschränkungen im Klaren sein:

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

Plant man dann noch auf einem solchen Cluster, der ebenfalls DC ist, Exchange zu installieren, so ist das noch weniger ratsam und auch nicht supported:

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

Ebenso ist es nicht ratsam einen Windows Cluster im Aktiv/Aktiv Aufbau zu betreiben, da im Falle eines Failovers der verbleibende aktive Node die Last von 2 Nodes zu bewältigen hat.
Idealerweise nutzt man die N+1 Regel, bei der ein Cluster immer wenigstens einen Node als passiven Node vorhält.
Wer trotzdem zB. Exchange in einer Aktiv/Aktiv Konfiguration betreiben will, sollte sich folgenden KB Artikel zu Gemüte führen:

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

Stay tuned,
N.Own