Cluster Shared Volumes: Neuerungen in Windows Server 2012

Mit der Einführung von Hyper-V in Windows Server 2008 änderten sich die Anforderungen, weil es möglich sein sollte, eine virtuelle Maschine unterbrechungsfrei von einem Host zu einem anderen umzuziehen. Windows Server 2008 besaß diese Fähigkeit noch nicht und bot nur die Quick Migration, die mit einer kurzen Unterbrechung des Services verbunden ist. Jede VM musste dabei einer eigenen LUN zugeordnet werden, es sei denn, man nutzte ein Cluster-Dateisystem von Drittanbietern wie Sanbolic Melio.

Windows Server 2008 R2 brachte nun ein solches Dateisystem unter der Bezeichnung Cluster Shared Volumes (CSV), das technisch gesehen als Filtertreiber für NTFS implementiert wurde. Damit verfügt Microsoft über ein Gegenstück zu VMware VMFS (PDF). Jedes CSV erscheint als Verzeichnis unter einem gemeinsamen ClusterStorage-Ordner, also beispielsweise als c:\ClusterStorage\Volume1.

Live Migration funktioniert auch ohne CSV

Cluster Shared Volumes sind jedoch keine zwingende Voraussetzung für eine Live Migration, diese kann auch erfolgen, wenn jede VM eine eigene LUN nutzt. Nach dem Umzug muss in diesem Fall das Laufwerk getrennt und vom neuen Knoten wieder gemountet werden. CSV beschleunigt daher eine Live Migration, vermeidet mögliche Unterbrechungen und beugt dem exzessiven Verbrauch von LUNs vor.

Dateiverwaltung läuft über einen Knoten im Cluster

Von ihrer Architektur her sind Cluster Shared Volumes so umgesetzt, dass zwar jeder Knoten die Nutzdaten direkt über das Storage-Netzwerk in das CSV schreiben kann, die Verwaltungs­informationen für das Dateisystem (Metadaten) aber über einen so genannten Coordinator Node laufen. Jedes CSV benötigt einen Knoten des Clusters für diese Aufgabe. Während die direkte Kommunikation mit einem Storage-System typischerweise über das iSCSI-Netzwerk auf Blockebene stattfindet, spielt sich der Transfer via Coordinator Node über das Cluster-Netzwerk und SMB ab.

Redirected I/O als Bremse

Die Umleitung der Kommunikation mit den Speichersystemen über einen Coordinator Node (Redirected I/O) ist aus diesem Grund in der Regel deutlich langsamer als Direct I/O, dient aber als eine Failover-Option. Wenn ein Knoten die Verbindung zum Storage verliert, kann er auf diesem Weg - wenn auch langsamer - weiter auf seine Daten zugreifen. Eine Schwäche der früheren Implementierung von CSV besteht aber darin, dass es aus auch verschiedenen anderen Gründen ebenfalls auf Redirected I/O umschaltet, beispielsweise bei einem Backup oder generell bei der Erstellung VSS-Snapshots, und damit die Performance reduziert.

Einschränkungen von CSV unter Server 2008 R2

Die erste Version von Cluster Shared Volumes weist aber noch weitere Defizite auf:

• CSV eignet sich nur zur Verwendung mit der Hyper-V-Rolle, Microsoft rät ausdrücklich davon ab, dort andere Daten, beispielsweise SQL-Datenbanken zu speichern.
• Alle Knoten eines Clusters müssen sich im gleichen IP-Subnetz befinden, weil der CSV-Traffic nicht geroutet werden kann.
• Beschränkung auf iSCSI-, Serial-Attached-SCSI- und Fibre-Channel-Storage
• Schlechte Kompatibilität mit bestehenden Tools, wie Backup, Defragmentierung oder Laufwerksverschlüsselung. So lässt sich ein CSV nicht mit Windows Server Backup sichern.
• Keine Unterstützung für Pass-through-Laufwerke für virtuelle Maschinen unter Hyper-V

Diese Liste gibt bereits vor, welche Hausaufgaben Microsoft mit Windows Server 2012 zu erledigen hatte. So fiel die Beschränkung von CSV auf Hyper-V, so dass auf einem solchen Volume auch SQL-Datenbanken oder Dateien eines File-Servers liegen dürfen.

Integration von CSV 2.0 mit SMB 3

Gerade für die Datei-Server stehen in Zusammenhang mit CSV einige interessante Neuerungen an. Sie sind nicht darauf beschränkt, als Mitglied eines Windows-Clusters ein Cluster Shared Volume auf einem SAN mitnutzen zu dürfen. Vielmehr können mehrere Maschinen auch auf Direct Attached Storage (z.B. Shared SAS) oder ein NAS gleichzeitig über SMB 3 zugreifen.

Auch auf File-Level via SMB, nicht nur auf Blockebene, operieren die Knoten des Clusters normalerweise im Direct-I/O-Modus, können aber bei Auftreten von Fehlern diese über Redirect I/O abfangen. Daher eignen sich File-Server unter Windows Server 2012 auch als Storage-System für Hyper-V, das auch Live Migration unterstützt.

DAS plus SMB 3 plus CSV statt SAN

Attaktiv dürfte an diesem Modell gerade für kleinere Firmen sein, dass damit die Notwendigkeit für ein SAN entfällt. Von Bedeutung ist das auch für die Desktop-Virtualisierung, weil dort das von den meisten Lösungen benötigte Shared Storage die Kosten in die Höhe treibt. Angesichts des relativ geringen Werts der dort anfallenden Daten (Windows-Images oder gar temporäre Dateien) reicht auch billigerer Speicher aus.

Die nötige Performance könnte über SMB 3 Multichannel erzielt werden, das mehrere parallele Pfade von einem Hyper-V-Server zu einer Netzfreigabe ermöglicht.

Besserer Support für Backup und Verschlüsselung

Auch hinsichtlich der Tools-Unterstützung ist Besserung in Sicht. So soll das Backup-Programm von Windows Server 2012 die Sicherung von CSV zulassen, auch die Verschlüsselung durch Bitlocker ist geplant, falls diese auf dem Server erforderlich ist.

Insgesamt sollen auch Werkzeuge von Drittanbietern besser mit CSV 2.0 zurecht kommen, weil es die unter Windows übliche Technik zum Einhängen solcher Volumes in das Dateisystem verwendet.