Block Level Zugriffe auf eine SAN können dynamisch via SMB über eine Netzwerkverbindung geroutet werden und an einen Node weitergeleitet werden, der noch eine Verbindung zur SAN hat.

Es können somit erstmals Ausfälle der Storage Pfade zu einer SAN, sei es SAS, Fibre Channel oder iSCSI, abgefangen und über einen Netzwerkpfad umgeleitet werden. Windows Server 2008 bietet dieses feature out-of-the-box in der R2 Version in Verbindung mit Hyper-V und Cluster Shared Volumes.

Stay tuned,
N.Own

» 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

» 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

Das rührt daher, wenn ein Storage Treiber, in der Regel ein Storport Miniport Treiber, nicht rechtzeitig oder gar nicht mehr reagiert oder die Storage nicht mehr adäquat reagiert.
Das wiederum kann am Storport Miniport Treiber, an einem File System Filter Treiber liegen oder an der Hardware, sprich dem Controller oder den Array Komponenten bzw. den SAN Komponenten.

Events
Typische Events dazu im Cluster sind Event ID 9, 11, 15 sowie Event ID 50. Diese Event IDs sind kritische Fehler und sollten mit in das Monitoring aufgenommen werden.

» Troubleshooting event ID 9, 11, and 15 on Cluster Servers

» How to troubleshoot event ID 9, event ID 11, and event ID 15

Folgender KB Artikel hilft einem den error message dump zu dekodieren:
» Format of event log data created by ScsiPortLogError

Nachfolgend erscheint Event ID 50: Delayed Write Failed (IO_LOST_DELAYED_WRITE), ein Datenvolume oder die ganze Storage ist nicht mehr erreichbar. Windows kann empfangene oder verarbeitete Daten nicht mehr auf das Volume speichern, sprich: Irreparabler Datenverlust.

» Description of the Event ID 50 Error Message

Recovery
Den Cluster nun wieder betriebsbereit zu bekommen bedeutet zuerst das Storage Device, die Controller und alle Array bzw. SAN Komponenten zu prüfen sowie ggf. den Storage Treiber und die verwendeten File System Filter Treiber.
Erst danach kann man zu einem Recovery übergehen, denn bevor die Storage nicht wieder 100%ig ohne Fehler verfügbar ist macht die Wiederinbetriebnahme des Clusters keinen Sinn – der Fehler kann jederzeit wieder auftreten.

Stay tuned,
N.Own

Um die CPU zu entlasten und einen höheren Durchsatz zu erreichen, gibt es die Möglichkeit den TCP/IP Overhead, den i.d.R. der TCP/IP Stack des OS verarbeitet, auf die NIC (sog. TOE NIC) zu verlagern. Dieses Verfahren nennt sich TCP Offload Engine (TOE) und schafft neben einer Entlastung der CPU eine effizientere Verarbeitung der Nutzdaten, sei es LAN Traffic oder iSCSI Payload.

Damit das TCP Offloading auf Windows Servern funktioniert, benötigt man neben einer TOE NIC auf 2K3 Servern <SP2 das Scalable Networking Pack (KB 912222), welches im SP2 enthalten ist. Microsoft spricht in dem Zusammenhang aus OS Sicht von TCP Chimney Offload, das weitere Aspekte beinhaltet (NetDMA/RDMA, RSS etc.).

In Zeiten von Gigabit Ethernet (1GbE/10GbE) ist TOE eine wünschenswerte Entwicklung, um den Flaschenhals NIC/CPU zu entlasten, allerdings bedeutet dies eine signifikante Veränderung der NDIS Architektur (2K3
In Verbindung mit NIC Teaming bringt einem TOE echtes Potenzial für Performancesteigerungen.

Im iSCSI Anwendungsfall auf Windows Cluster empfehle ich aus technischer Sicht anstatt von TOE NICs den Einsatz von iSCSI HBAs (Full iSCSI Offload HBA), die nochmals eine Steigerung des Durchsatzes/der IOPS schaffen, da diese rein für iSCSI Traffic optimiert sind. Zudem verwenden iSCSI HBAs wie auch FC HBAs den Storport Treiber und nicht den Windows Netzwerk Stack.
iSCSI HBAs sind nicht unbedingt billiger als FC HBAs, aber man spart sich immer noch die FC Switche

Stay tuned,
N.Own

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

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

» 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

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

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