VMWare 5.1 mit Win 2012R2 Guest Netzwerk

[cyberpeter]

Hallo,

bin neu hier und auch beim VMWare und hätte gleich mal eine Frage ...

Ich administriere eine Steuerkanzlei mit einem Dell T620 64 GB mit VM 5.1 (Dell 5.1 Update 2 1483097) mit zwei Xeon E5-26400 und SAS Platten im Raid 10. Aufgebaut wurde das ganze von einer externen Firma die uns dabei aber etwas im Stich läßt.

Darin sind zwei Windows 2012 Guests - ein SQL Fileserver und ein Terminalserver mit 5 Usern und einer Windows 8 VM auf der Veem läuft.

Eigentlich sollte ja alles laufen aber die Netzwerkperformance gerade wenn die Anwendung Daten vom SQL holt ist nicht wirlich berauschenend - eingesetzt als virtuelle Netzwerkkarte wird der vmxnet3.

Nachdem die Firma, die uns den Server hingestellt hat gemeint hat das ist normal was ich nicht glauben konnte weil unsere alte nicht virutalisierte Hardware deutlich schlechter war und merklich schneller gelaufen ist.. Nach suchen bin ich auf folgendes Document gestoßen.

http://www.behnsen.net/netzwerk-perform ... t-vmxnet3/

Bringt das was ?

Gruß Peter

[Supi]

Was für ein Geschoss für 5 User?

Also, wir brauchen mehr HW info.

-Anzahl der Platten des Raid-10 und welcher typ? SAS kann NL 7.200, 10K oder 15K sein.
- Anzahl der virtuellen CPU's in den 3 VM's

Grundsätzlich sollte mit der Konfig ( 12 Reale CPU's) die Anwendungenwie schmitz katze abgehen.

[cyberpeter]

HT ist aktiv - Server hat 8, der Terminalserver und Backup je 4. Die Angaben zu den Platten muß ich erstmal schuldig bleiben, liege gerade mit einer Grippe zu Hause.

Mein Problem ist halt das ich mit VM Ware nicht sonderlich fit bin und mich unser Händler hier "verhungern" läßt.

[Dayworker]

Das ganze Offload-Gebräu (TOE etc) würde ich bis auf weiteres immer deaktivieren. VMware seine Treiber unterstützen bisher TOE nur teilweise und je nach Gast-OS kann es dann dadurch auch zu Netzwerkinstabilitäten kommen.

[cyberpeter]

Danke!

Wie schaut es mit Receive Side Scaling aus.

Ist im moment disabled

[~thc]

Schau dir mal diesen Artikel an:

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2008925

Kannst du die anderen zwei Ursachen ausschließen?

[Supi]

Gerade die 8 CPU's des SQL Server könnten schon die Ursache sein, da diese 8 Kerne ja auf beide E5-2640 (je 6 Core + 6xHT) verteilt werden müssen.
( Es müssen immer diese 8 Kerne frei sein)
Ich würde den SQL auf 2-4 Kern und den Backup auch auf 2 Kern reduzieren.

[irix]

Gerade die 8 CPU's des SQL Server könnten schon die Ursache sein, da diese 8 Kerne ja auf beide E5-2640 (je 6 Core + 6xHT) verteilt werden müssen.
( Es müssen immer diese 8 Kerne frei sein)

Das ist pauschal so nicht richtig. Sollte eine vCPU keine Workload haben so erkennt dies der Hypervisor und muss keine logische CPU zuordnen. Sollte aber nur 1% Last da sein dann ist es so wie du es beschrieben hast.

Ich würde den SQL auf 2-4 Kern und den Backup auch auf 2 Kern reduzieren.

Einfach mal in das Monitoring gucken was die VM an CPU verbraucht hat und die zugeordneteten Resourcen daran anpassen.

Gruss
Joerg

[bla!zilla]

Das ganze Offload-Gebräu (TOE etc) würde ich bis auf weiteres immer deaktivieren. VMware seine Treiber unterstützen bisher TOE nur teilweise und je nach Gast-OS kann es dann dadurch auch zu Netzwerkinstabilitäten kommen.

Die Aussage ist, so pauschal, nicht nur mist, sondern auch ziemlich veraltet. Sorry für die harten Worte, aber sofern die darunterliegende Hardware das sauber unterstützt, zickt VMware auch nicht rum.

Gerade die 8 CPU's des SQL Server könnten schon die Ursache sein, da diese 8 Kerne ja auf beide E5-2640 (je 6 Core + 6xHT) verteilt werden müssen.
( Es müssen immer diese 8 Kerne frei sein)
Ich würde den SQL auf 2-4 Kern und den Backup auch auf 2 Kern reduzieren.

Wie Irix schon sagte stimmt das so pauschal nicht. Aber optimal ist das auch nicht (Stichwort NUMA/ vNUMA, Latency, &RDY etc.).

Derzeit gehe ich eher mal davon aus, dass die VMs massiv unter %RDY leiden. Die CPU Latenz würde ich mir auch ansehen. Da habe ich gerade selber erst ins Klo gegriffen (Stichtwort Powersaving der HW).

[Dayworker]

Das ganze Offload-Gebräu (TOE etc) würde ich bis auf weiteres immer deaktivieren. VMware seine Treiber unterstützen bisher TOE nur teilweise und je nach Gast-OS kann es dann dadurch auch zu Netzwerkinstabilitäten kommen.

Die Aussage ist, so pauschal, nicht nur mist, sondern auch ziemlich veraltet. Sorry für die harten Worte, aber sofern die darunterliegende Hardware das sauber unterstützt, zickt VMware auch nicht rum.

Stimmt, ist zu pauschal. TOE funktioniert bei mir unter nappit-in-One weiterhin nicht dauerhaft stabil und an den Host-Nics Broadcom und Intel dürfte es eigentlich nicht liegen. Von daher schalte ich es immer noch ab. Allerdings habe ich momentan auch noch Probleme mit OmniOS in der Appliance.

[cyberpeter]

Hallo,

ich hätte nochmal eine Frage.

Im vSphere Client unter Home-Bestandsliste-Konfiguration - Hardware - Energieverwaltung
steht

Technologie Enhanced: Intel Speed Step
Aktive Richtlinie: Hochleistung.

Heißt das, dass im Bios keine Stromsparmechnismen eingestellt sind die die Leistung beeinträchtigen können oder muß ich den Server neu starten und "live" ins Bios schauen?

Dann noch eine Frage. Installiert ist 5.1 Update 2 Build 1483097 also keine aktuelle Version. Bringt das Update auf 5.1 Patch 10 Build 200051, die es auch als "Dellversion" gibt noch was?

[irix]

Nein, das bedeutet das im Bios sowas wie "OS Control" eingestellt ist und der ESXi sein Profil "Hoechstleistung" verwendet. Der ESXi hat dann 3-4 Profile von denen du eins auswaehlen lkannst.

Gruss
Joerg

[cyberpeter]

Bringt es dann was im Bios "Höchstleistung" einzustellen ?

[irix]

Ja, das kann was bringen weil es mitunter Probleme gibt wenn CPUs heruntertakten und Cores stillgelegt und es dann "lange" dauert diese wieder zu reaktivieren.

AMDs koennen auch so betroffen sein das wenn die CPUs mal heruntergetaktet sich haben haben das sie nicht wieder die volle MHZ Erreichen. Das hat uns mal wochelang graue Haare bereitet bis ich den KB Artikel zum Thema fand.

Gruss
Joerg

[bla!zilla]

Irix hat Recht. Ich selber habe da gerade erst schön ins Klo gegriffen. Aktivierte Powersaving Settings führten zu hoher CPU Latenz und zu spürbaren Performanceeinbußen beim Anwender. Daher meine Empfehlung: Entweder immer High-Performance Settings einstellen, wenn der Stromverbrauch keine Rolle spielt. Beim Einsatz von latenzempfindlichen Anwendungen immer High-Performance Settings einstellen.

[cyberpeter]

So ist habe ich mal ein paar "Messungen" mit dem vSphare Client im laufenden Betrieb gemacht:

Terminalserver:
CPU-Nutzung %: 57,09 max / 21,84 min / 34,902 durchschn.
Latenz %: 38 max / 23,02 min / 31,072 durchschn.

File/SQL Server:
CPU-Nutzung %: 7,53 max / 2,41 min / 4,035 durchschn.
Latenz %: 8,06 max / 2,91 min / 3,95 durchschn.


Ich habe auf einer Workstation mit i7 und 8GB Speicher eine Datevinstalltion gemacht und mit dem dem File/SQL Server verbunden also genauso wie beim Terminalserver. Die Installation und der Betrieb waren deutlich flotter als auf dem Terminalserver.

Dann habe ich gestern Abend noch 100 GB Daten vom Fileserver auf die NAS kopiert. Die CPU des Fileservers kam dabei nur knapp auf 25 % Auslastung und der Durchsatz war bei größeren Dateien so um die 80 MB/s also an die Grenze desses was die NAS mit Ihrer GB Netzwerkkarte überhaupt kann.

Das Promblem scheint die VM mit dem Terminalserver zu sein ...

[~thc]

Bitte als Erstes die Sprache des Clients auf Englisch umstellen. Einfach an das Ziel ("...\VpxClient.exe") der Programmverknüpfung " -locale en-US" anhängern - das macht vieles einfacher.

Wir brauchen nicht die "Latenz"-Werte, sondern "Ready" (deutsch: "Bereit") und "Co-Stop" (deutsch: "Co-Stopp").

[irix]

Bitte als Erstes die Sprache des Clients auf Englisch umstellen. Einfach an das Ziel (...\VpxClient") der Programmverknüpfung " -locale en-US" anhängern ..

Code: Alles auswählen

-locale en_US

Beim WebClient einfach an die URL ein ? bzw. & "locale=en_US" oder dem Browser sagen er soll dem Server sagen das er Englisch bevorzugt.

Gruss
Joerg

[cyberpeter]

Hallo,

das Problem ist gelöst ....

Gestern Abend wurde folgendes geändert:

1. Update VM 5.1 auf Build 2000251
2. Änderung der Bioseinstellung Powermanagement von "OS Controlled" auf "Power"
3. Änderung der Netzwerkeinstellung gemäß der Eröffnungspost genannten Einstellungen

Problem ist, dass mein Bekannter der mir geholfen hat gestern Abend auch nich ohne Ende Zeit hatte weshalb ich die Schritte zwar einzeln gemacht habe aber ein "ordentliche Performancmessung" nach der jeweiligen Änderung unterblieben ist. Es wurde nur nach jeder Änderung eine TS Sitzung gestartet, der DATEV Arbeitsplatz gestartet die Ladezeit aufgeschrieben und das Laufzeitverhalten beim Daten laden und verarbeiten geprüft. Ich weis selber dass das sehr "rundimentär" ist und auch nichts darüber aussagt wenn jetzt mehrere User am TS angemeldet sind

Das Update auf 2000251 brachte keine Änderung in der Startzeit des DATEV Arbeitsplatzes und auch das Laufzeitverhalten hat sich "gefühlt" nicht verändert.

Die Änderung im Bios brachte die erste merkliche Änderung die Startzeit von sonst ca. 35-40 Selunden ging es auf knapp unter 30 Sekunden zurück und die Anwendungen liefen merklich "runder".

Die Änderung der Netzwerkeinstellung brachte dann den "Durchbruch". Die Startzeit ging auf unter 20 Sekunden zurück, die Daten wurden sehr schnell geladen und verarbeitet und das ganze System macht nun einen sehr "spritzigen" Eindruck.

Nachdem heute Vormittag alle geabeitet haben ging das System nicht in die Knie sondern blieb so performant und es kamen von allen positive Rückmeldungen.

So kann ich es lassen. Vielen Dank nochmal für die Hilfe.