Quelle est la contention de trop dans VMware?
Depuis un certain temps, 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 de la base de connaissances VMware ; 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 soient 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!
Cela signifie-t-il qu'en moyenne les VM sur cet hôte doivent attendre 2+ minutes pour le temps CPU ???
Cet hôte a deux processeurs 4 cœurs et il a un invité CPU 1x8 et des invités CPU 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 le VM 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é, surtout avec l'existence d'un invité unique avec 8 processeurs virtuels. Cela n'a aucun sens. Si vous avez besoin d'un VM aussi gros, vous avez probablement besoin d'un plus grand serveur.
Veuillez essayer de taille correcte 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, 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. RAM peut également être un problème si trop est alloué 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 un VM et en allant à Performance> Overview> CPU Graph.
- Moins de 5% CPU Ready - Ça va.
- 5-10% CPU Ready - Gardez un œil attentif sur l'activité.
- Plus de 10% de 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 cœur, et que vous exécutez une machine virtuelle 8vCPU, et quatorze = Machines virtuelles 4vCPU.
Si tel était mon environnement, je considérerais que cela est grossièrement sur-provisionné. 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 un VM plus de cœurs qu'il n'en a besoin. Raison? VMware utilise une co-planification assez stricte qui le rend difficile pour les VM d'obtenir du temps CPU à moins qu'il n'y ait autant de cœurs disponibles que le VM est assigné. Autrement dit, un 4vCPU VM ne peut pas effectuer 1 unité de travail à moins que il y a 4 cœurs physiques ouverts au même moment. En d'autres termes, il est préférable sur le plan architectural d'avoir un 1vCPU VM avec une charge CPU de 90%, puis d'avoir un 2vCPU VM 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 pourriez 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'un VM doit attendre que le nombre de CPU physiques égal à son nombre de vCPU soit disponible avant tout l'instruction peut être traitée, il est très préjudiciable d'avoir un surapprovisionnement de cette ampleur avec le rapport des machines virtuelles multi-vCPU aux cœurs physiques. 64 vCPU sur 8 cœurs est bien au-delà du rapport maximum de 4 pour 1. sur ces processeurs, vous disposez donc de 16 cœurs logiques. Cela pourrait être correct avec 1 et 2 machines virtuelles vCPU qui ont une charge légère, mais si vous avez une charge importante sur les machines virtuelles, cela serait difficile à réaliser.
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 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 regardant l'écran des goulots d'étranglement du processeur dans Veeam ONE, puis en utilisant Dépannage d'une machine virtuelle qui a cessé de répondre: comparaison d'utilisation de VMM et du processeur invité comme référence, nous avons compris où allouer notre conflit "inacceptable" est.
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.