Anzahl vCPUs für einen DC

[mwiederkehr 388]

Bei den vCPUs gilt "so wenig wie möglich, so viel wie nötig". Ich konnte mich aber nie dazu durchringen, eine VM mit nur einem Core zu betreiben. Wenn die Maus während Windows Updates ruckelt, bekommt man ein ungutes Gefühl. Zudem platziert der Core-Scheduler, der seit Server 2019 standardmässig aktiv ist, keine vCPUs unterschiedlicher VMs auf dem gleichen Core. Dies zur Verhinderung von Spekulations-Angriffen. Deshalb wohl auch die Empfehlung, immer eine gerade Zahl zu verwenden.

 

DCs bekommen bei mir deshalb zwei vCPUs. Zwar müssen nicht mehr alle vCPUs gleichzeitig laufen, aber der Scheduling-Overhead wächst mit deren Anzahl. Zudem stösst man irgendwann an die NUMA-Grenze. Ist man zu grosszügig, überschreitet man je nach Umgebung die Empfehlungen zum Overcommit. Da schreibt Microsoft von 4:1 als empfohlen und bis 8:1 unterstützt, wobei das natürlich keine fixe Grenze ist.

 

Bei Kunden habe ich mehrmals gesehen, dass jede VM so viele vCPUs hatte wie der Host Cores. Das ist gut gemeint, aber kontraproduktiv. Man sollte keine Angst vor CPU-Auslastung haben, schliesslich soll die CPU arbeiten. Wenn ein Datenbankserver im Tagesmaximum zu 80 % ausgelastet ist, ist das gut und kein Warnsignal für "der braucht viermal mehr Cores".

 

[wznutzer 36]

vor 23 Minuten schrieb cj_berlin:

für welchen Unsinn zahlst Du denn 180 €/Stunde? Frage für einen Freund

vor 1 Minute schrieb BOfH_666:

Wow ... ich bin neugierig .... wo kosten denn VMs mit 2 CPUs und 4GiB RAM 180€/h? ... in Azure wären das je nach Kategorie eher so 85€ - 120€/Monat.

Oh nein, Missverständnis, nicht die VM. Ich meine die Beratungssätze der Systemhäuser in der Gegend, die liegen je nach Junior, Senior, Architekt usw. bei bis zu 180€/Stunde.

vor 5 Minuten schrieb mwiederkehr:

Zwar müssen nicht mehr alle vCPUs gleichzeitig laufen, aber der Scheduling-Overhead wächst mit deren Anzahl.

Das wusste ich nicht. Bedeutet das, dass die VM auch Rechenzeit zugeteilt bekommen würde, wenn diese z. B. 4 vCPUs zugewiesen hat, aber gerade nur 1 Core "frei" ist.

[wznutzer 36]

Ergänzung:

Damit ich nicht dumm bleiben muss, habe ich mal nachgelesen. Hyper-V kann inzwischen wohl paralleles Scheduling. D. h. wie @mwiederkehr geschrieben hat, den vCPUs nacheinander Rechenzeit geben. Allerdings verteilt der Scheduler innerhalb der VM trotzdem auf alle vCPUs. Das geht aber nur begrenzt, denn der Scheduler in den VMs verteilt die Aufgaben trotzdem auf alle vCPUs. Je nach Auslastung führt das dann zu vielem wechseln auf der CPU und auch dann wieder zu Wartezeiten, was dann der erwähnte Overhead ist.

[testperson 1.758]

vor 9 Stunden schrieb cj_berlin:

Was würden denn Orgs mi 300.000 Usern machen, sich DCs mit 300 Kernen bauen?

 

Immerhin könn(t)en sie es jetzt. :)

 

What's new in Windows Server 2025 | Microsoft Learn

Zitat

Non-uniform Memory Access (NUMA) support: AD DS now takes advantage of NUMA-capable hardware by using CPUs in all processor groups. Previously, Active Directory would only use CPUs in group 0. Active Directory can expand beyond 64 cores.

 

[mwiederkehr 388]

vor 9 Stunden schrieb wznutzer:

Bedeutet das, dass die VM auch Rechenzeit zugeteilt bekommen würde, wenn diese z. B. 4 vCPUs zugewiesen hat, aber gerade nur 1 Core "frei" ist.

Wie Du inzwischen selbst nachgelesen hast, kann der Hyper-V mittlerweile die vCPUs nacheinander "ausführen". Jede vCPU ist ein eigener Thread. Leider halten sich die (öffentlich zugänglichen) Informationen über den Scheduler in Grenzen, so dass ich nicht weiss, wann genau das eingeführt wurde.

 

Das "Problem" bleibt, dass die VM nicht weiss, was der Hyper-V macht. Je nach Anwendung läuft eine Berechnung auf zwei Threads, die das Gastbetriebssystem auf zwei vCPUs verteilt und weil der eine Thread auf das Resultat des anderen angewiesen ist, dauert die Berechnung länger, als wenn sie nacheinander auf einer vCPU ausgeführt worden wäre. Wobei das in den meisten Fällen eher theoretische Überlegungen sind.

 

Bei massiver CPU-Überbuchung habe ich schon Probleme in der Praxis gesehen. Terminalserver waren so langsam, dass sogar Eingaben verzögert erschienen sind. Dabei hat der Task Manager nur wenige Prozent Auslastung angezeigt. In der Panik wurden denn noch mehr vCPUs zugeteilt...

[NorbertFe 2.155]

vor 3 Minuten schrieb mwiederkehr:

Bei massiver CPU-Überbuchung habe ich schon Probleme in der Praxis gesehen.

Nenn doch mal konkrete Zahlen. Wieviele Physical Cores gab es und wieviele vCPUs waren vergeben? Damit man einfach mal ne Größenordnung sieht. Denn eines ist ja logisch, wenn ich viel mehr zuordne als am Ende vorhanden ist und dann die VMs eben nicht vor sich hin-idlen sondern tatsächlich "arbeiten" ist logischerweise die physikalische Leistungsgrenze irgendwann erreicht.

[mwiederkehr 388]

Der Extremfall waren 273 zugeteilte vCPUs auf einem Host mit 32 Cores. Das ergibt eine Überbuchung von 8.5:1 bzw. 4.3:1, wenn man HT einberechnet (was ja bekanntlich nicht "voll" zählt).

 

Auf diesen VMs konnte man zeitweise kaum arbeiten, obwohl die Auslastung weder in den VMs noch auf dem Host über 20 % war. Die "CPU Wait Time Per Dispatch" war extrem hoch (habe mir den Wert leider nicht notiert).

 

Als man die zugeteilten vCPUs massiv reduziert hat (zwei für DCs, einen pro zwei bis vier Benutzer auf den Terminalservern etc.), war das System erheblich schneller.

 

Wobei zu erwähnen ist, dass der Host auf Windows Server 2016 lief, bei dessen Scheduler immer alle vCPUs einer VM gleichzeitig Ausführungszeit bekommen mussten. Da dauert es halt schon, bis 24 Cores für den TS frei sind, wenn jeder Webserver auch schon 16 Cores hat... Zudem wurde durch das Überschreiten der NUMA-Grenzen Performance verschenkt.

[daabm 1.384]

Am 11.2.2025 um 19:48 schrieb wznutzer:

Aus dem Grund, dass sonst die AD-DB beschädigt wird?

 

 

Ich weiß nicht, ob es in Deutschland Firmen gibt, die mehr DCs betreiben als wir (vermutlich ja - aber auf jeden Fall sind wir ganz oben mit dabei). Wir legen die vCPU nach Anzahl der zu erwartenden Logon-User aus, und uns ist noch nie (!) deswegen eine AD-DB kaputt gegangen. Die Dinger sind schweinsmäßig rock-stable... Such Dir nen anderen Berater.

Am 11.2.2025 um 22:15 schrieb cj_berlin:

Nein, da wird nichts beschädigt. Es war auch nie eine feste Größe, sondern eher ein Richtwert. Was würden denn Orgs mi 300.000 Usern machen, sich DCs mit 300 Kernen bauen?

 

Da kann ich darüber berichten, wenn das wirklich jemand braucht...