Implémentation de Live Migration pour Hyper-V

Présentation de Live Migration

L’objectif de cet article est de détailler l’implémentation de l’une des nouveautés majeures d’Hyper-V sur Windows Server 2008 R2. Cette fonctionnalité baptisée Live Migration se place en concurrence directe avec VMotion de VMware et permet de maintenir la disponibilité des machines virtuelles lors d’actions de maintenance sur les serveurs de virtualisation.

Il peut se révéler assez délicat, sur une infrastructure virtualisée, d’être contraint d’arrêter les machines virtuelles lors d’une opération de maintenance sur le serveur physique nécessitant un redémarrage.

L’objectif est donc de permettre le basculement d’une machine virtuelle d’un serveur physique à un autre de manière transparente, sans la moindre interruption de service...

Principe de fonctionnement

Avec Windows 2008, Microsoft proposait déjà un processus de basculement optimisé entre les serveurs physique nommé Quick Migration.

Ce processus lance une sauvegarde de l’état de la machine virtuelle incluant le disque dur et la mémoire, puis restaure cet état sur le serveur de destination.

L’avantage est que les opérations en cours ne sont pas interrompues car la machine est placée en « veille », mais les clients sont déconnectés durant la bascule.

Avec Windows Server 2008 R2 et Live Migration, le serveur physique contenant la machine virtuelle copie le contenu de la mémoire sur le serveur de destination qui la précharge.

Pendant cette copie, les clients continuent d’accéder à la machine virtuelle source modifiant entre autre le contenu de la mémoire vive, créant de se fait des divergences avec les copies du serveur cible. Les emplacements ainsi modifiés sont repérés pour être ensuite copiés à leurs tours de manière incrémentielle sur le serveur de destination. Dans la mesure où il y aura moins de données à répliquer (uniquement ce qui a été modifié depuis la copie précédente) la copie est beaucoup plus rapide.

La machine virtuelle source est ensuite mise en pause puis la machine virtuelle cible (qui est déjà en mémoire) sur le serveur de destination est mise en route. Des requêtes ARP permettent de rediriger les clients sur le serveur de destination.

Le temps d’indisponibilité est donc extrêmement court, aucune reconnexion n’est nécessaire pour le client. La migration est complètement transparente pour l’utilisateur.

Il est a noter que ces technologies nécessitent tout de même une homogénéité des plateformes serveurs (AMD ou Intel) pour le basculement.

Architecture

Pour permettre ce tour de force, il est impossible de recourir aux anciennes techniques de gestion de disque que l’on trouve sur les clusters classiques car elles sont assez lourdes à administrer et requièrent un temps de basculement plus important. (un disque dur par machine virtuelle, temps de prise de contrôle du disque par un nœud, …)

Ainsi une nouvelle fonctionnalité exclusivement destinée à Hyper-V et à Live Migration appelée Cluster Shared Volume a été ajoutée dans les services de cluster de Windows Server 2008 R2.

Cette solution basée sur le iSCSI (Protocole permettant le transport du SCSI sur un réseau TCP/IP classique) permet potentiellement aux différents nœuds d’accéder simultanément au même contenu.

Afin de garantir l’intégrité des données (et éviter l’écrasement des informations d’un nœud par l’autre), un coordinateur devient responsable de l’organisation du disque et les autres nœuds sont clients de celui-ci. En cas de défaillance du coordinateur, un autre coordinateur est élu parmi les nœuds restants.

Implémentation

Voici la liste des différents points à ne pas oublier pour mettre en place Live Migration :

1. Implémenter un domaine Active Directory
2. Connecter les nœuds au SAN
3. Installer le rôle Hyper-V sur les nœuds
4. Créer un réseau virtuel Hyper-V commun sur les nœuds
5. Configurer le Cluster Shared Volume avec le SAN
6. Créer la machine virtuelle
7. Tester la fonctionnalité Live Migration

L’implémentation des services de cluster nécessite l’utilisation d’un domaine Active Directory pour que les ressources soient démarrées avec le même contexte de sécurité (même privilèges et autorisations) sur les deux nœuds.

Il faut ensuite connecter les LUN iSCSI. Pour cela vous pouvez utiliser l’outil de connexion fourni par Windows nommé iSCSI Initiator. Il permettra de monter les volumes distants sur chacun des nœuds. Si vous souhaitez réaliser une maquette et que vous ne disposez pas de SAN, vous pouvez utiliser la version d’évaluation de l’outil Starwind qui émulera une baie SAN.

L’installation du rôle Hyper-V est quand à elle tout à fait standard sur les deux nœuds. Il est simplement nécessaire que le nom du réseau virtuel permettant la prise en charge des clients soit le même sur les deux nœuds (souvent un réseau de type externe lié à la carte physique). En effet lors de la bascule, la machine virtuelle recherchera ce nom sur le nœud de destination pour se reconnecter au réseau.

Il faut ensuite installer la fonctionnalité Failover Clustering sur les deux nœuds et configurer le cluster par l’intermédiaire de l’assistant. Le type de quorum (Jeu de nœud majoritaire, partage témoin, référence disque, …) n’est pas important tant qu’il est fonctionnel. Il faut ensuite associer les disques issues du SAN au cluster.

Puis activer l’option Cluster Shared Volume, qui va créer le répertoire C:\ClusterStorage sur l’ensemble des nœuds, ainsi que, pour chaque espace de stockage que vous aller ajouter, un sous-répertoire correspondant (ex : c:\ClusterStorage\Volume 1).

A l’aide de l’outil d’administration du cluster, vous devez ensuite créer la machine virtuelle qui devra être stockée sur l’un des LUN montés (ex : c:\ClusterStorage\Volume 1).

Cette manipulation intègre non seulement le processus de création de la machine virtuelle mais aussi la configuration de toutes les dépendances permettant de relancer la machine sur un autre nœud (disques durs, adresse ip, nom réseau, …).

Une fois la machine installée et opérationnelle, vous pouvez, à l’aide de l’outil d’administration du Cluster, basculer votre machine virtuelle d’un nœud à l’autre et constater le maintien de la connectivité.

Conclusion

Bien qu’il repose sur des technologies de clustering, Live Migration reste avant tout un outil de migration dans la mesure où les opérations de bascule requièrent une intervention. Il se révèlera comme un atout majeur dans les environnements requérant une haute disponibilité, lors de mises à jour logicielles ou matérielles requérant un arrêt / redémarrage des serveurs physiques (application de correctifs, prédiction de panne,…).