CPU overprovisioning verhindern

[pirx]

Hallo,

wir haben von einem Applikationshersteller in einem internen Projekt aktuell die Vorgabe, VMs mit einer 1:1 Zuordnung von physischem Core und virtueller CPU zu konfigurieren. Das ganze ist ein recht heißes Eisen, wenn die VMs Probleme haben, wirkt sich das unmittelbar finanziell aus. An dem Standort gibt es bereits einen Cluster in dem ca. 40 VMs laufen.

Ich war eigentlich der Meinung das ich pro VM diverse Parameter setzen kann, die sicherstellen, dass die VM sich den Core nicht mit einer anderen VM teilt (nicht unbedingt eine feste Zuweisung von einer VM zu einem bestimmten Core, sondern nur das der Core nicht geteilt wird). Ich haben bei den 6er Hosts die Option bzgl. CPU Latency gefunden, bin mir aber nicht sicher ob es das ist was ich suche. CPU Reservations verhindern glaube ich auch nicht das die vCPU sich den Core nicht teilt.

Die Alternative wäre es einen separaten Cluster aufzubauen und darüber sicherzustellen, dass darin immer genügend Ressourcen zur Verfügung stehen. Meine bevorzugte Lösung wäre es, die handvoll VMs im bestehenden Cluster mitlaufen zu lassen und diesen um einige Hosts zu erweitern. Idealerweise ohne diese 1:1 Zuordnung. Falls der Hersteller aber darauf besteht, sollte ich die Möglichkeit haben, die Vorgabe umzusetzen.

Hat mir dazu jemand einen Tipp?

[kastlr]

Hallo,

passt das hier in dein Anforderungsprofil?
Configure Processor Scheduling Affinity in the vSphere Client

Gruß,
Ralf

[pirx]

Das ist dann aber feste Zuweisung der VM zu einer CPU und verhindert vMotion, bzw. funktioniert nicht in einem DRS Cluster. Von mir aus kann die VM auf jeder beliebigen CPU laufen, solange sie die vCPUs/Cores exklusiv hat.

[Martin]

Reicht dafür nicht einfach eine entsprechend hoch gesetzte CPU reservation?

[pirx]

Ich bin mir nicht sicher. Ich halte das persönlich eh für Schmarrn. Die Applikation läuft schon an einem anderen Standort, dort gab es auch extrem hohe Anforderungen an die VMs (aber ohne 1:1 Verhältnis) und in den letzten Monaten lag die avg. CPU Auslastung bei < 10%. In der neuen Umgebung werden die größten Brummer die 4 Terminalserver a 20 vCPUs/Core mit 128 GB RAM werden. Ich hoffe immer noch das wir daraus 8 kleinere mit Loadbalancer machen können.

[Supi]

Hier scheint es als ob der APP Hersteller die schlechte Skalierung seiner Anwendung auf die VMWARE Umgebung schieben will.
Wie definierst du denn "Die VM hat Probleme", die sich gleich monetär auswirken?
Alles sehr diffus.
Oder sind das Hochfrequenz-Trading Anwendungen? Hier kommt es doch eher auf die Latenz des NW an.

[pirx]

Es geht nicht um banking. Wenn es mit der Applikation Probleme gibt, werden keine Waren mehr verschickt (Lagersystem).

[Supi]

Trotzdem seltsam. Selbst wenn der Host ausgelastet ist, dürfte doch nur die Antwortzeiten ein wenig nach oben gehen. > Lieferscheindruck dauert länger.
Wenn sich da die Anwendung ganz aufhängt, scheinen doch die Timeout Werte falsch gesetzt?
Aber bin auch kein Programmierer.

[pirx]

Das ist das übliche Vorgehen. Ressourcen wie zu Zeiten vorgeben als es noch keine Virtualisierung gab und den Support im Zweifelsfall verweigern. Ist leider bei vielen Herstellern so, auch bei Cisco mit ihren Appliances. Und da niemand das Risiko tragen will das so ein Projekt gegen die Wand fährt, wird im Zweifel mit Ressourcen um sich geworfen.

[Gad]

So eine Anwendung kenne ich aber auch.

Ist ein vorgefertigtes Windows Image des Herstellers auf dem ein paar Duzend zugekauft Tools laufen und irgendwas davon verträgt keine Latenz bei der CPU Zuweisung, sodass alles zusammen nicht mehr funktioniert und abstürzt sobald es zu lange dauert bis die VM Ihre CPU-Kapazitäten bekommt.

CPU Reservations haben das Problem gelöst bis der Cluster aufgerüstet war mit mehr Kernen, dann wurden die Reservations wieder entfernt.

CPU Ready war bei den Problemen übrigens bei 2-3%, das Verhältnis von CPU zu vCPU etwa 1:4