cat-failover-cluster

How-To: Verwaltung eines Cluster Shared Volume (CSV)

FAILOVER CLUSTER

Mit Windows Server 2008 R2 wurde für Hyper-V das Cluster Shared Volume (CSV) eingeführt. Im Artikel “Einblicke in Cluster Shared Volume (CSV)” wurde bereits detailliert darüber berichtet. Mit Cluster Shared Volume (CSV) nimmt allerdings nicht nur die Flexibilität, sondern auch die Komplexität eines Hyper-V Failover Cluster zu. Da durch den Einsatz von “Direct IO” gleichzeitig mehrere Hyper-V Hosts auf das gleiche LUN Zugriff haben, muss für den optimalen Betrieb eine perfekte Ausgangslage bezüglich Storage geschaffen werden. Aber auch das Cluster Network spielt eine wesentliche Rolle in dieser Architektur.

Da Aufgaben aus dem “Daily Business” bei Cluster Shared Volumes oftmals ein wenig anders durchgeführt werden, werden im nachfolgenden Artikel die wichtigsten Punkte näher erläutert.

Volume

Virtual Hard Disks (VHDs) arbeiten ausschliesslich mit NTFS Volumes. Wie auch bei Exchange und SQL Server wo ebenfalls mit sehr grossen Dateien gearbeitet wird, ist auch bei Cluster Shared Volume empfohlen die Allocation Unit Size auf 64 Kilobytes zu setzen. Da CSV auf NTFS aufbaut, gelten hier auch 1:1 dieselben Limiten. Das heisst es können LUN’s mit einer maximalen grösse von 256 Terabytes verwendet werden. Eine Limitierung der Anzahl Virtual Machines pro CSV Volume gibt es nicht – dies richtet sich ganz und gar nach der Leistung und Empfehlung der Hersteller. Jeder Storage Hersteller hat spezifische Angaben und Empfehlungen (Best Practices). Diese sollte nach Möglichkeit auch berücksichtigt und befolgt werden. Im Vergleich zu VMware sehen die Limiten wie folgt aus:

Komponente VMware (VMFS) Hyper-V (CSV)
Maximale Volume Grösse 2 TB 256 TB
Minimale Volume Grösse 1,2 GB 1 MB
Maximale Anzahl Partitionen 128 128
Maximale Anzahl Files pro Volume ~30’000 +4 Mrd.
Maximale Anzahl VMs pro Volume 256 Unlimitiert
Empfohlene Anzahl VMs pro Volume 40 Unlimitiert

Um Network und Storage I/O auf alle Cluster Nodes zu verteilen, wird automatisch der Host mit den wenigsten CSV Volumes als Coordinator Node konfiguriert. Daher wird es auch empfohlen, die Last auf mehrere CSV Volumes zu verteilen. Als Beispiel sollte bei einem Zwei-Node Cluster mindestens zwei CSV Volumes eingesetzt werden. Somit wird jeder Host als Owner für ein LUN eingesetzt und die Last von Network und Storage gleichmässig verteilt. Typische Aktionen für welche der Coordinator Node kontaktiert wird sind unter anderem, VM anlegen / löschen, VM power on / off, Snapshots, Live Migration, Dynamic VHDs.

Network

Die Kommunikation mit dem Coordinator Node für Änderungen an einem CSV Volume erfolgt über ein dediziertes Cluster Netzwerk. Der Failover Cluster wählt automatisch das Netzwerk welches am besten für die CSV Kommunikation geeignet erscheint. Mit geladenen Failover Cluster PowerShell Modules (PS> Import-Module FailoverClusters) kann die aktuelle Konfiguration angezeigt werden: PS> Get-ClusterNetwork | ft Name, Metric, AutoMetric, Role

Das Netzwerk mit der tiefsten Metric definiert jeweils das Netzwerk welches für CSV und die Cluster Kommunikation (Heartbeat) genutzt wird. Für Live Migration wird jeweils das Netzwerk mit dem zweit tiefsten Wert verwendet. Eine Anpassung dieser Metric und somit die Anpassung des CSV Netzwerk kann nur in PowerShell durchgeführt werden. Im nachfolgenden Beispiel wird die Metric für Private (aka Cluster Network 2) angepasst: PS> ( Get-ClusterNetwork "Private" ).Metric = 900

Ein performantes Netzwerk für CSV ist entscheidend wenn VSS Backups, oder eine Defragmentation des CSV Volume durchgeführt wird. Bei Fehler eines Host Bus Adapter (HBA) kann es ebenfalls zu Fehlermeldungen kommen:

Cluster Shared Volume ‘Volume1′ (hst-hyperv01′) is no longer directly accessible from this cluster node. I/O access will be redirected to the storage device over the network through the node that owns the volume. This may result in degraded performance. If redirected access is turned on for this volume, please turn it off. If redirected access is turned off, please troubleshoot this node’s connectivity to the storage device and I/O will resume to a healthy state once connectivity to the storage device is reestablished.

Eine Konfiguration mit mindestens vier Network Adapter wird empfohlen – ausgenommen Adapter welche für den Storage Zugriff benötigt werden. Wenn nicht genügend Network Adapter zur Verfügung stehen, so sollte mit “Policy-based QoS” die Bandbreite im Voraus definiert werden. Für Live Migration sollten mindestens 40-50% eines 1Gbps Adapters zur Verfügung stehen. Best Practices zu den jeweiligen Konfigurationen gibt es im TechNet Artikel Hyper-V: Live Migration Network Configuration Guide.

De- / Fragmentation

Aus verschiedenen Gründen ist das Problem der Fragmentierung bei der Virtualisierung eine besondere Herausforderung. Denn sowohl Hosts, als auch Guests sind von der Fragmentierung betroffen. Der Vorteil der hochgelobten Konsolidierung wirkt sich daher schnell zu einem Nachteil aus, denn das Storage Subsystem respektive die I/O Leistungen wird somit mehrfach verschlechtert.

Besonders VHDs welche auf dynamisches Wachstum (dynamically expanding) ausgelegt sind und Snapshots haben Einfluss auf die Fragmentierung. Zu benken ist auch dass nicht mehr benötigter Speicherplatz nicht wieder automatisch freigegeben wird, wenn eine Applikation diesen nicht mehr benötigen sollte. Um den Einfluss auf die Geschwindigkeit durch Fragmentierung zu minimieren, sollten ausschliesslich Virtual Hard Disks (VHDs) mit einer fix zugewiesenen Grösse (fixed size) eingesetzt werden. Ebenfalls sollte ein physikalisches Volume vor der Verwendung neu formatiert werden.

Wie bei herkömmlichen Volumes kann auch CSV defragmentiert werden. Die Herausforderung stellt sich allerdings, da mehrere Hosts gleichzeitig Dateien im Zugriff haben (locked / pinned), kann die Defragmentation nicht einfach so ausgeführt werden. Damit die der Vorgang nicht fehlschlägt, gibt es zwei Szenarien:

  • Redirected Access – Nur der Coordinator Host kann noch auf das LUN zugreifen. Alle anderen Hosts senden ihre I/O als SMB2 über das CSV Netzwerk. Redirected Access wird übrigens auch bei VSS Backups verwendet.
  • Maintenance Mode – Das CSV wird hier als Cluster Storage entfernt und die jeweiligen Virtual Machines werden gestoppt. Sämtliche Virtual Machines müssen nach dem Vorgang manuell gestartet werden.

Das Repair- cmdlet von FailoverCluster führt sämtliche Aktionen selbständig aus. Das CSV Volume wird auf den Node verschoben wo das cmdlet ausgeführt wird und anschliessend in den Maintenance Mode versetzt. Je nach Bedarf kann dann –Defrag oder -ChkDsk ausgeführt werden. Mit geladenen Failover Cluster PowerShell Modules (PS> Import-Module FailoverClusters) kann folgendes cmdlet für die Defragmentation gestartet werden: PS> Repair-ClusterSharedVolume C:\ClusterStorage\Volume1 -Defrag

Bevor die Defragmentation startet, wird eine Analyse erstellt. Zu diesem Zeitpunkt ist das CSV Volume im “Redirected Access” Modus. Die Defragmentation wird auch nur dann durchgeführt wenn dies auch erforderlich sein sollte.

Disk Space

Ein weiterer wichtiger Punkt ist die Auslastung der einzelnen CSV Volumes. Gerade beim Einsatz von dynamically expanding Disks und / oder Snapshots muss die aktuelle Auslastung regelmässig überprüft werden. In der Failover Cluster Management Console oder mit den PowerShell Modules kann dies einfach realisiert werden:

  • Failover Cluster Manager – In der Management Console die verfügbaren Volumes anzeigen
  • Failover Cluster PowerShell – Für PowerShell gibt es auch einen Befehl um die aktuelle Auslastung anzuzeigen welcher out-of-the-Box mitgeliefert wird : PS> Get-ClusterSharedVolume "Volume1" | fc *. Allerdings ist die Auswertung und Automatisierung eher umständlich… Für eine einfachere Darstellung hat das Failover Cluster Team daher ein PowerShell Script bereitgstellt (unsupported).
  • Eine Abfrage für die Disk Kapazität kann natürlich auch über ein WMI Objekt gemacht werden: PS> Get-WmiObject win32_volume | where-object {$_.Label -eq "Volume01"} | ft Label,Capacity,FreeSpace

Weitere Informationen

Failover Cluster , Hyper-V

, , ,

About the Author

Michel Luescher ist bei Microsoft Corporation als Architect im Center of Excellence (CoE) für Modern Datacenter tätig. Als technischer Berater fokussiert er sich auf die Planung und Umsetzung von Projekten mit dem Fokus auf Microsoft Cloud Lösungen für Datacenter im Enterprise und Service Provider Umfeld. { Hyper-V + System Center + Windows Azure = Your Cloud }.

Comments (1)

  • Christian says:

    Hallo,
    ich habe ein neues Volume formatiert (64k Blocksize, NTFS) und dem Cluster hinzugefügt. Wenn ich jetzt eine kleine Textdatei anlege, die >0kb hat, wird mir angezeigt, dass die Datei auf dem Datenträger “nur” 4kb hat. normalerweise sollte da eigentlich dann 64kb stehen wenn die Blockgröße richtig verwendet wird. Meine Systempartition hat eine Blockgröße von 4kb (win-standard). hängt es damit zusammen, dass nach dem einbinden in den ClusterShareVolume-Ordner die eigentliche Blocksize von 64kb ignoriert wird??

     

Hinterlasse eine Antwort.

Removable Virtual Hard Disk, Bug oder by Design? How-To: Mit WMI ein Network Adapter auf Server Core aktivieren