Server 2012 R2 miese Performance unter ESXi 5.5.0U2

[illumina7]

Hi Ihr,

hab einige Probleme in der Konstellation ESXi und Server 2012R2, vlt. hat jemand von euch den ein oder anderen Tipp.

Kurz zur Hardware des Servers:
Wortmann Terra 7430 G1
Server ist VMWare zertifiziert
Mainboard: Intel S2600CP4
CPU: 2x Xeon E5-2620v2
RAM: 8x 8GB PC1600 ECC Samsung
Raid: LSI MegaRaid 9271-8i mit BBU
HDD: 8x Seagate ST3600057SS/15k SAS in einem Raid10; ein Array, auf dem alle VMs laufen
Mainboard und LSI Firmware auf den letzten Stand.

OS: VMWare ESXi 5.5.0 U2 Build 2068190
Gäste: 4x MS Server 2012 R2 Standard, aktueller Patchlevel
- 1x DC, DNS, DHCP, Printserver (1 vCPU, 4GB Ram)
- 1x MS SQL Server, Fileserver (4 vCPU, 20GB Ram)
- 1x WTS, 6 User (4 vCPU, 16GB Ram)
- 1x MDaemon Mail-Server (1 vCPU, 4GB Ram)

Fehlerbild:
Windows VMs laufen extrem träge, so startet z.B. die Warenwirtschaftsoftware (Streitv.1) innerhalb von ~30s auf dem Terminalserver, laut Softwarehaus wären ca. 2-5s normal. Auch das Arbeiten in der Software selbst (läd von der SQL-DB auf einer anderen Maschine) ist mit viel Wartezeiten und langsamen Bildaufbau verbunden, teilweise bis zu 1min, beim wechseln der Registerkarten. Outlook 2013 braucht fast 3min zum starten (alle Plugins deaktiviert), wenn man z.B. auf freigegebene Kalender klickt, dauert das bis zu 10min pro(!) Kalender, währendessen ist das Outlook nicht bedienbar und die Performance für alle RDP-User im Keller. Wir verwenden komplett GBit Netzwerk mit Cat. 7 Verkabelung, Server verwendet 3 NICs im Lastenausgleich, alle Clients haben GBit.
Weder die einzelnen Windows-VMs, noch der ESXi selbst haben eine nennenswerte Auslastung. IdR liegt die pro VM bei max. 10%, unter ESXi eher bei 2-5%, mit einigen "Spitzen" auf ~15%. Der ESXi swappt nicht.
Dateikopiervorgänge von einer VM auf die andere liegen so bei 150-200 MB/s.
Entpacken einer kleinen Zip-File (7zip u/o WinRAR) dauert schon mal bis zu 60min!
MS SQL Benchmarks (von Streit durchgeführt) liefern doppelt so hohe Werte, als für ein ordentliches Arbeiten notwendig wären.
In-Guest HDD Benchmarks liefern auch durchweg gute Werte (IO und r/w).


Was wurde getan:
- Logfiles von Wortmann ausgewertet -> HW ok
- Logfiles jeweils an Intel und LSI weitergeschickt und ausgewertet -> HW ok
- VMWare Ticket erstellt, kompletter Host geprüft -> keine (Konfigurations-)Fehler feststellbar
- ESXi in verschiedenen Versionen -> absolut keine Unterschiede
- Zusätzliche NIC gesteckt -> kein Unterschied, wieder entfernt
- Extra Switch, nur Server und 1 Client -> kein Unterschied, wieder rückgängig
- TCP4/6 Offload deaktiviert -> kein Unterschied, atm noch deaktiviert
- RSS aktiviert -> kein Unterschied, atm noch aktiv
- Virenscanner (Kaspersky Endpoint Security) deinstalliert (Ausnahmen schon definiert) -> kein Unterschied, wieder installiert
- Auf einem Client Outlook und Streit lokal installiert (i7-3770k, 16GB Ram, 250 Intel SSD, GBit) -> gleiche Symptome wie der
WTS -> zurück in die Terminalsitzung gewechselt.
- ESXi Host und ALLE VMs neu aufgesetzt -> exakt das gleiche Verhalten
- Auf Kulanz wurde von Wortmann die komplette Hardware getauscht -> ESXi und VMs umgezogen -> gleiches Verhalten
- Sämtliche KB Artikel von MS und VMWare abgearbeitet -> nichts brachte IRGENDWAS
- vCPUs reduziert (Overprovisionierung) -> kein Unterschied, allerdings läuft der WTS mit 3 und weniger vCPUs so gut wie
garnicht, obwohl keine Last auf den vCores ist, nach oben machts keinen Unterschied
- VMWare Tools x-mal reinstalliert (auch clean etc.)
- evtl. habe ich auch noch etwas vergessen zu erwähnen, auf Nachfrage fällt mir das bestimmt ein.


Inzwischen bin ich ratlos, wo man da noch ansetzen soll, vielleicht seh ich auch den Wald vor lauter Bäumen nicht mehr?

Danke und Gruß
illumina7

 

[konfetti]

Hast Du Dir die Resourcenmonitore in dem VMs mal angeschaut? - die zeigen ja eigentlich ganz gut, wo der Flaschenhals liegen könnte.
RAID10 ? - warum? - Wäre ein RAID5 mit HotSpare nicht Sinniger gewesen? - SSD-Cache?

Wäre mal so meine Idee

 

[illumina7]

Ein reines Raid 5 erscheint mir zu langsam, auch da sich der SQL Server mit auf dem Array befindet. Was ich evtl. noch probieren möchte: Raid10 aus 4 HDDs für SQL Server und Raid5+Hotspare für die anderen drei Maschinen.
Leider zeigen die Ressourcenmonitore genau garnichts, bzw. kaum Last der einzelnen VMs (was sich mit der Anzeige des ESXi deckt).
SSD-Cache -> nein, dafür aber das Caching des LSI aktiviert (mit BBU).

Gruß

 

[TurboCharged]

Also damit Du wirklich den Unterschied zwischen Raid5 und Raid10 im DB Umfeld merkst, muss die DB auch richtig unter Feuer stehen. Genau so ist es auch mit dem SSD-Cache.

Ich glaube, Du hast ein grundsätzliches Problem auf dem Host, der die VMs in die Knie zwingt.

 

[illumina7]

Denke, das Raid-Level ist hier nicht ausschlaggebend, da ein Raid10 generell besser als ein Raid5 performt. Btw war vor der kompletten Neuinstallation ein Raid5 Array engerichtet.

Wie schon gesagt, das Caching des Controllers ist aktiv.

[...]
Ich glaube, Du hast ein grundsätzliches Problem auf dem Host, der die VMs in die Knie zwingt.

Wie meinst du das genau?

Also die VMs idlen eigentlich fast rum und bekommen irgendwie keine Performance vom Host.

 

[Morpheus2200]

Wie sind die Platten der VMs angelegt? Fixe größe?
Was passiert wenn nur ein Teil der VMs läuft? Wird die performance besser?
Hast du Ressourcenpools eingerichtet?

Schonmal ein bisschen am Netzwerkport gelauscht?

Einer deiner Tests macht mich ein bisschen Stutzig:
- Auf einem Client Outlook und Streit lokal installiert (i7-3770k, 16GB Ram, 250 Intel SSD, GBit) -> gleiche Symptome wie der WTS -> zurück in die Terminalsitzung gewechselt.

Wie sehen die Last-Protokolle vom ESX Server aus?
Irgendwas auffälliges in den Windows Protokollen der VMs? Kann es sein das eine der Kisten nicht sauber mit dem DC kommuniziert?

 

[TurboCharged]

Also die VMs idlen eigentlich fast rum und bekommen irgendwie keine Performance vom Host.

Genau das meinte ich. Wir hatten mal ein änliches Problem und da war irgendwas mit den Treiber, wenn ich es richtig im Kopf habe.

 

[konfetti]

Naja, Du kannst Dir doch im Resourcenmonitor mal anschauen, welcher Prozess HDD-Zeit bzw. Bandbreite braucht, das ist aussagekräftiger als der Resourcenmonitor vom esxi... - dann kann man mal schauen.

was passiert wenn nur eine einzige VM läuft?

 

[illumina7]

Wie sind die Platten der VMs angelegt? Fixe größe?
Was passiert wenn nur ein Teil der VMs läuft? Wird die performance besser?
Hast du Ressourcenpools eingerichtet?

Schonmal ein bisschen am Netzwerkport gelauscht?

Einer deiner Tests macht mich ein bisschen Stutzig:
- Auf einem Client Outlook und Streit lokal installiert (i7-3770k, 16GB Ram, 250 Intel SSD, GBit) -> gleiche Symptome wie der WTS -> zurück in die Terminalsitzung gewechselt.

Wie sehen die Last-Protokolle vom ESX Server aus?
Irgendwas auffälliges in den Windows Protokollen der VMs? Kann es sein das eine der Kisten nicht sauber mit dem DC kommuniziert?

Die VMs einzeln betreiben macht kaum Sinn, da die Anwendungen/Daten ja über die vier VMs verteilt sind.

Am Netzport gelauscht ja, über etwas auffälliges gestolpert aber eher nicht.


Windows Logs sind nahezu clean, Kommunikation mit dem DC klappt sauber (seh ich auch anhand von Policys etc.), 100%ig ausschließen mag ichs allerdings jetzt soweit auch nicht.

Genau das meinte ich. Wir hatten mal ein änliches Problem und da war irgendwas mit den Treiber, wenn ich es richtig im Kopf habe.

Laut VMWare liegen keine Treiberfehler vor. Theoretisch könnten die sich auch irren, aber die haben schon x-mal Logfiles des ESXi geladen und Live-Mitschnitte, diese Ausgewertet und Analysiert und keine Auffälligkeiten finden können. Zuletzt waren drei VMWare Support (2nd und 3rd Level) an einer Fernwartungssession gesessen und haben den ESXi Live analysiert, während ich einige Scenarien durchgeführt hab.
Ergebnis: ESXi ist ok...

Naja, Du kannst Dir doch im Resourcenmonitor mal anschauen, welcher Prozess HDD-Zeit bzw. Bandbreite braucht, das ist aussagekräftiger als der Resourcenmonitor vom esxi... - dann kann man mal schauen.

was passiert wenn nur eine einzige VM läuft?

Passiert nichts, mit einer VM kann ich effektiv nichts Testen, da die Dienste über die vier VMs verteilt sind.

 

[ludwinator]

Passiert nichts, mit einer VM kann ich effektiv nichts Testen, da die Dienste über die vier VMs verteilt sind.

doch, kannst du. Ich fände den WinRAR-Test sehr interessant...

 

[illumina7]

doch, kannst du. Ich fände den WinRAR-Test sehr interessant...

Hm gute Idee, das hab ich noch garnicht bedacht...
Muss ich mal sehen, ob ich das irgendwie mal testen kann.

 

[Morpheus2200]

So in etwa meinte ich das auch mit einzelne VM testen.
Am besten eine Kiste die nicht in der Domäne hängt.

 

[l0n]

Trotz deiner Aussage das I/O und RW in den Guest Systemen gut sind, irgendwie riecht das trotzdem nach I/O Delay auf dem Host.

Hau mal auf das Array im Host ein sudo hdparm -tT /dev/XXX bzw. sudo hdparm -tT --direct /dev/XXX (ohne Cache).
An den Lese/Schreibgeschwindigkeiten sieht man ganz gut wo I/O vergraben liegt.

 

[myBerg]

Du hast ja schon einiges gemacht, aber man kann noch nicht klar erkennen, ob die Platten, die CPU oder etwas anderes das Problem ist.

Um die CPU im Blick zu haben, würde ich mir per SSH auf den Host verbinden und esxtop nebenbei laufen lassen. Die Auswertungen in der ESX-Konsole sind zwar auch gut, aber machnmal sieht man hier mehr.
Nur die VM-Prozesse sollten die CPU belasten!

Dann wäre es nicht schlecht einen CPU und einen HDD-Benchmark in einer VM durchzufühen. Z.B. "Prime95" und "HD Tune 2.55 Free". Dabei sollten plausible Werte herauskommen, d.h. beim Lauf von HD Tune sollte keine nennenswerte CPU-Last auftreten und umgekehrt sollte bei Prime95 die dafür genutzte VM in esxtop einen %USED Wert von 100% * Anzahl der CPUs anzeigen. Der Benchmarkwert sollte plausibel sein, also bei Prime für FFT mit 2048k beispielsweise Werte kleiner 10ms. HD Tune sollte Werte deutlich über 100MB/sec liefern.

Falls sich damit immer noch nichts genaues sagen lässt, würde ich um das RAID als Fehlerquelle auszuschließen, eine SSD an den Controller auf dem Mainboard hängen und eine VM dort herüberschieben. Ist das Verhalten identisch, kannst Du die Platten und das RAID als Fehlerquelle ausschließen. Wird es wesentlich besser, stimmt vermutlich etwas mit den Platten/RAID/Dateisystem/HDD-Treiber nicht.

BTW, sind die vmware tools in den VMs installiert?

 

[illumina7]

Vielen Dank erstmal für die vielen Antworten.

@myBerg: vmware tools sind installiert, auch schon mal "clean" neu installiert. Raid Treiber ist dieser installiert: https://my.vmware.com/web/vmware/details?downloadGroup=DT-ESX55-LSI-SCSI-MEGARAID-SAS-660606001VMW&productId=353, dazu der entsprechende CIM-Provider.

Hab eben mal HD Tune pro VM durchlaufen lassen:
1.Durchgang, Nacheinander:
Terminalserver:

SQL Server:

Mail-Server:

DC:


2. Durchgang, Parallel auf allen vier VMs
Terminalserver:

SQL Server:

Mail-Server:

DC:

So in etwa meinte ich das auch mit einzelne VM testen.
Am besten eine Kiste die nicht in der Domäne hängt.

Werde ich Freitag Testen, sobald ich vor Ort bin.

Hau mal auf das Array im Host ein sudo hdparm -tT /dev/XXX bzw. sudo hdparm -tT --direct /dev/XXX (ohne Cache).
An den Lese/Schreibgeschwindigkeiten sieht man ganz gut wo I/O vergraben liegt.

In der ESXi Shell gibts den Befehl "hdparm" nicht? Oder versuche ich das an der falschen Stelle?

 

[Morpheus2200]

Hast du eine Idee warum die Burst-Rate teilweise deutlich unterhalb des Minimums liegt?
Was für virtuelle Storageadapter haben die VMs?

 

[konfetti]

kann es sein, das es ein Problem mit dem Cache am Raid-Controller gibt?

 

[illumina7]

Hast du eine Idee warum die Burst-Rate teilweise deutlich unterhalb des Minimums liegt?
Was für virtuelle Storageadapter haben die VMs?

Also die VMs bekommen ein LSI Logic SAS als vAdapter.

kann es sein, das es ein Problem mit dem Cache am Raid-Controller gibt?

Die Logfiles sind in den letzten 4 Wochen, dreimal von Wortmann und zweimal direkt an LSI weitergeschickt und ausgewertet - Controller ist in Ordnung... zumindest ist so die Aussage, die ich bekomme.

Was vermutest du, könnte mit dem Controller-Cache sein?

 

[l0n]

Shit ESXi... da war ja was. Durch die Busybox gibts kein HDParm und nachinstallieren lässt sichs ja auch nicht.
Kann esxtop sowas nicht?

 

[konfetti]

Naja, das der Cache vom Controller da reinspinnt - ist der denn ein oder ausgeschaltet?

Wir haben zuletzt immer auf die BBU und den Cache verzichtet, weil es effektiv nix bringt. - Der Cache kann die Messung ja auch verfälschen.
Du hast gesagt, die VMs arbeiten miteinander, also sind quasi voneinander abhängig, was für Netzwerkkarten hast Du in der VM denn drin?

Zuhause hatte ich mit einem ESXi probleme, wenn da ne 10G Netzwerkkarte intern zugewiesen war.
Weniger Probleme gab es mit VMXNET3

 

[illumina7]

Also ohne Caching ist die Performance miserabel. Caching aktivieren wir grundsätzlich bei unseren ESXi Maschinen, da sonst ein effektives Arbeiten möglich ist.
Kann heute Abend aber nochmal HD Tune mit deaktiviertem Caching ausführen, vielleicht bringt uns das der Lösung etwas näher.

VMXNET3 haben alle VMs zugewiesen, diese sind auf den internen vSwitch mit 10G connectet, dieser wiederrum mit 3 physischen 1GBit NICs auf dem Switch gepatched.

 

[Olaf16]

LSI Logic SAS als vAdapter? Der VMware Paravirtual ist doch viel besser... Muss man nur bei Installation dann normalerweise Treiber installieren, läuft bei mir aber viel Performanter

 

[konfetti]

Wie gesagt, ggf. kann die intern zugewiesene 10G-Karte ja das Problem sein - schon mal mit nur 1G getestet?
- ich mach mal nen bench von ner 2012R2 bei uns.

 

[illumina7]

LSI Logic SAS als vAdapter? Der VMware Paravirtual ist doch viel besser... Muss man nur bei Installation dann normalerweise Treiber installieren, läuft bei mir aber viel Performanter

Ja? Hab dazu jetzt keine eindeutigen Informationen finden können. Kann man den vAdapter nachträglich wechseln? Umsetzen kann ich den "Typ" ja bei den Settings, aber funktioniert das dann auch oder verschlimmbessert es das ganze eher?

Wie gesagt, ggf. kann die intern zugewiesene 10G-Karte ja das Problem sein - schon mal mit nur 1G getestet?
- ich mach mal nen bench von ner 2012R2 bei uns.

Jain, hatte den internen vSwitch auch schon mal im Verdacht, deshalb pro VM einen vSwitch erstellt und den ganzen Traffic über den physischen Switch geleitet (1 NIC pro vSwitch).
Die vNICs hatte ich auch schon auf E1000 und E1000E gewechselt, wobei die Performance damit spürbar schlechter war, deshalb wieder auf die VMXNET3 zurück gewechselt.
Wäre mal interessant, was dein 2012R2 für Werte bringt.

 

[olqs80]

Hast du schon probiert RAM und CPU Reservierungen zu setzen?
Sobald eine RAM Reservierung konfiguriert wird, legt ESX kein .vswp Memory Swapfile auf dem Datastore an, was eine Storage entlastung zu Folge hat.
Die CPU Reservierung ist hier ein Schuss ins Blaue, aber da du ja eh kein Overcommitment auf CPU Ebene machst, könnte mans mal ausprobieren.

Wie sieht es denn mit den Strip Sizes bei deinem Raid aus? Die können auch ein Performance Bremse sein. Grosse Stripe Sizes sind super für sequenziellen IO, aber bei Random IO wie bei Datenbanken und gleichzeitigen VMs können die richtig ausbremsen.

Du schreibst bei den Kopiervorgängen von einer VM zur anderen bekommst du >100MB/s. Auch in dem Setup 1 vSwitch mit dedizierter NIC pro VM? Dann könnte man das Netzwerk ja schonmal ausschliessen.

 

[illumina7]

RAM und CPU hab ich für SQL und Terminalserver reserviert. Leider hat das auch keinen Effekt gebracht.

Hier mal ein kleiner Auszug aus der Raid-Config, vielleicht beantwortet das schon ein paar Fragen:

 

[olqs80]

Ich würde bei Random IO und 8 Platten nicht über 64KB Stripe Size gehen.
So wie dein Setup aussieht sind das zwei Raid0 und darüber ein Raid1.
Bei 256KB Stripe Size heisst das:
Ein Schreibvorgang mit 4 oder 8 KB wie typisch für Datenbanken löst einen 256KB Read aus dann wird der Block verändert und komplett neu geschrieben. Aus einem IO auf die Platten werden zwei.
Beim Lesevorgang sinds auch immer mindestens 256KB. Je nach Read Ahead Implementierung können aber auch gleich mehr Blöcke eingelesen werden, die im ungünstigsten Fall bei RandomIO nicht gebraucht werden. Read Ahead auszuschalten, sollte man sich trotzdem gut überlegen.
-> unnötige Belastung der Platten

Bei Sequenziellen Schreibvorgängen mit 256KB oder mehr entfällt der vorherige Read vorgang und es kann direkt geschrieben werden.

Die kruz am runterdrehen der Stripe Size ist, dass der Durchsatz bei sequenziellen Lese bzw Schreiboperationen dann normalerweise zurückgeht.
Das schreiben einer 1MB Datei, benötigt dann nicht mehr 4 IOs (256KB Stripe), sondern 16 (64KB Stripe).

Ob die LSI Controller eine Online Migration hier möglich machen, kann ich dir leider nicht sagen.

 

[illumina7]

Vielen Dank für deine ausführliche Info.

Bei LSI wird ein Raid10 genau so erstellt, also zwei Raid0 und darüber ein Raid1.

Soweit ich das rauslese, empfiehlst du einen Wechsel der Stripe Size auf 64KB, oder hab ich das jetzt falsch verstanden?

Leider unterstützen LSI Controller keine Migration der Stripe Size, müsste dafür ein Backup erstellen, Array mit der neuen Stripe Size neu konfigurieren und anschließend das Backup zurückspielen. Wäre also durchaus ein Aufwand, deshalb müsste ich 100%ig sicher sein, dass eine 64KB Stripe Size einen Performancegewinn zur Folge hätte.

Meinst du, dass es sich lohnen würde?

 

[olqs80]

Ich würde bei dem Aufwand, das als letzte Lösung sehen.
Erst mal die anderen offenen Fragen noch klären.

Meiner Vermutung nach sollte es damit besser werden. Aber da ist auch ein bisschen in die Glaskugel schauen dabei.

 

[fdsonne]

Also nach den ganzen Werten schaut das alles nicht unbedingt nach einem Hardware oder Konfigproblem aus...

Ich würde, sofern möglich, hier einfach mal versuchen, Trockentests zu machen. Sprich die Umgebung runterfahren und mit einer nakten Install einer (oder mehrerer) VMs mit 2012 R2 oder auch älteren/anderen Versionen verschiedene Last Tests durchzuführen. Generell riecht mir das hier wie gesagt nicht nach einem Hardwareproblem. Die Messungen der einzelnen Tools usw. scheinen mir alle samt durchaus OK für diese Aufbau.

Meine Vermutung ins Blaue, das ist einfach irgendwas ganz banales wie nicht sauber funktionierendes DNS oder ähnliches... Nur bekommt man das entweder nur raus, wenn man da dediziert weis, wo man nachsehen muss. Oder man testet es in einer Trockenumgebung möglichst ohne Einfluss der "Liveumgebung" um entsprechend solche Geschichten auszuschließen.



Ansonsten, local via SSH auf den ESXi Konsoleport connectet, lässt sich via esxtop bspw. auch die IO-Last des physischen Adapters ablesen. Gerade Datenbanken können da extrem bissig sein. Bei mir Zuhause "parkt" mein SBS 2011 bspw. zyklisch durch eine Aktion in einer SQL Datenbank mein physisches Plattenarray für eine gewisse Zeit. -> und alle VMs die noch mit auf diesem Array liegen, sind in der Zeit fast nicht mehr ansprechar. -> da sieht man dann via esxtop auch, dass da mehrere hundert (oder tausend -> bei den SSDs) IOs gelesen/geschrieben werden und muss sich entsprechend nicht wundern, dass es zäh wird.

Bei dir ist dazu noch die Schwierigkeit, dass du ja nur ein oder zwei physische Arrays nutzt, entsprechend eine Last auf dem Array ggf. einfach die komplette Hütte quasi lahmlegen könnte... Der Cache selbst kompensiert das zwar etwas, aber auch nur in einem gewissen Maße. Arbeiten mit einer VM ala Terminalserver kann unterschiedlichste HDD Bereiche beanspruchen -> der Cache ist ja nur so groß wie er ist. Mehr Daten, die angefordert werden oder gepuffert werden müssen, zieht dann die Performance in den Keller.

LSI Logic SAS als vAdapter? Der VMware Paravirtual ist doch viel besser... Muss man nur bei Installation dann normalerweise Treiber installieren, läuft bei mir aber viel Performanter

Nach diversen Artikeln im Netz und auch Aussagen seitens VMware wird der Paravirtuelle Adapter für IO-Lastige VMs empfohlen, da der dort wohl minimal schneller sein soll. Ohne Last hingegen soll er langsamer sein als bspw. der default LSI Logic SAS Adapter...