Hyper-V: Cluster Shared Volumes anlegen und konfigurieren

Hyper-V-Cluster oder ein Dateisystem wie CSV sind jedoch keine zwingende Voraussetzung für eine Live Migration. VMs lassen sich auch von einzelnen Hosts ohne Shared Storage unterbrechungsfrei migrieren, allerdings werden dann nicht nur die RAM-Inhalte übertragen, sondern mit einem größeren Zeitfenster auch die virtuellen Laufwerke.

Damit virtuelle Maschinen zentral auf einer LUN für alle Knoten ansprechbar sind, kann man Cluster-Datenträger in Cluster Shared Volumes konvertieren. Sie müssen entweder mit NTFS formatiert sein, oder seit Windows Server 2012 R2 wird auch ReFS (Resilient File System) für CSV unterstützt. Nach Abschluss des Vorgangs wechselt ihre Bezeichnung in CSVFS, um unter anderem Applikationen zu verdeutlichen, dass es sich um ein CSV handelt.

Als Storage-Systeme kommen dafür nicht nur blockorientierte Speicher wie iSCSI-Targets in Frage, sondern auch Scale-out File-Server unter Windows 2012 (R2) im Zusammenspiel mit Storage Spaces. Microsoft positioniert diese Kombination als File-basierte Alternative zu SANs, wobei man es hier nicht mit LUNs, sondern mit virtuellen Datenträgern zu tun hat. ReFS ist in dieser Konstellation nicht als Basis für CSV zulässig. Cluster Shared Volumes im ReFS Format sind jedoch möglich in Storage Spaces Direct des Windows Server 2016.

CSV erstellen im Failovercluster-Manager

In der deutschen GUI des Failovercluster-Managers wurde diese Funktion mit Zu freigegebenen Clustervolumes hinzufügen übersetzt und ist über den Punkt Speicher => Datenträger und Rechtsklick auf die entsprechende LUN auswählbar.

Auch ein Rückkonvertieren ohne Datenverluste ist mit dem Failovercluster-Manager über das Kontextmenü des CSV möglich.

Nachdem der Datenträger in ein CSV konvertiert wurde, wird auf allen Knoten unter C:\ClusterStorage (%SystemDrive%\ClusterStorage) die LUN abgebildet. CSV verringern somit die Anzahl der erforderlichen LUNs für Failover-Clustering und benötigen keine Laufwerksbuchstaben. Die darin enthaltenen Volumes mit Namen Volume(x) können zu Beginn auch umbenannt werden.

Bei einem Zwei-Knoten-Cluster unter Windows Server 2012 empfiehlt es sich, pro Knoten ein CSV bereitzustellen, um unter anderem auch die Last der Zugriffsverwaltung auszugleichen. Windows Server 2012 R2 verteilt die Rolle des CSV Coordinator, also dem schreibberechtigten Besitzerknoten für Metadaten, automatisch über die CSV.

Wenn man ermitteln möchte, welcher Cluster-Knoten als Koordinator fungiert, kann man dies auch über das PowerShell-Cmdlet Get-ClusterSharedVolume herausfinden.

Aktivieren und anpassen des CSV-Cache

Der CSV Block Cache erhöht den lesenden Zugriff auf gleiche Blöcke und somit die IOPS in Hyper-V um ein Vielfaches. In Windows Server 2012 ist er standardmäßig nicht aktiviert, wohingegen er in Windows Server 2012 R2 und 2016 für jedes CSV eingeschaltet ist. Dort muss jedoch seine Größe konfiguriert werden. Der Cache nutzt den physischen Arbeits­speicher und ein empfohlener Wert für Hyper-V-CSVs liegt bei 512 MB. Der Ausgangswert für einen Server 2012 R2/2016 liegt bei null.

Unter Windows Server 2012 R2 und 2016 konfiguriert man die Größe des Cache über PowerShell folgendermaßen:

(Get-Cluster).BlockCacheSize = 512

Auf einem Windows Server 2012 aktiviert man den Cache zuerst mit diesem Kommando:

Get-ClusterSharedVolume "Cluster Disk 1" | Set-ClusterParameter CsvEnableBlockCache 1

Anschließend teilt man dem Cache den gewünschten Speicher zu:

(Get-Cluster).SharedVolumeBlockCacheSizeInMB = 512

Bei Windows Server 2012 müssen die CSV-Datenträger offline und wieder online geschaltet werden, nachdem der Cache eingeschaltet wurde. Für 2012 R2 und 2016 ist dies nicht erforderlich und mögliche Downtime entfällt.

Erweiterte CSV Diagnose

Das neue Cmdlet Get-ClusterSharedVolumeState dient dazu, den genauen Status von Cluster Shared Volumes anzuzeigen. Es können verschiedene Zustände und die Gründe dafür pro Server ermittelt werden: Direct, File System Redirected und Block Redirected.

Im obigen Beispiel wurde der umgeleitete Zugriff manuell über das Kontextmenü im unteren Bereich des Failovercluster-Managers im CSV herbeigeführt. Der Grund wird somit als UserRequest ausgegeben, welcher sich in diesem Fall auch über die GUI erkennen lässt. In anderen Fällen lässt sich über die GUI nicht feststellen, ob sich der Knoten in einem Redirected Mode befindet.