Domo 4 Geschrieben 27. Januar 2022 Melden Teilen Geschrieben 27. Januar 2022 (bearbeitet) Hallo zusammen Ich beschäftige mich gerade etwas mit der Kalkulation von vCPUs unter HyperV und finde irgendwie keine schlüssigen Antworten. In gewissen Guides im Internet finden sich Leute die der Meinung sind, dass pro Core ein vCPU gerechnet werden kann - bei einem Intel Silver 4110 CPU mit 8 Kernen wären das also gerade mal 8 vCPUs. Ich war aber bisher immer der Meinung dass es (eigentlich bei keinem Hypervisor) keine direkte 1:1 Zuteilung oder Abhängigkeit von Cores zu vCPUs gibt da es sich bei virtuellen CPUs um Threads, bzw. Prozessorzeit handelt in welcher die VMs dann denn Prozessor zur Berechnung ihrer Threads nutzen können. Hat eine VM also z.B. 4 vCPUs kann diese VM 4 Threads gleichzeitig auf dem Host CPU rechnen. In anderen Guides findet sich die altbekannte Best Practice dass pro Core 8 vCPUs gerechnet werden können - an anderer Stelle wird diese rule of thumb bereits als "konservativ" bezeichnet. In obigem CPU Beispiel würde das ja (Hyperthreading mal ausgeklammert) zu 64 möglichen vCPUs führen, die das System problemlos stemmen kann. Ich habe bis anhin den VMs im KMU Umfeld jeweils 4 vCPUs zugeteilt und bin damit eigentlich gut gefahren, durch all die verschiedenen Guides und Berechnungsgrundlagen bin ich aber irgendwie total durch den Wind ob dieser Ansatz nicht unterprovisoniert ist. Dass es dabei natürlich auch auf die Workload ankommt, welche die VM stemmen muss ist mir klar - in spezifischen Szenarien in welchen die VM CPU intensive Tasks betreiben muss passe ich die vCPU Konfiguration natürlich an. Ich betrachte hier primär den "mixed use", also etwas AD, Fileserver, ERP mit SQL, etc. im KMU Umfeld mit durchschnittlich 10-15 Usern. Wenn ich bei einem entsprechenden System den Task Manager beobachte wirkt es auf mich auch nicht so als ob hier grossartig Auslastung herrscht - sowohl auf den VMs wie auch auf dem Host. Die Auslastung beträgt im Schnitt an einem normalen Arbeitstag zwischen 30 und 40% - natürlich je nach VM UseCase. Der TaskManager ist dafür nur bedingt geeignet, ist mir klar. Es gibt mir aber doch so einen grundsätzlich ersten Hinweis in Sachen Auslastung der verschiedenen Komponenten. Lange Rede kurzer Sinn; kann mir allenfalls jemand sagen ob mein bisheriger Ansatz grundsätzlich korrekt ist oder ob ich meinen VMs zukünftig mehr vCPUs zuteilen soll? Ich kann mir irgendwie nicht vorstellen dass hier ein grossartiger Performance Boost zu erwarten ist aber wie gesagt - dank all den verschiedenen Angaben bin ich nun wirklich etwas verwirrt und unsicher Herzlichen Dank im Voraus LG Domo bearbeitet 27. Januar 2022 von Domo Zitieren Link zu diesem Kommentar
NilsK 2.939 Geschrieben 27. Januar 2022 Melden Teilen Geschrieben 27. Januar 2022 Moin, Ich habe deine Frage überhaupt nicht verstanden. Kannst du bitte noch mal knapp beschreiben, was du wissen möchtest? Gruß, Nils 1 Zitieren Link zu diesem Kommentar
cj_berlin 1.323 Geschrieben 27. Januar 2022 Melden Teilen Geschrieben 27. Januar 2022 Moin, für einen DC in solch einer Kleinstumgebung sind 4 vCPU mehr als er braucht. Ein SQL Server kann parallelisieren und könnte durchaus auch 8 vCPU auslasten, beispielsweise wenn das CRM-Programm den SQL Server durch gespeicherte Prozeduren zum Rechnen benutzt. Mein Ansatz ist es, mich dem "sweet spot" von unten anzunähern, denn die Gesamtzahl vergebener vCPUs ist genauso wichtig für die Performance wie die einzelne Zuteilung. PerfMon ist Dein Freund bei Fragen dieser Art. 1 Zitieren Link zu diesem Kommentar
Dukel 454 Geschrieben 27. Januar 2022 Melden Teilen Geschrieben 27. Januar 2022 In solchen Umgebungen ist die CPU das letzte wo es ein Bottleneck gibt. So viel vCPU wie nötig, so wenig wie möglich. Hier einfach an die Hersteller Empfehlungen halten und nicht per Default mehr vCPU zuweisen (weil man es hat). Zitieren Link zu diesem Kommentar
Domo 4 Geschrieben 27. Januar 2022 Autor Melden Teilen Geschrieben 27. Januar 2022 vor 3 Stunden schrieb NilsK: Moin, Ich habe deine Frage überhaupt nicht verstanden. Kannst du bitte noch mal knapp beschreiben, was du wissen möchtest? Gruß, Nils Hallo Nils Schade, habe eigentlich versucht alles möglichst umfassend und verständlich zusammenzufassen... Kurzum: 1. Wie berechne ich korrekt und verlässlich bei einem HyperV Host die maximal Anzahl möglicher vCPUs für meine VMs? 2. Wie teile ich diese CPUs unter meinen VMs auf, resp. ist mit einem Performanceboost zu rechnen wenn einer VMs mehr vCPUs zugeteilt werden obwohl im Task Manager keine grossartige Auslastung festzustellen ist? Die beiden anderen Antworten haben mich aber in meiner Annahme und meinem bisherigen Konzept soweit bestätigt, danke euch! Schönes WE wünsch ich allen Zitieren Link zu diesem Kommentar
NilsK 2.939 Geschrieben 28. Januar 2022 Melden Teilen Geschrieben 28. Januar 2022 (bearbeitet) Moin, Gut: 1. Gar nicht, weil es eine maximale Zahl nicht gibt. Du kannst dir am Ende nur anschauen, wie eine konkrete Umgebung läuft und das ggf. per Monitoring untermauern. Der Task Manager hilft dabei nicht, er führt normalerweise eher in die Irre. Als Faustregel: zwischen 2:1 und 20:1 trifft man alles an, das kann auch alles in der jeweiligen Situation passen. 20:1 passt aber längst nicht überall, und 2:1 ist meist übertrieben konservativ. Allerdings gibt es Software, die nur mit 2:1 von deren Hersteller Support kriegt. In gemischten Umgebungen würde ich mir bei 4:1 oder 8:1 keine größeren Sorgen machen. 2: das geben die Applikationen in den VMs vor, nicht die Host-Umgebung. Auch hier ist also keine pauschale Aussage möglich. In der Praxis sehe ich eher zu "dicke" als zu "dünne" Konfigurationen. Einem DC würde ich kaum jemals mehr als 2 vCPUs geben, ein SQL Server kann damit auch gut laufen, wird aber oft auch in kleineren Umgebungen mit 4 besser laufen, manchmal auch 8. Auch dies muss man sich konkret ansehen. Ja, auch ich stimme also den anderen zu. Und nein, eine VM, die nichts zu tun hat, läuft mit mehr CPU nicht besser. Sie langweilt sich nur schneller. Gruß, Nils bearbeitet 28. Januar 2022 von NilsK 2 Zitieren Link zu diesem Kommentar
cj_berlin 1.323 Geschrieben 28. Januar 2022 Melden Teilen Geschrieben 28. Januar 2022 vor 1 Stunde schrieb NilsK: Und nein, eine VM, die nichts zu tun hat, läuft mit mehr CPU nicht besser. Sie langweilt sich nur schneller. ...und behindert dabei dennoch die anderen VMs auf dem gleichen Host - dies um so mehr, je mehr vCPUs sie zugewiesen hat. 1 2 Zitieren Link zu diesem Kommentar
NilsK 2.939 Geschrieben 28. Januar 2022 Melden Teilen Geschrieben 28. Januar 2022 Moin, Jupp, das auch Gruß, Nils Zitieren Link zu diesem Kommentar
Weingeist 159 Geschrieben 1. Februar 2022 Melden Teilen Geschrieben 1. Februar 2022 Überbuchung ist übrigens im KMU Umfeld in der Regel deutlich problematischer als im grossen Umfeld. Grund: Die Anwendungen sind öfter nicht so optimiert wie im grössen Umfeld, sei es Datenbanken und deren Indexe, Clients die Videos abspielen, vielleicht Filer + Clients auf dem gleichen Host (ohne einbremsung der IO's, wird die volle CPU-Leistung für die LAN-Ports verbraten) usw. Alles Dinge die man im grösseren Umfeld in der Regel steuert, im kleinen aber entweder nicht kann (z.Bsp ESXi Essentials) oder schlicht zu aufwendig in der Pflege ist. ;) Auch sollte man eher viel MHZ statt viel Kerne haben. Grund: Viele KMU-Anwendungen sind Single Core basiert, Clients die man als VDI oder RDS laufen lässt profitieren enorm von hoher Single Core Leistung --> User Feeling --> KMU's sind meist Inhaber geführt = Computer soll gefälligst schnell sein, schnell heisst nicht insgesamt sondern genau dann wenn etwas gewünscht wird (Latenz) ;) Daher schaue ich immer das ich normal nicht mehr als 16 Kerne pro Host (Lizenzierung bzw. deren Kosten) und Taktrate von möglichst >3GHZ habe. Sprich das + an Leistung/Stromkosten ist oft deutlich günstiger als viele Stunden Optimierung auf welche man oft nichtmal einen Einfluss hat. Wie immer zu diesem Thema: Nur meine ganz persönliche Meinung. 2 Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.