En parcourant la toile ce soir, je suis tombé sur un excellleeent article de Niels Hagoort, que nous auront d’ailleurs la chance de rencontrer au prochain VMUG du 26 Septembre prochain (yeah ^^). Il nous décrit de manière très précise le fonctionnement de vMotion, à consulter ici. C’est un article anglais, forcément, du coup je me suis dit que ce serait une bonne idée de vous le traduire, pour vous, francophones ! Je ne suis pas un traducteur professionnel bien sûr, aussi j’espère que l’exercice sera le plus fidèle possible.
Faites fumer votre cerveau avec vMotion et n’hésitez pas à me dire s’il y a des coquilles de traduction ou des erreurs de fonds !
Introduction
Depuis ses premiers développements en 2002 jusqu’à sa première version publiée en 2003, vMotion permet de déplacer l’état d’une machine virtuelle depuis un ESXi vers un autre sans arrêt, une sorte de téléportation numérique. Le déplacement sans interruption de systèmes virtualisés reste encore aujourd’hui une brique fondatrice du fonctionnement clouds privés et hybdrides, ainsi adapté pour pouvoir s’accommoder des nouvelles contraintes de latence et débits des interconnexions entre différents datacenters et clouds.
Depuis la première version sur VirtualCenter 1.0 et ESX 2.0, vMotion a connu un développement ininterrompu jusqu’à nos jours :
Cet article a pour objectif de vous décrire le fonctionne du vMotion classique, qui s’occupe de migrer une VM depuis un ESXi source vers un ESXi de destination. Il est possible, comme vous le savez, de procéder aussi à un XvMotion afin de migrer aussi la partie stockage, encore appelé “Storage vMotion”. Il existe enfin d’autres modes de migration sur des longues distances et fortes latences, ou encore des migrations entre vCenter.
Après la lecture de cet article, j’espère (NDLR : c’est sûr ^^) que vous aurez une meilleure visibilité de ce qui se passe vraiment en interne lorsque vous déclencherez votre prochain vMotion.
Le Process vMotion
Losque qu’une migration de machine virtuelle est lancé, le serveur vCenter va tout d’abord exécuter une tâche spécifique de “migration”. La première étape consiste à faire un premier test de compatibilité entre la machine source et la destination. La VM concernée est-elle matériellement capable de tourner sur la machine cible ? Ensuite, si tout est ok, il faut indiquer aux deux ESXi ce qui va se passer. Pour se faire, un “dossier de spécification” est donc construit, qui contient ces informations :
– La machine virtuelle à migrer
– La configuration de cette machine virtuelle (nombre de CPUs, quantité de mémoire, etc.)
– L’hyperviseur source
– L’hyperviseur destination
– Les spécification du réseau vMotion à utiliser
Ce dossier de spécification est partagé par l’ensemble vCenter-ESXi source-ESXi destination afin que chacun connaisse tous les détails de l’opération à venir. Le vCenter utilise, pour communiquer avec ses partenaires ESXi le “Virtual Provisioning X Daemon”, aka VPXD (NDLR bien connu des administrateurs vSphere). Ce démon appelle chacun des “Virtual Provisioning X Agent”, aka VPXA, sur les ESXi impliqués. Le VPXA de chaque ESXi attente les spécifications de migration et les transfère au process VMX, via l’utilisation du process “Host Daemon”, aka hostd. Lorque la migration est démarrée, le démon hostd place la VM dans un mode intermédiaire entre “éteinte” et “allumée” qui en interdit la modification pendant toute la procédure.
Le process “Virtual Machine Monitor”, aka VMM, est en charge de gérer la mémoire de la VM ainsi que les diverses I/O stockage et réseau vers le VMkernel. Tous les autres types d’I/O non critiques pour les performances sont quant à eux directement renvoyés au process VMX, où “Virtual Machine Extension”, tournant au sein du VMkernel. A noter que le process VMM n’est utilisé que sur l’ESXi source pendant la phase de migration, car c’est à cet endroit que la VM tourne effectivement pendant toute l’opération.
Une fois que tout ceci est en place, le module de migration du VMkernel va ouvrir une connexion vers l’ESXi cible via le réseau vMotion décrit dans le dossier de spécification.
Phase de préparation “Pre-copy”
Tout est donc en place pour démarrer la phase active de la migration. Cette petite phase de préparation consiste juste à s’assurer et attendre que l’ESXi de cible réaliser la pré-allocation des ressources nécessaires à faire fonctionner, à terme, la VM qu’on s’apprète à migrer.
Phase “Pre-copy”
Le process de pre-copy peut commencer. Cette phase consiste à réaliser un premier transfert complet des pages mémoire de la VM. Il faut pendant ce temps là suivre toutes les modifications de pages mémoire sur l’ESXi source. Cela permet ainsi de garder la trace du “reste à transférer” une fois la pre-copy terminée. Toutes les pages écrites pendant la pre-copy sont ainsi “tagguées” en dirty pages, elles devront être re-transféré ensuite.
Le Page Tracing
Pour pouvoir suivre l’évolution mémoire de la VM lors de la phase de pre-copy, les vCPUs associés à la machine sont temporairement mis en pause afin d’installer des “page tracers”, des marqueurs de suivi des pages mémoire, chargés du tagging présenté plus haut. Le module de migration VMkernel indique alors au process VMM de démarrer la trace des modifications mémoire.
Phase “Iterative memory pre-copy”
Le suivi des modifications de pages mémoire et leur ré-émission vers l’ESXi cible est un processus continue évidemment, la VM continuant à travailler sur l’ESXi source. L’objectif est de réaliser toute une série de pre-copy afin de réduire progressivement le nombres de dirty-pages de la source par rapport à la cible. Typiquement, pour une VM de 24 Go, on va d’abord, en phase de pre-copy, transférer les 24 Go, ensuite relancer le transfert de quelques Go de dirty-pages et ainsi de suite jusqu’à la phase terminale. Après chaque itération, le process VMM demande au VMKernel si le process de pre-copy peut être terminé définitivement. Cela n’est possible que lorsque l’ensemble des dirty pages ont été transférées sur l’ESXi de destination. L’algorithme de pre-copy consiste précisément à vérifier que l’ensemble des pages mémoires sur la destination sont identiques à celles présentes sur la source.
Pour détecter si on peut déclencher la phase terminale de la pre-copy, on doit vérifier si le transfert des dirty pages restantes peut être réalisé dans une fenêtre inférieure à 500 millisecondes. Cela dépend de plusieurs paramètres : le nombre de pages restant à transferer, la vitesse de connexion entre l’ESXi source et l’ESXi destination, à quelle vitesse en Go/s les pages mémoires de la VM sont-elles déclarées comme dirty (niveau d’activité de la VM à migrer). Si ce n’est pas possible, une nouvelle itération est décenchée.
Mais que ce passe-t-il si la vitesse de déclaration de dirty pages est supérieure aux capacités de transfert entre les deux hyperviseurs ? En théorie, il n’est pas possible de converger vers une dernière fenêtre de pre-copy terminale et la migration ne peut se terminer. C’est pourquoi nous avons introduit la notion de “Stuen During Page Send”, aka SDPS, à partir de vSphere 5.0. De manière triviale, il s’agit au VMkernel d’indiquer au process VMM de bloquer très temporairement l’exécution des instructions de la VM pour limiter la génération de dirty pages. Cela peut sembler avoir un impact non négligeable sur l’activité de la VM et ses performances générales, mais il faut comprendre que nous somme en train de parler d’une “mise en sommmeil forcée” qui se chiffrent en microsecondes. Cela suffit à la phase d’itération d’arriver à une convergeance et de terminer le vMotion.
SDPS s’exécute à chaque itération si le nombre de dirty pages est supérieur à la vitesse de transfer entre les deux ESXi. Cela limite un temps soit peu la possibilité au système invité sur la machine virtuelle de réaliser des modifications mémoire. Au final, cela a certes un petit impact sur les performances de la machine pendant le vMotion, mais l’objectif ici est surtout que l’OS invité ne détecte pas ce qui est en train de se passer en back-end.
Le “Switchover”
Une fois la pre-copy terminée par le process VMM, toutes les pages mémoires de la VM ont été copiées à l’identique sur le serveur de destination. Le VMM envoie une RPC (Remote Procedure Call) au VMX afin qu’il suspendent la machine virtuelle source. Le VMX suit les ordres et fournit en retour l’état CPU de la VM à l’ESXi de destination.
Enfin, la machine virtuelle sur l’ESXi cible dé-masque la machine virtuelle et l’état est dans la foulée restoré au “checkpoint” réalisé par le process VMX sur l’ESXi source. Cette opération de restoration de l’état de la machinve virtuelle s’opère en 100 à 200 millisecondes. C’est typiquement le moment ou la machine est dans un état suspendu (ça correspond à ce qu’on voit souvent, une perte de ping en moyenne).
La machine virtuelle a été migrée !
Conclusion
Un grande merci à Neils Hagoort pour cet article, qui permet d’entrevoir les entrailles de ESXi et en particulier d’une fonction utilisée quotidiennement dans nos datacenters. On oublie souvent à quel point vMotion repose au départ sur une ingénierie logicielle et des idées brillantes à l’époque où elles ont été développées !
5
3.5