Migration à chaud : ce qu’il faut savoir sur Hyper-V
Hyper-V autorise la migration des VMs en cours d’exécution pour constituer une copie de secours du site de production en cas d’incident ou de montée en charge de l’activité. Mais des contraintes s’appliquent.
L'une des fonctionnalités les plus utiles des hyperviseurs tels que Microsoft Hyper-V est la possibilité de déplacer une machine virtuelle en cours d'exécution vers un autre hôte sans provoquer de temps d'arrêt. Ces migrations à chaud sont utiles pour tout, de l'équilibrage de la charge de travail de l'hôte à la mise hors ligne d'un hôte pour la maintenance. Trop souvent, les migrations Hyper-V à chaud ne sont qu'une réflexion après coup. Idéalement, les administrateurs devraient planifier les exigences et les paramètres de la migration Hyper-V à chaud avant de déployer le premier hôte.
Avant de configurer un nouveau déploiement Hyper-V vers un cloud privé de secours, les administrateurs informatiques doivent prendre en compte les exigences de la migration Hyper-V à chaud. La configuration de l'hôte Hyper-V joue un rôle majeur dans la rapidité et l'efficacité de ces migrations.
Les configurations individuelles des machines virtuelles sont les plus importantes. Les exigences de la migration Hyper-V à chaud font en sorte que les administrateurs ne peuvent pas migrer à chaud une VM à moins que l'hôte de destination ne puisse prendre en charge la configuration matérielle de la VM. Par exemple, une VM configurée pour utiliser des disques physiques locaux ne peut pas être migrée à chaud parce que ces disques n'existent pas sur l'hôte de destination.
Parmi les autres exemples, on peut citer l’utilisation de cartes PCIe spécifiques ou de GPU dédiés. Bien entendu, le degré de matériels virtualisés joue également un rôle. L'hôte de destination doit, par exemple, contenir un commutateur virtuel qui porte le même nom que le commutateur virtuel auquel la VM est attachée sur l'hôte source. Dans un monde parfait, chaque serveur Hyper-V de la destination serait identique à 100 % aux serveurs à la source. Dans le monde réel, les hôtes peuvent varier considérablement les uns des autres.
Assurer la compatibilité au niveau des processeurs
Hyper-V contient un paramètre de compatibilité des processeurs que vous pouvez utiliser pour déplacer une VM en cours d'exécution vers un hôte différent.
Vous pouvez accéder aux paramètres de compatibilité des processeurs d'Hyper-V en ouvrant le gestionnaire Hyper-V, en cliquant avec le bouton droit de la souris sur la VM dont vous souhaitez modifier les paramètres du processeur et en sélectionnant la commande Paramètres dans le menu contextuel. Hyper-V Manager affiche alors les paramètres de la VM. Si vous développez le conteneur du processeur, vous verrez un conteneur de compatibilité sous celui-ci. Sélectionnez le conteneur de compatibilité. Ensuite, activez le mode de compatibilité du processeur pour la VM en cochant la case Migrer vers un ordinateur physique avec une version de processeur différente.
L'interface indique que vous pouvez utiliser la fonction de compatibilité des processeurs pour déplacer la VM vers un ordinateur physique avec une version de processeur différente.
Notez que Microsoft utilise le mot version, et non pas architecture. En d'autres termes, vous ne pourrez pas utiliser la fonction de compatibilité des processeurs pour déplacer une VM d'un système basé sur Intel à un système basé sur AMD. Des articles sur Internet prétendent avoir réussi un tel transfert, mais les migrations inter-architectures à chaud, ou les migrations rapides ne sont pas officiellement prises en charge et ne fonctionneront probablement pas correctement.
Au lieu de cela, la fonction de compatibilité CPU est conçue pour vous aider à déplacer une VM en cours d'exécution vers un autre hôte Hyper-V équipé d'un CPU plus ancien ou plus récent qui utilise la même architecture que l'hôte sur lequel la VM fonctionne actuellement. Par exemple, vous pouvez déplacer une VM d'un hôte équipé d'un processeur Intel de sixième génération vers un hôte équipé d'un processeur Intel de huitième génération.
La fonction de compatibilité du processeur Hyper-V est très simple. Néanmoins, il y a certaines choses que vous devez savoir à son sujet. Tout d'abord, la fonction de compatibilité des processeurs fonctionne en désactivant certaines des fonctions les plus avancées du processeur, laissant la VM dépendre d'un ensemble plus standard de capacités du processeur. Microsoft n'a pas publié de liste officielle des fonctionnalités que le mode de compatibilité du processeur désactive, mais il n'a généralement que peu ou pas d'effet négatif sur les performances des charges de travail des entreprises, à moins qu'elles ne soient gourmandes en ressources graphiques.
En outre, le mode de compatibilité du processeur n'est prévu que pour une utilisation temporaire. Activez le mode de compatibilité du processeur juste avant d'effectuer une migration en direct ou une migration rapide, puis désactivez le mode de compatibilité du processeur une fois la migration terminée. La désactivation du mode de compatibilité des processeurs permet à la VM d'utiliser toutes les fonctionnalités avancées du processeur qui pourraient être disponibles sur le serveur hôte de destination.
Enfin, vous ne devez utiliser le mode de compatibilité des processeurs Hyper-V que dans des circonstances très spécifiques ; par exemple, si vous effectuez une migration en direct ou une migration rapide entre deux hôtes Hyper-V ayant des architectures de CPU similaires mais des versions de CPU différentes. Vous n'avez pas besoin d'utiliser le mode de compatibilité des processeurs si vous arrêtez la machine virtuelle avant de la migrer. Un arrêt est nécessaire si vous déplacez la VM vers une architecture CPU différente, mais il est facultatif pour les autres migrations. Le mode de compatibilité n'est pas non plus nécessaire si les hôtes ont des versions de CPU similaires.
Limiter le nombre de migrations à chaud simultanées
L'une des premières exigences de la migration Hyper-V à chaud est d'établir le nombre de migrations à chaud simultanées autorisées.
Certaines personnes considèrent que ce paramètre est sans importance en raison de la façon dont fonctionnent les migrations Hyper-V à chaud. À moins qu'il ne s'agisse d'une migration à chaud sans partage, il n'y a que deux choses qui sont transférées dans le cadre d'une migration à chaud : la propriété de la VM et son état de fonctionnement. Les opérations de migration à chaud n'exigent pas le transfert du contenu du disque dur virtuel, sauf dans le cas d'une migration à chaud sans partage. Certains professionnels de l'informatique estiment donc qu'il y a peu de raisons de limiter le nombre de migrations à chaud simultanées.
Le problème avec cette hypothèse est que lorsqu'une migration Hyper-V live transfère l'état de fonctionnement d'une VM, le contenu de la mémoire de la VM est transféré comme une partie de cet état. Même une VM de taille modeste peut disposer de plusieurs giga-octets de mémoire. Inversement, une grande VM de génération 2 fonctionnant sur l’Hyper-V de Windows Server 2016 peut avoir jusqu'à 12 To de mémoire vive. Copier 12 To de données d'un serveur à l'autre n'est pas une opération triviale.
Plus les VMs ont de mémoire, plus la migration à chaud sera longue à réaliser. Bien que plusieurs grandes VM puissent migrer à chaud simultanément, cela prendrait un temps considérable. Plus la durée d'une opération de migration à chaud augmente, plus le risque d'échec de l'opération augmente.
Régler les performances
Depuis l'introduction de Windows Server 2012 Hyper-V, Microsoft a proposé trois options de performances différentes pour les migrations à chaud. Ces options de performance déterminent comment le contenu de la mémoire d'une VM se déplacera sur le réseau vers l'hôte de destination pendant une migration à chaud.
L'option de performance par défaut est TCP/IP. L'utilisation de cette option indique essentiellement à Hyper-V de transmettre la mémoire de la VM à l'hôte de destination sans modifier les données ou la méthode de migration.
La deuxième option consiste à utiliser la compression. Avec cette option, les administrateurs peuvent compresser le contenu de la mémoire de la VM avant la transmission à l'hôte de destination. Cette compression réduit le volume total de données qui devront être déplacées sur le réseau, ce qui permet une migration à chaud plus rapide.
La mise en garde est que la compression du contenu de la mémoire d'une VM est une opération qui demande beaucoup de temps au processeur. En général, cela ne pose pas de problème car la plupart des hôtes Hyper-V ont beaucoup de ressources CPU, mais si un hôte exécute des charges de travail intensives en CPU -- au point que l'hôte est lié au CPU -- alors l'utilisation de l'option de compression pourrait ne pas être la meilleure idée.
La troisième option est l'option de blocage des messages du serveur (SMB). Avec cette option, les administrateurs peuvent envoyer le contenu de la mémoire de la VM à l'hôte de destination en utilisant SMB Direct. Cette option offre généralement les meilleures performances pour la migration Hyper-V à chaud, mais c'est aussi la plus restrictive. Cette méthode n'est disponible que si les cartes réseau des hôtes source et destination prennent en charge l'accès direct à la mémoire à distance.
Certaines versions d'Hyper-V interdisent également l'association des cartes réseau ou leur liaison à un commutateur virtuel. Malgré cela, cette exigence de migration à chaud Hyper-V est quelque peu discutable, car l'utilisation d'un adaptateur réseau dédié pour le trafic de migration à chaud est depuis longtemps une pratique exemplaire.
Le protocole d'authentification est la dernière exigence de la migration Hyper-V à chaud à examiner. Hyper-V offre deux choix : Kerberos et CredSSP. Dans presque toutes les situations, les administrateurs devraient utiliser Kerberos parce qu'il est plus sûr et parce qu'il ne nécessite pas le lancement de la migration à chaud directement depuis la console du serveur. Cependant, si les administrateurs choisissent Kerberos, alors il faudra une configuration de délégation limitée.
