Archiv der Kategorie: Cluster Storage

SAN I/O Fault Tolerance

★ von

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

Live Migration mit Hyper-V

★ von

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

EFS auf einem Cluster?

★ von

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

Delayed Write Failed

★ von

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

TCP Offload Engine (TOE) & iSCSI

★ von

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.
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