​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.

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 d​ie .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 ge​schrieben 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.

​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

ein weiterer Fehler in der Reihe unserer LiveMigration Errors mit der Event ID 21502.

Diesen Fehler habe ich bisher meist beim Update eines Windows Server 2012 R2 Failover Clusters auf einen Windows Server 2016 Failover Cluster gesehen, oder aber wenn ein Server unter 2016 neu installiert wurde.

Fehler bei der Livemigration von "Virtueller Computer "XXX"".

Fehler beim Migrationsvorgang für den virtuellen Computer "XXX" am Migrationsziel "Node1". (ID des virtuellen Computers: BA95E504-E33F-4EEB-94B0-B306A58B8D73)

Für den virtuellen Computer "XXX" werden prozessorspezifische Features verwendet, die auf dem physikalischen Computer "Node1" nicht unterstützt werden. Ändern Sie die Einstellungen des virtuellen Computers, um die vom virtuellen Computer verwendeten Prozessorfeatures zu beschränken, wenn Sie die Migration des virtuellen Computers zu physikalischen Computern mit anderen Prozessoren zulassen möchten. (ID des virtuellen Computers: "BA95E504-E33F-4EEB-94B0-B306A58B8D73")

Ergeignis ID 21502

Der Vorgang zum Verschieben von Clusterrolle "XXX" zum Ausgleichen konnte nicht abgeschlossen werden. Fehlercode: 0x80048016.

Als ich den Fehler zum ersten Mal gesehen habe, war ich ziemlich ratlos. Denn alle Clusterknoten hatten die selbe CPU, also woher kommen jetzt die Unterschiede. Mein erster Gedanke war, es doch mal mit der CPU Kompatibilität zu testen. Doch leider brachte dieser Test nicht den gewünschten Erfolg. Trotz der aktivierten CPU Kompatibilität konnte die VM nicht verschoben werden. Auf der Suche nach einer Lösung ist mir folgendes aufgefallen. Die Treiber Versionen der Prozessoren waren unterschiedlich.

Auf dem Server, zu dem die VM verschoben werden sollte war diese CPU Treiberversion installiert.

Auf dem Server, der die VM aktuell verwaltet, war eine neuere CPU Treiber Version installiert. Woher kommt nun die unterschiedliche Treiber Version. Es hat etwas gedauert, bis ich darauf gekommen bin, wir hatten zwar auf allen Servern, die Microsoft Patche installiert, aber ein Server war noch nicht neu gestartet worden und hatte somit noch den Original Treiberversionen der ISO .  

Wenn ihr die oben aufgeführte Fehlermeldung bekommt, dann überrüft am besten den Patchstand eurer Clusterknoten. Dies könnt ihr am schnellsten über die PowerShell machen.

$Nodes = (Get-Clusternode).Name

Get-HotFix -ComputerName $Nodes | sort HotFixID

In den Fällen, die ich bisher gesehen habe, waren entweder die Microsoft Patche nicht auf allen Knoten installiert oder aber, bei einen Knoten stand eben noch der Reboot aus.

Der Fehler tritt auch nur bei VMs auf, die auf dem Server mit dem neueren Patchstand, neu gestartet wurden. Denn diese haben durch den Neustart die neuen Processor Features geladen. Solche VMs müsst ihr leider herunterfahren und mit Hilfe der QuickMigration auf einen anderen Host verschieben. VMs die noch nicht neu gestartet wurden können problemlos verschoben werden.

Ich hoffe, ich konnte euch mit diesem kleinen Bericht aus der Praxis weiterhelfen.

Eure Petra

Live migration of <VMName> failed.

Virtual machine migration operation for <VMName> failed at migration destination <ServerName>. (Virtual machine ID <GuidIDderVM>.

The virtual machine <VMName> is unsing processor-specific features not supported on physical computer <ServerName>. To allow for migration of this virtual machine to physical computers with different processors. modify the virtual machine settings to limit the processor features used by the virtual machine. (Virtual machine ID <GuidIDderVM>

hier noch die deutsche Fehlermeldung:

Fehler bei der Livemigration von  <VMName>.

Fehler beim Migrationsvorgang für den virtuellen Computer <VMName> am Migrationsziel  <ServerName>. (ID des virtuellen Computers: <GuidIDderVM>)

Für den virtuellen Computer <VMName> werden prozessorspezifische Features verwendet, die auf dem physikalischen Computer <ServerName> nicht unterstützt werden. Ändern Sie die Einstellungen des virtuellen Computers, um die vom virtuellen Computer verwendeten Prozessorfeatures zu beschränken, wenn Sie die Migration des virtuellen Computers zu physikalischen Computern mit anderen Prozessoren zulassen möchten. (ID des virtuellen Computers: <GuidIDderVM>)

Nachdem wir die Bios Versionen auf dem zwei betroffenen Servern upgedaten hatten,  konnten wir die VMs ohne Probleme zwischen den vier Knoten des Failover Clusters hin und her vrschieben.

Ich hoffe, ich konnte euch auch mit diesem kurzen Blogbeitrag helfen.

Bis Bald und viel Erfolg

Petra

Wir haben in den vergangenen zwei Wochen mehrere Kundenanfragen erhalten, die mit massiven Performance Problemen zu kämpfen hatten, während sie ihren Storage Spaces Direct Cluster mit den Microsoft Patchen vom 12.01.2021 (KB4598230 für Windows Server 2019 oder KB4598242 für Windows Server 2016) aktualisierten.

Unsere Kunden berichteten von abgestürzen VMs und einem nicht mehr zu administrierenden Storage Spaces Direct Cluster. Die Problematik wird mit jedem Clusterknoten der gepatcht wurde schlimmer, die Repairjobs laufen oft stunden bis tagelang.  Am Ende hilft meist nur das Herunterfahren der VMs, damit der Cluster seine Repairjobs abarbeiten kann und sich das Ganze wieder etwas beruhigt. Nachdem alle Storagejobs abgearbeitet wurden, läuft der Storage Spaces Cluster wieder normal und performant.

In machen Fällen hat es etwas gebracht, wenn der Clusterdienst vor dem Neustart der Knoten auf "disabled" gesetzt wurde und nachdem der Knoten das Update verarbeitet hatte und wieder zur Anmeldung bereit steht, kann der Clusterdienst wieder auf "automatisch" gestetzt und gestartet werden.

Sobald wir neue Erkenntisse zu der Problematik haben, werde ich euch diese an dieser Stelle mitteilen.

Weiterhin viel Erfolg

Carsten und Bernhard Frank waren mal wieder fleißig und haben für euch eine Videoserie zum Thema Azure Virtual Desktop auf Basis von Azure Stack HCI erstellt. Viel geballtes Wissen von den Profis.

Ich habe euch die Videos hier zusammen gestellt und kann euch jetzt nur noch viel Spaß beim schauen und lernen wünschen.

Habt ihr Fragen oder Probleme rund um die Themen Hyper-V, Failover Cluster, Storage Spaces Direct und Azure Stack HCI, so könnt ihr euch gerne an uns wenden. Wir bereaten und unterstützen euch gerne bei Sizing- und Hardwarefragen und im Anschluss bei der Implementierung eurer Projekte. Wir verkaufen selbst keine Hardware, daher können wir euch ehrlich und aus der Erfahrung vieler Installationen im Hyper-V Umfeld sagen, was ihr beim Hardwarekauf beachten müsst. Habt ihr Interesse euer Wissen zu vertiefen oder aufzufrischen, kann ich euch nur die Powerkurse von Carsten ans Herz legen.

Weiterhin viel Erfolg

Bernhard Frank und Carsten zeigen euch in der folgenden Videoserie, wie ihr ein Azure Stack HCI Stretched Cluster aufbauen könnt und was dabei alles zu beachten ist. Es gibt geballtes Wissen und viele Tipps. Viel Spaß beim Schauen.

Habt ihr Fragen oder Probleme rund um die Themen Hyper-V, Failover Cluster, Storage Spaces Direct und Azure Stack HCI, so könnt ihr euch gerne an uns wenden. Wir bereaten und unterstützen euch gerne bei Sizing- und Hardwarefragen und im Anschluss bei der Implementierung eurer Projekte. Wir verkaufen selbst keine Hardware, daher können wir euch ehrlich und aus der Erfahrung vieler Installationen im Hyper-V Umfeld sagen, was ihr beim Hardwarekauf beachten müsst. Habt ihr Interesse euer Wissen zu vertiefen oder aufzufrischen, kann ich euch die Powerkurse von Carsten ans Herz legen.

Weiterhin viel Erfolg