28-Fonctionnalités de VSphere 4-Migration de VM

Migration de VM

Comme nous l’avons vu, la virtualisation propose des avantages considérables du fait de l’encapsulation du système tout entier dans des fichiers et leur indépendance matérielle. Il va être possible de migrer très facilement des VM d’un serveur hôte ESX à un autre. Pour ce faire, plusieurs solutions sont disponibles.

VMotion : migration de VM en fonctionnement (appelé migration à chaud). DRS va utiliser la technologie VMotion pour migrer automatiquement les VM.

Storage VMotion : migration à chaud des fichiers composants la VM (disponible avec les versions Enterprise ou Enterprise Plus).

Cold migration : migration des fichiers composants la VM machine éteinte d’un Datastore à un autre. Il est à noter que cette migration n’utilise pas la technologie VMotion.

1. VMotion

a. Définition

VMotion est la technologie inventée par VMware permettant 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.

b. Fonctionnement

Lors d’une migration avec VMotion, seul l’état de la VM avec sa configuration est déplacé. Le disque virtuel 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, iSCSI ou NAS.

Lorsque VMotion est déclenchée, 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 les transfère 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 la MAC Address et le SSID seront préservés. Les connexions réseaux actives sont également préservées.

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

Dans l’exemple cidessous, 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.

- 1 -© ENI Editions - All rigths reserved - Guillaume DUBOIS

enidentnumber-AAEAAAD/////AQAAAAAAAAAMAgAAAE1FTkkuRWRpdGlvbnMuTUVESUFwbHVzLCBWZXJzaW9uPTEuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49bnVsbAUBAAAAJ0VOSS5FZGl0aW9ucy5NRURJQXBsdXMuQ29tbW9uLldhdGVybWFyawIAAAAHcGlzVGV4dAlwaWR0ZURhdGUBAA0CAAAABgMAAABAMzg5NDA3IC0gR3VpbGxhdW1lIERVQk9JUyAtIGI5MzMxMjgxLTc0ZjktNGZiNy1hYzBmLWQzYzQxMTljYjgyY9IH6CelmcyICwA=-enidentnumber

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.

- 2 - © ENI Editions - All rigths reserved - Guillaume DUBOIS


c. Cas d’utilisation

VMotion est utilisé principalement pour des opérations de maintenance planifiées telles que des mises à jour de firmware ou des ajouts de composants (mémoire...). Ainsi, il est 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.

Cette technologie est utilisée par DRS pour répartir automatiquement la charge de travail des VM en fonction de l’activité sur les serveurs hôtes.

d. Prérequis

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

VMotion ne peut fonctionner que s’il y a une baie de stockage partagée accessible par les deux serveurs : source et destination. Pour rappel, le disque virtuel n’est pas déplacé lors de VMotion. Les baies partagées supportées sont le SAN, le NAS et l’iSCSI.

VMotion nécessite une carte réseau et un lien Gigabit.

Chacun des serveurs hôtes source et destination doit être configuré avec un VMkernel Port Group dédié pour VMotion et avec au moins une carte Gigabit connectée. Lors d’une migration avec VMotion, vCenter Server assigne les VM au Port Group en fonction du nom. Il faut donc bien veiller à avoir un nommage correct entre les hôtes.

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

Stockage

Réseau

CPU



processeurs de générations différentes.

Pour plus d’informations, allez sur la Knowledge Base de VMware KB 1992 et 1003212.

ESX4 introduit un virtual hardware version 7. Cette version n’étant pas compatible avec les versions antérieures à ESX4, les VM avec un virtual hardware 7 ne peuvent migrer que sur des serveurs hôtes ESX4

ou supérieur.

e. Comprendre EVC

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 (cf. section HA Cluster de ce chapitre) présentent les mêmes jeux d’instructions pour les VM garantissant ainsi une compatibilité pour VMotion.

Pour se faire, EVC travaille avec des Baselines. Une Baseline permet de définir un jeu de fonctionnalités supporté 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 AMDV Extended Migration afin de n’exposer que les jeux d’instructions communs et masquer les instructions qui risquent de poser un problème de compatibilité avec VMotion. Pour savoir quels sont les Baselines et les jeux d’instructions masqués, lisez l’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 famille Intel ou de la 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 entrer dans le cluster.

f. Bonnes pratiques



● VMotion génère des réservations SCSI et verrouille donc 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 faire du VMotion.

2. HA

a. Cluster

Un cluster au sens VMware est un regroupement de plusieurs serveurs ESX avec des ressources partagées. Avec un cluster, les fonctionnalités telles que HA, DRS ou FT peuvent être utilisés.

b. Définition

VMware HA (High Availability) est une fonctionnalité de haute disponibilité. Lorsqu’un serveur tombe en panne, l’ensemble des VM qui font partie du cluster HA sont redémarrées immédiatement et automatiquement sur les autres serveurs ESX du cluster. Ceci permet de réduire le temps d’indisponibilité des applications. Il est nécessaire que tous les serveurs faisant partie d’un cluster HA aient accès au même espace de stockage partagé.

VMware HA n’utilise pas la fonctionnalité VMotion car le redémarrage d’une VM ne nécessite pas de migrer à chaud la VM. VMware HA est fortement lié au DNS. Il faut bien s’assurer que tous les serveurs hôtes ESX

sont intégrés dans le DNS et que la résolution de nom se fait.

c. Fonctionnement de HA

Serveur hôte primaire

Lors de l’ajout d’un serveur hôte dans un cluster HA, un agent (aam agent) est installé sur le serveur qui communique avec les autres agents du cluster HA. Chaque serveur ajouté dans un cluster HA doit pouvoir communiquer avec un serveur primaire. Le serveur hôte primaire est important car c’est lui qui initialise les actions de bascule automatique des VM (appelée Failover). Si le serveur primaire tombe ou est supprimé du cluster, HA promeut un autre serveur hôte. Les 5 premiers serveurs hôtes du cluster sont déclarés comme primaires et tous les autres sont secondaires.

S’il n’y a pas de serveur primaire au moment où un serveur hôte tombe en panne, les bascules de VM ne peuvent pas être initialisées et HA ne fonctionne pas (cf. chapitre Études de cas).

Les agents du cluster HA communiquent entre eux au travers d’un échange privé appelé Heartbeat. Le Heartbeat permet aux VM de s’envoyer quelques trames par le réseau pour voir si elles peuvent communiquer.

S’il n’y a pas de réponse d’un serveur hôte pendant plus de 15 secondes alors celuici est déclaré failed. Le mécanisme HA provoque le redémarrage des VM sur un autre serveur hôte. Il peut arriver qu’un serveur hôte ne puisse pas répondre aux échanges Heartbeat car il perd sa connexion réseau (pour différentes raisons) tout en étant toujours opérationnel et avec les VM en fonctionnement : cette situation est appelée host network isolation (réseau de l’hôte isolé). Un serveur qui ne répond pas au Heartbeat pendant plus de 12 secondes est déclaré Host isolated.

Dans le cas où cette situation se produit, HA force les VM à s’arrêter (Shut down) et initialise le redémarrage des VM sur les autres serveurs hôtes du cluster. Mais il est aussi possible de changer le comportement en laissant les VM en fonctionnement (Leave powered on). Cela peut être utile dans certains cas où des applications peuvent travailler même si elles n’ont plus accès au réseau... Dans la configuration Host isolation respons les choix offerts sont Leave VM, Powered on, Power off VM ou Shutdown VM. Il est également possible dans le cas d’un redémarrage de préciser la priorité pour le redémarrage des VM : VM restart Priority : High, Medium, Low ou Disabled.

Cette configuration est détaillée dans le chapitre Configuration.

d. Problématique du nombre d’hôtes dans un HA

Lorsqu’un ou plusieurs serveurs du cluster HA tombent en panne, il faut que les ressources totales des serveurs restants puissent prendre en charge les VM qui doivent être migrées. C’est le Current Failover Capacity qui



détermine combien de serveurs hôtes peuvent tomber dans le cluster HA afin de garantir assez de slots pour satisfaire la charge de toutes les VM en fonctionnement.

Pour déterminer le nombre de serveurs qui peuvent tomber dans un cluster HA, HA travaille avec des slots size.

Un slot size détermine les ressources nécessaires de CPU et de mémoire que chaque serveur ESX peut recevoir.

● Pour le CPU, un slot size est la valeur la plus élevée de réservation d’une VM qui fait partie du cluster (s’il n’y a pas de réservation cette valeur est par défaut 266 Mhz mais peut être modifiée dans le paramètre avancé das.vmCpuMinMHz).

● Pour la mémoire, un slot size est la valeur de réservation la plus élevée des VM en fonctionnement du cluster.

Une fois le slot size déterminé, HA détermine le nombre de slots size disponibles sur chaque serveur. Le nombre maximum de slots est la quantité de ressources du serveur hôte divisé par le slot size CPU et mémoire. La valeur la plus basse est retenue. Pour bien comprendre, prenons un exemple :

Dans l’exemple cidessus 5 VM tournent (cela correspond à 5 slots nécessaires dans le cluster) : la valeur de réservation la plus élevée pour le CPU est 3 Ghz et pour la mémoire 2 Go : le slot size est donc 3 Ghz et 2 Go.

Exemple de nombre de slots size disponibles pour le serveur ESX3 :

CPU = 10 Ghz / 3 Ghz = 3

Mémoire = 8 Go / 2 Go = 4

Le nombre de slots disponibles pour ESX3 est donc 3.

Dans le cas où ESX1 tombe, ESX2 et ESX3 peuvent gérer 7 slots.

Si ESX1 et ESX3 tombent, ESX2 ne contient que 4 slots et donc ne pourra pas absorber la charge.

Le Current Failover Capacity du cluster est dans ce cas de 1 ce qui signifie que si un serveur tombe, les deux autres serveurs restants peuvent assurer la charge de travail de toutes les VM en fonctionnement du cluster HA.

Pour des besoins spécifiques, il peut arriver qu’une VM contienne une valeur de réservation surdimensionnée par rapport aux autres VM. Cela peut altérer le calcul des slots size. Il est donc possible de

déterminer une valeur haute maximale pour le processeur et la mémoire en allant dans les options avancées das.slotCpuInMHz ou das.slotMemInMB.



e. VMware HA Admission Control

Lors de la création d’un cluster HA, il est demandé de configurer le nombre de serveurs hôtes tolérés qui peuvent tomber Host failures cluster tolerates.

Dans le cas où l’administrateur configure un nombre inférieur ou égal au Current Failover Capacity, cela ne pose pas de problème. Dans le cas où ce nombre est supérieur au Current Failover Capacity, c’est le contrôle d’admission qui intervient et qui va autoriser ou interdire certaines actions en fonction du paramétrage défini.

● Lorsque le contrôle d’admission est activé :

Prevent VMs from being powered on if they violate availability constraints.

Les actions pour démarrer une VM, migrer une VM sur un serveur hôte ou augmenter la réservation du CPU ou la mémoire d’une VM sont interdites afin de garantir que toutes les VM aient assez de ressources pour redémarrer.

● Lorsque le contrôle d’admission est désactivé :

Allow VMs to be powered on even if they violate availability constraints.

Les nouvelles VM peuvent êtres démarrées même si le total des slots disponibles ne permet pas de prendre en charge l’ensemble des VM à migrer. Dans ce cas précis, le démarrage des VM se fait dans les slots disponibles du cluster en fonction du VM Restart Priority pour déterminer quelle est la VM à démarrer en priorité. Le risque est que certaines VM ne trouvent pas de slots disponibles.

Reprenons l’exemple précédent avec trois serveurs ESX avec chacun des slots disponibles.

5 VM tournent dans le cluster HA. Le Current Failover Capacity est de 1. Si le contrôle d’admission est activé, il est possible de démarrer au maximum 2 VM de plus (7 slots disponibles) garantissant la charge de toutes les VM. Si le contrôle d’admission des VM est désactivé, il est possible d’en démarrer plus de 2 mais dans ce cas, cela ne garantit pas que toutes les VM auront assez de slots disponibles dans le cluster pour pouvoir toutes démarrer.

VMware HA passe en alerte dans le cas où le nombre de VM (pour être précis de slots) excède le nombre de Current Failover Capacity. Si le contrôle d’admission est désactivé, il passe en normal.

f. Bonnes pratiques



L’utilisation d’HA rend les taux de consolidation moins importants car il est nécessaire de réserver des ressources. Il est donc important de n’utiliser HA que pour des applications réellement critiques.

3. DRS

a. Définition

DRS (Distributed Resource Scheduler) est un moyen d’automatiser l’utilisation de VMotion en environnement de production en faisant de la répartition de charge entre différents serveurs hôtes d’un cluster.

DRS collecte des informations sur l’utilisation des serveurs hôtes du cluster et fait des recommandations pour le placement des VM afin de mieux répartir la charge de travail. Lorsqu’un serveur fait partie d’un cluster et que DRS est activé, les recommandations peuvent intervenir dans deux cas :

● Initial Placement : au démarrage de la VM.

● 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 selon des critères définis ou manuellement après validation par l’administrateur.

b. Recommandations

Les recommandations interviennent lorsque certains critères sont atteints :

● Pour mieux répartir la charge CPU ou mémoire entre les différents serveurs hôtes ESX.

● Pour garder toujours des VM ensembles sur le même serveur hôte appelé Affinity Rule.

● Avoir toujours les VM sur 2 serveurs hôtes différents appelé Anti Affinity Rule.

DRS automatise le placement des VM en fonction des critères définis de façon manuelle ou plus ou moins automatique :

Manual : DRS propose des recommandations mais ne placera pas les VM sur les serveurs hôtes sans la validation de l’administrateur.

Partially Automated : le placement initial est fait automatiquement par DRS mais la migration des VM en fonctionnement ne se fera qu’après la validation par l’administration des recommandations de vCenter.

Fully Automated : le placement initial ainsi que les migrations des VM en fonctionnement se feront automatiquement. Cette migration automatique est fonction d’un seuil qui correspond à 5 niveaux de recommandations : Conservative (5 étoiles) à Agressive (1 étoile).

La migration n’interviendra que si :

Niveau 1 Conservative (5 étoiles) : si les règles d’affinité sont satisfaites.

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

Niveau 3 (3 étoiles) : si les deux premiers niveaux sont satisfaits ou si cela apporte de bonnes améliorations.

Niveau 4 (2 étoiles) : si les trois premiers niveaux sont satisfaits ou si les améliorations sont modérées.

Niveau 5 Agressive (1 étoile) : si les quatre premiers niveaux sont satisfaits ou si cela apporte une petite amélioration.

Le paramétrage Conservative entraîne moins de migrations et sera déclenché uniquement dans le cas où la règle d’affinité n’est pas respectée. Le niveau 5 entraîne des migrations de VM plus fréquentes entre les serveurs du cluster.

c. DPM

La fonctionnalité DPM (Distributed Power Management) permet de réduire la consommation électrique 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 et ainsi réduire la consommation électrique au niveau de l’alimentation et de la 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 telles que ILO (Integrated LightsOut) ou la fonctionnalité Wake on LAN.

Il est à noter qu’ESX 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.

DRS et HA peuvent être utilisés conjointement afin de garantir une bonne répartition de charge après l’initialisation du HA. Lorsque HA redémarre les VM avec Initial Placement, DRS préconise le meilleur serveur hôte du cluster à utiliser.

4. FT

VMware FT (Faut Tolerance) est l’une des plus grandes innovations technologiques de vSphere 4. Cela apporte de la très haute disponibilité.

a. La tolérance de panne

La tolérance de panne (Fault Tolerance) signifie que même en cas d’arrêt brutal d’un serveur il n’y a pas d’interruption de service. Des solutions matérielles de serveurs à tolérance de panne existent chez des constructeurs tels que NEC et Stratus qui proposent des serveurs dont tous les composants sont en redondance (même la carte mère et les processeurs). Un chipset appelé Fault Detection utilise le principe de lockstep permettant aux modules primaires et secondaires d’exécuter le même jeu d’instructions identiques sur plusieurs processeurs simultanément. Cela garantit une continuité de service même si un composant tombe en panne. Ces serveurs sont utilisés pour des applications très critiques qui ne doivent jamais s’arrêter. VMware FT adapte cette technologie de très haute disponibilité pour les environnements virtuels.

VMware HA fournit de la haute disponibilité car les VM sont automatiquement redémarrées si un serveur tombe. Ce redémarrage engendre un arrêt de production, le temps que la VM redémarre. VMware FT fournit

un très haut niveau de disponibilité puisqu’il n’y a aucune interruption de service, ni perte de données dans le cas où le serveur tombe.

b. Fonctionnement

Fault Tolerance crée une copie conforme d’une machine virtuelle donnée. Tout ce qui se passe sur cette VM appelée VM primaire est copié en miroir dans une VM appelée VM secondaire.



VMware FT utilise la technologie de vLockstep qui permet de capturer tous les événements de la VM primaire active : jeux d’instructions CPU, état mémoire, E/S pour les envoyer vers une VM secondaire passive sur un autre serveur hôte. Cette technologie qui permet d’enregistrer les tâches d’exécution puis de les restituer s’appelle Record/Replay.

Dans le cas où le serveur hôte primaire tombe, la VM secondaire qui détient les mêmes jeux d’instructions que la VM primaire peut reprendre l’activité de façon totalement transparente sans perte de données ni arrêt de service.

Le transfert d’informations et tous les logs sont envoyés et réceptionnés au travers du VMkernel port dédié pour FT : VMkernel FT Logging (vmklogger).

c. Précisions sur FT

● FT ne fonctionne qu’avec une baie de stockage partagée comme pour VMotion.

Les processeurs doivent être compatibles entre eux pour supporter FT ainsi que les Guest OS. Pour connaître les processeurs et Guest OS qui supportent VMware FT, consultez la Knowledge Base de VMware KB Article 1008027.

● Les Guest OS sont standard il n’y a aucune modification du Kernel ou patches spéciaux à installer.

● Un minimum de deux cartes réseaux Gigabit est requis : une pour FT Logging, l’autre pour VMotion.

● FT s’active au niveau de la VM. Une VM FT et sa copie ne peuvent pas tourner sur le même serveur hôte. FT utilise Anti Affinity rules garantissant que les deux VM ne seront jamais sur le même hôte ceci afin de ne pas avoir la perte des deux VM en même temps.

● Tous les serveurs hôtes ESX doivent avoir les mêmes niveaux de patchs et de versions.

● FT requiert au moins une carte Gigabit entre les serveurs mais il est recommandé d’avoir des cartes 10 Gigabit Ethernet.

● Les disques virtuels doivent être en mode Thick.

● Il n’est pas possible d’utiliser FT avec des VM ayant des snapshots.



● II n’est pas possible d’utiliser Storage VMotion. Dans le cas où vous souhaitez migrer le disque virtuel, il faut arrêter la fonctionnalité FT, migrer le disque puis réactiver FT.

● Seules les machines virtuelles avec 1 vCPU sont compatibles avec FT.

● La VM ne doit pas utiliser de paravirtualisation VMI.

5. Storage VMotion

Nous avons vu précédemment que VMotion permet de migrer une VM en fonctionnement d’un serveur physique à un autre sans interruption de service, mais les fichiers composants la VM ne sont pas déplacés : ils restent au même endroit sur le SAN.

Storage VMotion permet de migrer à chaud l’ensemble des fichiers composants la VM d’un Datastore à un autre dans une même baie de stockage ou entre deux baies de stockage différentes sans interruption de service.

a. Cas d’utilisation

Au même titre que VMotion, Storage VMotion va être utilisé pour des opérations de maintenance planifiée pour les baies de stockage. Lors de mise à jour nécessaire des baies, il est possible de déplacer les VM vers une autre baie de stockage. Cela peut être également très utile lors d’achat d’une nouvelle baie de stockage afin de ne pas interrompre le service. La migration se fait de façon totalement transparente.

Cold migration : VMotion et Storage VMotion permettent de migrer des VM en fonctionnement. La fonctionnalité cold migration permet de migrer une VM lorsqu’elle est arrêtée vers un autre serveur ESX ou un autre emplacement de stockage.



Documents

28-Fonctionnalités de VSphere 4-Migration de VM