Windows Server 2008 R2 bietet neben der erhöhten Ausfallsicherheit hinsichtlich der NICs und der Nodes auch die Möglichkeit Storage I/O Traffic umzuleiten.

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

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

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

Eine der unbeliebtesten Fehlermeldungen, die einem Cluster Admin widerfahren kann, ist die Meldung “Delayed Write Failed“. Diese Meldung besagt, daß Windows Daten im Speicher nicht mehr auf eine Storage schreiben kann, weil diese nicht mehr zur Verfügung steht. Das bedeutet kurz gesagt: Datenverlust (“The data has been lost”).

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

Bei der Verwendung von Clustering über iSCSI kommen völlig neue Anforderungen an eine NIC (Netzwerkarte). Es läuft nun nicht nur der Netzwerktraffic eines Servers über eine (separate) NIC, um Clientanfragen abzuarbeiten, sondern auch der Backendverkehr vom Server zu einer Storage Box.

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

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

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

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

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

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

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