Von DPEs, SPEs und LCCs…

Die nächsten zwei Wochen dreht sich bei mir alles um Navisphere, Flare OE, Switched Fabric und Fibre Optics etc.
Ich bin momentan in Bracknell (UK) im Hause Dell zur EMC SAN Schulung.
Design, Einrichtung, Konfiguration und Troubleshooting der Clariion CX-Serie (300-700) sowie der neuen CX3 Serie stehen im Mittelpunkt.

Normalerweise hat man selbst als Cluster Guy recht wenig mit der Storage jenseits des Windows Storport Treibers zu tun, für einen Windows Cluster ist die Storage Einheit sowieso eine Black Box.

Umso interessanter ist es mal den SAN Storage Unterbau in seiner Tiefe kennenzulernen. Gerade das SAN Zoning und LUN Masking sind wichtige Aspekte, die beim Clustering bedacht werden sollten.
Mehr zu diesen Themen zu einem späteren Zeitpunkt.

Cheers,
N.Own

„Giving a reprieve for resource…“

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

StarWind iSCSI Target nun Longhorn kompatibel

Gute Nachrichten: RocketDivision hat den Termin für die Longhorn Kompabilität ihres iSCSI Software Target „StarWind“ pünktlichst eingehalten und vor einigen Tagen eine neue Version released:

» http://www.rocketdivision.com/wind.html
Der kostenlose Download einer Testversion ist möglich.

StarWind’s iSCSI Target ist nun für Longhorn Server verfügbar, leider ist damit noch kein Clustering möglich. Das soll mit einer weiteren Version kommen, die für Mai/Juni geplant ist.
Mit dem » Wegfall von Shared SCSI in LHS ist die Nutzung eines iSCSI Targets die attraktivste Möglichkeit Clustering in VMs zu testen.

Stay tuned,
N.Own

Filtertreiber im Cluster

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 0x4 setzen, welches ein SERVICE_DISABLED bedeutet.
Siehe auch » KB816071 dazu.

Stay tuned,
N.Own

„Disk bus type does not support clustering“

Es gibt zur Zeit einige Newsgroup Einträge zu dieser Fehlermeldung unter Longhorn Server: „Disk bus type does not support clustering„. Wieso kommt diese Meldung beim Aufsetzen eins Longhorn Failover Clusters?
Longhorn bietet keine Unterstützung mehr für Shared (Parallel) SCSI Device als Storage.

Lediglich Fibre Channel (FC), iSCSI und Serial Attached SCSI (SAS) Storage Devices werden unterstützt
Dies hat Elden Christensen, Program Manager bei Microsoft für Windows Failover Clustering, bereits auf der WinHEC 2006 in einer Powerpoint Präsentation verkündet:

PPT: » WinHEC 2006: Windows Server High Availability With Windows Server Longhorn Failover Clustering
(Dateiformat: Microsoft Powerpoint)

Momentan unterstützt aber zB. StarWind’s iSCSI Target noch nicht Longhorn Server, dies wird für Anfang Q2 anvisiert.

Stay tuned,
N.Own