Ces configurations vSphere ralentissent vos machines virtuelles

Lorsque la plupart des administrateurs VMware provisionnent leurs machines virtuelles, ils ajoutent simplement le
processeur et la mémoire demandés et suivent leur petit bonhomme de chemin.
Cependant, il est important de savoir qu’il existe une possibilité de surdimensionnement des machines virtuelles, ce
qui peut les rendre plus lentes qu’elles ne le seraient normalement si elles avaient moins de CPU/Mémoire qui leur
était attribué.
De nos jours, nous commençons à obtenir ces grandes machines virtuelles avec 24 vCPU pour les grandes bases de
données.
Ces derniers temps, j’ai vu beaucoup de demandes de VM volumineuses pour des clusters SQL ou pour des logiciels
RGPD (ce qui devient un gros problème maintenant !)
Nous devons être encore plus prudents sur la façon dont nous les provisionnons pour la meilleure optimisation, ce
qui aidera à prévenir de nombreux problèmes de « lenteur » que nous rencontrons en cours de route.

Les deux grands concepts que vous devez bien comprendre lors du provisionnement de machines virtuelles
volumineuses sont le concept de dimensionnement de la machine virtuelle plus grand que la taille du nœud vNUMA
et l’ajout d’une trop grande quantité de processeur sur une machine virtuelle lorsqu’elle n’est pas le seul invité sur
un hôte (temps RDY du processeur).
Allons plus en profondeur sur chacun d’entre eux.

Dimensionnement des machines virtuelles supérieures à la taille du nœud vNUMA

Lorsque nous obtenons une machine virtuelle avec un grand nombre de ressources allouées qui sont supérieures à la
taille du nœud NUMA physique de l’hôte ESXi, une topologie NUMA virtuelle est déjà configurée pour permettre à la
machine virtuelle de bénéficier de NUMA sur l’hôte physique.

Qu’est-ce que NUMA ?

Il s’agit d’une méthode utilisée pour accéder à la mémoire lors de l’utilisation de plusieurs processeurs.
Donc, si vous avez un serveur avec 2 processeurs physiques, la mémoire va être répartie entre chaque processeur
dans ses emplacements de mémoire respectifs sur la carte mère.

NUMA sera utilisé pour accéder à la mémoire configurée pour chaque CPU ainsi que pour accéder à distance à la
mémoire attribuée aux autres CPU si plus de mémoire est nécessaire.
Avant ESXi 6.5, la topologie vNUMA n’était parfois pas la plus rapide et nous devions jouer avec les sockets par
rapport aux cœurs.

Mais dans vSphere 6.5 et 6.7, vNUMA est en fait un peu plus intelligent.
Il n’est plus contrôlé par la configuration des cœurs par socket dans la machine virtuelle.
L’hôte présentera automatiquement la topologie vNUMA la plus optimisée à la machine virtuelle, sauf si des
paramètres avancés sont utilisés.
Nous devons toujours être conscients des paramètres de mémoire, si la mémoire appliquée à une machine virtuelle
est supérieure à la taille du nœud NUMA, nous devrons séparer les cœurs et les sockets en conséquence.

Comment puis-je connaître la taille de mon nœud numa d’hôte ? Facile, démarrez une session SSH
dans votre hôte. Tapez la commande suivante pour accéder à ESXTOP :

esxtop

Appuyez ensuite sur « M » pour accéder à la section mémoire :

Sur mon hébergeur, je peux voir que j’ai 2 nœuds NUMA d’une taille d’environ 28 Go. ESXTOP
séparera chaque nœud par une virgule. Que se passe-t-il si nous allouons 36 Go de mémoire à une
machine virtuelle avec 1 socket et 10 cœurs ? La VM finira par devoir accéder à la mémoire du 2ème
nœud NUMA qui est accessible à distance puisque nous l’empruntons à notre nœud NUMA voisin. Cela
peut entraîner des retards dans les performances de notre machine virtuelle. Dans ce scénario, il est
recommandé de répartir les sockets de la VM afin qu’une topologie vNUMA soit créée pour chaque
socket et qu’une configuration de 2 sockets 5 cœurs fournisse une VM beaucoup plus optimisée.

Surdimensionnement du processeur
Lorsqu’une machine virtuelle se voit attribuer de nombreux cœurs, elle doit attendre que tous les
cœurs qui lui sont attribués soient disponibles pour exécuter son cycle CPU, même si elle n’utilise pas
tous les cœurs. Cela peut entraîner un décalage sur la machine virtuelle si d’autres machines virtuelles
utilisent le processeur hôte à ce moment-là. En règle générale, lors du dimensionnement de votre
machine virtuelle, si l’utilisation du processeur de l’invité est en moyenne inférieure à 20 % à tout
moment, réduisez le nombre de processeurs virtuels. Si la machine virtuelle est à 100 % d’utilisation
du processeur en permanence, augmentez le nombre de processeurs virtuels. Cela vous aidera à
minimiser et à maximiser vos machines virtuelles afin d’obtenir le meilleur rendement possible du
processeur.

Une autre mesure à surveiller lors de l’approvisionnement des ressources est le temps RDY du
processeur. Il s’agit de la métrique utilisée par vSphere pour enregistrer la durée pendant laquelle une
machine virtuelle a été planifiée pour effectuer une tâche, mais n’a pas pu le faire en raison de
l’attente du processeur. Le seuil à rechercher est généralement de 10 %. Tout ce qui est supérieur
connaîtra généralement une certaine lenteur. Comment trouver le temps RDY du processeur ? Facile,
tout comme l’exemple ci-dessus avec les nœuds NUMA, nous utiliserons ESXTOP. Alors SSH dans un
hôte et tapez ce qui suit :

Esxtop

Appuyez ensuite sur « c » et vous verrez la colonne pour %RDY. Dans mon exemple, j’ai deux
machines virtuelles auxquelles j’ai alloué de grandes quantités de vCPU. J’ai ensuite exécuté un
programme de benchmark CPU pour générer une charge de travail CPU de masse. Nous pouvons voir
que VM1 rencontre des problèmes de performances avec la colonne %RDY, elle est supérieure à 10 %
:

Conclusion

Il est très important de prêter attention à ces deux « pièges » de performance lors du provisionnement
de machines virtuelles volumineuses. D’autant plus qu’un grand nombre de ces machines virtuelles
sont utilisées pour servir des bases de données et sont souvent les back-ends des applications métier
principales et ne peuvent pas se permettre d’avoir des ralentissements. Assurez-vous donc de faire
vos devoirs et de connaître les tailles NUMA de votre infrastructure VMware afin de pouvoir
développer des processus de provisionnement de machines virtuelles volumineuses. En outre, il est
judicieux de s’assurer que tous les hôtes VMware ont les mêmes spécifications de matériel et de
ressources autant que possible.

Esxtop : Dépannage des utilisations et des performances

Bien que les hôtes VMware soient généralement très fiables, les choses peuvent mal tourner et c’est
parfois le cas et c’est dans de tels cas qu’Esxtop brille.
Lorsque cela se produit, il est important de disposer d’outils de dépannage qui peuvent vous aider à
résoudre rapidement le problème. Un outil particulièrement utile est Esxtop de VMware.
Cet article explique comment l’utilisation d’Esxtop pour collecter des statistiques de performance
vous aidera à résoudre les problèmes de production.

Esxtop est un outil de ligne de commande qui est inclus nativement sur vos hôtes VMware. Ici, nous
allons montrer comment dépanner avec Esxtop.

Pour commencer, connectez une session SSH au serveur hôte que vous souhaitez examiner. PuTTY
fonctionne bien à cet effet, mais il existe également d’autres outils disponibles.

Une fois connecté, la première chose que vous devrez faire est de récupérer les VMID de
vos machines virtuelles.

L’utilitaire Esxtop identifie les machines virtuelles par leur VMID, de sorte que la création d’une liste
de VMID à l’avance vous aidera à mieux comprendre les informations qui vous sont fournies. La façon
la plus simple de récupérer les VMIDs est d’utiliser cette commande :

Vim-cmd vmsvc/getallvms

Vous pouvez voir à quoi cela ressemble ici :

La première colonne affiche les VMID des machines virtuelles sur cet hôte.

Maintenant, entrez les commandes Esxtop pour accéder à l’interface Esxtop illustrée ici :
Il s’agit des informations qui s’affichent lorsque vous entrez les commandes ESXTOP.

Comme vous pouvez le voir dans l’écran ci-dessus, l’outil de commandes Esxtop fournit une mine
d’informations sur la charge de travail de l’hôte. Bien que ces informations puissent sembler quelque
peu alambiquées au départ, elles peuvent être utilisées pour aider à détecter les problèmes de
performances.

Charge du processeur
La toute première ligne de compteurs Esxtop démontre la contention du processeur comme indiqué
ci-dessus. Il fournit des informations sur l’utilisation du processeur de votre machine virtuelle à l’aide
de plusieurs mesures. Vous remarquerez que cette ligne se termine par un énoncé des moyennes de
charge du processeur, suivi de trois chiffres (0,01, 0,05 et 0,15). Le premier chiffre affiche la moyenne
de charge des cinq dernières secondes. Les autres chiffres affichent les moyennes de charge pour des
périodes plus longues (une minute, cinq minutes et quinze minutes).

La charge moyenne doit idéalement se situer autour de 1,00. Des valeurs inférieures signifient que les
processeurs sont sous-utilisés, tandis que des valeurs plus élevées signifient que les processeurs sont
surutilisés. Si la charge moyenne atteint 2,00, cela signifie que les processeurs sont sérieusement
surchargés et que vous devez soit mettre à niveau le matériel de votre hôte, soit déplacer certaines
machines virtuelles vers un autre hôte.
L’hôte VMware illustré ci-dessus est une machine de laboratoire avec une très faible utilisation du
processeur, mais si les moyennes de charge avaient été excessivement élevées, la question logique
suivante est de savoir quelles machines virtuelles consomment le plus de ressources CPU.

Le moyen le plus simple de déterminer quelles machines virtuelles utilisent actuellement le plus de
ressources CPU consiste à examiner la colonne %Used. Cette colonne reflète le pourcentage des
ressources CPU physiques de l’hôte qu’un CPU virtuel utilise. L’examen de la colonne %Ready peut
également être révélateur. Cette colonne reflète le pourcentage de temps pendant lequel le VPU
attendait d’exécuter une instruction, mais devait attendre que les ressources du processeur soient
disponibles. Idéalement, la colonne %Ready ne doit jamais dépasser 5 %.

Changer de mode
L’outil de commandes Esxtop est capable d’afficher les données d’utilisation des ressources pour plus
que les ressources CPU. Si vous appuyez sur la touche H, vous serez redirigé vers un menu d’aide qui
répertorie les différentes commandes prises en charge par l’outil Esxtop. Si vous regardez au bas de la
capture d’écran suivante, vous pouvez voir une section intitulée Switch Displays. Les commandes
présentées dans cette section peuvent être utilisées pour examiner d’autres types de mesures de
performances. Par exemple, si vous appuyez sur M, les données de mémoire s’affichent. De même, si
vous appuyez sur N, les données réseau s’affichent.

Le menu d’aide répertorie les différents modes de l’outil de commandes Esxtop.

Mémoire
Appuyez sur M pour accéder à l’état de la mémoire de l’hôte VMware. Cet écran vous indique la taille
actuelle de la mémoire de la machine virtuelle (MEMSZ), ainsi que la quantité de mémoire allouée à
chaque machine virtuelle (Grant). Vous pouvez également voir la quantité de mémoire d’échange
actuellement utilisée (SWCUR), comme indiqué ci-dessous :

L’outil Esxtop fournit des statistiques d’utilisation de la mémoire.

Les principales choses à vérifier sur l’écran de la mémoire sont l’épuisement de la mémoire et
l’échange excessif. Bien que l’on puisse s’attendre à une certaine permutation sur un hôte lourdement
chargé, une permutation excessive indique que l’hôte ne dispose pas de suffisamment de mémoire et
peut également entraîner des problèmes de performances. Dans ce type de situation, vous devez
ajouter plus de mémoire à l’hôte ou migrer certaines machines virtuelles vers un autre hôte.

Disques
Les problèmes de performances de stockage ont toujours été difficiles pour les administrateurs
vSphere, car ils ont un impact important sur les performances des machines virtuelles et peuvent être
difficiles à résoudre. Une latence de stockage élevée rendra les machines virtuelles lentes et nuira
aux performances de l’application qui s’y exécute.

Le problème peut se situer n’importe où dans le chemin d’E/S, de la machine virtuelle elle-même aux
disques de la baie de stockage, en passant par l’adaptateur HBA du serveur, les ports de commutation
SAN, la charge du commutateur, les contrôleurs de baie de stockage, le type RAID, la vitesse du disque.
Ajoutez à ces choix de conception tels que le dimensionnement et le nombre de LUN, ainsi que les
politiques de sélection de chemin et un certain nombre de machines virtuelles par banque de données
et vous obtenez une quantité écrasante de possibilités lorsqu’il s’agit de découvrir la cause première
d’un problème de performances de stockage de machine virtuelle.

Toutes ces causes potentielles de problèmes ont chacune une métrique spécifique ou une manière
spécifique d’identifier si la valeur est trop élevée ou trop faible. Vous voulez une bande passante et des
IOPS élevés, mais vous voulez une faible latence par exemple. Bien sûr, tous ne peuvent pas être
observés dans vSphere, car certains d’entre eux ne seront disponibles que dans la machine virtuelle
elle-même ou sur la baie de stockage via les outils de dépannage. Cependant, vous pouvez déjà obtenir
une bonne quantité d’informations uniquement auprès d’Esxtop, comme nous allons le voir. Nous
nous pencherons en particulier sur les mesures de latence, car elles constituent la majeure partie des
problèmes de performances de stockage dans les environnements virtualisés (pas seulement vSphere,
remarquez).

Notez qu’il existe trois types différents de visualisations de disque dans Esxtop ; d pour l’adaptateur
de disque ou les contrôleurs de stockage, u pour le périphérique de disque ou les volumes et v pour
les machines virtuelles de disque.

En commençant par M, vous obtiendrez des détails sur les disques de chaque machine virtuelle. Vous
obtiendrez des informations sur la latence observée par une machine virtuelle sur les opérations de
lecture (LAT/rd) et d’écriture (LAT/wr), ainsi que sur les métriques de bande passante (MBREAD/S et
MBWRTN/s) et les IOPS (CMDS/s, READS/s et WRITES/s).

Esxtop fournit des détails sur les performances des machines virtuelles avec V

Ensuite, appuyez sur D pour afficher des informations pour chaque adaptateur de disque ou vmhba.
Cela sera particulièrement utile pour identifier les goulots d’étranglement sur votre serveur et rendra
assez évident si quelque chose ne va pas avec un HBA spécifique. Vous obtenez des métriques
similaires à celles ci-dessus avec des données de latence plus détaillées (xAVG/ cmd) que nous
expliquerons plus en détail dans la section suivante.

Esxtop fournit des détails sur les performances de l’adaptateur de disque avec D

Enfin, en appuyant sur U, vous obtenez des données précieuses pour chaque volume ou LUN présenté
à l’hôte. Celui-ci est probablement mon écran de prédilection car les problèmes de performance sont
généralement observés au niveau du volume ou de la baie, ce qui signifie qu’il est plus granulaire à
identifier. Ici, vous obtenez des données sur la longueur de la file d’attente (ce qui est un niveau de
dépannage avancé plus approfondi), mais il contient également les métriques de latence avec xAVG/
cmd.

Esxtop donne des détails sur les performances de volume avec U

 CMDS/s Il s’agit du nombre total de commandes par seconde, y compris les IOPS et
d’autres commandes SCSI telles que les réservations SCSI, les verrous, les
demandes de chaîne de fournisseur, les commandes d’attention unitaire,
etc., envoyées ou provenant du périphérique ou de la machine virtuelle
surveillée.

DAVG/cmd Latence moyenne en millisecondes par commande envoyée au volume.

KAVG/cmd Latence causée par le VMkernel de l’hôte.

GAVG/cmd Latence telle qu’elle est observée par le système d’exploitation invité dans
la machine virtuelle. Ce nombre est calculé à l’aide de la formule : DAVG
+ KAVG = GAVG

Obtenir plus de données

Enfin, l’une des choses les plus importantes à savoir sur l’utilisation de l’outil de commandes Esxtop
est que les affichages sont hautement personnalisables. Appuyez simplement sur la touche F et vous
verrez une liste de colonnes qu’Esxtop peut afficher pour le mode actuel. La capture d’écran suivante,
par exemple, montre les colonnes disponibles pour le mode mémoire de l’outil. Les colonnes
marquées d’un astérisque sont actuellement activées, tandis que les autres sont désactivées. Pour
afficher une colonne, il suffit d’appuyer sur la lettre correspondante. Vous pouvez également appuyer
sur la lettre associée à une colonne si vous souhaitez arrêter d’afficher cette colonne.
Esxtop vous permet d’activer et de désactiver les colonnes.

Conclusion
Dans un monde rempli de tableaux de bord et d’interface utilisateur, il suffit parfois d’un outil en ligne
de commande qui vous fournit instantanément les détails dont vous avez besoin. Esxtop permet aux
gestionnaires d’hôtes VMware d’accéder à des informations précieuses et souvent perspicaces qui
peuvent être utilisées pour aider à prendre des décisions critiques.

Duncan Epping a écrit un blog opportun il y a plus d’une décennie qui est toujours pertinent à ce jour,
où il détaille les mesures dans esxtop. Ce blog a été mis à jour au fil du temps pour s’adapter aux
évolutions logicielles de vSphere.

Introduction à ESXTOP Partie 1

vSphere est livré avec un outil très pratique, appelé ESXTOP, qui est idéal pour aider les
professionnels de l’informatique à identifier rapidement les problèmes de performances. Il s’agit d’un
outil de ligne de commande qui peut être utilisé pour collecter des données et
fournir des informations en temps réel sur l’utilisation des ressources d’un environnement vSphere,
telles que le processeur, le disque, la mémoire et l’utilisation du réseau. Pour les gourous de Linux,
ESXTOP est essentiellement la version VMware de l’outil en ligne de commande Linux appelé TOP.
Consultez la partie 2 du guide ici.
Comment accéder à ESXTOP
ESXTOP est accessible via la console ESXi ou à distance à l’aide d’une session Secure Shell. La syntaxe
est simple, tapez la commande suivante pour accéder à ESXTOP :

esxtop

Vous serez immédiatement redirigé vers le mode d’affichage interactif.

ESXTOP peut être exécuté dans les trois modes suivants :

Interactif – Il affiche les informations de performance collectées et les affiche en temps réel. C’est le
mode par défaut d’ESXTOP et les statistiques affichées sont mises à jour toutes les 5 secondes par
défaut.

Lot – Collecte les données de performance et les enregistre dans un fichier. Ceci est utile pour
collecter des statistiques sur une longue période de temps à utiliser pour une analyse ultérieure. Les
données collectées peuvent être analysées à l’aide d’outils tels qu’Excel, Perfmon et d’autres 3Rd outils
de fête.

Relecture : rejoue de manière interactive les données collectées lors de l’utilisation de l’outil VM-
Support. Il s’agit d’un outil couramment utilisé pour capturer des journaux et des données de
configuration à envoyer au support VMware. Une chose importante à noter est que vous ne pouvez
pas relire de manière interactive les données collectées à l’aide du mode batch.

Utilisation du mode interactif

Étant donné que le mode interactif est le mode par défaut utilisé par ESXTOP, vous n’avez pas besoin
de spécifier de commandes supplémentaires pour entrer dans ce mode, tapez simplement ESXTOP
sans aucun commutateur supplémentaire et vous êtes en mode « Interactif ». Un bon moyen de s’y
retrouver en mode interactif est d’appuyer sur « h », cela vous donnera un menu des différentes
commandes disponibles :

Utilisez « h » pour vous aider à trouver votre chemin dans le mode interactif.

Notez la section « Switch Display » qui répertorie les différentes options d’affichage disponibles. Ces
options répertoriées nous permettent de basculer entre les différentes ressources que nous
souhaitons afficher. Par exemple, supposons que nous voulions jeter un coup d’œil aux ressources de
nos adaptateurs de disque, la section « Switch Display » montre que « d » est la commande pour
passer à l’affichage de l’adaptateur de disque, donc nous tapons simplement « d » :

ESXTOP affiche les statistiques de performance en temps réel sur les adaptateurs d’affichage.

Nous obtenons maintenant un affichage en temps réel des statistiques de ressources pour nos
adaptateurs d’affichage. Cela peut représenter beaucoup d’informations à afficher en même temps,
donc si nous le voulions, nous pourrions supprimer quelques-unes des colonnes qui ne nous
intéressent pas. Pour ce faire, il suffit d’utiliser la commande « f » :

Filtrez les champs indésirables pour simplifier votre affichage ou ajoutez des champs supplémentaires
pour obtenir plus d’informations.

Nous obtenons maintenant une liste de tous les champs disponibles que nous pouvons ajouter ou
supprimer. Les éléments qui ont un astérisque (*) à côté d’eux sont ceux qui sont activement affichés à
ce moment-là. Pour les supprimer ou les ajouter, il suffit de taper la lettre correspondante. Ainsi, par
exemple, supprimons le champ « ID » de notre écran en appuyant sur « b » :
Saisissez la lettre associée pour supprimer/afficher un champ.

Le symbole de l’astérisque est supprimé et nous appuyons sur n’importe quelle autre touche que A-P
pour revenir à la vue d’affichage. Nous pouvons maintenant voir que la colonne ID a disparu :

Le champ Chemin/Monde/Partition n’est plus visible.

Si nous le voulons, nous pouvons même enregistrer cette vue modifiée pour la prochaine fois que nous
accéderons au mode interactif. Pour ce faire, il suffit d’appuyer sur « W » (assurez-vous qu’il s’agit
d’une majuscule) pour enregistrer les paramètres. En outre, nous pourrions également enregistrer les
paramètres dans un autre nom de fichier au cas où nous souhaiterions avoir une vue personnalisée
distincte de la vue par défaut. Dans l’exemple ci-dessous, j’enregistre la vue sous le
nom esxtopdiskview, si nous voulions écraser la valeur par défaut, nous laisserions simplement le
champ vide :

Créez un fichier de configuration personnalisé ou enregistrez-le par défaut.

Pour utiliser notre fichier de configuration personnalisé avec ESXTOP, utilisez la syntaxe suivante :

Esxtop –c .\esxtopdiskview
Pour quitter esxtop, entrez simplement la lettre « q ».

Utilisation d’ESXTOP en mode batch

Pour utiliser le mode batch, ouvrez simplement ESXTOP avec le commutateur -b. Incluez également le
commutateur -n pour spécifier le nombre d’itérations que nous souhaitons exécuter. Une itération est
un instantané des statistiques de performances. Le délai par défaut entre chaque itération est de 5
secondes. Si nous voulions modifier ce paramètre, nous utiliserions le commutateur -d suivi du
nombre de secondes à attendre jusqu’à ce que les données soient à nouveau collectées. Ainsi, si nous
voulions collecter des données de performance pendant 50 secondes et les enregistrer dans un fichier
CSV, la syntaxe ressemblerait à ce qui suit :

Esxtop –b –n 10 > [Link]

Les données seront collectées et enregistrées dans le CSV spécifié, que nous pourrons consulter
ultérieurement pour analyse. Soyez également conscient de la quantité d’espace que cela peut
prendre. Vous pouvez également compresser les données collectées pour économiser de l’espace à
l’aide de la syntaxe suivante :

ESXTOP –b –n 10 | gzip -9c > [Link]

De plus, si nous voulons uniquement collecter les données de notre fichier de configuration
personnalisé que nous avons créé précédemment, nous pouvons spécifier le fichier de configuration à
l’aide du commutateur –c :

Esxtop –b –n 10 –c .\esxtopdiskview | gzip -9c > [Link]

N’oubliez pas de consulter la partie 2 où nous verrons comment utiliser le mode Replay et quelles
statistiques ESXTOP courantes surveiller lors du dépannage des performances.

Introduction à ESXTOP Partie 2

Il s’agit de la partie 2 de notre introduction à ESXTOP où nous allons voir comment utiliser le mode de
relecture avec ESXTOP ainsi que les statistiques à rechercher lors du dépannage de base dans ESXi.
N’oubliez pas de consulter la partie 1 pour plus d’informations sur l’accès à l’outil ESXTOP et
l’utilisation du mode interactif et du mode par lots.

Utilisation du mode Replay

Le mode de relecture permet à ESXTOP de relire les statistiques de ressources collectées lors de
l’exécution de VM-Support. Les informations peuvent être manipulées comme lors de l’utilisation du
mode interactif. Ceci est très utile si vous êtes dans une situation où vous souhaitez qu’un ingénieur
ou un collègue spécialisé VMware examine les informations de performances sur votre hôte. Il vous
suffit d’exécuter VM-Support, de créer les journaux de performances et de leur envoyer le fichier pour
qu’ils l’examinent.

Dans l’exemple ci-dessous, nous allons créer un fichier VM-Support à analyser avec le mode Replay
d’ESXTOP. Pour collecter des informations à l’aide de VM-Support, accédez à l’emplacement où vous
souhaitez que le fichier soit créé. Notez que ce fichier peut devenir assez volumineux, alors assurez-
vous de planifier correctement.

Il suffit d’utiliser la commande VM-Support avec le commutateur -p pour spécifier que nous voulons
collecter des instantanés de performances et d’inclure le commutateur –a suivi de «
PerformanceSnapshot :vsi » pour répertorier uniquement le manifeste d’instantané de performances.
En outre, nous utiliserons le commutateur -i pour spécifier les secondes entre les intervalles (VMware
recommande 10 dans la plupart des cas) et le commutateur -d pour spécifier la durée de la
surveillance des performances. Donc, si nous voulions collecter des informations pendant 300
secondes, la syntaxe ressemblerait à ce qui suit :

vm-support –p –a PerformanceSnapshot:vsi –i 10 –d 300 –w.

Une fois le processus terminé, un fichier .tgz est créé contenant nos données de performance. Dans
notre exemple, nous allons rejouer les informations, à l’aide d’ESXTOP, à partir du fichier que nous
avons créé. Nous aurons besoin d’extraire le contenu du fichier, pour ce faire, nous exécutons la
commande suivante :

Tar –xzf ./[Link]-2016-03-10—[Link]

Nous pouvons maintenant voir que les fichiers ont été extraits :

Maintenant, nous pouvons ouvrir ESXTOP en mode replay en utilisant le commutateur –R (assurez-
vous qu’il est en majuscule) et en spécifiant le dossier extrait :

esxtop –R [Link]-2016-03-10—17.16

ESXTOP ouvre les informations en mode interactif. Nous pouvons maintenant utiliser les commandes
du mode interactif pour naviguer et diagnostiquer le problème de performance :
Vous pouvez rencontrer un problème lors de l’exécution du mode de relecture où il affiche l’erreur
« tous les instantanés de prise en charge de vm ont été utilisés ». Vous devrez naviguer dans le dossier
extrait et exécuter le script [Link]. Le mode de relecture d’ESXTOP devrait fonctionner après
cela :

./[Link]

Dépannage des performances de base d’ESXTOP

Maintenant que vous savez comment utiliser chaque mode d’ESXTOP, comment résoudre les
problèmes de performances au niveau de la couche de virtualisation ? Eh bien, vous devez savoir ce
qu’il faut rechercher. Si vous appuyez sur la touche « h » en mode interactif, vous pouvez voir les
différentes vues d’affichage que vous pouvez utiliser pour diagnostiquer tout problème de
performance que vous pourriez soupçonner. Vous trouverez ci-dessous une liste de base de certaines
des statistiques à rechercher lors du dépannage. J’ai également inclus les valeurs seuils à respecter
pour chaque statistique. Cependant, je recommande vraiment d’en savoir plus sur chaque ressource, il
existe de nombreux excellents guides qui plongent dans les détails sur la façon de diagnostiquer un
problème de performance à l’aide d’ESXTOP :

CPU

%RDY- Indique le pourcentage de temps pendant lequel une machine virtuelle était prête à
s’exécuter, mais n’a pas pu l’être, car il n’y avait pas assez de ressources CPU disponibles. Cela peut
être dû à un trop grand nombre de vCPU, de machines virtuelles vSMP ou à une limite de processeur
imposée à une machine virtuelle. Seuil : supérieur à 10.

%SWPWT : indique le pourcentage de temps pendant lequel une machine virtuelle doit attendre que
l’hôte change de mémoire. Cela peut être le signe d’une mémoire surchargée. Seuil : supérieur à 5.

%MLMTD– Indique le pourcentage de temps pendant lequel une machine virtuelle ou un monde n’a
pas été planifié en raison d’un paramètre de limite. À moins qu’une limite sur un pool de ressources
ou une machine virtuelle n’ait été spécialement configurée par conception, il ne doit pas y avoir de
valeur supérieure à 0 dans ce champ. Seuil : supérieur à 0.

%CSTP – Indique le pourcentage de temps qu’une machine virtuelle passe dans un état prêt et co-
déplanifié. Ce champ ne s’applique vraiment qu’aux machines virtuelles qui utilisent vSMP et indique
qu’un vCPU est utilisé beaucoup plus que l’autre vCPU alloué à la machine virtuelle. Seuil : supérieur à
3.

Mémoire

MCTLSZ (MB) – Indique la quantité de mémoire physique que l’hôte ESXi récupère par le pilote de
ballon. Cela pourrait être le signe d’une mémoire surchargée. Seuil : supérieur à 0.

ZIP/s (Mo/s) : indique la quantité de mémoire compressée par seconde sur l’hôte. Si l’hôte compresse
des pages de mémoire, c’est un indicateur de problèmes de contention de mémoire et cela est
généralement dû à une mémoire surchargée. Seuil : supérieur à 0.
UNZIP/s (Mo/s) : indique la quantité de mémoire décompressée par seconde sur l’hôte. Peut être le
signe d’une mémoire surchargée. Seuil : supérieur à 0.

SWCUR (Mo) : mémoire échangée par la machine virtuelle ou le pool de ressources. Pointe vers une
mémoire surchargée. Seuil : supérieur à 0.

CACHEUSD (Mo) : quantité de mémoire compressée par l’hôte ESXi. Cela pourrait être une indication
d’une mémoire surchargée. Seuil : supérieur à 0.

SWW/s et SWR/s : indique la vitesse à laquelle l’hôte ESXi lit ou écrit sur le disque à partir de la
mémoire permutée ou dans celle-ci. La cause possible serait une mémoire surchargée. Seuil :
supérieur à 0.

Réseau

%DRPTX – Paquets abandonnés transmis. Des valeurs supérieures à 0 peuvent être le signe d’une
utilisation élevée du réseau. Seuil : supérieur à 0.

%DRPRX – Paquets abandonnés reçus. Des valeurs supérieures à 0 peuvent être le signe d’une
utilisation élevée du réseau. Seuil : supérieur à 0.

Used-by et Team-PNIC : ces deux champs sont très utiles pour distinguer la carte réseau physique
utilisée par une machine virtuelle.

Disque

DAVG/cmd – Indique la latence moyenne du périphérique par commande au niveau du pilote de

périphérique. Des valeurs élevées indiquent des problèmes de performances de stockage. Seuil : Plus
de 25

ABRTS/s – Commandes abandonnées par seconde. Les abandons sont émis à partir du système
d’exploitation invité lorsque le stockage cesse de répondre. Le système d’exploitation Windows a un
délai par défaut de 60 secondes. La cause possible peut être un problème avec les structures de
stockage ou la baie. Seuil : Tout ce qui est supérieur à 0

KAVG/cmd : latence VMKernel moyenne par commande. Une valeur élevée indique que les E/S sont
limitées entre le système d’exploitation invité et le stockage, le mieux est de vérifier auprès du
fournisseur les options de réglage des performances ou une version mise à jour du micrologiciel. Seuil
supérieur à 2

GAVG/cmd : latence moyenne du système d’exploitation invité par commande. Cette valeur est
calculée par la somme de la DAVG et de la KAVG. Seuil : Plus de 25

Resets/s– Réinitialisation des commandes par seconde. Une commande de réinitialisation est émise
lorsque l’opération ne parvient pas à atteindre la cible. Seuil : Tout ce qui est supérieur à 0
10 façons de résoudre les problèmes de performances médiocres de vSphere

La lutte contre la lenteur des performances de VMware est probablement l’un des principaux
problèmes que vous rencontrerez en tant qu’administrateur de virtualisation. Les problèmes de
performances de VMware sont parmi les plus difficiles à résoudre en raison de sa nature
multidimensionnelle. Quoi qu’il en soit, il y a un certain nombre de choses que vous pouvez faire pour
lire les symptômes tels que l’accès lent au disque ESXi et autres, vous pouvez ensuite affiner la cause
et appliquer un correctif s’il y en a un.

En nous appuyant sur les conseils de cette base de connaissances VMware, nous explorons
aujourd’hui 10 façons de résoudre les cas de lenteur de VMware. Jetez un coup d’œil à ce webinaire
d’Altaro pour une approche plus holistique de l’amélioration des performances VMware.

Surveillance des performances VMware

Avant de poursuivre, revenons sur la fonction de surveillance des performances intégrée dans le
client vSphere. Il s’agit du premier outil auquel il faut recourir lors de l’examen des problèmes de
performances VMware.

La figure 1 présente un graphique de performances avec les latences de lecture et d’écriture d’un
disque virtuel de machine virtuelle. Les pics de 7,5 ms observés se situent bien dans la plage
acceptable, mais des niveaux soutenus supérieurs à 10 ms peuvent indiquer un accès lent au disque
ESXi ou peut-être une congestion du réseau.

Utilisez des alarmes dans la mesure du possible afin d’être toujours au courant de tout problème de
performance. Vous pouvez également envisager de déployer vRealize Operations Manager pour une
évaluation plus approfondie de votre environnement.
Figure 1 : graphique de performances pour les latences de lecture et d’écriture du disque virtuel
de machine virtuelle

Il existe également un moyen simple d’identifier les gros frappeurs dans les graphiques en empilant
des graphiques VM. Dans l’onglet Surveillance avancée d’un hôte, cliquez sur les options du
graphique, sélectionnez la métrique que vous recherchez, définissez le type de graphique
sur Graphique empilé par machine virtuelle et supprimez l’hôte ESXi de la liste des objets cibles.

Figure 2 – Les options de graphique avancées vous permettent de modifier l’affichage des
graphiques. Vous pouvez enregistrer l’affichage pour une utilisation ultérieure avec l’option
« Enregistrer sous » en haut.

Une fois que vous avez cliqué sur OK, vous obtenez un graphique empilé qui facilite l’identification de
l’utilisation des ressources de machine virtuelle les unes par rapport aux autres.
Figure 3 – Les graphiques empilés sont utiles pour obtenir une vue de la consommation globale
des ressources.

Notez qu’il est recommandé d’utiliser des alarmes dans la mesure du possible afin d’être toujours au
courant de tout problème de performances VMware. Vous pouvez également envisager de déployer
vRealize Operations Manager pour une évaluation plus approfondie de votre environnement.

Comment résoudre les problèmes de lenteur des performances de VMware

Les étapes, ou plutôt les questions que vous devriez vous poser, sont énumérées de manière ordonnée
en commençant par les plus triviales.

Réévaluez les performances de la machine virtuelle affectée après chaque étape lorsque vous avez
essayé un correctif. Vous pouvez ensuite choisir de passer à l’étape suivante en fonction de
l’amélioration observée, le cas échéant. Si vous tombez sur quelque chose d’aussi flagrant qu’un
disque défaillant sur un hôte, il va sans dire que vous voudrez d’abord résoudre ce problème avant de
passer à autre chose !

1 – S’agit-il vraiment d’un comportement inattendu ?

Une VM soumise à une charge de travail lourde peut parfois être perçue comme peu performante
alors qu’elle remplit en réalité sa fonction. Quelques exemples sont des instances virtualisées
de serveurs SQL, des requêtes SQL gourmandes en processeur ou mal écrites, il peut également s’agir
de serveurs de messagerie avec de grandes bases d’utilisateurs...

Les graphiques de surveillance des performances VMware dans le client vSphere vous aideront à
évaluer l’utilisation des ressources sur une période donnée. Vous pouvez ensuite évaluer si le
changement de comportement était ponctuel ou continu et évaluer si le comportement est attendu ou
non.

De par leur conception, des produits tels que MS SQL et Exchange Server utilisent toute la mémoire
vive qui leur est lancée, sauf s’ils sont configurés autrement. Cela dit, c’est toujours une bonne idée de
se référer à la documentation du produit.

2 – Utilisez-vous le dernier produit ?

Les mises à jour et les nouvelles versions peuvent résoudre les problèmes de performances de
VMware sous la forme de bogues résolus ou de pilotes et de code améliorés. Parfois, cependant, la
dernière version pourrait, en fait, aggraver le problème. Exécutez la mise à jour dans un
environnement de test/développement ou sur un sous-ensemble de votre production avant de la
déployer à l’échelle mondiale.

Par exemple, vSphere 7 Update 2 a été déployé avec un bogue qui provoquait des écrans violets sur
les hôtes exécutant ESXi sur des cartes SD ou des clés USB. Pour les versions majeures, il est
recommandé d’attendre qu’il y ait suffisamment d’adoption dans la communauté pour que les mises à
jour et les correctifs soient publiés et bénéficient d’un produit plus stable.

o Matrice de compatibilité VMware

o Séquence de mise à jour pour vSphere 7.0 et ses produits VMware compatibles

3 – Vos machines virtuelles exécutent-elles VMware Tools ?

Il est important de s’assurer que les outils VMware sont installés, en cours d’exécution et à jour sur
chaque machine virtuelle qui les prend en charge, quel que soit l’environnement. Le package VMware
Tools, surtout, fournit un ensemble de pilotes de périphériques virtuels optimisés qui affectent
directement les performances de VMware (pour le mieux généralement).

Affichage des VMTools dans vSphere Client

Là encore, à l’aide du client vSphere, vous pouvez facilement vérifier l’état de VMware Tools dans
l’environnement, comme illustré à la Fig. 2. Vous devez ajouter les champs État des versions
de VMware Tools et État d’exécution de VMware Tools en cliquant sur la flèche de l’en-tête de l’un
des champs et en les cochant dans la liste.
Figure 4 : affichage de l’état VMtools pour les machines virtuelles gérées par vCenter Server

Affichage des VMTools dans PowerCLI

Vous pouvez également utiliser PowerCLI pour collecter des informations sur les outils VMware dans
votre environnement. Si vous débutez avec PowerCLI, consultez notre guide du débutant et
notre ebook sur le sujet.

Le moyen le plus rapide d’obtenir la version de VMware Tools consiste à utiliser

la propriété ToolsVersion de la propriété Guest.
Figure 5 – La version « lisible par l’homme » des outils est directement disponible dans
l’établissement des clients.

Vous trouverez des détails supplémentaires sur les outils VMware <vm>.[Link].

Figure 6 : utilisation de PowerCLI pour interroger l’état de VMtools sur les machines virtuelles

o Présentation des outils VMware

o Comment installer VMware Tools : le guide complet

4 – Vos VM sont-elles correctement dimensionnées en termes de ressources ?

Dans un large éventail d’environnements, vous rencontrerez des problèmes de dimensionnement en
ce qui concerne le provisionnement des ressources des machines virtuelles. Les machines virtuelles à
court de ressources souffriront de divers symptômes, tels que la lenteur de VMware en raison d’un
accès lent au disque ESXi, l’échange de RAM, etc. Si vous voyez une ressource atteindre régulièrement
100 % et que vous avez vérifié qu’il n’y a rien de mal dans le système d’exploitation invité, c’est
probablement une bonne idée d’ajouter plus de cette ressource.

Bien qu’il soit assez facile de diagnostiquer des machines virtuelles sous-dimensionnées, car vous
pouvez voir les graphiques augmenter régulièrement, d’un autre côté, les machines virtuelles
surdimensionnées peuvent causer tout autant de problèmes et nuire aux performances de VMware.
Figure 7 – vROPS peut vous aider à identifier les machines virtuelles surdimensionnées et sous-
dimensionnées

Le problème le plus courant est lorsqu’un trop grand nombre de processeurs virtuels sont
provisionnés. Bien que cela puisse sembler contre-intuitif, cela peut nuire à ses performances et à
celles des autres VM, car le vmkernel de l’hôte aura du mal à le programmer sur les cœurs physiques,
tandis que les VM plus petites obtiendront facilement une place libre. Si vous souhaitez en savoir plus
sur ce phénomène, consultez la métrique co-stop CPU dans esxtop.

Figure 8 : l’impact sur les performances de VMware est un effet secondaire des machines virtuelles
surdimensionnées.

En règle générale, il est recommandé de provisionner vos machines virtuelles avec des exigences
minimales et de les augmenter si nécessaire.

Identifier les problèmes de dimensionnement avec vROPS

o Déterminer si plusieurs processeurs virtuels sont à l’origine de problèmes de

performances VMware
5 – Le rapport entre votre vCPU et votre cœur physique est-il trop élevé ?
Cette rubrique est liée au point précédent sur le redimensionnement des machines virtuelles. L’un des
principaux arguments de vente de la virtualisation est son aspect consolidation. Cependant, le GHz du
processeur libre n’est pas la seule métrique à surveiller lors du provisionnement de machines
virtuelles sur un hôte.

Vous devez également prendre en compte le rapport entre le nombre de vCPU de machine
virtuelle et de cœurs de processeur physique sur le serveur physique. Nous l’appelons rapport
vCPU :pCore. vCPU fait référence au nombre de cœurs provisionnés sur la machine virtuelle
(#Sockets x #CoresPerSocket). Par exemple, si vous avez 10 machines virtuelles avec 4 vCPU chacune
sur un hôte équipé d'1 processeur doté de 12 cœurs, vous obtenez un rapport vCPU :pCore de 3,33:1
(40 / 12).

Un ratio trop élevé peut entraîner une valeur élevée du % de disponibilité du processeur et
entraîner des problèmes de performances VMware.

Figure 9 – N’utilisez pas de cœurs hyperthreadés pour le rapport

Il n’existe pas de valeur appropriée pour ce ratio, car il dépend des charges de travail que vous
exécutez. La règle empirique était de 4:1, mais je ne suis pas sûr que ce soit une valeur réaliste avec
des processeurs plus puissants d’aujourd’hui, car cela donne un rapport de consolidation plutôt faible.
En voici quelques exemples. Notez qu’il ne s’agit pas de recommandations officielles de VMware.

o Charges de travail mixtes : 6:1 – 7:1 conviendra dans la plupart des cas.

o Bases de données et autres poids lourds : 2:1 – 4:1 peut être votre limite pour éviter les
goulets d’étranglement.

o Charges de travail VDI : 10:1 à 13:1 conviennent aux environnements VDI qui prennent
en charge des densités plus élevées.

Si vous devez recourir à des ratios plus élevés pour une raison quelconque, vous devrez essayer de
vous assurer que les machines virtuelles exécutées sur le même hôte ne seront pas frappées durement
en même temps. La surcharge opérationnelle est plus importante car vous devrez recourir à des
règles DRS, affiner les tâches planifiées, les fenêtres de sauvegarde...
Vous pouvez utiliser PowerCLI pour trouver le rapport de courant d’un hôte spécifique.

$VMHost = Get-VMHost « [Link] »

$VMCores = Get-VMHost [Link] | Obtenir une machine virtuelle | Où

powerstate -eq poweredon | Measure-Object -Propriété numcpu -sum

write-host « $([math] ::round($[Link] / $[Link],2)) :1 »

Figure 10 : recherche du taux de consolidation du processeur dans PowerCLI

Si vous remarquez que votre machine VMware fonctionne lentement en raison de tels problèmes,
réduisez le ratio en déplaçant certaines machines virtuelles vers d’autres hôtes ou en mettant hors
tension les moins importantes. Vous pouvez évidemment aussi ajouter de la capacité avec des nœuds
supplémentaires, des processeurs...

o Panneau Métriques du processeur

6 – Votre stockage sous-jacent est-il sain ?

Que vous utilisiez des banques de données locales, virtualisées ou basées sur SAN, tout dépend des
performances et de l’état de vos disques et des sous-systèmes sous-jacents qui les hébergent. En
termes simples, si les machines virtuelles n’obtiennent pas leur juste part d’IOPS assez rapidement, les
performances de VMware commenceront à se dégrader.

S’il y a une métrique de stockage à connaître, c’est bien la latence. Vous devez commencer le
dépannage lorsque vous observez des latences supérieures à 10 ms. Les IOPS sont également une
mesure importante pour s’assurer que le backend de stockage est capable de traiter toutes les
demandes.
Figure 11 : la latence de stockage peut provenir de plusieurs composants dans le chemin d’E/S

Voici quelques éléments que vous pouvez vérifier et effectuer :

Disques défectueux : effectuez régulièrement des vérifications de l’état de votre disque/stockage en

réseau et remplacez immédiatement les disques vieillissants ou défaillants.

Latence / IOPS : assurez-vous que les IOPS sont traitées en temps voulu. Tout ce qui dépasse 10 ms
signifie qu’il y a un accès lent au disque ESXi. Cela peut être dû à une grande variété de raisons.

Instantanés : supprimez tous les instantanés inutilisés ou redondants. Plusieurs snapshots peuvent
ralentir les performances de VMware. En règle générale, vous ne devez pas conserver un instantané
plus de 72 heures. Et n’oubliez pas : un instantané n’est pas une sauvegarde ! Utilisez plutôt des
outils professionnels tels que Altaro Backup.

Chiffrement : n’utilisez le chiffrement du disque que lorsque cela est nécessaire. Chiffrement = frais
généraux = diminution des performances VMware.

Accélération de la machine virtuelle : si vous devez vous contenter du stockage sous-jacent actuel et
qu’il n’existe aucun autre moyen de résoudre les problèmes d’accès lent au disque ESXi, envisagez de
recourir à la mise en cache côté hôte.

o Dépannage de l’accès lent au disque esxi

o Stockage d’un fichier d’échange de machine virtuelle dans un emplacement autre

que celui par défaut dans ESX/ESXi

o Meilleures pratiques pour l’utilisation des snapshots dans l’environnement

vSphere
7 – Vos hôtes ESXi disposent-ils de suffisamment de ressources ?
L’exécution simultanée d’une douzaine d’ordinateurs portables configurés avec 16 Go de RAM sur un
seul hôte ESXi qui ne dispose que de 96 Go de RAM ne demande que des ennuis. Envisagez d’ajouter
de la RAM à l’hôte ou d’utiliser DRS (si vous disposez de plusieurs hôtes ESXi et d’une licence
appropriée) pour une meilleure répartition de la charge en activant la distribution des machines
virtuelles dans les options supplémentaires de DRS.

Figure 12 : appliquer une répartition plus uniforme des machines virtuelles entre les hôtes du
cluster pour assurer la disponibilité

N’oubliez pas que la surveillance de l’utilisation de la mémoire dans les graphiques de performances
VMware ne reflète pas nécessairement la réalité. La métrique de mémoire active est une estimation
basée sur des données échantillonnées et la métrique consommée peut être trompeuse car Windows
ne libère pas les pages de mémoire lorsqu’elles ne sont plus utilisées. Privilégiez toujours les agents
de surveillance in-guest pour obtenir des métriques de mémoire précises.

o Examen des ressources de machine virtuelle hébergée

o Vérification de l’espace disque disponible suffisant pour une machine virtuelle

hébergée

o Présentation des indicateurs Mémoire active et Utilisation de la mémoire

8 – La gestion de l’alimentation du processeur est-elle activée ?

La gestion de l’alimentation du processeur, lorsqu’elle est activée sur les serveurs ESXi, peut
introduire une latence qui peut être captée par les applications ou les charges de travail, ce qui ralentit
les performances de VMware. Si vous pensez que c’est le cas, consultez la documentation du
fournisseur pour savoir comment désactiver la gestion de l’alimentation du processeur. Si sa
désactivation n’a aucun effet, vous pouvez la réactiver dans l’esprit de l’exploitation de centres de
données économes en énergie.
Vous pouvez soit configurer le processeur pour des performances maximales directement dans le
BIOS, soit le configurer pour qu’il soit géré par le système d’exploitation. Dans ce cas, vous pouvez
configurer le profil de gestion de l’alimentation dans vCenter.

Figure 13 : la gestion de l’alimentation peut être définie à partir de vCenter Server

o L’application de machine virtuelle s’exécute plus lentement que prévu dans ESXi

o Les politiques d’alimentation du BIOS affectent les performances

o Impact de la gestion de l’alimentation surles performances de l’E SXi

9 – Tout est-il bon sur le plan du réseautage ?

Assurez-vous que la mise en réseau de votre hôte ESXi ne devient pas un goulot d’étranglement
empêchant les machines virtuelles de s’exécuter et de fonctionner de manière optimale. Les
symptômes peuvent inclure un temps de réponse lent lors de la connexion à des machines virtuelles
via des clients distants et des consoles de gestion, des transferts vMotion trop longs, etc.

Assurez-vous que les cartes réseau de vos hôtes sont correctement configurées. Si votre infrastructure
le permet, séparez la gestion et le trafic des charges de travail. Exécutez des services tels que la
gestion, vMotion et le stockage sur leur propre réseau dédié. Utilisez des piles TCP/IP optimisées et
des éléments tels que des trames Jumbo, le cas échéant. Assurez-vous que le microprogramme et le
pilote de tout matériel réseau ajouté au mélange sont à jour et dans la HCL VMware. Enfin, n’excluez
pas les problèmes liés aux commutateurs virtuels. Vérifiez vos groupes de ports, l’attribution de
VLAN, etc.

Il est recommandé d’utiliser des cartes réseau 10 Gbit/s dans la mesure du possible. Toutefois, si vous
devez établir des priorités, utilisez ces cartes pour le stockage iSCSI en priorité, puis vMotion, Backup
et le reste de vos charges de travail.

o Vérification de la vitesse de mise en réseau de l’hôte

 o Dépannage des problèmes de connexion réseau de machine virtuelle

o Dépannage des problèmes de performances réseau dans un environnement

vSphere

10 – Utilisez-vous les versions appropriées du micrologiciel/pilote ?

Avant même d’appeler le support technique concernant la lenteur des performances de VMware, vous
devez vous assurer que vous exécutez les dernières versions disponibles du micrologiciel et du pilote.
C’est la première chose qu’ils vous demanderont avant même d’examiner le problème, et à juste titre,
car cela résout une majorité étonnamment grande des problèmes de performance VMware.

Il arrive le plus souvent que quelqu’un oublie de mettre à jour le firmware d’un tas de nouveaux
serveurs avant de les mettre en production. Vous découvrez alors que vos hôtes vSphere fonctionnent
lentement et vous vous rendez compte que vous utilisez des versions de micrologiciel boguées vieilles
de 3 ans.

vSphere 7 a simplifié le processus de mise à jour des pilotes et du micrologiciel avec Lifecycle
Manager à partir du client vSphere. Les solutions hyperconvergées telles que les nœuds DellEMC
VXRail ou Nutanix offrent également des mises à niveau en un clic qui prendront en charge l’ensemble
du processus automatiquement.

Figure 14 : vSphere 7 vous permet de mettre à jour le micrologiciel via un gestionnaire de

support matériel (HSM)

Si vous n’avez accès à aucune de ces options, nous vous recommandons d’utiliser l’outil de gestion de
serveur du fournisseur, tel que Dell OME, et de toujours vérifier que les versions recommandées à
installer sont prises en charge dans la liste de compatibilité matérielle (HCL) VMware.

Gestion simplifiée du cycle de vie dans vSphere 7

o Vérification des niveaux de votre firmware et de votre BIOS

o Détermination de la version du micrologiciel et du pilote réseau/stockage dans

ESXi
 o Versions du firmware des pilotes prises en charge pour les périphériques d’E/S

o FAQ : Recommandation pour le pilote/micrologiciel

Envelopper

Cela résume à peu près l’article d’aujourd’hui sur la façon d’améliorer les performances de VMware.
Dans divers cas, vous vous retrouverez également à utiliser esxtop pour résoudre un problème, alors
assurez-vous de consulter notre guide esxtop. Cela dit, il ne s’agit pas d’une liste exhaustive, car il y
aura toujours d’autres facteurs à l’origine de la lenteur des performances de VMware, ainsi que des
moyens d’y remédier.

Je vous suggère de lire le matériel référencé dans les liens fournis tout au long de cet article et d’autres
articles, tels que celui-ci sur l’accélération des applications dans vSphere 7 pour plus
d’informations. Vous pouvez également vous rendre sur le réseau technologique VMware
(VMTN), où vous trouverez des personnes partageant les mêmes idées et partageant des questions,
des problèmes et des solutions potentielles similaires.

Enfin, n’oubliez pas de consulter notre ebook dédié : Guide de dépannage de vSphere par vExpert
Rya