ESXi-Lizenzen Enterprise Plus (up to 32 cores) bei physisch mehr vorhandenen Kernen macht was?

[Misdemeanor]

Was passiert eigentlich, wenn man im vCenter ESXi-Lizenzen eingespielt hat, die den Hinweis "up to 32 cores" beinhalten, wenn die Server selbst aber (durch zwei Sockel/CPUs) insgesamt jeweils 48 physische Kerne haben?

Ein Kollege bat mich heute Morgen lizenztechnisch um Rat und da ist mir das aufgefallen – eine Antwort habe ich aber auch nicht. 🤷‍♂️ es ist ja nicht so, als würden 48-Kern-Systeme leistungstechnisch beschränkt werden, dass nur 32 Kerne funktionieren.

Wie wird damit umgegangen? Ist es quasi einfach als Lizenzbruch zu verstehen, wenn man nur die CPUs lizenziert, aber insgesamt pro Sockel mehr Kerne hat als offiziell lizenziert sind? Bei uns ist der Pool irgendwas um 896 Kerne, also alles safe, ich verstehe es nur nicht.

 

[Rickmer]

mMn ist die Dokumentation von ESXi da relativ eindeutig?
https://docs.vmware.com/en/VMware-v...UID-7AFCC64B-7D94-48A0-86CF-8E7EF55DF68F.html

Auch anhand diesem Beispiel:

If you use the licensing model with up to 32 cores, you can assign a vSphere license for 10 32-core CPUs to any of the following combinations of hosts:

• Five 2-CPU hosts with 32 cores per CPU
• Five 1-CPU hosts with 64 cores per CPU
• Two 2-CPU hosts with 48 cores per CPU and two 1-CPU hosts with 20 cores per CPU

Solange die Gesamt-Anzahl der Core-Lizenzen die ihr besitzt mindestens so viele Cores beinhaltet wie ihr insgesamt vorhanden habt ist alles im grünen Bereich.
Könnte man nicht summieren müssten in dem letzten Beispiel 12 32-core Lizenzen vorhanden sein.

 

[Khorneflakes]

Ein Host mit zwei CPUs mit je 48 Cores braucht drei Lizenzen.

Also ja, das ist dann ein Lizenzverstoß und du bist unterlizensiert, wenn du dafür nur zwei Lizenzen hättest.

 

[Drewkev]

Was passiert eigentlich, wenn man im vCenter ESXi-Lizenzen eingespielt hat, die den Hinweis "up to 32 cores" beinhalten, wenn die Server selbst aber (durch zwei Sockel/CPUs) insgesamt jeweils 48 physische Kerne haben?

Du verstößt damit gegen die Lizenzbedingungen.

 

[GrillSgt]

Früher ließen sich die Lizenzen nicht mal zuweisen wenn die Anzahl ungenügend war. Hat sich das geändert?
Abgesehen davon ist es natürlich Lizenzbruch. Nicht alles was technisch geht, ist auch lizenztechnisch einwandfrei => ergo unterlizenziert (nicht lizensiert!)

 

[xxMuahdibxx]

Core-Lizenzierung: Jeder physische Prozessorkern eines Hosts benötigt eine Core-Lizenz.

Mindestlizenzierung: CPUs mit 16 Prozessorkernen oder weniger benötigen 16 Core-Lizenzen. Für eine 8-Core-CPU müssen Sie also 16 Core-Lizenzen kaufen.

 

[=dantE=]

Wenn der Host 48 Cores aufweist, dann sind diese auch zu lizensieren.
(Core Point Metrik, es sei denn ihr habt spezielle Verträge).
Ihr seid definitiv unterlizensiert.

Hat sich das geändert?

Offensichtlich ...

 

[Rickmer]

Ihr seid definitiv unterlizensiert.

Wie kommst du darauf?
Er schreibt doch, dass die insgesamt 896 Cores lizenziert haben, vermutlich in 28x 32-Core Lizenzen.

Damit kann man (mWn) 9x 48-core dual-socket Server betreiben bevor man mit dem 10ten unterlizenziert wäre.

 

[=dantE=]

und was ist mit den 48 cores je Socket, oder blick' ich jetzt hier nichts?

 

[GrillSgt]

Dann ist die Sache doch einfach:
Anzahl der CPUs im Cluster x phys. Kerne (>= 16) = Anzahl benötigter Core Lizenzen.
Hier dann, Anzahl der CPUs x 48 = Anzahl benötigter Lizenzen.

 

[Misdemeanor]

Also zunächst einmal Danke für eure Antworten. Ich hatte mir schon so etwas gedacht, dass ein 48-Kern-System im Prinzip also 32+16 zu zählen ist, sprich dass man mit drei solcher Lizenzen zwei physische Server zu lizenzieren hätte, also 32 + 32 + 32 = 96 | 2 x 48 = 96 – ein Blick in die Doku hätte geholfen; 😁 my bad.

Und Nein, wir sind definitiv nicht unterlizenziert. Es ist nur eine Frage gewesen, entsprechend begeht mein AG keinen Lizenzbruch.

Die Frage kam auf, weil ein Kollege neulich in unserem RZ ein Lizenz-Reporting-Tool installiert hat (vCloud Usage Meter), welches zu Broadcom nach Hause telefoniert und irgendwas von nochmal knapp 100 physischen Kernen mehr im Inventar berichtet hat, die wir wiederum nicht nachvollziehen können. Die Lizenz umfasst, wie erwähnt, knapp 900 Kerne, wovon aber noch nicht einmal die Hälfte in Benutzung ist.

Es verbleiben also dennoch einige Fragezeichen, aber da ist ein Distri dazwischengeschaltet, dem wir einen vCenter-Auszug der Hosts und weiteren Details geschickt haben, der das auseinanderklamüsern muss. Wäre ja nicht das erste Mal, dass es Unklarheiten/Unstimmigkeiten bezüglich der Lizenzen gibt, und das ist mit dem Wechsel zu Broadcom nicht besser geworden. 🤔

 

[xxMuahdibxx]

Auch bedenken das die Lizenzen pro CPU gerechnet werden also jede CPU mit weniger als 16 Kernen = 1 Lizenz ...

und dann ist die Frage welche Sprünge da sind ... also eine 24 Core CPU bräuchte wohl ja auch 32 Lizenzen.

 

[Sobber]

Beim alten Model lizenzierst du die Cpus.
Eine Cpu mit 33-64 Kernen braucht eben 2 Lizenzen. Wenn 2 solcher CPUs in einem Server sind, dann sind es eben 4 Lizenzen für den Server, nicht nur 3.

Vgl: https://docs.vmware.com/en/VMware-v...UID-7AFCC64B-7D94-48A0-86CF-8E7EF55DF68F.html

 

[Rickmer]

Die Frage kam auf, weil ein Kollege neulich in unserem RZ ein Lizenz-Reporting-Tool installiert hat (vCloud Usage Meter), welches zu Broadcom nach Hause telefoniert und irgendwas von nochmal knapp 100 physischen Kernen mehr im Inventar berichtet hat, die wir wiederum nicht nachvollziehen können.

Schau mal hier rein:
https://knowledge.broadcom.com/external/article/339588/counting-cpu-licenses-needed-under-new-v.html

ggf. kommst du damit auf der Spur, wo die Kerne ausgelesen werden.

Beim alten Model lizenzierst du die Cpus.
Eine Cpu mit 33-64 Kernen braucht eben 2 Lizenzen. Wenn 2 solcher CPUs in einem Server sind, dann sind es eben 4 Lizenzen für den Server, nicht nur 3.

Auch richtig, falls es sich um das alte Lizenzmodell handelt. Da müsste man in Erfahrung bringen, exakt nach welchem Modell die Lizenzen besorgt wurden.

 

[GrillSgt]

Das "alte Modell" ist aber schon asbach uralt und gibt es bereits seit - ich meine Anfang 2020 - nicht mehr. Die Umstellung müsste schon irgendwann bei vSphere 6 gewesen sein.

 

[Misdemeanor]

Also, nochmals Danke an das rasche Feedback an alle.
Wie ich sehe, war ich nicht der Einzige, bei dem es Unklarheiten gab, jetzt ist es klar(er).