La performance sous VMWare – Partie 4 – Les métriques spécifiques à la virtualisation à surveiller

Cet article fait partie d'un groupe d'articles:

  1. Généralités
  2. Les optimisations proposées par VMWare
  3. Comment dimensionner une VM
  4. Les métriques spécifiques à la virtualisation à surveiller durant un test de charge

Lors de test de performance, on se concentre surtout sur les métriques systèmes de la VM et peu de l'ESX. Pourtant, dans certains cas, les problèmes de performance ne peuvent pas s'expliquer au niveau de la VM mais au niveau de l'ESX. Exemple : l'ESX qui SWAP par manque de mémoire RAM physique.

Cet article propose les meilleures métriques à surveiller lors d'un test de performance. Cela peut également servir pour la production.

Les problèmes de performance potentiels provoqués par la virtualisation

Tout d'abord, attardons-nous sur les pertes de performance potentiels propre à l'ESX.

La virtualisation implique obligatoirement une perte de performance (heureusement assez réduite). Voici quelques causes :

  • La consommation de ressources pour gérer la virtualisation
  • Le fait d'avoir des éléments techniques communs :
    • Disque dur
    • Réseau
    • Entrées / sorties machine
    • CPU
    • RAM

La virtualisation peut induire les problèmes de performance suivants :

  • CPU de l’ESX saturés
  • CPU de la machine virtuelle saturée
  • Application utilisant une CPU uniquement
  • Mauvaise répartition de l’attribution de la puissance CPU sur les machines virtuelles
  • Applications non adaptées à la virtualisation
  • Accès mémoire trop importants
  • Mémoire insuffisante sur l’ESX pour répondre au besoin des machines virtuelles (allocation excessive)
  • Temps de réponse du stockage élevés
  • Stockage insuffisant (allocation excessive)
  • Débit du stockage insuffisant
  • Paquets réseaux perdus
  • Débit réseaux excessif

Ces pertes de performance peuvent être maîtrisées par  :

  • Une allocation des ressources (CPU / RAM) pour chaque système d’exploitation virtualisé (Cf. partie 3)
  • Les optimisations réalisées par défaut par VMWare
  • La possibilité de compartimenter et d'ajouter des ressources :
    • Multiplication de disques durs
    • Multiplication de cartes réseau
    • Ajout de RAM
    • Ajout de CPU

Les métriques à surveiller et leurs seuils d'alerte associés

Voici les métriques de performance spécifique à VMWare avec leurs seuils d'alerte associés :

Type d’élément N° Métrique Métrique VCenter Métrique VCOpts Seuil d’alerte

Cluster

M1

Memory -> Total Memory > Total Capacity (KB)

Valeur Intermédiaire

M2

Memory -> Consumed Memory > Consumed (KB) <90% de M1

M3

CPU -> Total capacity CPU Usage > Total Capacity (MHz)

Valeur Intermédiaire

M4

CPU -> Usage in MHz CPU Usage > Usage (MHz) <90% de M3

M5

Espace disque provisionné Planning > Capacity Provisioned > Disk Space Peut dépasser la valeur M18 mais faire un suivi strict de la consommation réelle. Alerte gérée par la supervision.

VM

M6

Memory -> Consumed Memory > Consumed (KB) M6 + M2 +M7 <90% de M1

M7

Memory -> Overhead Memory > Overhead (KB)

Valeur Intermédiaire

M8

CPU -> Usage in MHz CPU Usage > Usage (MHz) M4 + M8 < 90%M3

M9

Virtual disk -> Average request per seconde

Virtual Disk > Aggregate of all instances > Commands per Second

Somme des M9 de toutes les VM < 90% X

M10

Espace disque provisionné

Disk Space > Provisioned Space (GB)

Valeur Intermédiaire

M11

Espace disque utilisé

Disk Space > Virtual Disk Used (GB)

M11 < 60 % M10

Somme des M11 de toutes les VM < 60 % M18

M12

Ratio CPU Used/ Ready

CPU Usage > Ready (%)

<10% ou 5% interactif (desktop)

M13

Paquet dropped received and send

Network > Aggregate of all instances > Packets Dropped (%)

Proche de 0

M14

Latence disque

Virtual Disk > Aggregate of all instances > Total Latency

Moy < 30 ms

M15

Balloon

Memory > Balloon (KB)

moy < 10% M6

M16

Swapped

Memory > Swapped (KB)

Proche de 10 000

M17

memory -> Active

Memory > Guest Demand (KB)

Valeur permettant de savoir si l’utilisation mémoire est optimisée:

M17/M6 :

0 : mémoire peu optimisé

0,5 : mémoire optimisée

1 : manque de mémoire

Datastore

M18

Somme des Capacity des datastores

Disk Space > Capacity (GB)

Valeur Intermédiaire

ESX

M19

Somme de chaque ESX de « Datastore Average request per seconde »

Datastore > Aggregate of all instances > Commands Averaged

< 90% X

M20

Swapused

Memory > Swap Used (KB)

< 10 000

Conclusion

Notre série de quatre articles sur la performance sous VMWare se termine.

Nous avons pu découvrir tout d'abord comment fonctionne VMWare d'un point de vue technique.
Puis nous avons pu aborder les nombreuses optimisations proposées VMWare permettant d'atténuer les pertes de performance induites par la virtualisation.
Par ailleurs, nous avons vu comment bien dimensionner une VM et sur quels paramètres agir.
Enfin, nous avons listé un certain nombre de métriques clés à surveiller durant un test de performance ou en production.

Nous espérons que cela vous aidera, en particulier durant vos tests de performance ou même en environnement de production.
N'hésitez pas à poser vos questions ou ajouter vos commentaires!

Thibault van den Broek

6 réponses à to “La performance sous VMWare – Partie 4 – Les métriques spécifiques à la virtualisation à surveiller”

  • Chakib:

    Je vous remercie vraiment sur ces cours tres riches et bien detaillé

  • fafarun:

    Bonjour,

    Serie d’articles très intéressante, par contre les informations que vous fournissez sont génériques à toutes les versions des ESX? Vous avez mené vos essais avec quel version de ESX (5.0 5.1 ?)

    • thibault.vandenbroek:

      Bonjour,
      J’ai rédigé cet article en me basant sur une ESXi 4. Mais je pense que cela peut parfaitement s’appliquer aux versions supérieures.
      Thibault

    • Agree, great training sssieon.I combined it togheter with the Storage Area Networks (SANs) for DBAs sssieon , 6-8 hours of extremly well invested time that made gave me a lot of ammo to use in conversations with storage/vm-admins.

  • TEO:

    Merci beaucoup pour cette série d’article bien présenté.
    Un vrai plaisir à lire.

  • lewil84:

    Bonjour,

    pour les besoins d’un indicateurs et aussi pour ma compréhension.

    Actuellement :

    1 lame avec deux sockets à 6 cœurs chacun avec l’hyperthreading activé soit 24 Vcpu potentiel sur cette lame.

    Via VMWare on y a « placé » plusieurs VMs dont le global des Vcpu dépasse les 24 Vcpu.

    Si toutes les VMs tournent en même temps le risque est que la lame parte en vrille, quelle en serait l’impact ?

    Quelqu ‘un a t il l’information du seuil de VMWare au delà de ces 24 Vcpu ?

    Merci coopération

Laisser un commentaire

Merci d'effectuer cette opération simple pour valider le commentaire *

Mots-clés
RSS Feed