Hyper-V 2.0 sous Windows Server 2008 R2
Live Migration
Live Migration est sans aucun doute la fonctionnalité la plus attendue sur Windows Server 2008 R2 concernant Hyper-V. Elle vient se positionner en concurrence direct avec son équivalence chez VMware et son produit VMotion.
L’objectif est d’offrir la possibilité aux administrateurs de déplacer une machine virtuelle d’un serveur physique à un autre sans déconnexion des clients de la machine virtuelle. Cela permet la mise en place de nouveau scénario d’implémentation :
· Continuité de service pendant les phases de maintenance des serveurs physique.
· Répartition des machines virtuelles afin d’optimiser la consommation d’énergétique.
· Répartition des machines virtuelles afin de repartir la charge des processeurs.
Quick Migration (Windows Server 2008 Hyper-V)
Actuellement avec Windows Server 2008, le déplacement d’une machine virtuelle passe par le processus Quick Migration.
Le principe de fonctionnement est le suivant :
1. Sauvegarder l’état en sauvegardant la machine virtuelle sur la cible puis en enregistrant la mémoire de la machine virtuelle sur un espace de stockage partagé.
2. Déplacer la gestion du stockage de la source à la destination pour déplacer la machine virtuelle.
3. Restaurer l’état en chargeant la mémoire de la machine virtuelle à partir de l’espace de stockage partagé et lancer la machine virtuelle.
Ce processus est très couteux en temps car il impose des étapes très longues qui peuvent induire un temps de déplacement prenant plusieurs minutes donc autant en indisponibilités.
Live Migration (Windows Server 2008 R2 Hyper-V)
Le passage de Quick Migration à Live Migration n’impose pas de mise à jour du système d’exploitation invité, ni de la machine virtuelle, ni de l’infrastructure de stockage ou de l’infrastructure réseau. Il est seulement nécessaire de migrer les machines virtuelles sur Hyper-V 2.0 et c’est tout.
Avec Live Migration sous Windows Server 2008 R2, voici le processus exécuté à chaque demande de basculement d’un administrateur (ou d’un script) :
1. Le premier serveur physique contenant la machine virtuelle auquel sont connectés les clients copie l’ensemble du contenu de la mémoire de la machine virtuelle sur le serveur de destination.
2. La machine virtuelle est ensuite pré-chargée en mémoire dans le serveur de destination prête à être démarrée.
3. Pendant cette copie, les clients continuent d’accéder à la machine virtuelle sur le premier serveur et modifient le contenu de sa mémoire vive. Les emplacements mémoire modifiés sont ainsi repérés pour être copié à leur tour de manière incrémentiel (donc uniquement les changements) sur le serveur de destination. Dans la mesure où il y aura moins de donnée à copier (uniquement ce qui a été modifié depuis la copie précédente) la copie sera beaucoup plus rapide.
4. La machine virtuelle sur le premier serveur est alors mise en pause et une copie de l’état de la partition est transmise du premier serveur vers le serveur de destination.
5. On lance la machine virtuelle (qui est déjà en mémoire) sur le serveur de destination. Le laps de temps d’indisponibilité est donc très court.
6. Des requêtes ARP permettent alors de rediriger les clients sur le serveur de destination et dans la mesure où l’état de session est maintenu, aucune reconnexion n’est nécessaire pour le client.
Avec ce processus, le temps de basculement est réduit à quelques secondes donc une quasi-transparence pour les clients.