Quelle est la contention de trop dans VMware?

Depuis un certain temps maintenant, j'essaie de comprendre pourquoi bon nombre de nos systèmes critiques reçoivent des rapports de «lenteur» allant de légère à extrême. J'ai récemment tourné mon regard vers l'environnement VMware où tous les serveurs en question sont hébergés.

J'ai récemment téléchargé et installé la version d'essai du pack d'administration Veeam VMware pour SCOM 2012, mais j'ai du mal à croire (et mon patron aussi) les chiffres qu'il me rapporte. Pour essayer de convaincre mon patron que les chiffres qu'il me dit sont vrais, j'ai commencé à regarder le client VMware lui-même pour vérifier les résultats.

J'ai regardé cet article VMware KB ; spécifiquement pour la définition de Co-Stop qui est définie comme:

Durée pendant laquelle une machine virtuelle MP était prête à fonctionner, mais a subi un retard en raison d'un conflit de planification de co-vCPU

Que je traduis

Le système d'exploitation invité a besoin de temps de l'hôte, mais doit attendre que les ressources deviennent disponibles et peut donc être considéré comme "ne répondant pas"

Cette traduction semble-t-elle correcte?

Si c'est le cas, voici où j'ai du mal à croire ce que je vois: l'hôte qui contient la majorité des machines virtuelles qui sont "lentes" affiche actuellement une moyenne de CPU Co-stop de 127 835,94 millisecondes!

Est-ce à dire qu'en moyenne les VMs sur cet hôte doivent attendre 2+ minutes pour le temps CPU ???

Cet hôte possède deux processeurs à 4 cœurs et il a un invité de processeur 1x8 et des invités de processeur 14x4.

Je peux décrire certaines des expériences que j'ai eues dans ce domaine ...

Je ne pense pas que VMware fasse un travail adéquat pour éduquer les clients ( ou les administrateurs ) sur les meilleures pratiques, ni mettre à jour les anciennes meilleures pratiques à mesure que leurs produits évoluent. Cette question est un exemple de la façon dont un concept de base comme l'allocation de vCPU n'est pas entièrement compris. La meilleure approche consiste à commencer petit, avec un seul vCPU, jusqu'à ce que vous déterminiez que la machine virtuelle nécessite plus.

Pour l'OP, le serveur hôte ESXi possède deux processeurs quadricœurs, ce qui donne 8 cœurs physiques.

La disposition de la machine virtuelle décrite est de 15 invités au total; Systèmes 1 x 8 vCPU et 14 x 4 vCPU. C'est beaucoup trop engagé, en particulier avec l'existence d'un seul invité avec 8 processeurs virtuels . Cela n'a aucun sens. Si vous avez besoin d'une machine virtuelle aussi grande, vous avez probablement besoin d'un plus grand serveur.

Veuillez essayer de dimensionner correctement vos machines virtuelles. Je suis pratiquement certain que la plupart d'entre eux peuvent vivre avec 2 processeurs virtuels. L'ajout de CPU virtuels n'accélère pas les choses, donc si c'est un remède à un problème de performances, c'est la mauvaise approche à adopter.

Dans la plupart des environnements, la RAM est la ressource la plus contrainte. Mais le CPU peut être un problème s'il y a trop de conflits. Vous en avez la preuve. La RAM peut également être un problème si trop de ressources sont allouées aux machines virtuelles individuelles .

Il est possible de surveiller cela. La métrique que vous recherchez est "CPU Ready%". Vous pouvez y accéder depuis le client vSphere en sélectionnant une machine virtuelle et va Performance> Overview> CPU Graph.

• Moins de 5% CPU Ready - vous allez bien.
• 5-10% CPU Ready - Gardez un œil attentif sur l'activité.
• Plus de 10% CPU Ready - Pas bon.

Notez la ligne jaune dans le graphique ci-dessous.

Pourriez-vous vérifier cela sur vos machines virtuelles problématiques et en faire rapport?

Vous déclarez dans les commentaires que vous avez un hôte ESXi double quadricœur et que vous exécutez une machine virtuelle 8vCPU et quatorze machines virtuelles 4vCPU.

Si tel était mon environnement, je considérerais cela comme excessivement surapprovisionné . Je voudrais tout au plus mettre quatre à six invités 4vCPU sur ce matériel. (Cela suppose que les machines virtuelles en question ont une charge qui les oblige à avoir le plus haut nombre de vCPU.)

Je suppose que vous ne connaissez pas la règle d'or ... avec VMware, vous ne devez jamais attribuer à une machine virtuelle plus de cœurs qu'elle n'en a besoin. Raison? VMware utilise une co-planification quelque peu stricte, ce qui rend difficile pour les machines virtuelles d'obtenir du temps CPU, sauf s'il y a autant de cœurs disponibles que la machine virtuelle est affectée. Cela signifie qu'une machine virtuelle 4vCPU ne peut effectuer 1 unité de travail que si 4 cœurs physiques sont ouverts au même moment. En d'autres termes, il est préférable sur le plan architectural d'avoir une machine virtuelle 1vCPU avec 90% de charge CPU, puis d'avoir une machine virtuelle 2vCPU avec 45% de charge par cœur.

Alors ... TOUJOURS créer des VM avec un minimum de vCPU, et ne les ajouter que lorsque cela est jugé nécessaire.

Pour votre situation, utilisez Veeam pour surveiller l'utilisation du processeur sur vos invités. Réduisez le nombre de vCPU autant que possible. Je serais prêt à parier que vous pouvez passer à 2vCPU sur presque tous vos invités 4vCPU existants.

Certes, si toutes ces machines virtuelles ont réellement la charge du processeur pour exiger le nombre de vCPU dont elles disposent, il vous suffit d'acheter du matériel supplémentaire.

Les 127 835,94 millisecondes sont une somme et vous devez diviser par le temps d'échantillonnage pour obtenir les valeurs% RDY correctes. Il semble que vous obteniez déjà les lectures% RDY correctes maintenant. Vous pouvez aller assez haut avec le rapport vCPU / CPU physique, mais pas comme vous le faites.

Vous avez beaucoup trop de machines virtuelles vCPU quad et même une machine virtuelle 8 vCPU. Certaines réponses de qualité discutent déjà du bon dimensionnement et de certaines ramifications de la non consolidation des cycles à moins de processeurs virtuels. La seule chose que je voulais clarifier est que, bien qu'il ne soit plus vrai qu'une machine virtuelle doive attendre que le nombre de processeurs physiques égal à son nombre de processeurs virtuels devienne disponible avant de pouvoir traiter une instruction, c'est très préjudiciable. d'avoir un surprovisionnement de cette ampleur avec le rapport des machines virtuelles multi-vCPU aux cœurs physiques. 64 processeurs virtuels sur 8 cœurs dépassent largement le rapport maximum de 4 pour 1. Je suppose que vous avez HT sur ces processeurs, vous avez donc 16 cœurs logiques? Cela pourrait être OK avec 1 et 2 machines virtuelles vCPU qui ont une charge légère, mais si vous avez une lourde charge sur les machines virtuelles, cela serait difficile à accomplir.

Pour info Les processeurs HT ne sont pas utilisés dans les calculs% CPU utilisé - ce qui signifie que si vous avez 32 cœurs logiques fonctionnant à 2,4 Ghz sur un serveur, vous êtes à 100% d'utilisation lorsque vous atteignez 38,4 GHz. Donc, lorsque vous voyez les moyennes de charge affichant plus de 1,0, c'est pourquoi.

Voici un hôte ESXi qui exécute un rapport de 3,5 à 1 vCPU / CPU physique (y compris les cœurs HT) avec un% RDY moyen de 3%.

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

......

Depuis, nous avons installé Veeam ONE, qui nous a permis de savoir où se situent nos problèmes de performances. En examinant l'écran des goulots d'étranglement du processeur dans Veeam ONE, puis en utilisant le dépannage d'une machine virtuelle qui a cessé de répondre: comparaison de l'utilisation de VMM et du processeur invité comme référence, nous avons déterminé où se trouve notre conflit "inacceptable".

Une petite astuce que je voulais partager spécifiquement est que dans un cas, je ne pouvais pas éliminer les conflits de CPU tant que je n'avais pas supprimé l'instantané qui se trouvait sur la machine virtuelle. J'espère que cela aide quelqu'un.