Performance Probleme: Hyper-V Cluster mit SAN Storage und CSVs mit ReFS formatiert
immer wieder bekommen wir Anfragen von Kunden, die über Performance Problemen bei ihrem Hyper-V Failover Clusters klagen. Es handelt sich hierbei um Hyper-V Failover Cluster die mit einem iSCSI oder Fibre Channel SAN verbunden sind.
Bei der Fehlersuche ist mir aufgefallen, dass die CSVs in den Hyper-V Failover Cluster mit ReFS formatiert wurden. ReFS als Dateisystem ist für ein CSV das an ein SAN angeschlossen ist NICHT supported. Warum das so ist und welche Effekte dabei zu beobachten sind, das möchte ich euch in diesem Blog aufzeigen.
In den Microsoft Docs findet ihr die unterstützen Umgebungen, dazu zählen
- Storage Spaces Direct
- Storage Spaces
- Backup target
- Basic Disks
Der große Unterschied zwischen ReFS und NTFS Format bei einem CSV sind der Kommunikationsweg, den die Änderungsdaten aus der VM zu dem darunterliegenden Storage zurücklegen. Was ist damit gemeint?
Im ersten Beispiel ist das CSV mit NTFS formatiert.
Das CSV wird von Hyper-V Host1 verwaltet, die VM1 wird von Hyper-V Host2 verwaltet. Änderungen in der VM1 können vom Hyper-V Host2 direkt in die .vhdx Datei der VM1 gespeichert werden und landen so über Fibre Chanel oder iSCSI auf dem darunter liegenden Storage.
Im zweiten Beispiel ist das CSV mit ReFS formatiert.
das CSV wird wieder von Hyper-V Host1 verwaltet, unsere VM1 wird durch den Hyper-V Host2 verwaltet. Bei ReFS Formatierung können Änderungen nicht direkt durch den Hyper-V Host2 in die .vhdx Datei der VM1 geschrieben werden. Der Hyper-V Host2 muss die Änderungen an den Hyper-V Host1 senden und dieser schreibt dann die Daten auf das CSV. Dieses Verhalten wird Redirected Mode genannt.
Im Storage Spaces Direct Cluster spielt der Redirected Mode keine Rolle, da wir hier für die Kommunikation zwischen den Clusterknoten performante Netzwerkverbindungen zur Verfügung haben.
Genau dieser Redirected Mode kann im Hyper-V Failover Cluster mit Fibre Channel oder iSCSI Storage zu erheblichen Performance Problemen führen, wenn die VMs durch andere Hyper-V Hosts wie das CSV verwaltet werden. Denn die Daten werden über die zur Verfügung stehenden Clusternetzwerke an den Owner Node des CSVs gesendet. Wie sich das bei 1 Gbit Netzwerken zwischen den Hyper-V Hosts auswirken kann, möchte ich euch an einen Beispiel aus der Praxis zeigen.
Beispiel aus der Praxis
Unser Kunde hat einen zwei Knoten Hyper-V Cluster mit direkt angeschlossenem NetApp Storage. Die Clusterknoten sind für die Livemigration mit einen Windows Team (LBFO Team) aus zwei x 1Gbit NICs verbunden. Das CSV wurde mit ReFS formatiert. Das könnt ihr mit dem PowerShell Befehl
Get-Volume
feststellen.
Der Kunde hat nun Tests mit dem Tool "CrystalDiskMark" durchgeführt.
Im ersten Testlauf wurden Daten direkt von dem Hyper-V Host der das CSV als Owner verwaltet auf "C:\ClusterStorage\Volume1" geschrieben. Also in den Mountpoint für das CSV.
Wir sehen, es gehen kaum Daten über das Netzwerk und wir können mit einer Geschwindigkeit von ca. 6 GBit/s auf das Storage schreiben und Lesen. Wir greifen hier eindeutig über Fibre Channel auf das Storage zu.
Für den nächsten Testlauf haben wir das CSV auf den zweiten Hyper-V Host verschoben und führen den Test wieder auf "C:\ClusterStorage\Volume1" aus.
Jetzt können wir sehen, dass während des Lesens und Schreibens ca. 2 GBit an Daten über die Netzwerkkarte gesendet wurden. Das zeigt uns, dass der Hyper-V Host, der nicht Owner des CSVs ist, die Änderungsdaten über das Netzwerk an den Ownernode sendet und nicht direkt über Fibre Channel auf das Storage zugreifen kann.
Um den Redirected Mode bei Hyper-V Cluster mit SAN Storage zu vermeiden, müssen die CSVs mit NTFS formatiert werden.
Ich hoffe ich konnte euch mit diesem Blogpost bei der Suche nach Problemlösungen helfen.
Bis zum nächsten Mal
Eure Petra
