Posts Tagged VMkernel
Auditer les performances des machines virtuelles sous VMware vSphere 4 (deuxième partie)
Publié par Aurélien dans Virtualisation le 16 avril 2010
Avant toute chose, je vous invite à lire la première partie de cet article si vous n’en avez pas encore pris connaissance.
Maintenant que vous avez saisi l’importance du triptyque d’analyse de performance (système d’exploitation, VM, hôte), il ne vous reste plus qu’à le vérifier par vous-même. Pour cela, les graphs de performance intégrés au vCenter sont particulièrement utiles. Lorsque vous sélectionnez une machine virtuelle, vous aurez probablement remarqué l’onglet Performance qui permet d’obtenir à la fois une vue synthétisée de l’état actuel de la VM (Overview) et une vue plus précise et personnalisable (Advanced) qui était d’ailleurs la seule disponible avant la sortie de VMware vSphere 4.
La vue Advanced permet de personnaliser les compteurs que l’on veut surveiller et de remonter dans le temps selon les réglages pré-enregistrés dans le moteur de SGBD du vCenter. Dans les exemples ci-dessous, on a choisi d’afficher les valeurs CPU Usage et CPU Ready. Pour cela, il suffit de cliquer sur le lien Chart Options… et de choisir les valeurs qui nous intéressent.
Etude de cas
Si la valeur CPU Usage est connue et maitrisée, CPU Ready est quant à elle fort intéressante dans le sens où elle reflète l’intervalle pendant lequel la VM est prête pour exécuter des instructions mais ne le peut pas car elle n’arrive pas à obtenir de ressources processeur suffisantes de l’hôte. En d’autres termes, le CPU Ready correspond au temps passé (en millisecondes) avant d’obtenir un contexte d’exécution mémoire disponible. On ne peut donc à nouveau pas interpréter de lenteurs à coup sûr sans croiser les relevés de performance…
1er cas : la VM est moyennement utilisée mais l’hôte ne répond pas de façon optimale
- Moyenne CPU Usage : 37%
- Moyenne CPU Ready : 16ms
2ème cas : la VM charge beaucoup et l’hôte ne répond pas de façon optimale
- Moyenne CPU Usage : 86%
- Moyenne CPU Ready : 24ms
3ème cas : la VM est peu utilisée et l’hôte répond quasi de façon optimale
- Moyenne CPU Usage : 1%
- Moyenne CPU Ready : 3ms
Note : la valeur CPU Ready n’a de sens qu’analysée sur du long terme. En effet, votre hôte peut charger ponctuellement, des VMs peuvent nécessiter beaucoup de ressources en même temps et au moment même où vous mesurez les performances, etc…
La valeur de référence de CPU Ready étant 0ms, vous pouvez tenir pour acquis que plus vos mesures sont près de 0, plus votre infrastructure virtualisée répond bien.
Il existe bien d’autres moyens de déterminer des lenteurs dans un système d’exploitation, dans une VM ou un hôte ESX. Le tout étant de bien comprendre le mécanisme de virtualisation. A présent vous n’aurez qu’à appliquer le même principe de réflexion pour la RAM, le réseau ou les I/O disque.
Pour aller plus loin, je vous invite à lire les documents de référence VMware suivants qui prolongent cet article :
Auditer les performances des machines virtuelles sous VMware vSphere 4 (première partie)
Publié par Aurélien dans Virtualisation le 14 avril 2010
Déterminer des problèmes de performance en environnement virtualisé est nettement plus complexe qu’avec des serveurs physiques. Non seulement les ressources des machines virtuelles sont à corréler avec la couche de l’hyperviseur, mais également avec le serveur physique qui héberge les machines, le stockage centralisé et le réseau. Il convient donc de mettre en place un audit pas à pas afin d’avoir un cheminement cohérent.
Mesurer la charge courante d’une machine
Le préalable à toute modification structurelle d’un serveur consiste de prime abord à constater – principalement – la charge CPU, RAM, réseau ainsi que les I/O disque (téléchargez Iometer). A partir de cette observation, vous devrez être en mesure de déterminer un goulot d’étranglement et les moyens à mettre en oeuvre pour retrouver une situation acceptable.
Ici on a pris l’exemple d’un serveur pour lequel un service Java charge notablement le CPU. Le gestionnaire des tâches de Windows permet de confirmer des crètes à répétition qui peuvent durer plusieurs minutes d’affilée. Dès qu’on limite significativement les connexions, la charge revient à des valeurs très basses, ce qui étaye notre propos.
L’origine de la charge étant connue, on peut penser à la suite des opérations. Néanmoins, gardez toujours en tête que la mesure de performance que vous effectuez à l’intérieur d’une machine virtuelle n’est valable que dans une certaine mesure. En effet, cette machine étant justement virtuelle, il faudra mettre en perspective la mesure de performance du serveur ESX, de la machine virtuelle et des outils habituels dans le système d’exploitation de cette même VM. Pour prendre pleinement conscience de cet état de fait, dites-vous toujours qu’ une machine virtuelle qui montre une charge CPU à 100% ne signifie pas nécessairement une charge à 100% dans l’ensemble des couches de la virtualisation.
Tirer parti de l’intégration des VMware Tools pour mesurer les performances
On ne le répétera jamais assez, les VMware Tools doivent être installés sur vos machines virtuelles. Voici encore un cas concret de leur utilité : une DLL Perfmon est installée et permet l’accès aux statistiques de performance mémoire et processeur directement depuis l’OS d’une machine virtuelle.
Pour lancer Perfmon, cliquez sur le menu Démarrer > Exécuter puis entrez perfmon. Dans la fenêtre du logiciel, les premières courbes de performances s’affichent. Cliquez droit > Propriétés
Dans la fenêtre des compteurs qui apparaît ensuite, sélectionnez soit l’objet VM Processor, soit VM Memory. Puisque dans notre exemple c’est le processeur qui pose problème, on choisi l’objet VM Processor avec son compteur % Processor Time et on clique Ajouter.
Nous avons désormais quatre compteurs. Puisque les courbes vont se marcher un petit peu dessus, on grossit volontairement la largeur du trait et on valide les modifications.
On peut maintenant tirer parti des compteurs spécifiques proposés par les VMware Tools et confronter les relevés de performances.
Pour lire la deuxième partie de cet article, rendez-vous ici.
Gérer les modules du VMkernel avec vmkload_mod et esxcfg-module
Publié par Aurélien dans Virtualisation le 30 septembre 2009
Décharger un module peu sembler superflu de prime abord. En effet, l’hôte ESX sur lequel vous allez effectuer l’opération ne sera probablement pas plus performant et bien malin qui pourrait voir une augmentation des performances CPU et/ou RAM. Pourtant, au niveau réseau, vous pourrez observer dans certains cas (installations avec de nombreuses LUNs et volumes VMFS…) une rapidité accrue dans le rafraîchissement de vos datastores et de vos adaptateurs de stockage iSCSI et Fiber Channel.
Opérations en environnement VMware ESX 3.5
Pour lister les modules actifs du VMkernel, on utilise soit la commande vmkload_mod -l, soit la commande esxcfg-module -l.
[root@srv5 etc]# vmkload_mod -l
Name R/O Addr Length R/W Addr Length ID Loaded
vmklinux 0x87e000 0x20000 0x28a3280 0x4d000 1 Yes
ata_piix 0x89e000 0xb000 0x28f02a0 0x4000 2 Yes
megaraid_sas 0x8a9000 0x7000 0x28f42c0 0x3000 3 Yes
bnx2 0x8b0000 0x10000 0x28f72e0 0x17000 4 Yes
e1000 0x8c0000 0x1c000 0x290e300 0x6000 5 Yes
lvmdriver 0x8dc000 0xb000 0x292b580 0x2000 6 Yes
vmfs3 0x8e7000 0x2c000 0x292d5c0 0x1000 7 Yes
etherswitch 0x913000 0x3000 0x292e688 0x1000 8 Yes
shaper 0x916000 0x3000 0x292fb80 0x1000 9 Yes
tcpip 0x919000 0x3a000 0x2930c00 0x1c000 10 Yes
cosShadow 0x953000 0x3a000 0x294cc80 0x1c000 11 Yes
migration 0x98d000 0xf000 0x2968ca0 0x2000 12 Yes
nfsclient 0x99c000 0x12000 0x296acc0 0x1000 13 Yes
deltadisk 0x9ae000 0x7000 0x296bf60 0x1000 14 Yes
vmfs2 0x9b5000 0x10000 0x296cf80 0x11000 15 Yes
iscsi_mod 0x9c5000 0x35000 0x297dfa0 0xa000 16 Yes
Ici, on remarque que le module vmfs2 est chargé, or nous n’utilisons que vmfs3. On peut donc désactiver ce module pour décharger le VMkernel de cette gestion inutile. Pour cela, on utilise à nouveau la commande vmkload_mod mais cette fois avec l’argument -u (pour unload). La commande esxcfg-module -d aurait également été possible.
[root@srv5 etc]# vmkload_mod -u vmfs2
Ne reste plus qu’à lister de nouveau pour vérifier que le module vmfs2 a bien été désactivé. Vous pouvez bien sûr répéter l’opération pour tout autre module qui vous serait inutile. Comme nous avons pris l’exemple du stockage, continuons dedans. Si vous n’utilisez pas NFS (module nfsclient), désactivez-le à son tour et validez l’opération en listant de nouveau les modules.
[root@srv5 etc]# vmkload_mod -l Name R/O Addr Length R/W Addr Length ID Loaded vmklinux 0x87e000 0x20000 0x28a3280 0x4d000 1 Yes ata_piix 0x89e000 0xb000 0x28f02a0 0x4000 2 Yes megaraid_sas 0x8a9000 0x7000 0x28f42c0 0x3000 3 Yes bnx2 0x8b0000 0x10000 0x28f72e0 0x17000 4 Yes e1000 0x8c0000 0x1c000 0x290e300 0x6000 5 Yes lvmdriver 0x8dc000 0xb000 0x292b580 0x2000 6 Yes vmfs3 0x8e7000 0x2c000 0x292d5c0 0x1000 7 Yes etherswitch 0x913000 0x3000 0x292e688 0x1000 8 Yes shaper 0x916000 0x3000 0x292fb80 0x1000 9 Yes tcpip 0x919000 0x3a000 0x2930c00 0x1c000 10 Yes cosShadow 0x953000 0x3a000 0x294cc80 0x1c000 11 Yes migration 0x98d000 0xf000 0x2968ca0 0x2000 12 Yes deltadisk 0x9ae000 0x7000 0x296bf60 0x1000 14 Yes iscsi_mod 0x9c5000 0x35000 0x297dfa0 0xa000 16 Yes
Seul bémol, les modifications effectuées ne seront plus valables au prochain boot. Il faudrait donc envisager de scripter les opérations pour bénéficier de vos modifications à long terme.
Opérations en environnement VMware vSphere 4
Il y a eu peu de changements dans la gestion des modules avec l’arrivée de VMware vSphere 4, néanmoins, ils sont assez significatifs pour être décrits ici. En effet, les commandes de listage et de déchargement de modules sont les mêmes mais la commande esxcfg-module permet désormais de préserver les modifications, même après redémarrage !
Si la désactivation d’un module par esxcfg-module -d <module> fonctionne sans problème, la confirmation n’apparaît pas en listant les modules avec esxcfg-module -l ce qui peut être déroutant. Pourtant, en utilisant la commande esxcfg-module -q (pour lister les modules actifs), on verra bien que le module est déchargé, de même que dans le fichier /etc/vmware/esx.conf, à la ligne correspondante.
/vmkernel/module/vmfs2/enabled = "false"
Pour information, voici le détail des arguments les plus utiles de la commande esxcfg-module :
-e --enable Enable the given module, indicating it should load at boot time. -d --disable Disable the given module preventing it from loading at boot. This will have no immediate effect on the module state on a running system. -q --query Query the system for the modules to load at boot. -l --list Detailed list of loaded modules
Remarquez que l’argument -d se comporte donc bien différemment de VMware ESX 3.5. : “Disable the given module preventing it from loading at boot”.
