Wie viel Streit ist in VMware zu viel?

Seit einiger Zeit versuche ich herauszufinden, warum einige unserer geschäftskritischen Systeme Berichte über "Langsamkeit" erhalten, die von mild bis extrem reichen. Ich habe mich kürzlich der VMware-Umgebung zugewandt, in der alle fraglichen Server gehostet werden.

Ich habe kürzlich die Testversion für das Veeam VMware Management Pack für SCOM 2012 heruntergeladen und installiert, aber es fällt mir schwer, die Zahlen, die mir gemeldet werden, zu glauben (und mein Chef auch). Um meinen Chef davon zu überzeugen, dass die Zahlen, die er mir sagt, wahr sind, habe ich begonnen, den VMware-Client selbst zu untersuchen, um die Ergebnisse zu überprüfen.

Ich habe mir diesen VMware-KB-Artikel angesehen . speziell für die Definition von Co-Stop, die definiert ist als:

Zeitspanne, in der eine virtuelle MP-Maschine betriebsbereit war, die sich jedoch aufgrund von Konflikten mit der Ko-vCPU-Zeitplanung verzögerte

Dem übersetze ich

Das Gastbetriebssystem benötigt Zeit vom Host, muss jedoch warten, bis Ressourcen verfügbar sind, und kann daher als "nicht reagierend" eingestuft werden.

Ist diese Übersetzung korrekt?

Wenn ja, fällt es mir hier schwer zu glauben, was ich sehe: Der Host, der die Mehrheit der "langsamen" VMs enthält, zeigt derzeit einen CPU-Co-Stop-Durchschnitt von 127.835,94 Millisekunden an!

Bedeutet dies, dass die VMs auf diesem Host im Durchschnitt mindestens 2 Minuten auf die CPU-Zeit warten müssen?

Auf diesem Host befinden sich zwei 4-Core-CPUs und ein 8-CPU-Gast sowie ein 4-CPU-Gast.

Ich kann einige der Erfahrungen beschreiben, die ich in diesem Bereich gemacht habe ...

Ich bin nicht der Meinung, dass VMware die Kunden ( oder Administratoren ) in angemessener Weise über Best Practices aufklärt, und sie aktualisieren auch nicht frühere Best Practices, wenn sich ihre Produkte weiterentwickeln. Diese Frage ist ein Beispiel dafür, wie ein Kernkonzept wie die vCPU-Zuweisung nicht vollständig verstanden wird. Der beste Ansatz ist, mit einer einzelnen vCPU klein anzufangen, bis Sie feststellen, dass die VM mehr benötigt.

Für das OP verfügt der ESXi-Hostserver über zwei Quad-Core-CPUs, die 8 physische Kerne ergeben.

Das beschriebene Layout der virtuellen Maschine umfasst insgesamt 15 Gäste. 1 x 8 vCPU- und 14 x 4 vCPU-Systeme. Das ist viel zu überlastet, vor allem mit der Existenz eines einzelnen Gastes mit 8 vCPUs . Das macht keinen Sinn. Wenn Sie eine so große VM benötigen, benötigen Sie wahrscheinlich einen größeren Server.

Bitte versuchen Sie, die Größe Ihrer virtuellen Maschinen anzupassen. Ich bin mir ziemlich sicher, dass die meisten von ihnen mit 2 VCPU leben können. Das Hinzufügen virtueller CPUs beschleunigt die Ausführung nicht. Wenn dies also eine Lösung für ein Leistungsproblem darstellt, ist dies der falsche Ansatz.

In den meisten Umgebungen ist RAM die am stärksten eingeschränkte Ressource. Aber CPU kann ein Problem sein, wenn es zu viele Konflikte gibt. Sie haben Beweise dafür. RAM kann auch ein Problem sein, wenn einzelnen VMs zu viel zugewiesen wird .

Es ist möglich, dies zu überwachen. Die Metrik, nach der Sie suchen, lautet "CPU Ready%". Sie können dies vom Client vSphere zugreifen , indem Sie eine VM - Auswahl und gehen Performance> Overview> CPU Graph.

• Unter 5% CPU Ready - Es geht Ihnen gut.
• 5-10% CPU Ready - Beobachten Sie die Aktivität genau.
• Über 10% CPU Ready - Nicht gut.

Beachten Sie die gelbe Linie in der folgenden Grafik.

Würde es Ihnen etwas ausmachen, dies auf Ihren problematischen virtuellen Maschinen zu überprüfen und eine Rückmeldung zu erhalten?

In den Kommentaren geben Sie an, dass Sie einen Dual-Quad-Core-ESXi-Host haben und eine 8vCPU-VM und vierzehn 4vCPU-VMs ausführen.

Wenn dies meine Umgebung wäre, würde ich das als stark überversorgt betrachten . Ich würde höchstens vier bis sechs 4vCPU-Gäste auf diese Hardware setzen. (Dies setzt voraus, dass die betreffenden VMs über eine Auslastung verfügen, die es erforderlich macht, dass sie eine so hohe vCPU-Anzahl aufweisen.)

Ich gehe davon aus, dass Sie die goldene Regel nicht kennen ... Mit VMware sollten Sie einer VM niemals mehr Kerne zuweisen, als sie benötigt. Grund? VMware verwendet eine strenge gemeinsame Planung, die es VMs erschwert, CPU-Zeit zu erhalten, es sei denn, es sind so viele Kerne verfügbar, wie die VM zugewiesen ist. Dies bedeutet, dass eine 4vCPU-VM nur dann 1 Arbeitseinheit ausführen kann, wenn 4 physische Kerne gleichzeitig geöffnet sind. Mit anderen Worten, es ist architektonisch besser, eine 1vCPU-VM mit 90% CPU-Auslastung zu haben, als eine 2vCPU-VM mit 45% Auslastung pro Kern.

Also ... ERSTELLEN SIE IMMER VMs mit einem Minimum an vCPUs und fügen Sie sie nur hinzu, wenn dies als notwendig erachtet wird.

Verwenden Sie für Ihre Situation Veeam, um die CPU-Auslastung Ihrer Gäste zu überwachen. Reduzieren Sie die Anzahl der vCPUs auf so viele wie möglich. Ich würde wetten, dass Sie bei fast allen Ihren vorhandenen 4vCPU-Gästen auf 2vCPU fallen könnten.

Zugegeben, wenn all diese VMs tatsächlich über die CPU-Auslastung verfügen, die für die vCPU-Anzahl erforderlich ist, müssen Sie lediglich zusätzliche Hardware kaufen.

Die 127.835,94 Millisekunden sind eine Summe, und Sie müssen durch die Abtastzeit dividieren, um die korrekten% RDY-Werte zu erhalten. Es sieht so aus, als würden Sie jetzt bereits die korrekten% RDY-Werte erhalten. Sie können mit dem Verhältnis von vCPU zu physischer CPU ziemlich viel anfangen, aber nicht so, wie Sie es tun.

Sie haben viel zu viele Quad-vCPU-VMs und sogar eine 8-vCPU-VM. Es gibt einige Qualitätsantworten, in denen bereits die richtige Dimensionierung erörtert wird, und einige Konsequenzen, wenn Zyklen nicht auf weniger vCPUs konsolidiert werden. Die eine Sache, die ich klarstellen wollte, ist, dass es zwar nicht länger der Fall ist, dass eine VM warten muss, bis die Anzahl der physischen CPUs, die der Anzahl der vCPUs entspricht, verfügbar ist, bevor Befehle verarbeitet werden können, dies ist jedoch sehr nachteilig übermäßige Bereitstellung dieser Größenordnung mit dem Verhältnis von VMs mit mehreren vCPUs zu physischen Kernen. 64 vCPUs auf 8 Kernen liegen weit über dem Maximalverhältnis von 4 zu 1. Ich nehme an, Sie haben HT auf diesen Prozessoren, also haben Sie 16 logische Kerne? Das mag bei 1 und 2 vCPU-VMs mit geringer Auslastung in Ordnung sein, aber wenn Sie eine hohe Auslastung der VMs haben, ist dies schwer zu bewerkstelligen.

Zu Ihrer Information Die HT-Prozessoren werden in den Berechnungen zur Prozessorauslastung in% nicht verwendet. Wenn also 32 logische Kerne auf einem Server mit 2,4 GHz ausgeführt werden, ist die Auslastung bei 38,4 GHz zu 100%. Wenn Sie also sehen, dass die Lastdurchschnitte mehr als 1,0 anzeigen, ist dies der Grund.

Hier ist ein ESXi-Host, auf dem ein Verhältnis von 3,5 zu 1 vCPU zu physischer CPU (einschließlich HT-Kerne) mit einem durchschnittlichen% RDY von 3% ausgeführt wird.

11:13:49pm up 125 days  7:20, 1322 worlds, 110 VMs, 110 vCPUs; CPU load average: 1.34, 1.43, 1.37


  %USED    %RUN    %SYS   %WAIT %VMWAIT    %RDY   %IDLE  %OVRLP   %CSTP  %MLMTD  %SWPWT 
  13.51   15.87    0.50  580.17    0.03    4.67   66.47    0.29    0.00    0.00    0.00 
  15.24   18.64    0.43  491.54    0.04    4.65   63.70    0.43    0.00    0.00    0.00 
  13.44   16.40    0.44  494.10    0.02    4.33   66.24    0.48    0.00    0.00    0.00 
  13.75   16.30    0.51  494.26    0.32    4.32   66.06    0.35    0.00    0.00    0.00 
  17.56   20.72    0.58  489.35    0.04    4.31   60.76    0.45    0.00    0.00    0.00 
  13.82   16.43    0.50  494.12    0.07    4.31   66.26    0.26    0.00    0.00    0.00 
  13.65   16.81    0.49  493.81    0.03    4.21   65.93    0.37    0.00    0.00    0.00 
  13.73   16.51    0.42  493.63    0.09    4.06   66.24    0.29    0.00    0.00    0.00 
  13.89   16.37    0.55  580.61    0.04    3.95   66.69    0.28    0.00    0.00    0.00 
  14.02   17.00    0.33  494.11    0.03    3.93   66.10    0.29    0.00    0.00    0.00 
  13.44   15.84    0.49  495.17    0.04    3.87   67.24    0.27    0.00    0.00    0.00 
  13.59   15.84    0.50  580.27    0.04    3.81   67.24    0.44    0.00    0.00    0.00 
  17.10   19.86    0.50  490.97    0.04    3.74   62.21    0.39    0.00    0.00    0.00 
  13.32   15.77    0.50  495.34    0.03    3.73   67.47    0.27    0.00    0.00    0.00 
  13.43   16.15    0.48  494.95    0.05    3.72   67.09    0.38    0.00    0.00    0.00 
  13.44   16.47    0.49  580.88    0.04    3.72   66.81    0.40    0.00    0.00    0.00 
  13.71   17.00    0.29  494.13    0.03    3.71   66.26    0.37    0.00    0.00    0.00 
  17.34   20.41    0.39  490.50    0.05    3.70   61.70    0.37    0.00    0.00    0.00 
  13.42   16.19    0.50  495.07    0.03    3.66   67.15    0.38    0.00    0.00    0.00 
  13.56   16.23    0.48  494.97    0.03    3.60   67.12    0.30    0.00    0.00    0.00 
  14.95   17.53    0.42  578.82    0.09    3.57   65.72    0.35    0.00    0.00    0.00 
  13.44   16.07    0.56  581.14    0.04    3.54   67.34    0.40    0.00    0.00    0.00 
  17.19   21.27    0.37  575.41    0.04    3.44   61.08    0.51    0.00    0.00    0.00 
  13.57   16.99    0.30  580.64    0.01    3.37   66.69    0.38    0.00    0.00    0.00 
  13.79   16.25    0.43  495.25    0.04    3.35   67.39    0.39    0.00    0.00    0.00 
  11.90   14.67    0.30  496.86    0.02    3.31   69.00    0.36    0.00    0.00    0.00 
  17.13   19.28    0.56  491.83    0.03    3.30   63.26    0.48    0.00    0.00    0.00 
  14.01   16.17    0.50  495.56    0.01    3.30   67.66    0.39    0.00    0.00    0.00 
  16.86   20.16    0.57  491.19    0.05    3.20   62.44    0.43    0.00    0.00    0.00 
  14.94   17.46    0.42  580.05    0.08    3.16   66.24    0.40    0.00    0.00    0.00 
  14.56   16.94    0.36  494.86    0.08    3.14   66.91    0.42    0.00    0.00    0.00

......

Seitdem haben wir Veeam ONE installiert, das einiges an Aufschluss darüber gibt, wo unsere Leistungsprobleme liegen. Durch Betrachten des Bildschirms "CPU Bottlenecks" in Veeam ONE und anschließende Fehlerbehebung bei einer virtuellen Maschine, die nicht mehr reagiert: Vergleich der CPU-Auslastung von VMM und Gast als Referenz haben wir herausgefunden, wo all unsere "inakzeptablen" Konflikte liegen.

Ein kleiner Tipp, den ich speziell teilen wollte, ist, dass ich in einem Fall die CPU-Konflikte nicht beseitigen konnte, bis ich den Snapshot entfernt habe, der sich auf der VM befand. Hoffe das hilft jemandem.