Hyper-V vCPU Einstellungen Best Practice bzw. wie macht Ihr es?

[Wolke2k4 11]

Hallo zusammen,

 

über manche Dinge macht man sich weitergehend keinen Kopf. Man nimmt an, dass das was man einstellen kann das ist, was zum Ziel führt. Getreu dem Motto "viel hilft viel", wird dann schon mal durchaus Murks eingestellt.

 

So beim Thema vCPUs unter Hyper-V. Ich habe die letzten beiden Tage einige Artikel gesucht, gelesen, vieles ist da mit Details garniert, die mich garnicht interessieren sondern ich suche etwas praktisches, mit Beispielen. Auch hier im Forum gab es bereits Beiträge dazu, verweise auf diesen Artikel, der auch schon entsprechend als ist.

 

Mich würde daher folgendes interessieren:

 

1. Hat noch jemand einen leicht verständlichen und relativ aktuellen Artikel zum Thema?

2. Wie stellt Ihr eure VMs bezüglich vCPUs ein?

3. Mich interessiert insbesondere die Dimensionierung bei virtuellen RDS Servern.

 

Und ja auch diesen Artikel kenne ich, der schlussendlich besagt, dass es keine allgemeingültige Empfehlung gibt...

[cj_berlin 1.133]

Moin,

 

ich fange mal mit 3 an. VDI-Sizing (Terminalserver inklusive) war schon immer eine schwarze Kunst und keine exakte Wissenschaft. Daher ist es extrem wichtig, ein End-to-End-Monitoring zu haben und in der PoC-Phase eine Reserve für schnelle Anpassungen vorzuhalten. Nach der PoC-Phase hat man hoffentlich genug Real Life-Daten gesammelt, dass man die gesamte Umgebung sizen kann. Zwei Dinge jedoch sind, zumindest in meiner Praxis, unverändert gültig:

• Für Front-End-Workloads gilt die Annahme "die meiste Zeit macht die CPU nix" nicht oder zumindest in deutlich geringerem Maße als für Infrastruktur-Server. Daher sollte das Overcommitment Ratio von 5:1 oder so extrem kritisch betrachtet werden. Am Ende hilft nur die Beobachtung der "CPU ready time" (VMware-Terminologie, hat Hyper-V aber auch als Perfmon-Counter). Die besten Umgebungen (aus User-Sicht), die ich persönlich kenne, laufen auf Overcommitment-Werten von 2:1 oder weniger.
• Für Front-End-Workloads ist das RAM-Core-Ratio wichtig. Pi*Daumen sollte es sich zwischen 2 und 12 GB vRAM pro vCPU bewegen, idealerweise zwischen 4 und 8. Wenn man also Programme fährt, die extrem viel RAM brauchen und ein Terminalserver 128GB vRAM haben muss und sie auch auslastet, sollte er nach dieser Berechnung im Idealfall 12-16 vCPUs erhalten, mit den entsprechenden Auswirkungen auf Scheduling, Ready Time usw.

 

EDIT: Es bleibt natürlich noch die Frage, wieviele vCPUs ein Terminalserver *mindestens* haben sollte, um X User zufriedenstellend zu bedienen. Dies wird extrem davon abhängen, ob dieser Terminalserver a. Zugriff auf GPU hat (im Falle von Hyper-V also derzeit DDA) und b. in einer Version läuft, die von der GPU auch tatsächlich was hat (2016+). Ich würde, falls GPU tatsächlich verwendet wird, den CPU-Bedarf mindestens halbiert sehen. Da das Scheduling zwischen RDS- (oder auch ICA) Sessions auf einem Server anders funktioniert als zwischen VMs, ist es auch hier schwierig, verbindliche Richtwerte theoretisch zu generieren. Mehr als 5 User pro vCPU mit HyperThreading und ohne Grafik wird aber kaum zufriedenstellend möglich sein - und das kann auch nicht beliebig skaliert werden, denn so würdest Du bei einem Server mit 2x16 Cores (also 60 nutzbare htCores oder 120 vCPUs bei 2:1 overcommitment) bei 600 Sessions Packungsdichte auf einem Server landen, und dass dies unrealistisch ist, sollte jedem klar sein  

 

Wenn Du dich von erfahrenen VDI-Consultants beraten lässt, werden sie ihre Erfahrungen mit Dir teilen. Die User Experience wird aber in jedem Fall im PoC beurteilt werden müssen. /EDIT.

 

Für Infrastruktur-Workloads muss man schauen, ob sie parallelisieren können und müssen. SQL kann es, wenn aber in den Datenbanken keine Stored Procedures verwendet werden, sondern höchstens mal Views oder Functions, wird der Parallelisierungsgrad nicht so hoch ausfallen. Exchange könnte zwar theoretisch (seit 2013) einen CPU-Thread pro Datenbank zuweisen, aber die Datenbank-Engine lastet die CPU nicht aus, sondern höchstens die Indexing-Engine, und die ist nicht wirklich parallelisierungsfähig und willig. Bei IIS muss man schauen, ob die AppPools so konfiguriert sind, dass sie mehrere Worker spawnen können.

Das Ziel dieser Übung ist es, Server-VMs zu bestimmen, die mehr als 2 vCPUs brauchen können, und dort jeweils die minimale Anzahl zu errechnen, die man wirklich braucht. Alle anderen Windows Server 2012+ VMs kriegen 2 vCPUs zugewiesen. 2008 und Lightweight-Linux-Maschinen (Betonung liegt auf Lightweight) könnten evtl. mit einer vCPU zufriedenstellend bedient werden, in diesem Fall kriegen sie auch nur die eine, bis sie sich beschweren.

Die Logik ist also, sich der benötigten CPU-Anzahl stets von unten anzunähern. Dabei wieder die CPU Ready Time im Blick behalten. Wenn diese nach einer Anpassung von vCPU-Zuweisungen dauerhaft ansteigt, braucht man mehr physische Rechenleistung.

 

Artikel kann ich keinen beibringen. Alles, was bei @NilsK steht, gilt für den Teil der Planung, der in Excel passiert, nach wie vor. Alle Optimierungen, die die Scheduler im Laufe der Jahre erfahren haben, sind nicht deterministisch, und deren Auswirkung kann nur durch Monitoring in einer konkreten Umgebung bewertet werden.

 

Bin aber jetzt schon gespannt auf weitere Stimmen, die ihre VDI seit Jahren erfolgreich bei 7:1 Overcommitment und die Infrastruktur-VMs bei 15:1 fahren  

 

bearbeitet 16. Januar 2022 von cj_berlin

[NilsK 2.781]

Moin,

 

Ich stimme zu, dass die generellen Betrachtungen aus meinem Artikel für VDI in allen seinen Geschmacksrichtungen nicht oder nur sehr begrenzt zutreffen.

 

Daneben stimme ich aber auch der Beobachtung zu, dass man in der freien Wildbahn unglaublich viel Murks in den Konfiguratoren antrifft.. Und ich wage weiterhin zu behaupten, dass man bei "allgemeinen" Konfigurationen die CPU deutlich stärker auslasten kann, als es oft geschieht.

 

Gruß, Nils

[zahni 521]

Ich kann hier beitragen, dass man darauf achten sollte, die echten CPU Cores (ohne HT) und den verfügbaren RAM pro NUMA-Node nicht überschreiten darf und vielleicht auch nicht voll ausschöpfen sollte.