Diesmal nur ein KB Tipp: Es gibt einen laufend aktualisierten KB Artikel zum Thema SQL Failover Cluster und deren Eigenheiten:

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

This article describes some important do’s and don’ts for using SQL Server clustered servers with the different versions of SQL Server.

Da weiterführende KB Artikel verlinkt sind, bietet sich der Artikel als gute Checkliste für die Installation eines SQL Failover Clusters an.

Stay tuned,
N.Own

Es gibt einige Besonderheiten, die man bei der Netzwerkkonfiguration eines Windows Cluster Servers beachten sollte.

Dazu gehört die Verwendung von statischen IP Adressen, eine korrekte Bindungsreihenfolge (1. public, 2. private), kein NetBIOS auf der Heartbeat Verbindung etc.

Mehr dazu:
» Cluster Networking Best Practices
» Recommended private “Heartbeat” configuration (KB258750)

Es empfiehlt sich die Liste der Aktionen für die Konfiguration der Netzwerkeinstellungen beim Setup eines Clusters durchzuarbeiten.

Stay tuned,
N.Own

Wie sehen die default resource dependencies bei einem Windows Server Cluster aus?

Zu den Standard Ressourcenabhängigkeiten gibt es im Windows Server 2003 TechCenter ein Dokument:

» TechNet TechCenter: Setting resource dependencies

Stay tuned,
N.Own

Windows Storage Server 2003 kommt mit dem Single Instance Store Feature, bei dem von einer Datei lediglich immer nur eine Version gespeichert wird – kommt ein Duplikat hinzu, wird darauf referenziert.

Läuft Single Instance Store auch auf einem Windows Server Cluster?

Ja, wenn man folgende Punkte bedenkt:
» Using SIS on Server Clusters

Whitepaper zum Thema SIS:
» New Single Instance Store whitepaper available

Stay tuned,
N.Own

Wie überprüft der Cluster Service die Verfügbarkeit einzelner Ressourcen?

Um zu überprüfen, ob Cluster Ressourcen noch verfügbar sind gibt es im allgemeinen zwei Checks, die der Clusterdienst periodisch ausführt: Den LooksAlive check und den IsAlive check.
Der LooksAlive check ist eine einfache Überprüfung, ob eine Ressource ansprechbar ist. Der IsAlive check geht -je nach Ressourcentyp- darüber hinaus.

Die LooksAlive und IsAlive checks fallen je nach Ressourcentyp unterschiedlich aus, hier anhand des Beispiels einer Cluster Print Spooler Ressource:

LooksAlive
Der Windows Service Control Monitor (SCM) wird abgefragt, ob der Spooler Dienst läuft

IsAlive
Ein API Call auf das Printer Subsystem (localspl.dll) wird abgesetzt

Der LooksAlive-/IsAlive check einer Ressource ist also stark davon abhängig, welche Funktion eine Ressource inne hat. Folgender KB Artikel gibt einem eine gute Übersicht wie die üblichen Cluster Standardressourcen überprüft werden:

» Behavior of the LooksAlive and IsAlive functions… (KB 914458)

Im Falle einer Physical Disk Ressource prüft der Clusdisk.sys Clusterdienst zusätzlich alle 3 Sekunden mittels eines SCSI Reserve Kommandos, ob die LUN noch verfügbar ist. Weiterhin wird eine Lese-/Schreiboperation auf den sog. “Private Sector”, den Sektor 12 einer LUN, ausgeführt.

Um die LooksAlive-/IsAlive checks zu unterdrücken, um beispielsweise ein “chkdsk /f” exklusiv und vor allem unterbrechungsfrei auf einer Shared Disk auszuführen zu können, gibt es seit Windows Server 2003 SP1 den Maintenance Mode. Mittels folgendem cluster.exe Parameter kann eine Disk in diesen Wartungsmodus versetzt werden:

cluster.exe . res "ADisk" /maint:on

Weiterführende Informationen zum Wartungsmodus:
» http://support.microsoft.com/kb/903650/en-us

Das LooksAlive-/IsAlive Intervall kann alternativ dazu über ein cluster.exe Parameter angepasst werden:

» Cluster.exe Parameters: LooksAlivePollInterval – IsAlivePollInterval

Die Defaultwerte sollten nur in begründeten Fällen angepasst werden, zB. um die Zeit für einen Restore zu erhöhen. In der Regel können ab W2K3 SP1 anstatt der manuellen Anpassung die Werte des Maintenance Mode verwendet werden.

Stay tuned,
N.Own

Nebst der Liste empfohlener Hotfixe für Windows 2000 Server und Windows Server 2003 SP1 Cluster gibt es inzwischen auch eine Liste empfohlener Hotfixe für Windows Server 2003 SP2 Cluster:

» Recommended hotfixes for Windows Server 2003 Service Pack 2-based server clusters

Ende letzter Woche wurde die Liste aktualisiert. Diese Liste sollte jeder Cluster Admin im Auge behalten und die Nodes entsprechend patchen.

Stay tuned,
N.Own

Wie deinstalliert man eigentlich einen Clusterknoten rückstandslos?

Folgende Vorgehensweise über den Cluadmin empfiehlt sich, um einen Knoten zu deinstallieren:

1. Ressourcen auf passiven Knoten schwenken
2. Cluster Knoten anhalten: “Stop the Cluster Service”
3. Knoten evicten: “Evict Node”

Das führt dazu, daß der Knoten entfernt wird und alle Clusterspezifischen Einstellungen gelöscht werden.
Der Clusterdienst an sich gehört zum Funktionsumfang eines Windows Servers und bleibt erhalten.

Falls dies fehlschlägt, kann die Kommandozeilen-Option forcecleanup gewählt werden:

cluster node nodename /forcecleanup

Vorsicht: Diesen Befehl keinesfalls auf einem aktiven Node ausführen. KB 282227 beschreibt diese Optionen:
» How to Uninstall the Cluster Service

Sinn macht ein forcecleanup auch, falls der Knoten ursprünglich mal einem anderen Cluster (KB 555216) angehört hat oder das evicten nicht vollständig abgeschlossen wurde.

Stay tuned,
N.Own

Im Fehlerfall kann es vorkommen, daß eine einzelne Cluster Ressource über den als Pending Timeout definierten Zeitraum hinaus im Status On- oder Offline Pending verbleibt.
Die entsprechende Ressource DLL gibt weiterhin Statusmeldungen an den Ressource Monitor zurück, so daß der Status in diesem Fall weiterhin bestehen bleibt.
Siehe dazu auch folgenden Beitrag: http://www.cluadmin.de/giving-a-reprieve-for-resource-p104/

Um den Zustand zu beenden, kann man einen manuellen Failover initiieren:

» Cluster Resource Appears to Stop Responding in an Online Pending State…

Der KB Artikel zeigt dazu zwei Lösungsmöglichkeiten auf:

1. Initiieren eines Failovers über den Cluster Administrator

Dazu sucht man sich eine Ressource in der gleichen Gruppe, die online ist, wie zB. eine IP Ressource und initiiert über ‘Initiate Failure’ einen Failover

2. Initiieren eines Failovers über die cluster.exe

cluster res "ResourceName" /fail

Ein weiterer Fehlerfall zB. beim Neueinrichten einer Applikation kann ebenfalls dazu führen. Ein Löschen der Ressource zur Neukonfiguration ist dann im Status On-/Offline Pending nicht möglich.
Eine praktikable Möglichkeit dies zu lösen ist das Offlineschalten der Ressourcen einer Gruppe:

1. Auswählen aller Ressourcen in der Gruppe
2. Über Rechtsklick ‘Take Offline’ alle Ressourcen offline nehmen
3. Hängende Ressource löschen und mit korrekten Parametern neu einrichten

Stay tuned,
N.Own

Der Cluster Service Account (CSA) braucht gewisse Rechte, um alle Operationen des Cluster Dienstes ausführen zu können.

Voraussetzung für den ordentlichen Betrieb ist die Mitgliedschaft des Cluster Service Accounts in der Gruppe der Lokalen Administratoren sowie, daß der CSA Mitglied einer Domäne ist. Kein Cluster ohne DC und ohne Windows Domäne.

Weitergehende Rechte müssen in den Lokalen Sicherheitsrichtlinien auf jedem Nodes eines Clusters explizit vergeben werden:

Klicken Sie den Screenshot zum Vergrößern an. Bei den grün markierten Rechten muss der CSA eingetragen werden, bei den orange markierten Rechten muss die lokale Administratorengruppe eingetragen sein (standard).

Das gilt für Windows Server 2003 Cluster – bei Windows Server 2000 müssen weiterhin folgende Rechte eingetragen sein:

• Increase quotas
• Load and unload device drivers
• Lock pages in memory

Ein Fehlen dieser Rechte kann zu unvorhergesehenen Effekten und Fehlern führen, daher empfehle ich dringend die Einrichtung dieser Rechte, die man manuell vornehmen muss.

Wichtig: Keine Security Templates auf Cluster Nodes verteilen, typische Stolperfallen sind Security Templates wie die Highly Secure Predefined Security Templates (hisec*.inf). Die Predefined Templates müssen stark verändert werden für einen reibungslosen Betrieb des Cluster Dienstes.

KB Artikel zu den CSA Rechten:
» How to manually re-create the Cluster service account

Unter Windows Server 2008 wird der CSA obsolet, der Cluster Dienst läuft dort im Kontext des LocalSystem Accounts.

Stay tuned,
N.Own

Wird ein Volume als dirty markiert, das als Clusterressource eingebunden ist, so läuft es in den checkdisk. Der chkdsk geschieht erst nach dem Systemstart und nicht, wie außerhalb des Clusters üblich, während des Bootens und wird vom ClusDisk Treiber initiiert.
Folgender Eintrag ist in einem solchen Fall im cluster.log sichtbar:

00000a24.00000220::2007/05/04-07:31:33.934 INFO Physical Disk <Datenträger F:>: DriveIsAlive called for Online check
00000a24.00000220::2007/05/04-07:31:34.091 INFO Physical Disk <Datenträger F:>: DriveIsAlive checking that file system is not corrupt. If so, chkdsk may run.
00000a24.00000220::2007/05/04-07:31:34.091 INFO Physical Disk <Datenträger F:>: DisksIsVolumeDirty: Volume is dirty
00000a24.00000220::2007/05/04-07:31:34.091 INFO Physical Disk <Datenträger F:>: DisksOpenChkdskLogFile: chkdsk.exe output is in file: C:\WINDOWS\Cluster\ChkDsk_Disk0_Sig7D01274F.log

Im Hintergrund läuft nun ein chkdsk Prozess, der aktuelle Status ist im chkdsk(…).log ersichtlich.

Die Ressourcen verbleiben solange im Status Online Pending, im cluster.log wird folgendes geloggt:

00000a24.00000df0::2007/05/04-07:36:55.915 WARN [RM] ChkdskNotRunning: Found process chkdsk.exe.
00000a24.00000df0::2007/05/04-07:36:55.915 INFO [RM] RmpTimerThread: Giving a reprieve for resource Datenträger F:…

Der Resource Monitor (RM) wartet solange auf die Resource DLL, solange diese Statusupdates meldet.
Das bedeutet, daß die Zeit für ein PendingTimeout erst ab dem Zeitpunkt läuft, wenn keine Rückmeldung mehr von einer Resource DLL zurückgegeben wird.
Siehe: » MSDN – PendingTimeout
In diesem Fall muss der chkdsk Prozess abgewartet werden, die Ressourcen verbleiben währenddessen wie gesagt im Status Online Pending.
Folgender Eintrag ist im cluster.log zu finden über den chkdsk status:

00000a24.00000220::2007/05/04-08:39:59.779 WARN Physical Disk <Datenträger F:>: FixCorruption: chkdsk.exe returned status of X (…)

Erläuterung zu den status codes:
» http://support.microsoft.com/kb/265533/en-us/
Allgemeines zum chkdsk im cluster:
» http://support.microsoft.com/kb/272244/en-us

Ein Failover würde hier keine Verbesserung des Status bewirken, da erst das Dateisystem sauber sein muss, bevor eine Disk Ressource online genommen werden kann.

Um zum Titel dieses Beitrags und den eingangs erwähnten Eintrag im cluster.log zurückzukommen (“giving a reprieve for resource…”): Interessante Wortwahl

Stay tuned,
N.Own

Typische third party File System Filtertreiber sind AntiVirus Treiber, Disk Quota Treiber oder Open File Agents. Jegliche Software, die einen Filtertreiber auf einem Cluster Node installiert, sollte für den Einsatz in einem Cluster vorgesehen sein (» KB250355). Ansonsten kann ein Filtertreiber, der zB. sein Handle auf ein Volume gar nicht oder nicht rechtzeitig freigibt, dazu führen, daß kein geordneter Failover mehr möglich ist.
Zu Troubleshootingzwecken ist es daher fallweise sinnvoll bestimmte Filtertreiber vorübergehend zu deaktivieren, um diese als Fehlerquelle auszuschließen und das Fehlerbild weiter einzugrenzen.

Welche Filtertreiber sind auf meinem Cluster installiert?
Viele Filtertreiber sind leicht über den Gerätemanager zu lokalisieren. Über “Ausgeblendete Geräte anzeigen” bzw. “Show hidden devices” sind die Treiber in der Sektion “Nicht-PNP-Treiber” bzw. “Non-Plug and Play Drivers” zu finden.
Der McAfee Filtertreiber trägt beispielsweise die Bezeichnung “NaiAv…”.

Über den Kommandozeilenbefehl devcon.exe erhält man diese Legacy Treiber auch angezeigt:

C:\>devcon listclass LegacyDriver

Ein Beispiel der Ausgabe: devcon_sample.txt

Devcon.exe ist in den Support Tools zu finden oder über einen Download bei Microsoft:
» http://support.microsoft.com/kb/311272/en-us

Der Clusterdienst benötigt für den Betrieb selbst zwei Kernel Filtertreiber: Den ClusDisk Treiber für den Storage Stack und ClusNet für den Network Stack.

Im Cluster » MPS Reporting Tool ist ein Kommandozeilenprogramm namens fltrfind.exe zu finden, daß einem alle Filtertreiber ausgeben soll. Leider liefert einem das Tool keine Infos zu File System Filtertreibern.

Um einen Filtertreiber zu deaktivieren, kann man den Gerätemanager verwenden oder über die Registry gehen. Die Treiber sind im Services Zweig zu finden:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services

Dort den betreffenden Treiber suchen und den Wert unter “Start” auf 0×4 setzen, welches ein SERVICE_DISABLED bedeutet.
Siehe auch » KB816071 dazu.

Stay tuned,
N.Own

Dr. Tom Moreau, MVP für SQL Server, hat in einem aktuellen TechNet Magazine Artikel vom März diesen Jahres seine Top Tips für SQL Server Clustering zusammengestellt.
Er gibt eine Übersicht der Möglichkeiten MS SQL Server 2005 zu clustern und zu spiegeln:

» Dr. Tom Moreau’s Top Tips for SQL Server Clustering

Dr. Tom Moreau ist seit 2001 MVP für Windows Server System – SQL Server.

Stay tuned,
N.Own

Ein kürzlich veröffentlichter Hotfix ermöglicht nun den Einsatz von GPT Disks in einem Cluster. Volumes mit mehr als 2 Terabyte sind nun auch im Cluster möglich.

Siehe: » A hotfix is available that adds support for GPT volumes… (KB 919117)

Um ein Volume vom Typ MBR auf GPT umzustellen, kann man den diskpart Befehl convert gpt nutzen.

Mehr dazu: » Change a MBR disk into a GPT disk

Voraussetzungen:

x86: Windows Server 2003 SP1/SP2, 32 Bit
IA64: Windows Server 2003 SP1/SP2 für Intel Itanium
x64: Windows Server 2003, 64 Bit

Stay tuned,
N.Own

Gestern ist das Service Pack 2 für Windows Server 2003 offiziell erschienen.
Es enthält auch eine Neuerung, die den Clusterdienst betrifft:

Falls der Cluster Service Account (CSA) nicht alle erforderlichen Rechte erhalten hat, wird ein Event 1239 ausgelöst, der weitere Informationen über das fehlende Recht trägt.

Siehe: » What’s New in Windows Server 2003 Service Pack 2

» Microsoft TechNet – Windows Server 2003 Service Pack 2

Der CSA sollte die Rechte halten wie in » KB 269229 beschrieben.

Event 1239 war bisher als Exchange Event (Quelle: MSExchangeIS, MSExchangeDS) bekannt.

Stay tuned,
N.Own

Es gibt eine aktualisierte Version des KB Artikels der empfohlenen Hotfixe für Server Clusters:

» Recommended hotfixes for W2K3 SP1 – Server Clusters (Rev. 8.0, 27.02.07)

Microsoft empfiehlt die Installation der Hotfixe auf dieser Liste.
Für Windows Server 2003 Cluster, auf denen noch nicht SP1 installiert ist, gibt es auch eine Liste:

» Recommended hotfixes for W2K3 – Server Clusters

Stay tuned,
N.Own

ClusPrep (Microsoft Cluster Configuration Validation Wizard) ist vor kurzem in der Version 1.0 erschienen.

Mit ClusPrep kann man Nodes vor der Installation des Clusterdienstes auf etwaige Probleme prüfen. Man kann es auch gegen vorhandene Clusternodes laufen lassen für Inventoryzwecke.

ClusPrep 1.0 läuft derzeit nur auf 32-Bit Maschinen und auch nur auf englischen Windows Server 2003 und Windows XP SP2 Systemen. ClusPrep läuft nicht unter Windows Vista.
Das Tool an sich gab es schon länger, nun ist eine neue Version erschienen.

Download: » Microsoft Cluster Configuration Validation Wizard (ClusPrep)

KB 933462: » Frequently asked questions about ClusPrep 1.0

Stay tuned,
N.Own

Ende Dezember hat MS einen sehr interessanten Hotfix für W2K3 SP1 Cluster veröffentlicht, der mehr ist als ein bloßer Hotfix:

» KB 921181: “An update is available that adds a file share witness feature and a configurable cluster heartbeats feature to Windows Server 2003 Service Pack 1-based server clusters”

Neu ist die erweiterte Funktionalität des Majority Node Sets (MNS): File Share Witness

Dies bietet einem eine echte Alternative, um Split Brain Szenarios (=Downtime) und Partition-in-Time Szenarios (=Dateninkonsistenz) zu umgehen – beides unschöne Effekte.

Ein echtes Highlight sind die neuen Parameter, um den Heartbeat zu konfigurieren:

cluster cluster_name /priv HeartBeatLostInterfaceTicks=5:DWORD
cluster cluster_name /priv HeartBeatLostNodeTicks=10:DWORD

Man kann damit die Latenzgrenzen für Multi-Site Cluster, ehemals GeoCluster/Stretched Cluster, etwas entschärfen und somit das Failoververhalten bei erhöhten Latenzzeiten der private NIC.

Scheint so, als ob ein paar Longhorn Cluster Features nun auch 2K3 Servern zu Gute kommen.

Stay tuned,
N.Own

Eine recht interessante Fallstudie ist zur Zeit auf microsoft.com online: An der größten elektronischen Börse NASDAQ werden >64 000 Transaktionen pro Sekunde ausgeführt.
Dazu kommen 2 Windows Cluster a 4 Nodes zum Einsatz, um five nines zu realisieren – also eine Uptime von 99,999%.

Auch wenn die Zahl beeindruckend erscheint – in einem realen IT Umfeld mit Endanwendern ist sie eher akademischer Natur, siehe u.a.: Myth of the nines. Trotzdem beeindruckende Werte, keine Frage.

Die NASDAQ Cluster setzen MS SQL Server 2005 ein und basieren auf DELL PowerEdge 6850 Nodes.

MS Kundenreferenzblatt:
» http://download.microsoft.com/…Nasdaq_D_Final_02086.pdf

Nettes Setup

Stay tuned,
N.Own

Aufgrund des Vista Launch diese Woche kommt man nicht mehr über den Windows Catalog auf die Auswahl für Cluster zertifizierter Hardware, diese ist nun hier zu finden:

» Windows Server Catalog of Tested Products – Cluster Solutions

Aus der Windows HCL (2K) wurde der Windows Catalog (2K3) und nun der Windows Server Catalog.

Warum ist der Einsatz zertifizierter Hardware besonders wichtig für den Einsatz in einem Cluster?
Diese Frage taucht immer wieder im » www.MCSEboard.de auf.

Wer ernsthaft Cluster betreiben will, sollte nur zertifizierte Hardware einsetzen. In einem Cluster laufen zeitkritische Aktionen im Millisekunden Bereich ab, dabei spielen Latenzzeiten besonders der HBAs und der NICs eine Rolle.
Das betrifft nicht nur die Hardware sondern auch die entsprechenden Treiber.

Bei GeoClustern (“stretched Cluster”) muss zB. sichergestellt sein, daß die Latenz der NICs <500ms bleibt [1][2] – das gilt natürlich auch für klassische Cluster.
Zudem supportet MS PSS/GTSC Cluster, die nicht im Windows Catalog gelistet sind, nur bedingt.

Unabhängig davon gibt einem ein zertifiziertes System die Sicherheit, daß der Betrieb eines MS Failovers Clusters in Verbindung mit dieser Hardware von Spezialisten auf Herz und Nieren geprüft und getestet wurde.

» Aktueller KB Artikel 309395

Also: Am besten zu zertifizierter Hardware greifen und man fängt Ärger und Downtimes bereits im Vorfeld ab.

Stay tuned,
N.Own

Alle Operationen des Clusterdienstes werden in das cluster.log geschrieben, das einem einen hervorragenden Ansatz zu Troubleshootingzwecken bietet. Speicherort des cluster.log ist standardmäßig:
%SystemRoot%\Cluster\cluster.log

Der Clusterdienst schreibt ein sehr ausführliches Log, alle Operationen werden hier im Millisekundenbereich aufgezeichnet.
Daher ist der Zeitraum, den das cluster.log abdeckt meist im Minutenbereich – je nach Auslastung des Clusters.

Die Größe des Cluster Logs -nicht zu verwechseln mit dem Quorum Log- kann über eine Umgebungsvariable einfach angepasst werden, siehe:

» Change the size of the cluster diagnostic log

» How to turn on cluster logging in Microsoft Cluster Server (KB168801)

Standardwert ist 8 MB, eine Größe um die 32 MB ist praktikabel und bietet einem ein größeres Zeitfenster.

In späteren Einträgen gehe ich näher auf die Spezifika des Logs ein.

Die Zeitangaben im cluster.log sind übrigens in GMT.

Stay tuned,
N.Own