Interpretation der ready Werte in einem HA Cluster

[Login]

Hallo zusammen,

ich habe Verständnisprobleme bei einer Performanceproblematik. Kann jemand helfen?

Situation:

3 ESXi Hosts an einem Shared SAS/SAS Storage. 2 Pfadig angebunden, MRU.

Nun stelle ich fest, dass der ready Wert auf allen drei Hosts auffällig weit auseinander geht.

1. Frage: Was sagt der ready Wert, gemessen auf einem Host aus und warum ist dieser immer höher als der seiner VMs, aber nie die Summe dieser einzelnen Werte? Sind die Richtwerte für den Host die selben wie für die VMs?

2. Frage: Wie kann ein readywert einer VM über 1000 steigen, solange der Host vCPU technisch def. noch lange nicht überbucht ist?

Am besten ich stelle ein paar Screenshots zur Verfügung, die evtl. etwas besser beschreiben können als ich.

1. Host mit 30 logischen CPUs (Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz), 130GB RAM.



Ready Wert auf Host:



Ready Wert bei VM auf Host:




2. Jetzt ein Host mit 24 logischen CPUs (Intel(R) Xeon(R) CPU X5680 @ 3.33GHz), 98GB RAM.



Ready Wert auf Host:



Ready Wert bei VM auf Host:



Kurios, dass auf dem leistungsfähigeren Host deutlich höhere Readywerte existieren. Wie gesagt, kann hier jemand den Sinn erklären?

Ressourcenzuteilung ist "default". Ram ist auf allen Hosts mehr als genug vorhanden.

LG
Conne

[bla!zilla]

Readywert ist ein Ausdruck dafür, wie lange Maschinen darauf warten, im Scheduler eingeplant zu werden. Das ist überlicherweise ein Indikator dafür, dass du zu viele Maschinen mit zu vielen vCPUs hast.

Führe mal dieses PowerCLI Script aus und poste hier die Werte.

[~thc]

Der obere Host hat vermutlich 2 Xeon E5-2690 - das sind 16 physische Kerne (32 logische mit HyperThreading) und der untere 2 Xeon X5680 - das sind 12 physische Kerne (24 logische mit HyperThreading).

Ich würde einen Kern für das ESXi abziehen, oben 15 vCPUs verteilen und unten 11. Dann hättest du keine Ready-Probleme selbst bei hoher Last aller VMs. Wenn du mehrere Niedriglast-VMs hast, kannst du auch entsprechend vCPUs überbuchen.

EDIT: Zu deinen Fragen:

1. Ich vermute, dass der Ready-Wert des Hosts nicht die Summe darstellt, sondern wie lange er selbst warten muss - die VMs haben Vorrang.

2. HyperThreading ersetzt keine echten Kerne.

[Login]

nabend,

ja, das macht natürlich Sinn.

Interessant, dass die VMs in dem Fall dem Host vorgezogen werden.

@Bla!zilla: ich scheitere am Ausführen des Scripts. Meine Erfahrungen mit der PowerCLI halten sich in Grenzen. Was für Voraussetzungen müssen für das Script geschaffen werden?

[Login]

[irix]

Das Script setzt vorraus das du dich bereits mit einem Connect-VIServer angemeldet hast an deinem vCenter und deiner PowerCLI. Ansonsten muss man noch die *.dll laden.

Aber wenn ich mir den Code angucke macht das Script nichts anderes als das Verhaeltnis von vCPUs zu pyhs. Cores auszurechnen. Es werden auch ausgeschaltete VMs mit einbezogen was das Ergebnis verfaelschen kann.

Sofern vSphere PowerCLI installiert ist starte man die vSphere CLI und gebe dann

Code: Alles auswählen

Connect-VIServer -server  deinvcs.example.com

ein.

Gruss
Joerg

[irix]

Das Script definiert nur die Funktion. Du must sie dann noch aufrufen

j

Code: Alles auswählen

PowerCLI C:\> get-cpuratio

Hostname                PhysicalThreads               vCPUs Ratio
--------                ---------------               ----- -----
esx-node-200.n...                  24                  79 3,29:1
esx-node-01.n...                  32                  84 2,63:1
esx-node-02.n...                  32                  91 2,84:1
esx-node-03.n...                  32                  49 1,53:1
esx-node-07.n...                  48                  31 0,65:1
esx-node-04.n...                  48                  17 0,35:1
esx-node-06.n...                  48                  41 0,85:1
esx-node-08.n...                  24                  12 0,50:1
esx-node-09.n...                  24                  11 0,46:1
esx-node-10.n...                  24                  12 0,50:1


[~thc]

Ich hatte "Login" so verstanden, dass die Bilder oben vollständig sind - also je 9 VMs auf beiden Hosts mit den angezeigten vCPUs.

oben: 28/32 = 0,875:1
unten: 21/24 = 0,875:1

[mbreidenbach]

zur Vervollständigung.für interessierte Mitleser...

Es werden auch ausgeschaltete VMs mit einbezogen was das Ergebnis verfaelschen kann.

Zeile ändern:

Code: Alles auswählen

$vms=Get-VM | where PowerState -eq PoweredOn

[bla!zilla]

EDIT: Zu deinen Fragen:

1. Ich vermute, dass der Ready-Wert des Hosts nicht die Summe darstellt, sondern wie lange er selbst warten muss - die VMs haben Vorrang.

Das ist leider falsch interpretiert. %RDY für den Host sind die für alle VMs kumulierten %RDY Werte. Der Wert ist pro VM, so dass 100% bei einer 1 vCPU Maschine 200% bei einer 2 vCPU Maschine entsprechen. Allgemein sollte %RDY nicht über 5% für eine 1 vCPU Maschine liegen. Dieser Wert bedeutet, dass die Maschine 5% ihrer Zeit darauf wartet, für einen Kern eingeplant zu werden. Dementsprechend sind 20% bei einer 4 vCPU Maschine auch noch okay.

Hohe %RDY Werte sind das Ergebnis von falsch oder schlecht konfigurierten VMs. Wer meint allen VMs 4 vCPUs auf einem QC ohne HT geben zu müssen, der wird das kennen... vCPU:pCPU Verhältnisse von 3:1 sind meist okay, es kommt aber auf den konkreten Workload an.

[~thc]

Das ist leider falsch interpretiert. %RDY für den Host sind die für alle VMs kumulierten %RDY Werte. Der Wert ist pro VM, so dass 100% bei einer 1 vCPU Maschine 200% bei einer 2 vCPU Maschine entsprechen. Allgemein sollte %RDY nicht über 5% für eine 1 vCPU Maschine liegen. Dieser Wert bedeutet, dass die Maschine 5% ihrer Zeit darauf wartet, für einen Kern eingeplant zu werden. Dementsprechend sind 20% bei einer 4 vCPU Maschine auch noch okay.

"Login" hatte zwar nicht die %RDY-Werte (esxtop) angegeben, sondern die Performance-Chart-Werte in Millisekunden, aber da diese ineinander umrechenbar sind (1% = 200 ms), hast du natürlich Recht. Ich habe inzwischen bei meinen Hosts mal nachgerechnet - die Millisekunden-Summe der VMs entspricht der Angabe vom Host.

Hast du mal eine Quelle für deine 5% pro vCPU Regel? Ich kann dazu nichts finden.

[bla!zilla]

ESXTOP gibt die %RDY in Prozent aus. Alternativ kann man auch die PowerCLI verwenden.

Die 5% haben sich über die Jahre als Wert herausgestellt, bei dem noch alles okay ist. Für eine 1 vCPU Maschine verwende ich:

=< 5% = grüner Bereich
6% - 9% = sollte man im Auge behalten
>= 10% = Da sollte man tätig werden

Für eine 2 vCPU Maschine gelten die doppelten Werte usw.

[Login]

Ich habe inzwischen bei meinen Hosts mal nachgerechnet - die Millisekunden-Summe der VMs entspricht der Angabe vom Host.

Kewl, die Mühe habe ich mir bisher tatsächlich nicht gemacht. Dazu war die Vermutung noch nicht ausgereift genug.

Also doch die Summe aller VMs? Dann hat der Wert erst mal gar nichts mit dem ESXi OS zu tun, sondern ist als Zusammenfassung der VMs anzusehen.

Langsam kommt Licht ins Dunkle.

Nur leider scheitere ich immer noch am Ausführen des popeligen Scripts :-/ Wie auf dem Screenshot zu sehen ist, habe ich als erstes mit Connect-VIServer den vCenter verbunden, authentifiziert wurde sich per passthough mit der Windowsanmeldung. In der Theorie sollte das passen, der Dom-Admin ist in der AdminGruppe der System-Domain enthalten.
Es kommt noch die Sicherheitswarnung für das Cert. aber mit "M" sollte das Script ausgeführt werden. Wie man sehen kann, passiert aber einfach nichts.

Gruß,
Conne

Edit: kurios, Get-VM listet aber alle VMs des Clusters auf.

[irix]

Das "ausfuehren" dieses Scriptes ist nur Definition einer Funktion. Nach dem laden must du diese nun auch mal aufrufen. Gebe dazu "get-cpuratio" ein und warte einige Sekunden.

Gruss
Joerg

[Login]

Was mache ich nur falsch



Sorry Jungs, für die Anfängerrunde mir der PowerCLI...

[irix]

Hmm.... dann lass einfach mal per C&P den Code aus dem Script in die Shell fallen und rufe dann das CMDLET auf.

Gruss
Joerg

[Login]

Hmm.... dann lass einfach mal per C&P den Code aus dem Script in die Shell fallen und rufe dann das CMDLET auf.

holla, so klappt es. Klingt komisch, ist aber so.

Naja, warum ist mir jetzt erst mal egal. Habe in diesem Fred schon genug neue Erkenntnisse erwerben können



Danke euch für alles hier...

Gruß,
Conne