Hyper-V Cluster über iSCSI Target langsam

[Doso 77]

Ich habe aus drei alten Servern einen Hyper-V Cluster zum testen gebaut. Alle Server sind 2012R2, auf einem Server ist das Microsoft iSCSI Target konfiguriert was für den Cluster den Speicher zur Verfügung stellt. Die Hyper-V Hosts greifen dann mittels MPIO und iSCSI zu. Leider ist die ganze Sache sehr träge. VMs fahren vernünftig hoch, nur reagieren sie danach sehr zäh. Der Aufruf von z.B. Startmenü gefolgt von Aufruf der Kommandozeile dauert manchmal eine Minute. Speicher haben die Server genug, die CPU Auslastung auf den Hosts bewegt sich gegen null. Das Speicher-Netzwerk sollte mit 2x 1GBe eigenen Netzwerkkarten auch genug Power haben. 

 

Die drei Server waren vorher ein Backup System und 2 produktive Hyper-V Server. Daher kann ich eigentlich ausschließen das die Hardware zu lahm ist. Jemand eine Idee wie ich der Langsamkeit auf die Schliche kommen kann? Mir gehen irgendwie die Ideen aus. So macht das testen von neuen System leider irgendwie keinen Spaß :(

[NilsK 2.957]

Moin,

 

wie sieht denn die Netzwerkverbindung zwischen den Hosts und dem Target genau aus?

 

Und was für Disks laufen da in welcher Konfiguration?

 

Gruß, Nils

[Dunkelmann 96]

Moin,

 

sind Jumbo Frames auf Host, Switch und Target aktiv? Testen kannst Du z.Bsp. mit 'ping [target] -l 8000 -f'

 

Ist MPIO auch konfiguriert? Installieren alleine reicht nicht.

http://blogs.technet.com/b/keithmayer/archive/2013/03/12/speaking-iscsi-with-windows-server-2012-and-hyper-v.aspx

[Lian 2.436]

Ich habe aus drei alten Servern einen Hyper-V Cluster zum testen gebaut.

 

Wie alt sind die Server, was steckt für eine Hardware dahinter?

[Necron 71]

auf einem Server ist das Microsoft iSCSI Target konfiguriert was für den Cluster den Speicher zur Verfügung stellt.

Hi,

 

auf was für einem Disksystem legt den das iSCSI Target seine LUNs, die übrigens VHDX Container sind, ab?

[NilsK 2.957]

Hm,

 

viermal derselbe Fragetyp, aber nach zwei Tagen keine Antwort. Scheint also nicht so dringend zu sein.

 

Gruß, Nils

[Necron 71]

Hm,

 

viermal derselbe Fragetyp, aber nach zwei Tagen keine Antwort. Scheint also nicht so dringend zu sein.

 

Gruß, Nils

Hast recht. :D Handelt sich ja um eine Testumgebung, daher gehe ich mal davon aus, dass es nicht so dringend ist. ;)

[Doso 77]

Hardware

Das sind alles Fujitsu Primergy RX300S4 mit zwei Intel Xeon CPUs. Insgesamt jeweils 4 1GBe Netzwerkports, 2 für VM Netzwerke, 2 für Storage iSCSI Netzwerk. LSI Megaraid 5/6 Hardware Controller mit BBU.

 

Festplatten

Alle drei Server haben 6 Festplatten, davon einmal Hot-Spare, restliche 5 Platten als RAID-5. Auf dem RAID-Controller sind Einstellungen für hohe Performance gesetzt, also Write-Back, Apdative Read, Cache an. In den Hyper-V Hosts sind lokale SAS Platten, da liegt aber nur das Betriebssystem drauf. Auf dem iSCSI Target sind es 7.2K SATA Platten. Zugegeben, vermutlich nicht die schnellsten Teile, aber die sind halt recht groß.

 

Storage Netzwerk

Das Storage Netzwerk läuft über einen HP Procurve 1810G. Die beiden Storage Netze sind durch VLANs voneinander getrennt.  Klar wären 2 seperate Switches besser, aber für eine Testumgebung sollte es auch so gehen. Jumbo Frames sind nirgends aktiviert da wir diese nicht verwenden. Anbindung mit MPIO Round Robin, entsprechend die Pfade auf den Hyper-V Servern definiert. Ich sehe das auch beide NICs bei Übertragungen beschäftigt werden, das Failover klappt auch wenn ich testweise Netzwerkkabel ziehe.

 

iSCSI Target

Es gibt drei Targets, eine 2.4 TB VHDx als Speicher für die VMS, eine 1GB Test-CSV damit ich die Cluster Überprüfung durchlaufen lassen kann und eine 1GB Disk für das Quorum (Disk Wirness). Ich sehe in den Eigenschaften der iSCSI Targets das beide Hyper-V Hosts verbunden sind.

 

Cluster

CSV-Cache ist angeschaltet und mit 1024MB konfiguriert. Die Cluster Überprüfung liefert keine Fehler, nur ein paar Warnungen das z.B. einige VMs ausgeschaltet sind - also nix besonderes. Cluster funktioniert soweit Einwandfrei, Live Migration etc. alles kein Problem. Ausser halt das die Reaktionszeiten der VMs teilweise unterirdisch sind.

 

Jemand Ideen?

[DocData 85]

Ja, mehr Platten und schnelle Platten. Da bringen dir auch Jumbo Frames nichts mehr. Jumbo Frames sind im übrigend kein Allerheilmittel und ich würde sie heute nicht mal mehr als Best Practice bezeichnen, wenn überhaupt ein Common Practice. Dumm nur, dass viele IOs < 9000 Byte sind und in vielen Fällen (wenn wir von echtem IO ausgehen und nicht irgendwelcher Benchmarkkram) der Vorteil von Jumbo Frames nicht gehoben werden kann.

 

Aber um es noch mal ganz konkret zu sagen: Mehr und schnellere Platten. Der Rest ist nur Kosmetik.

[NeMiX 76]

Von wievielen VMs reden wir überhaupt und tritt das ganze schon auf wenn nur eine VM läuft?

[NilsK 2.957]

Moin,

 

hm. Die bislang gegebenen Hinweise sind sicher richtig. Für eine Laborumgebung ohne Last erklären sie aber trotzdem das beschriebene Verhalten nicht.

 

Erfahrungsgemäß sollte ein Labor mit der gegebenen Ausstattung durchaus flüssig laufen. Ich selbst habe hier ein lokales Labor auf meinem Notebook, in dem keine der VMs so zäh läuft, wie du es beschreibst. Und ich habe nur eine einzige Platte, bislang war es sogar nur eine Notebook-SATA-Disk. Noch dazu läuft Hyper-V bei mir in "Nested Virtualization", also selbst als VM.

 

Ich vermute also, dass in deinem Labor noch irgendwas Weiteres faul ist. Einen heißen Tipp habe ich ohne nähere Analyse aber leider nicht.

 

Gruß, Nils

 

EDIT: Tippfehler korrigiert.

bearbeitet 1. Dezember 2014 von NilsK

[Dunkelmann 96]

Der HP Switch ist ein 'store and forward' und damit nicht wirklich für iSCSI geeignet. In einer kleinen Umgebung könnte es noch gerade so gehen.

 

Zu den HDD: schom Mal an RAID0 über alle 6 Platten gedacht? Ist ja nur eine Testumgebung

[Doso 77]

Der HP Switch ist ein 'store and forward' und damit nicht wirklich für iSCSI geeignet. In einer kleinen Umgebung könnte es noch gerade so gehen.

 

Uhm. Woran erkennt man sowas und was bewirkt es? Wir haben diese Switches auch in unserem produktiven Hyper-V Cluster im Einsatz, immerhin 6 Nodes und 60 VMs.

[Dunkelmann 96]

Uhm. Woran erkennt man sowas und was bewirkt es?

So etwas steht im Handbuch oder man löchert den Vertriebler.

 

 

Besonders nachteilig für den Einsatz im Speichernetz können aber auch ungeeignete Ethernet-Switches sein, die im Store and Forward-Modus laufen und daher erheblich höhere Latenzen als FC-Switches verursachen

http://de.wikipedia.org/wiki/ISCSI

 

 

Wir haben diese Switches auch in unserem produktiven Hyper-V Cluster im Einsatz, immerhin 6 Nodes und 60 VMs.

Ist eine kleine Umgebung, da fällt es vielleicht noch nicht ins Gewicht.

Beim nächsten Hardwarezyklus würde ich trotzdem über ein Upgrade nachdenken - ein Small Business Switch hat mMn nichts im iSCSI verloren.

[Doso 77]

Kleines Update hierzu. Ich habe nun das iSCSI Target von Windows Server 2012R2 deinstalliert und durch die freie Version von Starwind Virtual San ersetzt. Diese Software hat auch die Möglichkeit Schreibzugriffe im Arbeitsspeicher zu cachen. Der iSCSI Server hat 16 GB, habe ich halt mal 10GB für den Cache reserviert. Die Reaktionszeiten der VMs ist dadurch um Welten besser. Natürlich auf Grund der SATA Platten jetzt immer noch nicht perfekt, aber für Testzwecke tut es das alle mal. Das iSCSI Target von Microsoft scheint einfach viel zu lahm zu sein.