vendredi , 19 janvier 2018
Templates by BIGtheme NET
Home / VMware / VMware vSphere : Les serveurs ESXi

VMware vSphere : Les serveurs ESXi

Les serveurs ESXi

1. Gestion de la mémoire

a. Memory Overcommitment

Dans un environnement virtualisé, les ressources sont partagées. Cela apporte des avantages par rapport à des architectures traditionnelles et notamment pour la gestion mémoire des serveurs hôtes ESXi. Ainsi, il est possible d’avoir plus de mémoire dans les machines virtuelles configurées qu’il n’y a de mémoire physique (appelée RAM). C’est ce qui est appelé Memory Overcommitment (ou, en français, surallocation de mémoire). Cela permet d’atteindre un haut niveau de consolidation des serveurs.

esx1

II est possible d’avoir 8 machines virtuelles configurées chacune avec 2 Go de mémoire sur un serveur ne contenant que 8 Go de RAM physique. Ceci est réalisé sans dégradation de performance.

Lorsque la surallocation de mémoire est employée, ESXi doit employer des techniques pour récupérer de l’espace mémoire d’une ou plusieurs VM. Ces techniques sont les suivantes : le Transparent Page Sharing, le Ballooning, le Swap et la compression mémoire.

b. Transparent Page Sharing

Lorsque des systèmes d’exploitation sont de même nature, il est fort probable que certaines pages mémoires soient identiques. Le processus de Transparent Page Sharing scanne la mémoire et s’il trouve des pages identiques, il garde une copie et fait pointer les VM qui utilisent cette page puis libère la page en double. Ceci est complètement transparent pour l’OS (d’où le nom de Transparent Page Sharing) qui n’a pas conscience de partager une page mémoire avec d’autres VM.

esx2

Exemple

Imaginons 10 VM avec une mémoire de 1 Go créées à partir d’un même Template. Après le démarrage de ces VM, les pages mémoires sont identiques.

Sans TPS, l’espace occupé par les 10 VM serait de 10 *1 Go = 10 Go.

Avec TPS, l’espace occupé est d’1 Go : soit une économie réalisée de 9 Go. Cette technique permet de faire des gains considérables en espace mémoire.

Conseil : il est judicieux de créer des VM à partir d’un template pour exploiter au mieux le Transparent Page Sharing.

c. Ballooning

Le Ballooning est le fait de prendre de la mémoire à une VM qui n’en a pas besoin pour la donner à une VM qui en a besoin dans le cadre de la surallocation.

Cette technique n’est pas utilisée dans le cas où il n’y a pas de surallocation de mémoire.

Le ballooning part du principe qu’en environnement de production seul un pourcentage de la mémoire est utilisé intensivement : c’est la mémoire active indispensable au bon fonctionnement du système. Le reste de la mémoire (mémoire inactive ou idle) est très peu utilisée. Comme la mémoire est partagée, il est donc possible de récupérer cette mémoire inactive pour la rendre disponible pour les autres VM. VMware tire profit de cette mémoire inutilisée grâce au ballooning.

esx3

Dans cet exemple, la mémoire consommée est de 2 Go alors que seulement 25 % de la mémoire est active. Le reste de la mémoire a été chargé au démarrage et est inutilisé. En environnement traditionnel, cela n’a pas d’importance mais en environnement de partage de ressources cette mémoire inutilisée peut être récupérée et mise à disposition pour les autres VM, c’est ce que fait le ballooning.

Comment fonctionne le ballooning ? Lorsqu’on installe les VMware Tools, un balloon driver (vmmemctl) est chargé dans la VM. Ce driver n’a aucune interface avec l’extérieur et communique directement avec ESX grâce à une communication privée. Quand le serveur ESX souhaite récupérer de la mémoire, il donne l’instruction au driver de gonfler (comme un ballon d’où le nom de ballooning) ce qui a pour conséquence d’accroître la pression sur la VM. Le Guest OS fait appel à ses propres algorithmes de gestion de la mémoire afin de libérer les pages mémoire qui sont les moins utilisées (celles qui sont en mode idle).

esx4

Lorsqu’une troisième VM souhaite démarrer, le balloon driver des autres VM gonfle et accroît la pression sur les autres VM libérant les pages mémoires inactives.

Lorsque le ballooning est employé, ESX doit décider de gonfler le balloon driver dans certaines VM pour récupérer la mémoire. Mais quelle VM va libérer de la mémoire ?

C’est à ce moment qu’intervient la notion de Share. Le Share est une notion d’importance ou de priorité relative aux autres VM. Il existe 4 niveaux : Low, Medium, High ou Custom ayant un ratio de 1:2:4 et Custom. ESX récupère en priorité de la mémoire aux VM ayant un share de niveau bas (Low) pour la donner en priorité aux VM ayant des share élevés. La mémoire ayant un share élevé (High) n’est récupérée qu’en dernier recours.

Exemple

Soit un Serveur ESXi avec 4 Go de RAM. Les 2 VM sont configurées avec 4 Go chacune : VM1 en High (ratio 4) et VM2 en Low  (ratio 1).

Le calcul de proportion est le suivant avec les share :

VM 1 = 4/5 *4 Go soit 3,2 Go pris sur la RAM.

VM2 = 1/5 *4 Go soit 800 Mo pris sur la RAM.

Si vous souhaitez rajouter une 3éme VM en niveau High (ratio 4), cela donne pour chaque VM :

VM1 = 4/9 *4 Go = 1,77 Go

VM2 = 1/9 *4 Go = 444 Mo

VM3 =4/9 *4 Go =1,77 Go

Idle Memory tax

La limitation importante du share est qu’il n’intègre pas de critères sur l’utilisation de mémoire active. Il est donc probable qu’une VM avec un share en niveau High accumule de la mémoire inactive alors qu’une VM avec un share en niveau Low peut être pénalisée si elle utilise une grande quantité de mémoire active.

ESXi résout ce problème en introduisant la notion d’Idle Memory tax (taxe pour la mémoire inactive). L’objectif de cette taxe est simple : récupérer en priorité de la mémoire inutile (celle qui est idle) quel que soit le niveau de share de la VM. L’idée est qu’une page inactive sera taxée alors qu’une page active ne le sera pas. Nous ne rentrerons pas dans les détails pour le calcul de mesure de cette mémoire idle. Il faut savoir qu’ESX utilise une approche de probabilité sur des échantillons de pages mémoire directement sans intervenir à l’intérieur des systèmes d’exploitation des VM. Chaque VM est échantillonnée individuellement selon une période configurable. Par défaut, ESX échantillonne 100 pages toutes les 30 secondes.

Par défaut, le paramètre idle memory tax est de 75 %, ce qui correspond à une récupération maximum de 75 % de la mémoire non utilisée.

Exemple

Un Serveur ESX dispose de 4 Go de RAM. Chaque VM est configurée avec 4 Go de mémoire avec un share paramétré en normal. Imaginons 2 VM dont l’une a une activité mémoire intensive et l’autre pas.

VM1 = Active Directory avec une mémoire active de 1 Go (3 Go idle).

VM2 = SQL avec une mémoire active de 3 Go (1 Go idle).

Les share étant ’normal’, chaque VM reçoit en proportion 50 % soit 2 Go chacune. VM1 possède 1 Go disponible.

Idle memory tax autorise l’hyperviseur à récupérer jusqu’à 75 % de la mémoire inactive de VM1 (en l’occurrence 75 % de 1 Go soit 750 Mo).

Soit avec idle memory tax, VM1= 1,25 Go et VM2 = 2,75 Go.

Il est possible de protéger une VM en interdisant au ballooning de récupérer la mémoire de cette VM. Pour cela, il suffit de configurer la VM avec un niveau de réservation identique à la mémoire configurée.

d. Swap

Au démarrage d’une VM, un fichier de swap est créé dont l’extension est .vswp. Une VM ne peut démarrer que si ce fichier peut être créé et disponible (attention donc à l’espace de stockage disponible).

L’hyperviseur utilise ce fichier de swap dans le cas où il y a de la surallocation et que le balloon driver ne peut pas récupérer de la mémoire dans les autres VM. Dans ce cas, il utilise le disque dur comme mémoire. Il est à noter que cette technique ne devrait jamais être employée du fait des performances largement dégradées par des accès disques. Le seul mérite de ce swap est de ne pas avoir de crash de VM si la mémoire devient insuffisante.

Pour information, le temps d’accès d’un disque dur se mesure en ms (millième de seconde) et la mémoire en ns (1 milliardième de seconde), soit 1 000 000 fois plus lent. Ainsi, pour donner une idée, lorsque la mémoire met 1 seconde pour accéder à une information, le disque dur met 11,5 jours (soit 1 000 000 / (60 s *60 mn *24 heures)).

Les caractéristiques de ce fichier de swap sont les suivantes :

  • L’extension est .vswp.

  • Sa taille est équivalente à la taille mémoire configurée – la réservation.

  • Il est placé par défaut dans le répertoire dans lequel se trouve le fichier de configuration vmx (modifiable dans les options avancées de la mémoire).

Conseil : il peut être judicieux de stocker les fichiers de swap sur des disques SSD, qui sont très performants.

  • Il est supprimé dès que la VM est éteinte (la suppression peut être interdite).

  • Une VM ne peut pas démarrer s’il n’y a pas assez d’espace de stockage pour créer le fichier.

e. Compression de mémoire

Avant que l’hyperviseur décide de swapper ses pages sur le disque dur, un niveau intermédiaire intervient qui est la compression mémoire. ESXi compresse les pages et les stocke dans un espace protégé de la mémoire. L’accès à la mémoire compressée est plus rapide qu’un accès disque sans trop dégrader les performances. Lorsqu’une page virtuelle doit être permutée, ESXi tente tout d’abord de la compresser sur des blocs de 2 Ko ou inférieur.

Il est possible de définir la taille maximale du cache de compression et/ou de désactiver la compression mémoire dans les paramètres avancés de vCenter.

f. Dimensionnement

Pour bénéficier d’un bon niveau de consolidation, il faut faire de la surallocation de mémoire. Le principe de dimensionnement suivant peut être appliqué :

Une règle de base pour le dimensionnement est de mettre entre 4 et 8 Go de RAM par cœur physique.

Exemple

Un serveur avec un total de 12 cœurs doit avoir entre 48 Go et 96 Go de RAM.

Pour déterminer le nombre de VM pouvant fonctionner, plusieurs approches sont possibles :

  • Pour une approche optimisée pour des applications de test, développement, pré-production, etc. Il est possible de partir sur la règle suivante : la somme des mémoires configurées dans les VM peut être le double de la mémoire physique RAM dans le serveur.

Exemple

Un serveur de 32 Go de RAM peut avoir 32 VM configurées avec 2 Go de mémoire chacune (ou 64 VM avec 1 Go de mémoire chacune).

  • Pour une approche conservative (pour des applications sensibles), il faut transposer la même quantité de mémoire utilisée dans l’environnement physique pour déterminer la quantité de mémoire nécessaire sur le serveur ESX et rajouter 10 % de quantité de mémoire.

Exemple

Un serveur avec 32 Go de RAM peut avoir 30 VM configurées avec 1 Go de mémoire chacune.

g. Bonnes pratiques

  • Il faut privilégier le Transparent Page Sharing qui permet de ne pas dégrader les performances. Pour l’exploiter au mieux, il faut mettre des VM de même nature Windows ou Linux sur le même serveur. Il faut également utiliser des templates pour la création de VM, cela permet d’avoir une base commune.

  • Pour des applications critiques (Tiers 1), le ballooning doit être proche de 0 à tout moment. En revanche, pour des applications non critiques (Tiers 3) le ballooning peut être utilisé.

Certains environnements comme SAP utilisent la mémoire de façon intensive et recommandent de ne pas faire de l’overcommitment memory. Dans ce cas, il faut mettre une réservation à la taille de la mémoire configurée.

  • Il faut bien configurer les machines virtuelles avec des valeurs représentant l’activité : ne pas surdimensionner, ni sous dimensionner la quantité de mémoire.

2. Le processeur

a. Terminologie

Avant d’expliquer le fonctionnement, définissons la terminologie qui est utilisée :

  • 1 CPU (Central Processor Unit) = 1 processeur physique = 1 socket

  • 1 cœur physique = 1 cœur au sein d’un processeur physique

  • L’Hyper-Threading consiste à créer deux instances logiques pour chaque cœur physique.

  • Un Logical CPU (ou LCPU) correspond au nombre de CPU logiques disponibles (au sein du serveur ESXi) et configurable pour les VM. Le maximum supporté est de 160 LCPU par serveur ESXi.

Exemple

2 processeurs physiques avec 6 cœurs et l’Hyper-Threading activé correspondent à 24 LCPU. Cela permet de configurer en théorie une VM avec 24 vCPU ou 4 vCPU avec 6 vCore. Cependant, la bonne pratique veut que l’on ne dépasse pas 70/80 % des LCPU disponibles sur l’ESXi pour une seule VM. En l’occurrence, avec 24 LCPU on peut configurer 18 vCPU maximum pour la VM.

  • vCPU est un CPU virtuel (ou virtual socket) configuré dans la VM.

  • vCore est un cœur au sein d’un vCPU.

Sous vSphere 5, il est possible de configurer une VM jusqu’à 32 vCPU et d’avoir jusqu’à 2048 vCPU par hôte ESXi. Il est également possible de configurer le nombre de vCore au sein du vCPU dans la limite de 25 vCPU/cœur.

Le fait de pouvoir configurer au niveau vCore peut être parfois intéressant car certains OS ou applicatifs se basent sur le nombre de vCPU (et non pas sur le nombre de vCore). Par exemple, on peut configurer une VM avec 1 vCPU et 4 vCore plutôt qu’une VM avec 4 vCPU car cela ne change absolument rien en termes de performance mais permet de faire des économies sur les licences si celles-ci se basent sur le nombre de vCPU dans la VM. Cela permet également de s’affranchir de certaines limitations en termes de nombre maximum de processeurs pour certains OS comme par exemple Windows 2008 Server Standard qui est limité à 4 vCPU (et 256 LCPU).

esx5

Lors de la création d’une VM, il est demandé le nombre de virtual sockets et de cœurs par virtual socket à configurer.

b. La gestion du processeur par ESX

esx6

Les instructions du processeur virtuel (appelé vCPU) des Guest OS sont interceptées par les VMM (cf. chapitre Les composants logiciels de vSphere 5 – L’hyperviseur ESXi5) qui sont transmises au VMkernel. Le VMkernel se charge de répartir dynamiquement à intervalles réguliers la charge de travail des VM sur les différents processeurs (ou cœurs dans le cas d’un processeur multicœur) du serveur. Les instructions des VM sont ainsi migrées d’un processeur (ou un cœur) à un autre en fonction de la charge de chaque processeur. Le processeur est le seul composant du serveur à ne pas être masqué par la couche de virtualisation. Le Guest OS voit donc le type et le modèle du processeur physique du serveur sur lequel il s’exécute.

c. Le multicœur et la virtualisation

Certaines études d’Intel ont montré que l’augmentation de la fréquence apporte un gain de 13 % de performances pour une consommation électrique en hausse de 73 %. En revanche, en ajoutant un cœur tout en réduisant leur fréquence de 20 %, on augmente les performances de 70 % avec uniquement 2 % de consommation électrique supplémentaire. Si 2 autres cœurs sont ajoutés, on augmente d’à peine 6 % la consommation totale pour une augmentation de 210 % des performances !

Le multicœur permet donc de réduire de manière considérable la consommation électrique et permet d’avoir de très bonnes performances. La virtualisation est l’une des technologies exploitant le mieux les possibilités des multicœurs car ESX sait gérer un cœur comme un processeur physique.

Il est donc intéressant d’avoir un grand nombre de cœurs afin d’atteindre des taux de consolidation importants. Aujourd’hui, certains processeurs possèdent 6 cœurs, mais il est probable que dans quelques années, il y aura plusieurs dizaines voire centaines de cœurs dans les processeurs afin d’atteindre des taux de consolidation encore plus importants.

d. vSMP et le vCPU

vSMP (Virtual Symmetric Multi-Processing)

Il s’agit pour un système d’exploitation d’adresser plusieurs processeurs différents simultanément en parallélisant les tâches d’exécution ; ceci est appelé le multithread.

Cela permet d’équilibrer la charge entre les processeurs. En théorie, cela peut paraître très intéressant. En pratique, il faut prendre certaines précautions.

Un serveur avec plusieurs processeurs physiques peut exploiter le SMP et en tirer des bénéfices si l’application a été développée pour gérer ce parallélisme des tâches d’exécution. Mais en pratique, excepté pour quelques applications de type bases de données (Microsoft SQL, Oracle, IBM DB2, SAP) ou des applications métiers ou scientifiques, il existe très peu d’applications en multithread dans la mesure où il est nécessaire de redévelopper les applications si elles n’ont pas été développées de base dans cet objectif.

Dans certains cas, l’utilisation du vSMP peut même dégrader les performances car une VM configurée avec 2 vCPU nécessite que les 2 processeurs soient disponibles en même temps pour traiter la tâche. En environnement partagé ceci risque de créer des contentions.

De manière générale, avant d’utiliser le SMP, il convient de se renseigner auprès des éditeurs de logiciels.

vCPU

Le Guest OS travaille avec des processeurs virtuels dits vCPU. Sous vSphere 5, il est possible de configurer une VM avec 1, 2, 4, 8 ou 32 vCPU permettant d’exploiter le SMP.

Pour les raisons citées précédemment dans de très rares cas où les applications sont développées spécifiquement en exploitant vSMP, il est préférable de limiter le nombre de vCPU dans les VM.

e. L’Hyper-Threading

Cela consiste à créer 2 instances logiques sur un processeur ou un cœur. Les tâches d’exécution sont ainsi parallélisées au sein même du cœur pour un traitement plus efficace Alors que cette fonctionnalité avait disparu avec des processeurs d’anciennes générations, les processeurs de type Intel Nehalem ont réintégré cette fonctionnalité.

Pour en savoir plus sur les résultats de performances, allez sur : http://www.vmware.com/products/vmmark/results.html

f. Les techniques de virtualisation

Pour pouvoir faire tourner différents systèmes d’exploitation simultanément sur un même matériel, les hyperviseurs utilisent plusieurs techniques différentes : la full virtualisation, la paravirtualisation ou la virtualisation assistée au niveau matériel.

Avant de comprendre comment fonctionnent ces 3 techniques, il est nécessaire de connaître les architectures des processeurs x86.

Les architectures des processeurs x86 offrent 4 niveaux de privilèges (Ring 0 à 3) :

Ring 0 = kernel mode, Ring 3 = mode utilisateur

esx7

Les niveaux d’exécution ou Rings définissent les privilèges d’exécution des programmes. Plus un programme est installé sur un niveau bas, plus il exerce de contrôle sur le système. L’OS dispose du plus haut niveau de contrôle et accède directement aux ressources en s’exécutant sur le Ring 0.

Les applications tournent sur le Ring 3, le plus élevé. Elles ne peuvent pas modifier ce qui s’exécute sur des rings inférieurs au leur. Une application ne peut pas arrêter l’OS, alors que l’OS peut arrêter une application.

Les Rings 1 et 2 définissent des privilèges moins importants que ceux du Ring 0.

Dans ce type d’architecture, comment faire pour placer un hyperviseur entre le matériel et l’OS qui est conçu pour s’exécuter en Ring 0 ?

Ce challenge a été résolu grâce aux techniques de full virtualisation et de paravirtualisation.

Full virtualisation

VMware fut le premier à résoudre ce challenge en 1998 en développant une technique appelée translation binaire (Binary Translation) permettant de :

  • Placer l’hyperviseur en Ring 0.

  • Déplacer les OS à un niveau supérieur (Ring 1) en leur garantissant un niveau de privilèges supérieur à ceux des applicatifs (Ring 3).

esx8

Les OS étant conçus pour s’exécuter sur le Ring 0, ils vérifient régulièrement qu’ils y résident car certaines instructions ne s’exécutent que si elles viennent du Ring 0 ou y vont. VMware utilise la translation binaire en interceptant certaines requêtes ce qui permet de leurrer l’OS invité sur la place qu’il occupe réellement sur le système.

La translation binaire modifie certaines instructions provenant du Guest OS avant de les envoyer pour traitement aux processeurs physiques.

L’avantage de cette technique est qu’elle ne nécessite aucune modification au niveau du kernel (le noyau) du Guest OS car la translation binaire est exécutée au niveau du code binaire par le processeur.

Avantage : le système d’exploitation hôte n’est pas conscient d’être virtualisé et aucune modification du système d’exploitation n’est nécessaire. Cela permet d’avoir une compatibilité avec de nombreux systèmes d’exploitation.

Inconvénient : la translation binaire nécessite un travail supplémentaire de la part du CPU pour faire la translation binaire (appelé overhead).

Paravirtualisation

C’est l’autre technique développée par Xen notamment. Elle consiste à modifier les OS invités (la couche du noyau : le kernel) pour leur permettre de s’exécuter ailleurs que sur le Ring 0.

Le Guest OS est conscient d’être virtualisé et modifie certaines instructions bas niveau avant qu’elles soient envoyées au matériel. Il n’y a donc pas d’interception d’instructions ni de translation binaire.

esx9

Cette technique de paravirtualisation est performante mais nécessite un travail de modification du Guest OS qui n’est pas toujours possible notamment avec certaines versions de Windows. Elle simplifie la tâche de l’hyperviseur qui possède des privilèges pour certains jeux d’instructions du processeur et de la mémoire.

Avantage : les performances sont très proches d’un environnement pur matériel.

Inconvénients : assez complexe à mettre en œuvre car il faut modifier le kernel. La compatibilité est très faible avec les OS.

Drivers paravirtualisés : VMware a introduit certains aspects de la technique de paravirtualisation en introduisant des drivers paravirtualisés. Ces drivers spécifiques développés par VMware ont conscience de la couche de virtualisation, ils communiquent plus facilement avec l’hyperviseur. Ils sont rajoutés par les VMware Tools pour certains Guest OS. Les performances sont ainsi améliorées.

Virtualisation assistée au niveau matériel

Pour simplifier la tâche de l’hyperviseur en évitant de mettre l’OS sur un ring qui n’est pas conçu pour lui ou modifier le kernel de l’OS, les processeurs Intel avec Intel VT et AMD avec AMD-V introduisent un nouveau mode d’exécution. Ce qui est appelé la virtualisation assistée au niveau matériel (Hardware Assisted Virtualization).

Il comporte un niveau racine (Root) correspondant à des rings inférieurs à 0, et un niveau normal correspondant aux anciens rings de 0 à 3. Ce niveau privilégié accède directement au matériel. Cela permet de recevoir directement certaines instructions provenant du Guest OS pour limiter le travail de translation binaire.

esx10

L’hyperviseur fonctionne en mode Racine (Root Mode) avec le niveau de contrôle le plus élevé. Les systèmes d’exploitation invités fonctionnent sur le Ring 0. Ils occupent bien l’emplacement pour lequel ils ont été conçus.

Il n’est plus besoin de modifier les Guest OS, ni d’utiliser de translation binaire (la translation binaire est cependant toujours nécessaire pour certains jeux d’instructions).

Ce nouveau niveau racine réduit considérablement l’overhead. Cette évolution du jeu d’instructions fluidifie également le partage des ressources physiques entre les machines virtuelles.

Grâce à cette assistance matérielle dans le processeur, les architectures x86 s’affranchissent d’un certain nombre de barrières techniques et fournissent des performances en environnement virtuel très proches de l’environnement natif (entre 90 % et 95 % selon les cas).

g. Les indicateurs CPU

Il existe beaucoup d’indicateurs disponibles pour le processeur. Cependant, deux indicateurs dans vCenter Server sont particulièrement intéressants : le CPU Usage (Average) et le CPU Ready Time.

  • CPU Usage (Average) :

    Cet indicateur permet de déterminer l’utilisation des processeurs physiques (pCPU) de l’ESXi. Il faut veiller à ce que cette valeur ne dépasse pas 75 % d’utilisation en moyenne.

  • CPU Ready Time :

    Un indicateur très intéressant et moins connu est le CPU Ready Time. Dans un environnement virtuel où les ressources sont partagées, plusieurs VM peuvent utiliser le CPU physique au même moment. Certaines VM devront patienter avant de pouvoir être traitées par le CPU. Le Ready Time est le temps qu’une VM attend avant qu’elle ne puisse être traitée par un CPU. C’est le gestionnaire de ressource au sein du VMkernel qui attribue du temps CPU en fonction des requêtes des VM et qui décide sur quel cœur la VM doit tourner.

Si un cœur d’un processeur est trop chargé, le gestionnaire de ressource privilégie de laisser la VM sur le même cœur afin de pouvoir utiliser les instructions qui se trouvent dans le cache du CPU. Cela peut générer un peu de CPU Ready Time. Le gestionnaire au sein du VMkernel peut cependant décider de migrer la VM sur un autre cœur si l’attente devient trop longue.

esx11

Même s’il est normal qu’un serveur accumule du Time Ready, il faut cependant veiller à ce que cette valeur ne dépasse pas :

  • 10 % pour 1 vCPU soit 2000 ms.

  • 20 % pour 2 vCPU soit 4000 ms.

  • 40 % pour 4 vCPU soit 8000 ms.

Cette valeur ne doit pas être la seule à prendre en considération mais elle est un bon indicateur sur d’éventuels problèmes de configuration (mauvaise utilisation du Scheduling Affinity, du vSMP ou des VM avec un paramétrage Share ou Limit non approprié) ou sur le mauvais placement de certaines VM au sein de l’infrastructure.

h. Bonnes pratiques

  • Combien de VM par serveur hôte ESXi ? Il est bien évidemment difficile de répondre à cette question car cela dépend fortement de l’environnement et de la charge applicative. Cependant, pour avoir quelques repères, le nombre de VM pouvant tourner sur un serveur est dépendant du nombre de cœurs (sans tenir compte de l’Hyper-Threading) disponibles au sein de l’ESXi. On peut partir sur le dimensionnement global suivant :

  • Entre 2 et 4 vCPU par cœur pour des charges moyennes.

  • 1 vCPU par cœur pour des charges élevées.

Exemple : un serveur avec 12 cœurs permet de faire tourner entre 24 et 48 vCPU pour des charges moyennes. Ce qui est équivalent à mettre par exemple entre 24 et 48 VM configurées chacune avec 1 vCPU. Pour les applicatifs ayant une forte activité, cela représente 12 vCPU, soit par exemple 12 VM avec 12 vCPU ou 3 VM avec 4 vCPU.

  • Les monoprocesseurs (1 socket), sont intéressants en termes de prix mais le taux de consolidation est plus faible que les serveurs disposant de plusieurs CPU. Les biprocesseurs (2 sockets) sont aujourd’hui les plus largement répandus dans la virtualisation car ils offrent un très bon rapport prix/ratio de consolidation. Les quadriprocesseurs (4 sockets) vendus ont un très fort taux d’attachement à la virtualisation. Les octoprocesseurs (8 sockets) et plus représentent en proportion un très faible pourcentage de vente.

  • Comme nous l’avons vu, le licensing se fait en partie sur le nombre de processeurs physiques (pas sur le nombre de cœurs). Or, comme ESX sait gérer un cœur comme un processeur physique, il faut privilégier les processeurs intégrant le plus grand nombre de cœurs.

  • Il est important de faire un placement des machines virtuelles en fonction de leurs charges applicatives et de leurs activités.

  • Certaines études ont montré que l’activation de l’Hyper-Threading améliore les performances pour des applications qui savent gérer le multithread.

  • Certaines applications ne tirant pas profit de plusieurs vCPU, il convient de configurer les VM avec le minimum de vCPU. Il faut bien se renseigner auprès des éditeurs.

  • Les processeurs plus rapides en fréquence améliorent les performances, cependant pour certaines charges de travail des caches plus importants permettent d’améliorer les performances. Il faut se renseigner auprès des éditeurs de logiciels.

3. Déplacement de VM avec vMotion

vMotion est la technologie inventée par VMware qui permet de déplacer une VM en fonctionnement d’un serveur hôte ESX à un autre de façon totalement transparente. Le système d’exploitation et l’application qui tournent dans la VM ne subissent aucun arrêt de service.

a. Comment fonctionne vMotion ?

Lors d’une migration avec vMotion, seul l’état de la VM avec sa configuration est déplacé. Le disque virtuel, lui, ne bouge pas, il reste au même endroit sur le stockage partagé. Une fois la VM migrée, elle est gérée par le nouvel hôte. vMotion ne peut fonctionner qu’avec une architecture de stockage centralisé de type SAN FC, SAN FCOE, iSCSI, NAS ou avec vStorage Appliance.

Lorsque vMotion est déclenché, la mémoire active est transférée au travers du réseau sur l’hôte de destination en différentes étapes :

  • vCenter Server vérifie que la VM est dans un état stable.

  • L’état de la mémoire de la VM et son contenu sont transférés sur le serveur de destination au travers du VMkernel Port vMotion. vMotion fait une succession de snapshots de la mémoire et transfère successivement ces snapshots sur le serveur de destination.

  • Une fois la copie terminée sur le serveur de destination, vCenter Server déverrouille et suspend la VM source pour que le serveur de destination puisse en prendre le contrôle en faisant un verrouillage sur le disque (on disk lock).

  • La couche réseau étant également gérée par le VMkernel, vMotion garantit qu’après la migration l’identité de la VM sur le réseau comme l’adresse MAC et le SSID sera préservée. Les connexions réseau actives sont également préservées.

  • La VM continue son activité sur l’hôte de destination.

esx12

La VM tourne sur ESX1. Son disque virtuel vmdk est sur le stockage partagé. vCenter déclenche la migration de la VM vers le serveur de destination. L’état de la VM est copié sur le deuxième serveur.

esx13

Une fois l’état de la VM copié, le serveur ESX1 libère le verrouillage du disque (on disk locking) et le serveur ESX2 verrouille le vmdk pour sa propre utilisation. Le disque virtuel vmdk n’a pas bougé lors de cette migration.

b. Dans quels cas utiliser vMotion ?

vMotion sert principalement lorsque des opérations de maintenance sur les serveurs sont planifiées (telles que des mises à jour de firmware ou de rajout de composants comme de la mémoire par exemple). Il est donc possible de migrer les VM sur un autre serveur, réaliser l’opération de maintenance puis une fois les opérations terminées, remettre les VM sur le serveur initial. Ainsi, ces interventions sont réalisées sans interruption de service.

c. Pré-requis et bonnes pratiques

vMotion génère des réservations SCSI et donc verrouille le LUN pendant un bref instant. Pour cette raison il ne faut pas utiliser trop fréquemment vMotion car cela peut provoquer des dégradations de performance au niveau des accès disques.

Il est important d’éviter de passer trop de temps à essayer de faire du vMotion sur des processeurs ayant des jeux d’instructions trop différents. Il est préférable de privilégier dans la mesure du possible des processeurs de même génération et de même famille.

Pour fonctionner correctement, vMotion nécessite un certain nombre de pré-requis.

  • Stockage : vMotion ne peut fonctionner que s’il y a une baie de stockage partagée accessible par les 2 serveurs : source et destination.

  • Réseau : vMotion nécessite une carte réseau et un lien Gigabit. Chaque serveur hôte source et destination doivent être configurés avec un VMkernel port group dédié pour vMotion et avec au moins une carte Gigabit connectée. Lors d’une migration vMotion, vCenter Server assigne les VM en fonction du nom du portgroup. Il faut donc bien veiller à avoir un nommage consistant des port groups entre les hôtes et faire attention au fait que le nom du port group est case sensitive (distinction entre les majuscules et les minuscules).

Sous vSphere 4, seule une carte réseau pouvait être utilisée lors d’une migration avec vMotion. Cette limitation est levée sous vSphere 5 qui permet d’utiliser simultanément plusieurs cartes réseau (dans la limite de 16 cartes 1 GbE et 4 cartes 10 GbE). Cela permet de réduire le temps de migration d’une VM, notamment pour des VM ayant une activité mémoire intensive. À noter que le nombre de vMotion concurrents supportés par hôte est de 4 dans un réseau GbE et 8 dans un réseau 10 GbE et dans la limite de 128 opérations de vMotion concurrents par datastore.

  • CPU : la partie CPU est l’aspect le plus contraignant. Les jeux d’instructions pouvant changer entre les types, modèles et générations de processeur, il faut s’assurer de la compatibilité entre les différents processeurs. VMware a beaucoup travaillé sur ce sujet pour avoir une grande compatibilité entre les processeurs. EVC (Enhanced vMotion Compatibility) permet de masquer certaines différences pour apporter une plus grande compatibilité entre des serveurs ayant des processeurs de générations différentes.

Allez sur la Knowledge de VMware KB 1992 et 1003212.

ESXi5 introduit un virtual hardware version 8. Cette version n’étant pas compatible sur des versions antérieures à ESXi5, les VM avec un virtual hardware 8 ne peuvent migrer que sur des serveurs hôte ESXi5 ou supérieur.

Il faut maintenir une compatibilité des versions virtual hardware des VM pour supporter vMotion.

À noter que pour des raisons de sécurité, il est possible d’activer de l’encryption lors d’un transfert avec vMotion (dans les options avancées de vCenter).

d. EVC (Enhanced vMotion Compatibility)

EVC (Enhanced vMotion Compatibility) favorise la compatibilité des processeurs de générations différentes pour utiliser vMotion.

Chaque génération de processeur apportant son lot de nouvelles fonctionnalités, EVC assure que tous les serveurs hôtes dans un cluster présentent les mêmes jeux d’instructions pour les VM, garantissant une compatibilité entre les processeurs de générations différentes pour vMotion.

Pour ce faire, EVC travaille avec des Baselines. Une Baseline permet de définir un jeu de fonctionnalités supportées par l’ensemble des processeurs du cluster. La Baseline est le dénominateur commun à tous les processeurs.

VMware travaille directement avec les processeurs et les technologies Intel VT Flex Migration et AMD-V Extended Migration afin de n’exposer que les jeux d’instructions communs et masquer ceux qui risquent de poser un problème de compatibilité avec vMotion. Pour savoir quelles sont les Baselines et les jeux d’instructions masquées voir article : VMware KB 1003212.

EVC ne dégrade pas les performances, ni le nombre de cœurs ou la taille du cache. La seule dégradation possible concerne certaines instructions comme par exemple SSE4.2 qui ne seront pas exploitées.

Pour utiliser EVC, il faut créer un cluster avec des processeurs de la même famille (famille Intel ou famille AMD).

Une fois EVC activée dans un cluster, tous les serveurs hôtes sont automatiquement configurés pour correspondre à la Baseline définie. Les serveurs hôtes qui n’ont pas les pré-requis ne peuvent pas entrer dans le cluster.

4. vSphere DRS (Distributed Resource Scheduler)

vSphere DRS est un moyen d’automatiser l’utilisation de vMotion en faisant de la répartition de charge pour le déplacement des VM entre différents ESXi d’un cluster.

Il est possible d’utiliser la fonctionnalité Fault Tolerance avec DRS quand EVC est activée.

DRS collecte des informations sur l’utilisation des serveurs hôtes du cluster et intervient dans les deux cas suivants :

  • Initial Placement : au démarrage d’une VM, DRS préconise le meilleur serveur du cluster à utiliser.

DRS et HA peuvent être utilisés conjointement car, lorsque HA redémarre les VM, DRS choisit le meilleur hôte à utiliser.

  • Load Balancing : lorsque les VM sont en fonctionnement, DRS optimise les ressources en répartissant la charge de travail des VM sur les différents serveurs du cluster. Cette migration de VM se fait automatiquement ou manuellement (après validation par l’administrateur) selon des critères définis.

a. L’automatisation de DRS

L’algorithme de DRS permet d’automatiser le déplacement des VM ou de faire des recommandations lorsque certains critères sont atteints. DRS intervient afin de :

  • Mieux répartir la charge CPU ou mémoire entre les différents serveurs hôtes ESXi du cluster.

  • Migrer des VM lorsqu’un serveur est mis en mode maintenance.

  • Garder toujours des VM ensemble sur le même serveur hôte (affinity rule) ou pour avoir toujours les VM sur 2 serveurs hôtes différents (anti-affinity rule).

Plusieurs niveaux d’automatisation existent :

esx14

  • Manual : DRS propose des recommandations pour le placement initial et pour répartir la charge des VM entre les serveurs hôtes. Mais cela n’intervient qu’après validation de l’administrateur.

  • Partially automated : le placement initial est fait automatiquement par DRS. DRS fait des recommandations pour la migration des VM en fonctionnement, mais celle-ci n’intervient qu’après validation de l’administrateur.

  • Fully automated : le placement initial ainsi que les migrations des VM en fonctionnement se font automatiquement. Cette migration automatique est fonction de seuils qui correspondent à 5 niveaux de recommandations : Conservative (5 étoiles) à Aggressive (1 étoile).

  • Niveau 1 – Conservative (5 étoiles) : la migration de VM intervient pour satisfaire les règles d’affinité ou si l’hôte est mis en mode maintenance.

  • Niveau 2 (4 étoiles) : la migration n’interviendra que si le premier niveau est satisfait ou si la migration apporte des améliorations significatives.

  • Niveau 3 (3 étoiles) : la migration n’interviendra que si les 2 premiers niveaux sont satisfaits ou si cela apporte de bonnes améliorations.

  • Niveau 4 (2 étoiles) : la migration n’interviendra que si les 3 premiers niveaux sont satisfaits ou si les améliorations sont modérées.

  • Niveau 5 – Agressive (1 étoile) : la migration n’interviendra que si toutes les recommandations du niveau 1 à 4 sont appliquées ou si cela apporte une petite amélioration.

Le niveau 1 Conservative entraîne moins de migrations alors que le niveau 5 Agressive entraîne des migrations de VM plus fréquentes entre les serveurs du cluster.

Nous recommandons de laisser le paramètre par défaut au niveau 3.

Certaines VM du cluster peuvent avoir un niveau d’automatisation différent de celui défini au niveau du cluster DRS :

esx15

Il est possible de définir un niveau d’automatisation au niveau de chaque VM.

Les choix offerts sont :

  • Fully Automated

  • Partially Automated

  • Manual

  • Disabled

b. Les règles DRS (DRS Rules)

Au sein d’un cluster ESXi et lorsque DRS est activé, il est possible d’établir des règles soit pour garder toujours les VM ensemble sur le même serveur (appelé affinity rule), soit pour que les VM tournent toujours sur des serveurs différents (appelé anti-affinity rule) ou soit pour que les VM tournent sur des serveurs spécifiques (appelé host affinity).

esx16

Les différentes règles d’affinité pour DRS.

  • Keep Virtual Machines Together : cette option (appelée VM affinity) assure que les VM restent ensemble sur le même serveur au sein du cluster ESXi lors des déplacements des VM. Le principal intérêt de ce paramétrage est relatif à des considérations de performance entre les VM (par exemple un serveur relié à une base de données). La communication entre des VM se situant sur le même hôte est extrêmement rapide puisqu’elle se fait en interne du serveur ESXi (on ne passe pas par le réseau externe).

  • Separate Virtual Machines : cette option (appelée VM anti-affinity) assure que les VM sont positionnées sur des serveurs ESXi différents. Le cas d’usage de cette configuration est principalement pour des considérations de haute disponibilité. Prenons l’exemple de cluster Microsoft MSCS (ou Windows Server Failover Clustering sous Windows 2008). Grâce à cette règle, les VM étant sur des serveurs physiques différents, dans le cas où un serveur est en panne, cela garantit d’avoir la VM de secours sur un autre serveur.

  • Virtual Machines to Hosts : cette option (appelée host affinity) permet d’avoir des VM sur des serveurs hôtes spécifiques. Host affinity permet de spécifier sur quels hôtes les VM tournent. Cela permet d’avoir une gestion fine de la relation entre les VM et les serveurs hôtes dans un cluster. Il est ainsi possible de dédier une partie d’un cluster pour des VM.

    Les paramétrages possibles sont :

  • Must Run On Hosts In Group

  • Should Run On Hosts In Group

  • Must Not Run On Hosts In Group

  • Should Not Run On Hosts In Group

À noter que le paramétrage Must Run (ou Must Not Run) donne un caractère obligatoire et agit sur l’utilisation de vSphere HA et vSphere DPM.

Le tableau suivant permet de comprendre l’intérêt de mettre en place le paramétrage Must ou Should avec HA.

DRS

Type

Affinity

Anti-Affinity

Respecté par vSphere HA ?

VM-VM

Les VM sont ensemble sur le même hôte.

Les VM sont sur des hôtes différents.

Non

VM-Host

Should Run On Hosts In Group

Should Not Run On Hosts In Group

Non

Must Run On Hosts In Group

Must Not Run On Hosts In Group

Oui

Lorsque le contrôle d’admission (cf. chapitre La continuité de service locale et distante – vSphere HA – Admission Control) est activé, vSphere HA ignore certaines règles d’affinité (ou anti-affinité) lors du placement des VM après qu’un hôte soit tombé, à l’exception de la règle Must Run ou Must Not Run qui est respectée par HA.

5. vSphere DPM

La fonctionnalité vSphere DPM (Distributed Power Management) permet de réduire la consommation électrique des serveurs du Datacenter en plaçant les VM sur les serveurs de façon à faire fonctionner un minimum de serveurs hôtes. DPM est couplé à DRS pour déplacer les VM des serveurs qui sont très peu utilisés afin de réduire le nombre de serveurs en fonctionnement. Ceci permet de réduire la consommation électrique au niveau de l’alimentation et du besoin en climatisation.

DPM utilise les technologies de redémarrage à distance des serveurs à savoir l’IPMI (Intelligent Power Management Interface) ou des cartes d’accès à distance tels que ILO (Integrated Lights-Out) ou la fonctionnalité Wake on LAN.

Il est à noter qu’ESXi sait tirer également profit des fonctionnalités avancées des processeurs tels qu’Intel Enhanced Speed Step ou AMD Power Now pour adapter la fréquence des processeurs en fonction des besoins réels.

 

Source :  Livre VMware vSphere 5 au sein du Datacenter (Edition ENI)

About sebihiy

Check Also

cert

VMware Certification

VMware certification établit la norme pour les professionnels de l’IT et valide les organisations de ...

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Vous pouvez utiliser ces balises et attributs HTML : <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>