Introduction

Les hyperviseurs que sont ESX 4 et ESXi 4 proposent (comme dans la version 3.5) une gestion avancée de la mémoire physique. Le noyau du système (désigné par VMkernel) gère l'ensemble de la mémoire disponible dont une partie lui est réservée, et une autre réservée, dans le seul cas d'ESX, au Service Console (ESXi en étant dépourvue) qui par défaut occupe environ 300 Mo (au maximum 800 Mo). Le reste de la mémoire est utilisable par les machines virtuelles moyennant pour chacune d'elle un "overhead" (espace mémoire supplémentaire utilisé par le VMkernel pour les traitements liés à la gestion de cette mémoire) qui dépend de l'espace mémoire et du nombre de vCPU qui leur sont alloués.

ESX(i) 4 permet une sur-allocation de la mémoire, c'est à dire qu'il est possible d'attribuer à l'ensemble des machines virtuelles sur un serveur hôte, plus de mémoire que ce dernier n'en possède réellement. Afin de gérer efficacement cette sur-allocation, et ce, même en cas de contention (quand les machines virtuelles se disputent l'accès aux ressources physiques), VMware a doté ESX(i) de 3 différents mécanismes de gestion de la mémoire : le "Transparent Memory Page Sharing", le "Balloon driver" (vmmemctl), et le "VMkernel Swap". Le premier est activé par défaut (il peut être désactivé) et fonctionne systématiquement (même sans contention). Les deux derniers n'entrent en jeu qu'en cas de contention, et le serveur ESX(i) qui doit trouver de la mémoire pour une machine virtuelle, préfère d'abord le "Balloon driver", puis le "VMkernel Swap" en dernier recours (ce dernier étant bien sûr le moins satisfaisant en termes de performances).

Transparent Memory Page Sharing

La théorie

Le Transparent Memory Page Sharing (TMPS) est un mécanisme qui, comme son nom l'indique, permet de partager les pages mémoires identiques des différentes machines virtuelles hébergées par le serveur hôte. Ce mécanisme fonctionne un peu comme les systèmes de dé-duplication que l'on peut rencontrer sur les SAN modernes. Le VMkernel calcul les "hashs" des pages mémoire utilisées par les machines virtuelles et stocke ces valeurs de "hash" dans une table. De façon périodique les "hashs" sont comparés et si certains sont identiques, une comparaison bit à bit est alors effectuée. De cette façon, le VMkernel détecte quand les machines virtuelles possèdent des pages mémoires avec un contenu strictement identique, et n'enregistre physiquement en mémoire, qu'une seule copie (en lecture seule dans ce cas) des pages mémoires dupliquées. Ainsi une page mémoire physique peut être adressée dans l'espace mémoire virtuel de plusieurs machines virtuelles. Si une des machines virtuelles tente de modifier une page mémoire partagée, le VMkernel en créé une copie privée que seule la machine virtuelle concernée peut adresser.

Comme la dé-duplication au niveau du stockage, ce mécanisme permet "d'économiser" de l'espace mémoire, d'autant plus si les machines virtuelles hébergent la même version d'un système d'exploitation. Par exemple, entre 2 Windows Server 2003 64 bits, de nombreuses pages mémoires sont strictement identiques.

Par défaut TMPS est activé et fonctionne systématiquement en arrière plan, pour comparer les pages mémoires à intervalle régulier, et dé-dupliquer celles qui sont strictement identiques. Il est possible de désactiver ce mécanisme dans les options avancées du serveur hôte ESX(i).

Plusieurs outils permettent de s'assurer du fonctionnement du mécanisme TMPS sur les machines virtuelles ou directement sur un serveur hôte ESX(i). Sur une machine virtuelle l'onglet "Resource Allocation" permet de connaître l'espace mémoire partagé, "Shared" dans l'encadré "Memory". De même l'onglet "Performance" permet de suivre l'évolution de cet espace mémoire partagé ; il suffit de choisir le graphique "Real-time" dans la vue "Memory" et de sélectionner le compteur "Memory Shared". Pour un serveur hôte ESX(i), l'onglet "Performance" permettra de retrouver ce même graphique auquel on peut ajouter le compteur "Memory Shared Common" qui correspond à "l'overhead" (mémoire utilisée pour les traitements du mécanisme de partage mémoire) du TMPS. Il est également possible de suivre l'évolution de la mémoire partagée au travers du Service Console sur ESX avec l'outil esxtop (touche "m" pour passer sur la vue mémoire), ou grâce à l'appliance vSphere Management Assistant (vMA) et l'outil resxtop (même fonctionnement que esxtop). Les outils en ligne de commande tels que VMware PowerCLI (la collection des "cmd-let" PowerShell dédiées à l'administration de vSphere) sont également utiles pour retrouver ce type d'information avec, par exemple, une commande comme celle ci : Get-Stat -Entity (Get-VMHost <serveur ESX(i)>) -Memory -Realtime -MaxSamples 1 -Stat mem.shared.average. Enfin, l'installation des "VMware Tools" dans une machine virtuelle Windows ajoutent de nouveaux compteurs de performances dans l'outil "Performance Monitor" dont "MemSharedMB" qui permet de suivre la mémoire partagée par TMPS.

La pratique

Dans la pratique, en conservant les paramètres par défaut de la configuration avancée du serveur ESX(i), on constate effectivement une quantité non négligeable de mémoire partagée sur des machines virtuelles exécutant Windows Server 2003 (32 ou 64 bits). Même une machine virtuelle Windows seule sur un serveur hôte, voit une partie de sa mémoire "partagée" ; en effet des pages mémoires peuvent être les mêmes à l'intérieur d'une même machine virtuelle.

Cependant, quand il s'agit de machines virtuelles exécutant Windows Server 2008 et 2008 R2, on remarque que la quantité de mémoire partagée est négligeable voire nulle dans certain cas. En réalité, le mécanisme TMPS est efficace mais seulement (pour l'instant ?) en travaillant avec des pages mémoires de 4 Ko (taille par défaut). Depuis ESX(i) 3.5, VMware a introduit un véritable support des pages mémoires dites "larges" de 2 Mo, pour les machines virtuelles. Sans entrer dans les détails, le support des "super pages" permet aux applications (qui ont été conçues pour en tirer partie) d'adresser la mémoire en utilisant des blocs de 2 Mo (au lieu de 4 Ko). La translation d'adresses mémoire utilise le "translation lookaside buffers"(TLB). Ce dernier est un cache qui contient une table de translation (correspondances entre adresses mémoire virtuelle et adresses mémoire physique), directement au niveau du processeur physique, et qui est utilisé pour augmenter la vitesse à laquelle cette translation d'adresse mémoire est effectuée. Le TLB est potentiellement plus efficace avec des "super pages" de 2 Mo qu'avec des petites pages de 4 Ko (exemple si une application a besoin d'instancier une DLL de 1200 Ko elle devra selon le cas, soit lire une seule fois la table de translation soit la parcourir 1200 / 4 = 300 fois). Le support des "super pages" de 2 Mo par ESX(i) 3.5 et 4 pour les machines virtuelles 32 bits (en mode PAE) et 64 bits, permet donc selon VMware d'augmenter les performances de 10% dans certains cas (outil de benchmark SPECjbb2005).

De nombreux systèmes d'exploitation (Windows Server 2003 SP1, 2008, 2008 R2, Linux à partir du noyau 2.6) et certaines applications (Oracle et SQL Server par exemple) sont capables de tirer partie des "super pages". Contrairement à Windows Server 2003 sur lequel il faut activer manuellement le support des "super pages" (privilège "Lock pages in memory"), Windows 2008 et 2008 R2 sont capable de "travailler" nativement avec des pages mémoires de grande taille. C'est pourquoi quand le support des "super pages" (option avancée formalisée par Mem.AllocGuestLargePage = 1) est activé sur un serveur ESX(i) 4, une machine virtuelle exécutant Windows Server 2008 ou ultérieur n'aura qu'une trés petite partie (voire pas du tout) de mémoire partagée. De plus, dans cette configuration et en cas de contention, un quatrième mécanisme de gestion de la mémoire intervient avant le "VMkernel swap". Cette technique nommée "share‐before‐swap", fait en sorte que le VMkernel divise les "super pages" de 2 Mo (instanciées par les machines virtuelles) en petites pages mémoire de 4 Ko afin de faire intervenir le mécanisme TMPS. Cette technique est bien évidemment coûteuse en temps de traitement.

Doit on laisser activé ou non le support des "super pages" ? VMware présente un gain de performances d'environ 10% lié à l'utilisation des "super pages", dans le cas de certaines applications telles que les base de données Oracle et SQL Server, mais au détriment du mécanisme TMPS. Il convient alors plutôt de se demander si l'on souhaite bénéficier de la possibilité de surallouer la mémoire, et si oui quelles machines virtuelles vont héberger des applications qui tireront pleinement partie des grandes pages mémoire. Ainsi, si l'on souhaite tirer profit de la sur-allocation de la mémoire (ce qui représente malgré tout un véritable avantage par rapport à l'hyperviseur de Microsoft : Hyper-V version 1 et 2), la bonne pratique sera comme souvent un compromis, qui consistera à laisser le support des "super pages" activé au niveau du serveur hôte, et à le désactiver sur toutes les machines virtuelles (option avancée de la machine virtuelle monitor_control.disable_mmu_largepages = true) excepté celles qui sauront en tirer vraiment partie (serveur Oracle par exemple).

Les options avancées

Le comportement du TMPS est encadré par plusieurs options qui sont pour la plupart disponibles au niveau des paramètres avancés dans la configuration du serveur ESX(i) (onglet "Configuration" puis "Advanced Settings" et enfin catégorie "Mem"). Certaines des options avancées agissant sur le serveur hôte, existent également au niveau machine virtuelle (fenêtre "Edit Settings", onglet "Options", catégorie "Advanced" et sous catégorie "General").

Balloon driver

La théorie

Avant de décrire plus en détails, le fonctionnement du "Memory Ballooning", il est utile de rappeler dans quelles conditions le serveur hôte ESX(i) a besoin de "reprendre" de la mémoire à certaines machines virtuelles. Ces dernières sont isolées (les unes des autres, et du serveur hôte). De plus, le système d'exploitation invité n'a pas "conscience" de s'exécuter sur une machine virtuelle, et il ne connaît pas l'état des autres machines virtuelles qui sont exécutées sur le même serveur hôte. En cas de contention, les machines virtuelles ne libéreront pas d'elles mêmes une partie de la mémoire puisqu'elles ne "savent" pas que le serveur hôte est à court d'espace mémoire. C'est pour cette raison que VMware a introduit dans ESX(i) le mécanisme de "Memory Ballooning".

Ce dernier se présente sous la forme d'un pilote, installé dans les machines virtuelles avec les "VMware Tools". Ce pilote ne présente pas d'interface avec le système invité et communique avec le serveur hôte par le biais d'un canal privé. Dans un cas de contention et quand le serveur ESX(i) souhaite réquisitionner de la mémoire sur une machine virtuelle, il demande au "balloon driver" de "gonfler" (d'ou l'idée de ballon) dans cette dernière et d'occuper artificiellement un certain espace dans la mémoire du système d'exploitation invité (par défaut le "balloon driver" peut réquisitionner jusqu'à 65 % de la mémoire allouée ; option Mem.CtlMaxPercent). Comme ce pilote spécial est exécuté dans la machine virtuelle cible, c'est le système d'exploitation invité qui gérera la pression mémoire exercée par le "balloon driver", en utilisant ses propres algorithmes de gestion mémoire. Ainsi, il cédera d'abord la mémoire qu'il n'utilise pas, puis déchargera si besoin une partie du contenu de cette dernière dans son propre espace de swap (pagefile.sys sous Windows).

Comme pour le TMPS il existe plusieurs moyens de s'assurer du fonctionnement du mécanisme de "Memory Ballooning". Sur une machine virtuelle l'onglet "Resource Allocation" permet de connaître l'espace mémoire qui est réquisitionné par le "Balloon driver", "Ballooned" dans l'encadré "Memory". Que ce soit sur une machine virtuelle, ou sur un serveur hôte, l'onglet "Performance" permet également de retrouver cette information. Enfin, les outils esxtop, resxtop, PowerCLI et "Performance Monitor" peuvent aussi être utilisés.

Les options avancées

Comme pour le TMPS, plusieurs options régissent le fonctionnement du "Memory Ballooning".

VMkernel Swap

La théorie

 Le "VMkernelSwap" est l'ultime recours du serveur hôte ESX(i) qui doit trouver un espace mémoire pour une machine virtuelle. Nous l'avons vu plus haut, le TMPS a un impact relativement faible sur les performances de la machine virtuelle. Le "Memory Ballooning" n'induit l'utilisation du "swap" de la machine virtuelle que si elle ne possède pas assez de mémoire libre.

Ainsi, dans le cas ou les mécanismes de TMPS et "Memory Ballooning" ne sont plus à même de satisfaire les besoins des machines virtuelles en termes d'espace mémoire, le serveur hôte utilisera le "VMkernel Swap" (différent du swap du système d'exploitation invité dans une machine virtuelle). A cet effet, le serveur ESX(i)créé un fichier de "swap" pour chaque machine virtuelle au démarrage de ces dernières. Ce fichier de "swap" (.swp) est stocké par défaut, au même endroit que le fichier de configuration de la machine virtuelle. La taille de ce fichier est égale à la taille de l'espace mémoire alloué à la machine virtuelle moins l'éventuelle réservation mémoire(sur une machine virtuelle à laquelle est alloué 2 Go de mémoire et une réservation mémoire de 1 Go, la taille du "VMkernel Swap" sera de 1 Go ; si la réservation est de 2 Go le fichier de "swap" ne sera pas créé).

Au dela de la limitation liée à la quantité de mémoire (qu'il est possible "d'économiser" et / ou de réquisitionner),  TMPS et le "Balloon driver" ont besoin d'un certain temps pour accomplir leurs tâches respectives. La vitesse à laquelle "travaille" TMPS dépend du taux de pages mémoires scannées par seconde (voir les options TMPS avancées plus haut), mais également des opportunités à trouver des pages mémoires identiques. La vitesse à laquelle le "Memory Ballooning" est capable de réquisitionner de la mémoire dans une machine virtuelle dépend principalement du système d'exploitation invité et de sa capacité à répondre (rapidement ou non) aux demandes d'allocations mémoire. Au contraire, le "VMkernel Swap" est une technique qui permet de "fournir" aux machines virtuelles, un espace mémoire d'une taille donnée dans un temps donné (trés court puisque le fichier de swap est toujours prêt à remplir son rôle).

Cependant, le "VMkernel Swap" pénalise beaucoup les performances des machines virtuelles qui l'utilisent. Cette dégradation des performances est due principalement au fait que le serveur ESX(i) ne "maîtrise" pas le contenu de la mémoire occupée par les machines virtuelles (le "VMkernel Swap" est considéré par la machine virtuelle comme de la mémoire physique et non comme un espace de "swap" sur un disque). Par exemple, le système d'exploitation invité ne "swap" jamais les pages mémoires utilisées par le noyau, afin d'assurer un niveau de performance optimal de ce dernier. Le serveur ESX(i), qui ne peut pas identifier ces pages mémoires comme étant utilisées par le noyau du système d'exploitation invité, pourra éventuellement les positionner dans son espace de swap (ce qui dégradera fortement les performances de la machine virtuelle). De la même façon, le serveur hôte ne peut pas non plus identifier les pages mémoires utilisées par le système d'exploitation invité pour des mécanismes de tampon mémoire (positionner dans un espace mémoire des données fréquemment utilisées ; ce afin d'éviter d'accéder plusieurs fois au disque pour une même donnée, car la mémoire physique est plus rapide). ESX(i) pourra donc éventuellement "swapper" ces pages mémoires spécifiques.

De plus, le mécanisme de "VMkernel Swap" peut entrainer certains cas particuliers où le contenu d'une page mémoire peut être déplacée 2 fois vers un espace de "swap" différent, d'abord de la mémoire physique vers le "VMkernel Swap" et ensuite de ce dernier vers le "swap" du système d'exploitation invité (à sa demande). En effet, il est possible que le serveur ESX(i) décharge une page mémoire (utilisée par une machine virtuelle) dans son espace de "VMkernel Swap", puis que la machine virtuelle concernée décide de décharger à son tour, cette même page mémoire dans son propre espace de "swap".

Les mêmes outils cités précedemment pour TMPS et "Memory Ballooning" permettent d'observer le comportement du "VMkernel Swap".

La pratique

Toutes les raisons énoncées plus haut font que le mécanisme de "VMkernel Swap" n'est utilisé qu'en tout dernier recours. En pratique, il est vraiment préférable de dimensionner correctement le ou les serveurs ESX(i) afin d'éviter le déclenchement du "VMkernel Swap".S'il n'est pas possible d'éviter l'utilisation du "VMkernel Swap", il sera peut être judicieux de placer les fichiers de "swap" sur un espace de stockage performant afin d'éviter de trop pénaliser les machines virtuelles.

Les options avancées

Plusieurs options permettent de conditionner le fonctionnement du "VMkernel Swap". Il est important de noter que le fait de placer le fichier de "swap" d'une machine virtuelle ailleurs qu'avec les fichiers de cette dernière (par défaut) entrainera forcément un temps de migration vMotion potentiellement doublé (le mécanisme vMotion devra dans ce cas déplacer le contenu de la mémoire vive de la VM et son fichier de "swap").

Les seuils de déclenchement

Nous l'avons vu plus haut, le mécanisme TMPS (dans sa configuration par défaut) fonctionne toujours quelque soit l'utilisation de la mémoire du serveur hôte. Au contraire, les deux autres mécanismes que sont le "Memory Ballooning" et le "VMkernel Swap" ne fonctionnent qu'en cas de contention mémoire. Nous allons maintenant étudier les conditions de déclenchement de ces deux mécanismes.

ESX(i) présente 4 états définissant la quantité de mémoire physique libre, qui sont autant de seuils de déclenchement des fonctions de réquisition mémoire:

high représente une quantité de mémoire physique libre supérieure ou égale à 6%de la totalité de la mémoire disponible sur le serveur hôte. Cet état signifie que (même en situation de surralocation mémoire) la quantité de mémoire utilisée par l'ensemble des machines virtuelles ne dépasse pas la quantité de mémoire disponible sur le serveur ESX(i). S'il y a pas de limites à satisfaire (une machine virtuelle limitée à l'usage de 1 Go de mémoire par exemple), "Memory Ballooning" ou "VMkernel Swap" ne se déclencheront pas dans cet état. 

soft représente une quantité de mémoire physique libre inférieure à 6% et supérieure ou égale à 4%. A l'approche de cet état, l'hyperviseur commence à réquisitionner de la mémoire à l'aide du "Memory Ballooning". Le déclenchement du "Balloon driver" est fait par anticipation car il prend un certain temps à libérer de la mémoire.

hard représente une quantité de mémoire physique libre inférieure à 4% et supérieure ou égale à 2%. Si ce seuil est atteint, ESX(i) déclenche le "VMkernel Swap" en plus du "Memory Ballooning" (déclenché par le seuil "soft" ). Cela permet de revenir rapidement à l'état "soft".

low représente une quantité de mémoire physique libre inférieure ou égale à 1%. Dans les rares cas ou le serveur ESX(i) atteint ce seuil "Memory Ballooning" et "VMkernel Swap" continuent de réquisitionner de la mémoire physique, et les machines virtuelles qui consomment plus que leur allocation cible (calculée en fonction des réservations, limites et shares) sont stoppées.

Enfin, il existe certains cas ou les mécanismes de réquisition mémoire se déclenchent sans tenir compte des états décrits plus haut. Par exemple, même dans l'état "high", ESX(i) peut déclencher le "Ballon driver" ou le "VMkernel Swap" pour empêcher une machine virtuelle de consommer plus de mémoire que sa limite (si elle en a une).

Arbitrer la distribution de la mémoire

La théorie

Nous allons maintenant voir comment ESX(i) gère l'allocation de la mémoire en situation de contention (à quelle VM le serveur hôte doit "prendre" de la mémoire? quelle VM favoriser ? au détriment de laquelle ?).

ESX(i) propose trois paramètres qui permettent de controler finement l'allocation de la mémoire à une machine virtuelle :

le "share"qui définit le pourcentage de la mémoire physique globale, qui est dédiée à une machine virtuelle. Supposons par exemple un serveur hôte disposant de 4 Go de mémoire physique disponible pour les VMs, et deux machines virtuelles VMA et VMB dotées respectivement de 4 Go avec un "shares" de 6000, et de 2 Go avec un share de 2000. Il y a ici une sur-allocation de la mémoire ( 6 Go alloué sur 4 Go physiquement disponible). Dans ce cas la machine virtuelle VMA disposera de 4000/6000 * 4 Go = 2,6 Go  de mémoire physique. VMB disposera de 2000/6000 * 4 Go = 1,4 Go de mémoire physique.

la limite qui définit la quantité maximum de mémoire physique qui sera utilisée par la machine virtuelle. Par défaut ce paramètre est positionné à illimité ("unlimited") ce qui signifie que la totalité de la mémoire allouée (plus l'overhead) peut être de la mémoire physique.

la réservation qui représente la quantité minimum et garantie de mémoire physique que la machine virtuelle pourra utiliser, et ce même en situation de contention. Par défaut ce paramètre est positionné à 0 ce qui signifie que la machine virtuelle ne possède pas de réservation mémoire.

La limite et la réservation sont deux contraintes qui surpassent ce qui est acquis au travers du "share". C'est à dire que si nous reprenons l'exemple précédent et que nous rajoutons une réservation de 2 Go à la machine virtuelle VMB, cette dernière aura dans tous les cas 2 Go (soit la totalité de la mémoire qui lui est alloué) de mémoire physique. VMA ne disposeras alors que du reste, soit 2 Go aussi, alors que son "share" lui donnait droit initiallement à 2,6 Go.

A intervalle régulier (option avancée Mem.BalancePeriod), ESX(i) calcul "l'allocation mémoire cible" pour chaque machine virtuelle. Cette valeur est basée sur son "share", l'estimation de la mémoire réellement utilisée ("Working Set Size"), la limite et la réservation de la VM. Le "Working Set Size" est une estimation de l'espace mémoire réellement utilisé par le système d'exploitation invité. Quand la mémoire n'est pas sur-allouée, "l'allocation mémoire cible" est la mémoire consommée par l'hôte pour exécuter la machine virtuelle (la mémoire utilisée par la VM plus l'overhead). "L'allocation mémoire cible" maximum est donc définit par min{Mémoire allouée, Limite}. En situation de sur-allocation, "l'allocation mémoire cible" est quelque part entre la réservation et la limite, et dépend du "share" et de la charge de travail.

Si la quantité de mémoire physique utilisée par le serveur hôte pour exécuter une machine virtuelle, dépasse la quantité de mémoire calculée dans "l'allocation mémoire cible" (ce qui arrive fréquemment en cas de surallocation), le système déclenche "Memory Ballooning" ou "VMkernel Swap" sur la machine virtuelle concernée pour réquisitionner une partie de la mémoire physique et ainsi faire en sorte que "l'allocation mémoire cible" soit "respectée". La décision d'utiliser "Memory Ballooning" ou "VMkernel Swap" est fonction de l'état de la mémoire libre (voir partie précédente).

La notion de "share" joue un rôle prépondérant pour déterminer "l'allocation mémoire cible" quand la mémoire du serveur hôte est sur-allouée. Si ESX(i) a besoin de mémoire, il en réquisitionnera d'abord à la machine virtuelle qui présente le ratio "shares par page mémoire allouée" le plus petit.

Pourtant, l'utilisation d'un algorithme basé uniquement sur un poids relatif (les "shares" qui privilégient certaines machines virtuelles par rapport à d'autres), présente l'inconvénient majeur de ne pas tenir compte de l'utilisation réelle de la mémoire par les machines virtuelles. Avec un tel mécanisme, les machines virtuelles avec un "share" élevé, "retiendront" de la mémoire physique non utilisée par le système d'exploitation invité alors qu'elles n'en ont pas l'utilité. Ceci au détriment d'autres machines virtuelles avec un "share" moins important et qui pourraient avoir besoin de plus de mémoire physique.

ESX(i) propose une solution avec l'estimation du "Working Set Size" cité plus haut, ainsi que la notion de "Idle Memory Tax". Il s'agit ici d'appliquer une "taxe" plus ou moins élevée, en fonction de la mémoire utilisée par le système d'exploitation invité (le "Working Set Size"). Ainsi une machine virtuelle qui dispose de beaucoup de mémoire libre (du point de vue du système d'exploitation invité) sera plus "taxée" que d'autres, et son ratio ajusté de "shares par page mémoire allouée" sera plus faible, la désignant comme cible privilégiée si le serveur hôte a besoin de réquisitionner de la mémoire. L'algorithme qui est utilisé par ESX(i) pour calculer le ratio ajusté de "shares par page mémoire allouée" est le suivant :

L'efficacité de l'algorithme précedent dépend principalement du calcul du "Working Set Size" et de la précision de son estimation. Pour déterminer ce dernier, ESX(i) utilise une méthode statistique sans "interroger" directement le système d'exploitation invité. Chaque machine virtuelle est échantillonée indépendamment des autres. Au début de chaque période d'échantillonage, le serveur hôte invalide volontairement un petit nombre n (par défaut 100 pages par tranche de 60 secondes, option avancée Mem.SamplePeriod) de pages mémoire physique allouée à la machine virtuelle, et sélectionnées aléatoirement. Durant cette période d'échantillonage, ESX(i) incrémente un compteur t quand une page mémoire précedemment invalidée est validée à nouveau (par un accès du système d'exploitation invité à la page concernée). A la fin de la période d'échantillonage la fraction f de mémoire physique utilisée ("Working Set Size") est : f = t / n.

Les options avancées

VMware propose encore une fois, des paramètres de configuration avancés, qui permettent de régler l'arbitrage du système pour l'accès à la mémoire.

Conclusion : les bonnes pratiques

Nous l'avons vu dans les pages précedentes, ESX(i) intègre 3 mécanismes de gestion avancée de la mémoire physique. Ces algorithmes qui ont pour but de mutualiser de manière optimale l'accès à la ressource mémoire, ne sont pertinents que s'ils sont correctement utilisés. Voici donc une liste non exhaustive de bonnes pratiques à observer quand à l'attribution de la mémoire physique aux machines virtuelles.

Attribuer un espace mémoire approprié pour chaque machine virtuelle.La taille mémoire allouée à chaque machine virtuelle ne doit ni être trop petite ni trop grande. Une taille mémoire trop réduite induira forcément l'utilisation de la mémoire paginée dans le système d'exploitation invité ("swap" sur le disque donc une dégradation des performances), alors même que le serveur hôte pourrait encore disposer de mémoire physique non utilisée. A l'inverse, attribuer un large espace mémoire à une machine virtuelle, bien que satisfaisant pour cette dernière, n'est pas non plus un choix judicieux. En effet cela entraine, d'une part un overhead mémoire plus conséquent pour la machine virtuelle concernée, et d'autre part une utilisation plus intensive du "Memory Ballooning" (qui ne se privera pas de réquisitionner la mémoire non utilisé si la machine virtuelle concernée ne dispose pas d'une réservation mémoire).

Utiliser les "shares" pour établir les priorités d'accès à la mémoire physique. Ainsi, en situation de contention la mémoire physique sera répartie de manière à respecter les priorités indiquées par les "shares".

La taille de la mémoire physique disponible sur le serveur hôte doit être correctement dimensionnée. Dans l'idéal il convient de limiter la surralocation de la mémoire à un maximum de 1,5 fois la taille de la mémoire physique. La règle est de dimensionner la ressource mémoire physique afin que le serveur hôte ne soit jamais dans la situation ou il doit utiliser le "VMkernel Swap" (synonyme de trop grande dégradation des performances).

Utiliser avec parcimonie les notions de limite et réservation mémoire. Décrite plus haut, "l'allocation mémoire cible" dépend entre autres, de la limite et de la réservation. Mal utilisées, ces deux options peuvent entrainer l'utilisation du "Memory Ballonning" ou du "swap" du système d'exploitation invité, même si le serveur hôte dispose encore de mémoire physique libre. Par exemple ESX(i) peut décider de réquistionner de la mémoire physique à une machine virtuelle si d'autres ont une réservation (que le système doit satisfaire même si ces machines virtuelles n'utilisent qu'une part très limitée de leur mémoire réservée).

Ajouter un Commentaire