Performanceverlust durch Virtualisierung

[bouncer86 5]

Moin,

 

ich bin auf einen Artikel gestoßen (worden), der beschreibt, warum die stark vereinfachte Darstellung in Post Nr. 25 bei näherem Hinsehen nicht mehr zutrifft.

 

http://www.virtuallycloud9.com/index.php/2013/08/virtual-processor-scheduling-how-vmware-and-microsoft-hypervisors-work-at-the-cpu-level/

 

Gruß, Nils

 

Hallo Nils,

 

sehr interessanter Beitrag. Ob das wirklich so ist, irgendwie schwer vorstellbar. Aber würde ja bedeuten, dass unter Hyper-V zwei VM's mit 2 Kernen auf einem Host mit 2 physischen Kernen, wo innerhalb der VM nur eine CPU ausgelastet wird, beide relativ performant gleich schnell arbeiten können.

Bei VMware würden beide VM's deutlich langsamer werden.

 

Das müsste mal jemand testen ;)

[Dukel 455]

Ein Beispiel aus der Praxis: Mit einfachen Kopieraktionen kann man - genügend IO-Leistung der Storage vorausgesetzt - mehrere Kerne mit hoher GHZ mit der virtuellen Netzwerkkarte komplett auslasten. Für die eigentlichen Operationen innerhalb der VM bleibt dann nicht viel Rechenleistung übrig. Das gibt dann einen riesigen Overhead bei viel Schreibleistung die nicht auf "lokale" Platten gehen und somit dem Host seine Kerne "belasten".

Mit ein paar einfachen Kopieraktionen zieht man unter Umständen die Performance des ganzen Hosts in den Keller. Ich konnte dabei feststellen, dass mit einer höheren Taktrate und dafür weniger Kerne pro VM  das Problem deutlich entspannter wurde. Die Performance war besser obwohl im Host weniger Gesamt-GHZ vorhanden waren und weniger Kerne.

 

War das mit emulierten oder Synthetischen Netzwerkkarten?

[zahni 554]

 

Bei VMware würden beide VM's deutlich langsamer werden.

 

Das müsste mal jemand testen ;)

Das würde ich daraus  nicht  schließen. Du kannst das  aber  gern testen ;)

[NilsK 2.957]

Moin,

 

ganz so einfach ist es nicht. Man muss dabei auch berücksichtigen, dass ein CPU-Thread je nach CPU nicht gleichbedeutend mit einem Core ist. Heutige CPUs sind viel komplexer und leistungsfähiger. Ich bin zu wenig mit CPUs bewandert, um das genau sagen zu können, aber die sehr simplen Analogien, die in diesem Thread gemacht wurden, beschreiben den Vorgang nicht korrekt. Sie sind für ein Grundverständnis OK, für die Beurteilung tatsächlicher Performance aber nicht geeignet.

 

Was den Netzwerktraffic betrifft: Ja, grundsätzlich trifft auch das zu. Die Host-CPUs können durch starken Traffic enorm belastet werden. Das ist ja auch der Grund, warum die Virtualisierungshersteller dort eine ganze Menge Entwicklung betreiben, die in modernen Versionen zu einer deutlichen Verbesserung führt. Wer oft solche Last hat, sollte über den Einsatz von VMQueue oder SR-IOV nachdenken, die genau diese Dinge angehen.

 

So langsam driften wir dann aber ins Allgemeine ab ...

 

Gruß, Nils

[Weingeist 159]

So langsam driften wir dann aber ins Allgemeine ab ...

 

Naja, bin ich anderer Meinung. Schon die Fragestellung ist allgemein gesprochen. Wenn meine Verallgemeinerung - wenn auch zu Recht - zu wenig tiefgründig bzw. heute teilweise falsch ist, dann kann man relevante Punkte welche die Performance/Overhead der Virtualisierung unter Umständen massgeblich beinflussen, nicht als abdriften bezeichnen. ;)

 

Fakt ist aber nach wie vor - daran ändern alle modernen Features nichts - dass je mehr Cores oder von mir aus aus CPU-Sicht auch Threads (Hyperthreading ergibt einen gewissen Performance-Vorteil, den haben aber auch physische Maschinen) pro VM zugewiesen sind, desto mehr Verwaltungsaufwand für das Host-OS entsteht und dies die Performance gegenüber physischen Maschinen beeinträchtigt. Ich würde mich aber sehr stark wundern, wenn dies bei einem gut ausgelasteteten sowie Kerne oder noch schlimmer Thread überbuchten Host bei den 5-6% bleiben würde (Je mehr Cores einzelnen VM zugewiesen wurden). Bei RAM-Überbuchung siehts noch schlimmer aus. Das ist aber mittlerweile eh vom Tisch, macht fast niemand mehr.

Bevor ich da keine aktuellen Tests vorliegen habe, kann ich da aber nur von meinen Erfahrungen mit der CPU-Taktung zehren. Wenn hier ein paar Aktionen die Performance spürbar in den Keller ziehen, muss dass massiv mehr als 5-6% sein.

Auch Grafikkarte kann ziemlich Overhead verursachen. Im Serverumfeld eher weniger relevant sondern Desktopvirtualisierung.

 

Am Ende kann heute vieles an zusätzliche Hardware ausgelagert werden, mann muss dann aber dennoch so ehrlich sein, dass es dann nicht mit 5-6% getan ist, wenn einfach mehr spezifische Rechenleistung hineingebracht wird, die z.B. in kleinen Umgebungen in der Regel gar nicht finanziert und eingebaut wird. ;)

 

 

 

 

War das mit emulierten oder Synthetischen Netzwerkkarten?

Das war mit VmWare. Normale Netzwerkkarten E1000 sowie VMXNET3, Host 5.5. Also keine physisch durchgereichte Karte oder SR-IOV aktivierte Karte.

bearbeitet 28. Mai 2015 von Weingeist

[zahni 554]

Hohe CPU-Last durch ausgelastete virtuelle NIC's mag ich nicht bestätigen. Hier dürfte ehr ein Storage-Problem vorliegen (zu lahm...)

[Weingeist 159]

Hohe CPU-Last durch ausgelastete virtuelle NIC's mag ich nicht bestätigen. Hier dürfte ehr ein Storage-Problem vorliegen (zu lahm...)

Eigentlich nicht. Im Gegenteil. Waren hochperformante SSD. Der Durchsatz stieg quasi proportional zur Menge Cores die ich einer VM zugewiesen hatte an. Bei weniger Cores, dafür aber höherer Taktung (neue CPU) waren aber die Auswirkungen auf den Host bzw. das Benutzerfeeling der Desktops die auf der gleichen Maschine liefen deutlich entspannter. Beim Copy auf den lahmen Storage war die CPU-Auslastung tief.

 

Wie auch immer: Ich sage ja nur, dass man ned in jedem Fall von 5-6% ausgehen kann. Insbesondere nicht bei

- Spitzenbelastung von VM's zur Arbeitszeit

- Hohe Belastung durch virtuelle Hardware, insbesondere bei VDI oder extrem hohem LAN Traffic

- Überbuchung von Cores/Threads wenn obiges zutrifft

 

Zudem muss auch noch der Handlager der Hosts (z.B. vCenter) mit einberechnet werden, der in kleinen Umgebungen verhältnissmässig viel Power verbratet.

Wenn überbucht wird, ist es ja eigentlich kein fairer Vergleich physisch und virtuell und eigentlich auch zu allgemein gesagt mit Overhead. Ist ja dann streng genommen ned Overhead... Aber jetzt driftets wirklich ab. Wollte beim Overhead aber auch vor allem auf die mehr Kerne = mehr Verwaltungsaufwand zielen.

 

Aktuelle Vergleiche P/V  habe ich keine zur Hand. Mit aktueller Hardware kann ich nur auf Erfahrungen im praktischen Umfeld zurückgreifen. Bei reinen, gemischten Server-Workloads sind ja meist eher die IO's der Flaschenhals, nicht die CPU.

[DocData 85]

Wer heute noch Workloads auf Physik aufbaut, der hat irgendwas falsch gemacht. Es macht gar keinen Sinn. Ich sehe auch immer mehr Kunden die Tier-1 Workloads von UNIX Hobeln auf Linux/ VM umziehen. Vor allem das Argument OPEX zieht an dieser Stelle (Wartung, Betrieb etc.).

 

Was richtig ist: Die Anzahl der Kerne ist nur ein Teil der Rechnung. Der Takt ist nicht zu vernachlässigen, eben vor allem bei Single Thread Applikationen. Aber da gibt es ja mittlerweile eine bunte Auswahl an hochgetakteten CPUs mit vielen Kernen.

[NilsK 2.957]

Moin,

 

trotzdem sollten wir vielleicht dann doch mit Verallgemeinerungen etwas vorsichtiger sein.

 

Sowenig sich die "schlechten" Beobachtungen verallgemeinern lassen, ist es automatisch "falsch gemacht", wenn man "heute noch" mit physischen Servern arbeitet. Es gibt durchaus Workloads von Relevanz, die mit Virtualisierung eben oft nicht gut funktionieren. Dazu zählen VoIP-Anwendungen wie Asterisk und Lync in größeren Umgebungen. Hier sind die prinzipbedingten Latenzen schnell so groß, dass die Sprachübertragung gestört ist. (Auch dies ist keine 100-Prozent-Regel - so setzen wir in unserem Unternehmen Lync sehr wohl als VM ein, aber die Umgebung ist auch noch unter einer kritischen Größe.)

 

Gruß, Nils

[Daniel -MSFT- 129]

Vielleicht sollte man noch beachten, dass bei hohem Netzwerktraffic es stark darauf ankommt, was für Netzwerkkarten verwendet werden mit welchen Treibern und wie das OS damit umgeht. Früher war das Problem, dass zum Beispiel der Windows TCP/IP-Stack die Interrupts, die eine Netzwerkkarte auslöst, wenn Verkehr anliegt, nur auf einer CPU verarbeiten konnte. Damit stieg und fiel die Leistung des Servers durch die Geschwindigkeit der einen CPU. Das wurde mit neueren Windows-Versionen geändert.

 

Weiterhin war das Verarbeiten der Interrupts durch die CPU ein Problem, das durch Offloading-Techniken wie TCP Chimmney drastisch minimiert werden konnte. Leider glauben auch hier viele Admins einfach weiter urbane Mythen und deaktivieren das Offloading, sod ass die Serverperformance beeinträchtigt ist.

 

Mit aktuellen Techniken wie RDMA kannst Du problemlos mehrere 10 GBit-Verbindungen bündeln und hast trotzdem wenig bis keine Leistungsverluste mehr bei Virtualisierung. Siehe z.B. http://download.intel.com/support/network/adapter/pro100/sb/understanding_iwarp.pdf und https://technet.microsoft.com/en-us/library/dn583825.aspx

 

Have fun!
Daniel

[zahni 554]

Bei VMWare wird Offloading hauptsächlich durch die Hardware und dessen Treiber bestimmt. Konfigurieren kann man nur auf der Ebene des Treibers. Hier hat VMWare aber schon mal Offloading durch Updates abgeschaltet, wenn es mit der Hardware oder mit Treibern der Hersteller Probleme gab. Der VMXNET3 reicht diese Funktionen "paravirtualisiert" aber auf jeden Fall an die VM weiter.

Wenn man immer noch hohe Last hat, sollte  man andere (Server)-NICs verwenden.

[KingKompass 0]

Moin,

 

okay, also, ein Datev-Server für 40 Personen braucht ganz bestimmt nicht "das Maximum" an Performance. Wenn du die Hyper-V-Umgebung sinnvoll aufbaust, kannst du das problemlos darauf betreiben. Klär das aber vorher mit Datev ab, die sind da oft pingelig.

 

Den DC solltest du auf jeden Fall davon trennen.

 

Gruß, Nils

 

Hallo,

ich hatte ja versprochen gehabt euch auf dem laufenden zu halten.

Der Datev Teamservice hat mittlerweile übrigens auch sein Feedback gegeben, hier ein Auszug aus der Mail vom Datevsupport:

 

"Guten Morgen Herr,

ich komme auf Sie zu aufgrund Ihrer Anfrage zur Virtualisierung Ihrer Serversysteme.

Ihre angedachte Konfiguration eignet sich sehr gut für die Virtualisierung der beiden Server-Systeme (DC + DATEV-SQL/DMS).

Heute kommen in 99% der Fälle virtualisierte Systeme zum Einsatz, die Einbußen hinsichtlich Performance durch die Virtualisierung sind zu vernachlässigen.

Ich empfehle Ihnen folgendes Setup:

DC: 1 vCPU, 4 GB RAM

SQL: 6 vCPU, 50 GB RAM (40 GB Zuweisung zum SQL-Server)

Sie könnten auf diesem System durchaus noch einen Remote-Desktop-Server betreiben und damit Ihr System „WTS3“ ablösen, dann natürlich mit angepasster Konfiguration.

Bitte beachten Sie: Hyper-V unterstützt keine angeschlossenen USB-Geräte, daher benötigen Sie ggf. (sofern Sie am SQL-Server einen Lima-Server betreiben wollen) noch ein USB-to-LAN-Device.

Achten Sie bitte darauf, im BIOS-Setup Ihres Systems bzgl. der CPU-Energieverwaltung „Maximale Leistung“ (o. ä.) einzustellen, da es ansonsten zu Einbußen in der Performance kommen kann.

Bitte kommen Sie bei weiteren Fragen gerne auf mich zu!"

 

Also alles im allen, wurden eure sehr hilfreichen Antworten und Ratschläge seitens der Datev auch noch einmal bestätigt.

 

Bei der Vorbereitung des Projektes bin ich aber noch auf eine andere Fragestellung gekommen, die ich mir leider bis jetzt noch nicht selbst beantworten konnte.

Von daher hoffe ich noch einmal auf Feedback von eurer Seite, vielleicht mache ich mir bei dieser Thematik auch zu viele Gedanken und es ist zu vernachlässigen.

Es geht um die Partitionierung bzw Aufteilung der VHDX Dateien in der virtuellen Maschine.

Um das noch einmal kurz in Erinnerung zu rufen, ich plane einen Host mit zwei virtuellen Maschinen auf einem RAID 10 (BBU / Intel DC S3700 SSD)

mit einer Gesamtkapazität von ca 800 GB.

Der DC (keine weiteren Rollen) bekommt eine "dynamic virtual hard disk" mit 50 GB zugewiesen, ich denke das sollte erst einmal reichen.

Für den Datev/SQL/File Server habe ich mich nach langen Recherchen für eine "fixed virtual hard disk" (650GB) entschieden. 

Jetzt stellt sich für mich nur die Frage, erstelle ich nur eine VHDX Datei (fixed disk) und installiere sowohl das OS (Server2012R2) als auch die restlichen Daten inklusive SQL DBs und DMS

in dieser VHDX Datei auf nur einer Partition (C:) oder partitioniere ich innerhalb der VHDX Datei noch einmal , so das , wie ich es vom physikalischen Server gewohnt bin, Laufwerk C: für das OS

und Laufwerk D: für die Daten habe.

Die nächste Alternative wäre, zwei VHDX Laufwerke für die Datev/SQLFile VM zu erstellen und zum Beispiel eine VHDX mit 50GB für das OS zu erstellen und eine zweite VHDX mit 600GB für die Daten, das ganze wiederum unter dem Gesichtspunkt der maximal möglichen Performance. 

Macht die ganze Partitionierung innerhalb einer VHDX Datei bzw Aufteilung auf verschiedene VHDX Dateien in meinem Fall überhaupt Sinn ?

Vielen Dank noch einmal im voraus für euer Feedback !

 

Gruß Michael

[NilsK 2.957]

Moin,

 

das Sizing für den SQL Server klingt für mich reichlich übertrieben. 6 vCPU und 50 GB RAM wird das Ding nicht benötigen. Warum der SQL Server dann von diesen 50 GB nur 40 bekommen soll, bleibt auch das Geheimnis des Supporters. Und natürlich packt man keinen Terminalserver auf einen SQL Server.

 

Virtuelle Festplatten nie partitionieren, sondern immer einzelne anlegen.

 

Gruß, Nils

[Dukel 455]

Es gibt die Empfehlungen feste min und max Werte einem SQL Server zuzuweisen und den Max Wert etwas (mit etwas ist 4-8GB gemein) unter dem Verfügbaren Ram zu konfigurieren (damit das OS auch noch Ram zum arbeiten hat).

[NilsK 2.957]

Moin,

 

wer sowas (pauschal) empfiehlt, hat das Memory Management von Windows nicht verstanden.

 

Gruß, Nils