Die Foren-SW läuft ohne erkennbare Probleme. Sollte doch etwas nicht funktionieren, bitte gerne hier jederzeit melden und wir kümmern uns zeitnah darum. Danke!

CPU overprovisioning verhindern

Alles zum Thema vSphere 6, ESXi 6.0 und vCenter Server.

Moderatoren: irix, continuum, Dayworker

Member
Beiträge: 475
Registriert: 08.08.2008, 10:45

CPU overprovisioning verhindern

Beitragvon pirx » 04.04.2016, 11:17

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?

Profi
Beiträge: 993
Registriert: 31.03.2008, 17:26
Wohnort: Einzugsbereich des FC Schalke 04
Kontaktdaten:

Beitragvon kastlr » 04.04.2016, 11:36

Hallo,

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

Gruß,
Ralf

Member
Beiträge: 475
Registriert: 08.08.2008, 10:45

Beitragvon pirx » 04.04.2016, 12:19

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.

Profi
Beiträge: 858
Registriert: 18.03.2005, 14:05
Wohnort: Ludwigshafen

Beitragvon Martin » 04.04.2016, 12:22

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

Member
Beiträge: 475
Registriert: 08.08.2008, 10:45

Beitragvon pirx » 04.04.2016, 15:29

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.

Experte
Beiträge: 1335
Registriert: 25.04.2009, 11:17
Wohnort: Thüringen

Beitragvon Supi » 04.04.2016, 15:46

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.

Member
Beiträge: 475
Registriert: 08.08.2008, 10:45

Beitragvon pirx » 04.04.2016, 15:51

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

Experte
Beiträge: 1335
Registriert: 25.04.2009, 11:17
Wohnort: Thüringen

Beitragvon Supi » 04.04.2016, 16:15

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. 8)

Member
Beiträge: 475
Registriert: 08.08.2008, 10:45

Beitragvon pirx » 04.04.2016, 17:03

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.

Member
Beiträge: 243
Registriert: 27.03.2012, 15:03
Wohnort: Würzburg

Beitragvon Gad » 05.04.2016, 07:35

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


Zurück zu „vSphere 6.0“

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast