Performanceverlust durch Virtualisierung

[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,

der Datev Teamservice ist schon angeschrieben und ich warte auf Rückantwort, wobei Datev meist keine direkte Unterstützung und Empfehlung für Virtualisierungslösungen gibt.

Und das mit dem "pingelig" kann ich unterschreiben, wobei das aber auch nicht immer unbedingt schlecht sein muss  ;)

Sorry, hatte ich vergessen zu schreiben , im Falle einer Virtualisierung würde der DC natürlich in einer separaten VM laufen,

die bessere Rollentrennung wäre dann auch ein weiteres pro Argument für die mögliche Virtualisierung.

Danke !

 

Gruß 

Michael

Hi,

 

bei Datev solltest du beachten, dass du das USB Softwareschutzmodul (USB-Dongle) sowie den Betriebsstätten mIDentity in der VM brauchst. Dazu benötigts du beim Hyper-V (auch sonst sinnvollerweise) einen USB zu LAN Server (z.B.: SEH myUTN 50a).

 

Je nach Anforderungen könnt es durchaus noch Sinn ergeben, den Datev DMS Server vom restlichen Datev SQL zu trennen sowie die Kommunikationsdienste und / oder Lizenzdienste der Datev ebenfalls auf separaten VMs bereitzustellen.

 

Und noch was zum Lesen ;)

 

Virtualisierung von Datev Servern:

http://www.datev.de/dnlexos/mobile/document.aspx?document=1080017&consumer=webApp

http://www.datev.de/dnlexos/mobile/document.aspx?document=1080080&consumer=webApp

 

Der Datev SQL Server:

http://www.datev.de/dnlexos/mobile/document.aspx?document=1033860&consumer=webApp

 

Datev Performance:

http://www.datev.de/dnlexos/mobile/document.aspx?document=0908365&consumer=webApp

 

Gruß

Jan

 

Hallo Jan,

die meisten Dokumente der Info DB, in Bezug auf Performance und Virtualisierung, hatte ich schon durchgearbeitet,

das Dongleproblem ist mir auch schon über den Weg gelaufen , ich hätte dafür den Backupserver oder den zweiten physikalischen DC in Betracht gezogen,

aber die Variante mit dem USB zu Lan Adapter hört sich auch nicht schlecht an, habe ich bisher aber leider noch nie testen können.

Ist der SEH myUTN 50a zu empfehlen ?

Das mit der Aufsplittung von DMS und dem Rest der Datev war auch schon mal ein Gedankenspiel, ist aber erst einmal wieder in den Hintergrund getreten.

Würdest du den DMS Server nur in eine separate VM packen oder ganz von dem aktuellen Host trennen und dafür weitere Hardware anschaffen ?

Der Kommserver ist schon immer eine separate Kiste gewesen und wird auch in Zukunft bleiben, ob dann später auch in einer VM wird sich noch ergeben,

dann aber nicht mehr auf dem Host für die SQL Datenbanken.

Danke !

 

Gruß 

Michael

[testperson 1.707]

Hi,

 

von den myUTN haben wir einige im Einsatz. Wenn ich mich recht entsinne gabs da maximal defekte bei einem bestimmten Firmware Update, was aber schon einige Zeit zurück liegt. Bevor du den Backupserver oder den zweiten DC als Lizenzserver installieren willst, pack ihn lieber mit auf den Kommunikationsserver oder eben per UTN an den Datev SQL.

 

Ob es in deinem Fall Sinn macht, den DMS vom restlichen Datev zu trennen kann ich dir pauschal nicht sagen. Dafür müsste man deine jetztige Umgebungen kennen / gesehen haben sowie wissen welche Produkte Ihr da genau (wie) einsetzt.

 

Gruß

Jan

[KingKompass 0]

Hi,

 

von den myUTN haben wir einige im Einsatz. Wenn ich mich recht entsinne gabs da maximal defekte bei einem bestimmten Firmware Update, was aber schon einige Zeit zurück liegt. Bevor du den Backupserver oder den zweiten DC als Lizenzserver installieren willst, pack ihn lieber mit auf den Kommunikationsserver oder eben per UTN an den Datev SQL.

 

Ob es in deinem Fall Sinn macht, den DMS vom restlichen Datev zu trennen kann ich dir pauschal nicht sagen. Dafür müsste man deine jetztige Umgebungen kennen / gesehen haben sowie wissen welche Produkte Ihr da genau (wie) einsetzt.

 

Gruß

Jan

 

Hallo Jan,

ich denke das wird wirklich schwierig ohne die komplette Umgebung genau zu kennen und würde hier wahrscheinlich auch den Rahmen sprengen. Das mit der myUTN werde ich antesten und wahrscheinlich dann auch einsetzten.

 

Wenn ich die hilfreichen Antworten von euch richtig deute, scheint die Mehrheit in diesem Fall für die Vorteile der Virtualisierung zu sein und würden die geschätzten 4-6% Overhead / Verlustleistung in Kauf nehmen. Wie Nils schon sagte, den DC noch als zweite virtuelle Maschine auf den neuen Host und vielleicht für später noch die Trennung des DMS System überlegen.

Dann Danke ich noch einmal in die Runde :jau: , für die kompetenten und hilfreichen Antworten :thumb1:  und werde den Weg der Virtualisierung gehen und "hoffen" das die Datev Software den Flaschenhals darstellt und ich bzw die ca. 40 Mitarbeiter die geschätzten 4-6% Performanceverlust nicht spüren !

Falls es den einen oder anderen , der vielleicht gerade eine ähnliche Überlegung anstellt, hilft, könnte

ich auch gerne nach der Umstellung Anfang Juli berichten.

 

Gruß Michael

[Weingeist 159]

Also bei ordentlich ausgelasteten System würde ich da eher in Richtung 10-20% Verlustleistung tendieren. Je weniger Auslastung und je weniger VM's mit mehreren Kernen definiert sind, desto besser und einfacher wirds für den Host die Ressourcen freizuschaufeln und somit sinkt die Verlustleistung.

 

ABER: Das spielt bei ordentlicher Hardware ned wirklich eine Rolle. CPU-Leistung ist in der Regel eh mehr als genug vorhanden, RAM auch. Nur IO-Leistung muss man etwas mehr einrechnen. Bitte nicht einfach davon ausgehen was für einen Server OK ist, ist auch für viele VM's i.O.

 

Ansonsten: Gibt durchaus auch Serverdienste die Mühe mit der Virtualisierung haben. Ein Kunde hat eine Zeiterfassung wo der Serverdienst gerne mal stolpert und die Syncro deaktiviert wird. Es muss dann zwar einfach nur der Dienst neu gestartet werden, lästig ist es aber trotzdem. Angeblich tritt das nur bei virtualisierten Systemen auf und habe etwas mit dem Timing zu tun. Die ganzen Vorteile der Virtualisierung überwiegen aber eigentlich fast immer.

[Dunkelmann 96]

Also bei ordentlich ausgelasteten System würde ich da eher in Richtung 10-20% Verlustleistung tendieren. Je weniger Auslastung und je weniger VM's mit mehreren Kernen definiert sind, desto besser und einfacher wirds für den Host die Ressourcen freizuschaufeln und somit sinkt die Verlustleistung.

Wo hast Du denn diese Zahlen und die Theorie des Freischaufelns her?

[NilsK 2.957]

Moin,

 

Also bei ordentlich ausgelasteten System würde ich da eher in Richtung 10-20% Verlustleistung tendieren. Je weniger Auslastung und je weniger VM's mit mehreren Kernen definiert sind, desto besser und einfacher wirds für den Host die Ressourcen freizuschaufeln und somit sinkt die Verlustleistung.

 

ABER: Das spielt bei ordentlicher Hardware ned wirklich eine Rolle. CPU-Leistung ist in der Regel eh mehr als genug vorhanden, RAM auch. Nur IO-Leistung muss man etwas mehr einrechnen. Bitte nicht einfach davon ausgehen was für einen Server OK ist, ist auch für viele VM's i.O.

 

Ansonsten: Gibt durchaus auch Serverdienste die Mühe mit der Virtualisierung haben. Ein Kunde hat eine Zeiterfassung wo der Serverdienst gerne mal stolpert und die Syncro deaktiviert wird. Es muss dann zwar einfach nur der Dienst neu gestartet werden, lästig ist es aber trotzdem. Angeblich tritt das nur bei virtualisierten Systemen auf und habe etwas mit dem Timing zu tun. Die ganzen Vorteile der Virtualisierung überwiegen aber eigentlich fast immer.

 

kann ich so überhaupt nicht bestätigen. Vor allem den ersten Absatz.

 

Bei Disk-I/O gilt das, was für die Virtualisierung allgemein gilt: Man muss schon wissen, was die konkreten Workloads (also die VMs) wirklich benötigen. Sonst kann man nicht sizen.

 

Und das Problem mit dem Dienst, der stolpert, klingt für mich nach Einzelfall. Habe ich so noch nirgends beobachtet. Vielleicht ist die Software einfach schlecht geschrieben oder der Hersteller hat eine Ausrede gesucht.

 

Gruß, Nils

[Azharu 119]

Also bei ordentlich ausgelasteten System würde ich da eher in Richtung 10-20% Verlustleistung tendieren. Je weniger Auslastung und je weniger VM's mit mehreren Kernen definiert sind, desto besser und einfacher wirds für den Host die Ressourcen freizuschaufeln und somit sinkt die Verlustleistung.

 

 

Also 10-20% kann ich auch nirgendwo in meinem Bekanntenkreis feststellen. Und da ist schon von Mittelstand bis Großunternehmen alles dabei.

[Marco31 33]

Wenn du irgendwie die Möglichkeit hast von der Hardware her würde ich das mal testen....

Wir haben letztens unseren SQL-Server virtualisiert, auf dem auch unsere FiBu-Software läuft. Der Support hatte uns bereits im Vorfeld darauf hingewiesen, dass bei der Software bei Virtualisierung eine schlechtere Performance zu erwarten ist... Bei einigen Auswertungen habe ich in Tests dann auch tatsächlich festgestellt, dass die Software in der VM teilweise ca. 20 - 30% (!) langsamer läuft... Na ja, da nicht viele Benutzer darauf arbeiten und es auch sonst da nicht auf die letzten Minute ankommt macht das nix. Die DB's liegen am gleichen SAN mit gleichen Platten wie vorher auf der physischen Maschine, der VM Host ist sogar "stärker" als der physische.

Warum das so ist konnte mir bisher noch niemand sagen... Da ansonsten keine sonderlich anspruchsvollen SQL-basierten Anwendungen laufen kann ich leider nur diese Software als Anhaltspunkt verwenden, aber ich bezweifle dass es am SQL liegt.

 

Das nur mal so als Beispiel dass man nicht immer von den oft angegebenen 5% ausgehen sollte... Theorie und Praxis ;)

[NilsK 2.957]

Moin,

 

bevor hier in großem Stil ein Verunsicherungskurs gefahren wird, lasst uns eins festhalten: Beim absolut überwiegenden Teil von Serverapplikationen ist durch Virtualisierung kein nennenswerter Performancenachteil zu erwarten.

 

Aussagen von Softwareherstellern in dieser Hinsicht sind oft nichts als Ausreden, weil man dort nicht die Kenntnisse hat, um den Kunden beim korrekten Aufbau seiner Umgebung zu beraten. Die Fälle, in denen ich sowas beobachtet habe, waren praktisch alle darauf zurückzuführen, dass die VM-Umgebung schlecht konfiguriert war. Das ist der eigentliche Punkt: Auch heute ist Virtualisierung kein Selbstläufer. Man braucht dazu schon Know-how.

 

Gruß, Nils

[Weingeist 159]

Wollte weder jemanden verunsichern noch angreifen. Hätte wohl auch etwas weiter ausführen sollen. Wie auch immer.

 

Logisch kommt es neben der Power des Hosts auf den Workload und vor allem die Konfig der VM's sowie der Core-Überbuchung an. Die meisten sind mit 5-6% aber etwas gar optimistisch. Trifft aber sicher in grösseren Umgebungen zu wo die hungrigen VM's auf verschiedene Hosts verteilt werden können. In solchen Umgebungen gibts aber eh reichlich mittel das ganze besser zu strukturieren und zu steuern.

 

Da die meisten VM's eh ned besonders Ressourcenhungrig sind, "klauen" die den anderen ned allzuviel Rechenleistung und die Performance ist oft unmerklich tiefer und bewegt sich sehr oft in dem genannten Bereich. Einfach weil den CPU's eh langweilig ist.

 

Bei einer VM mit einem Core ist der Unterschied kaum merklich, auch wenn viele VM's auf einem Host sind und die Kerne überbucht sind. Auch mit zwei Kernen hält sich das meist noch in Grenzen. Mit jedem Kern mehr steigt der Nachteil bzw. Overhead rapide an. Wird etwas besser wenn die VM die Leistung explizit zugewiesen bekommt. Aber selbst dann steigt der Overhead spürbar an, je mehr Kerne die VM hat. Vor allem wenn mehrere solcher Multi-Core VM's auf einem Host laufen. --> Der Grund ist - wie oben schon genannt - dass der Host alle Kerne die zugewiesen sind, gleichzeitig für eine Operation verfügbar haben muss. Selbst wenn für die Operation nur ein Kern benötigt wird. Ist die Maschine Core-Technisch überbucht, ist der Overhead unter Umständen enorm und der Host viel zu tun mit der Organisation.

Je höher die Taktfrequenz sowie die IO-Leistung, desto tiefer ist der Overhead wieder, so meine praktische Erfahrung. Wird alles zügig verarbeitet, sinkt auch der wahrnehmbare Overhead deutlich. Auch kann man dann unter Umständen auf nen Core verzichten und hat trotzdem mehr Leistung. Das gilt natürlich auch bei physischen Maschinen.

 

Aus diesem Grund nehme ich zum Beispiel gerne Single-Socket-Maschinen mit über 3GHZ getakteten CPU's. Das fliegt deutlich besser - auch mit vielen VM's - als niedrig getaktete Dual Socket-Maschinen und mehr Kernen aber meistens tieferen Taktraten. Oder es wird extrem teuer. --> Ist bei kleinen Umgebungen relevant.

[NilsK 2.957]

Moin,

 

hast du dafür Belege? In "Standardsituationen" habe ich solche Effekte nicht beobachten können.

 

Gruß, Nils

[zahni 554]

@Weingeist,

 

lies Dir mal http://www.vmware.com/files/pdf/techpaper/VMware-vSphere-CPU-Sched-Perf.pdf durch und denke über den fett geschriebenen Teil nochmal nach.

Ist bei Hyper-V ähnlich.

[bouncer86 5]

Zur kleinen Info nebenbei. Der Citrix Xenserver bis einschließlich Version 6.2 war deutlich langsamer was Disk und Netzwerk IO angeht. Identische Hardware mit Version 6.5 und auf einmal ist die Performance ähnlich der nativen.

 

Was ich damit sagen möchte, es gibt also auch durchaus Unterschiede zwischen den Hypervisoren.

[NilsK 2.957]

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

[Weingeist 159]

Tatsächlicher Overhead: Gibt/gab doch zuhauf Benchmarks zum Thema physisch und virtuell. Bis hin zu Extrembeispielen wo der Overhead extrem hoch liegt. In Spezialfällen über 100%. Da gibts die unterschiedlichste Bandbreite. Wobei ich mir da wohl aktuellste Lektüre einverleiben sollte.

 

@Zahni: Habs durchgelesen und widerspricht dem fett geschriebenen. Bin ich nimmer up to Date. Danke für die Richtigstellung inkl. Doku.

Allerdings ist das meiner Meinung nach trotzdem nur die halbe Miete. Bin nach wie vor überzeugt, dass Kernüberbuchung sowie anzahl Kerne pro VM's Ihren Anteil am Overhead haben. Sehr oft verteilt ja das GuestOS seinen Kram auf mehrere Kerne. Wären da z.b. nur zwei anstatt vier zugewiesen, wäre der allgemeine Verwaltungsaufwand für den Host mit Sicherheit kleiner. Unter Umständen ist der Guest ja darauf angeweisen das eine Op des anderen Kerns abgeschlossen ist bevor er auf dem anderen weitermachen kann. Irgendwas muss das verwalten.

Dann gibts noch das Problem mit der virtuelle Netzwerkkarte. Herrscht da viel Traffic, dann ist die Performance bei anderen CPU-lastigen Tätigkeiten total im Eimer. Diese verursacht einen enormen Overhead.

 

 

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.