Single Instance Store im Cluster – Teil 2

Es gibt inzwischen einen KB Artikel zum Thema Single Instance Store auf einem Cluster – danke an H.V. für den Hinweis. In einem früheren Artikel habe ich bereits die Besonderheiten beim Einsatz von SIS auf einem Cluster Volume angesprochen, nun gibt es in einem aktuellen KB Artikel die Empfehlung den Groveler über ein VBS Skript (Sisclusr.vbs) einzubinden:

» KB 947266: Single Instance Store on a Cluster (sisclusr.vbs)

Das Skript wird über den Ressourcentyp ‚Generic Script‘ in der Cluster Verwaltung angelegt, ähnlich wie das bei dem Skript clusweb.vbs zum Clustern eines IIS der Fall ist.

Single Instance Store ist ein feature, daß ursprünglich aus dem Exchange Umfeld kommt und zur Datendeduplizierung verwendet wird. Es bietet einem echte Deduplizierung von File System Daten über Pointer, den sog. SIS Links: So wird eine Datei immer nur einmal auf einem Volume abgelegt, die Kopien zeigen via SIS Links auf diese originäre Datei.

Für den Einsatz von Single Instance Store benötigt man einen Windows Storage Server oder Windows Unified Data Storage Server.

Weiterführende Informationen zu dem Thema Single Instance Store bietet das SIS Technical White Paper (Word DOC).

Stay tuned,
N.Own

Cluster Shared Volumes

Bis dato basierte Windows Server Failover Clustering (WSFC), ehemals MSCS, auf der Shared Nothing Architektur. Das bedeutet unter anderem, daß kein Volume gleichzeitig von zwei Nodes im Zugriff sein darf.

Das wird sich mit Windows Server 2008 R2, codename Windows 7 Server, ändern.
Das Feature dazu heißt:

Cluster Shared Volumes (CSV)

· Cluster Shared Volumes erlauben gleichzeitigen Zugriff auf CSV Disks von jedem Node aus

· Man spricht in dem Fall von „Distributed File Access for Hyper-V“

· Volumes werden nicht mehr dismounted und remounted

· VMs bleiben online während eines Failovers (!)

· Ein Coordinator Node hält die Disk Ressource und regelt den Zugriff auf die CSV Disk

· Single Name Space für den Zugriff auf die CSV Disk: %windir%\ClusterStorage\…

· Keine spezielle Storage, keine Agenteninstallation, kein neues Filesystem nötig

· Der File System mini-filter CSVFilter.sys ermöglicht die neue Funktionalität

· CSV in R2 wird nach derzeitigem Stand nur in Verbindung mit Hyper-V unterstützt

In Verbindung mit Hyper-V wird es dank CSV Disks sehr spannende Clustering-Möglichkeiten geben. So kann eine VM zwischen den Nodes in einem Windows Server 2008 R2 Cluster ohne Downtime verschoben werden. Der Failover geschieht ohne, daß der client dies bemerkt. Offene TCP Verbindungen werden dabei erhalten, es kommt zu keinem Abbruch der Verbindung oder einer Session.  Die ersten Demos sehen sehr vielversprechend aus.

Cluster Shared Volumes können über die GUI oder mit Hilfe der Powershell erstellt werden.

Stay tuned,
N.Own

File Server Resource Manager auf einem Cluster?

Dieser Tage kam die Frage im MCSEboard.de auf, ob denn der File Server Resource Manager (FSRM) mit gesetzten Quotas auf einem Windows Server 2003 R2 Cluster läuft: Ja, absolut.
Die Einstellungen die für ein Volume gesetzt sind, werden auf dem Laufwerk selbst im ordner „System Volume Information“ gespeichert [» 1]. Bei einem Failover wandert also die Konfiguration mit dem Volume auf den jeweils aktiven Node.

Informationen wie die Quota Templates werden in der Registry gespeichert und sind auf einem Cluster in folgendem Hive zu finden: HKLM\Cluster\SRM

Um Quotas und File Screens zu konfigurieren verbindet man sich nicht mit dem virtuellen Namen des File Server Clusters, sondern mit dem aktiven Node [» 2].
Um ein Backup der FSRM Konfiguration durchzuführen siehe folgenden TechNet Artikel:
» http://technet.microsoft.com/en-us/library/cc771319.aspx [3]

Hier ein Screenshot von einem 2-Node Cluster, bei den Nodes handelt es sich um Windows Storage Server 2003 R2 x64 mit aktivem FSRM:

FSRM auf einem Cluster

FSRM auf einem Cluster

Stay tuned,
N.Own

Single Instance Store auf einem Cluster

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

Delayed Write Failed

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