vSphere 4 : Les mécanismes d’optimisation de la mémoire

Lors du dimensionnement d’une infrastructure virtuelle, la quantité de mémoire par hôte est une élément essentiel.   La quantité de VM pouvant fonctionner par hôte est un élément important à prendre en compte dans le calcul du ROI d’une infrastructure virtuelle. Plus on va utiliser la mémoire plus le ROI sera rapide.

Un des avantages de VMware face à ses concurrents est la gestion des mémoire. L’éditeur a développé plusieurs mécanismes permettant d’attribuer plus de mémoires aux VM que n’en dispose l’hôte. Ce procédé est nommé Memory overcommit (ou overcommitment).

Le lexique

Tout d’abord, voici un rappel du lexique :

Active Guest Memory : Mémoire récemment utilisée par le  système. Cette mémoire ne peut pas être réduite par le ballooning.

Consumed Host Memory : Quantité maximale de mémoire consommée depuis le démarrage de la VM. Cette valeur prend en compte la surcharge liée à la virtualisation (overhead).

Les seuils

Les techniques de réductions de la consommation de la mémoire se déclenchent en fonction de certains seuils.

Les seuils sont définis par défaut avec les valeurs suivantes:

• High : plus 6% de mémoire libre
• Soft : 4%  de la mémoire libre
• Hard : 2% de la mémoire libre
• Low : 1% de la mémoire libre

Seuils	Techniques
High	Aucune
Soft	Ballooning
Hard	Swapping, Ballooning
Low	Swapping

Les techniques

Le TPS (transparent page sharing) : L’hyperviseur déduplique les pages mémoires identiques (particulièrement efficace en VDI). Cette technique est utilisée en permanence.

ex: 5Go sur  de mémoire économisée sur un serveur disposant de 64Go de RAM et n’hébergeant que des serveurs Windows 2003.

Le ballooning : VMware créé un processus dans l’OS à l’aide des VMware Tools. Ce processus a pour but de provoquer un swap de l’OS. Le système d’exploitation swappe en priorité la mémoire inutilisée, préservant ainsi l’Active Guest Memory. La quantité de Consumed Host Memory est réduite pour tendre vers l’Active Guest Memory (+ l’overhead). Cette méthode permet de conserver de bonnes performances.

ex: 2048Mo de mémoire économisée. 1750Mo de mémoire ciblée par le ballon => phase de “dégonflage”.

La compression (à partir de vSphere 4.1) : L’hyperviseur compresse la mémoire à la volée.  Cette technique entraine une charge CPU supplémentaire. Cette technique est utilisée en permanence.

ex: 278Mo de mémoire économisée grâce à la compression.

Le swapping : Dans ce cas là, le swapping est réalisé non pas par l’OS invité mais par l’hyperviseur. Celui-ci écrit aléatoirement des pages mémoires dans un fichier de swap (créer au démarrage de la VM).   Cette technique est la plus pénalisante car si une page mémoire doit être accédée à partir du swap, une opération de lecture sur les disques a lieu .

Mais il est possible de tirer parti de cette technique en utilisant des disques SSD pour stocker les fichiers de swaps. Cette architecture est particulièrement intéressante dans le cas d’une infrastructure VDI.

ex: 398Mo de mémoire swappée (493Mo ciblée).

Les outils de monitoring

esxtop : Utilitaire en mode console. Pour le lancer, se connecter en SSH sur l’hôte à surveiller.

Puis saisir esxtop. Puis taper m pour passer en vue memory.

vSphere Client : Via l’onglet performance

Conclusion

Il ne faut pas avoir peur du memory overcommit (“surutilisation” de la mémoire) car les mécanismes mise en place par l’hyperviseur permettent de conserver des performances correctes évitant ainsi un effondrement brutal des VM.

Ces techniques sont particulièrement intéressantes dans une infrastructure VDI (TPS trés performant dans le cadre de 100 postes identiques sous Windows 7 par exemple).

Concernant les applications critiques aux comportement aléatoires (périodes charges inconnues par exemple), l’overcommit ne dois être utilisé que temporairement.

Je n’ai pas abordé la mise en place de limites et de priorités concernant la gestion de la mémoire car l’expérience montre que le coût de gestion de ces critères est très important par rapport au retour attendu.

Ces mécanismes associés à la mise en place d’un processus de capacity planning vous permettront de proposer une infrastructure virtuelle performante sans aléas.