Migration de machines virtuelles

Cette stratégie est la plus basique, il est nécessaire de mettre la machine virtuelle hors tension afin de copier l'état de sa mémoire sur l'hôte cible. Elle est utilisée avec la stratégie de répartition de charge dynamique lorsque l'hôte reçoit plus de requêtes qu'il ne sait en gérer. La décision de migration se fait sur base d'un calcul des requêtes entrantes, de l'utilisation du processeur, des ressources disponibles sur l'hôte physique ainsi que de la consommation énergétique[2] - [5].

L'avantage principal de cette méthode est qu'elle n'impliquera aucune faute lors de la migration de la mémoire. La machine étant arrêtée, les services ne seront plus disponibles et la mémoire ne sera pas altérée sur l'hôte source. La machine une fois migrée pourra reprendre son activité dans le même état que lorsqu'elle s'est arrêtée[6].

Elle comporte par contre un désavantage certain. À partir du moment où la machine est arrêtée, les services fonctionnant sous celle-ci ne seront plus disponibles durant toute la durée de la migration. Ce qui pose évidemment des problèmes majeurs pour des applications nécessitant une haute disponibilité. De plus, la mémoire étant transférée entièrement sur l'hôte cible, la migration à froid provoque un ralentissement sur tout le réseau du cloud[6].

La migration à chaud est une stratégie utilisée pour pallier les problèmes de la migration à froid. Elle permet à un hyperviseur de transférer, au travers d'une connexion TCP, une machine virtuelle d'un hôte à un autre sans être obligé de l’arrêter[7] - [8].

Migration de VM à chaud par pré-copie

• Etape 0 : Pre-migration : La machine virtuelle est active sur l'hôte source, durant cette étape l'hyperviseur est à la recherche d'un hôte de destination capable de gérer la machine à migrer.
• Etape 1 : Reservation : L'hyperviseur se charge de réserver un conteneur sur l'hôte distant en lui envoyant une requête de réservation en y indiquant les ressources nécessaires à la machine virtuelle. Si la requête est acceptée par l'hôte cible, la phase de pré-copie peut démarrer.
• Etape 2 : Pré-copie itérative : Durant cette phase, l'hyperviseur copie les pages de mémoire sur l'hôte distant via TCP. Lors de ce transfert, si une page de mémoire est modifiée sur l'hôte source, elle est marquée comme "sale". Cette étape est répétée, on ne copie plus que les pages qui ont été modifiées durant la pré-copie précédente. Le cycle s'arrête lorsqu'un nombre d'itérations maximum a été atteint (29 fois par défaut pour Xen) ou bien lorsque ce sont toujours les mêmes pages qui sont salies. En moyenne, l'hyperviseur Xen itère 9 fois avant de passer à l'étape suivante.
• Etape 3 : Arrêt et copie : Lors de cette étape, la machine virtuelle est arrêtée sur l'hôte source et les pages sales restantes sont copiées sur l'hôte cible. C'est lors de cette étape que la machine virtuelle ne sera plus accessible. Elle ne sera active sur aucun hôte. Cette période est appelée downtime[N 3], c'est ce temps là qu'il est important de minimiser[9].
• Etape 4 : Validation : Lors de la validation, l'hôte de destination indique à l'hôte source qu'il a bien réceptionné toute l'image de la machine virtuelle. L'hôte source envoie un accusé de réception à l'hôte de destination et libère les ressources bloquées par la VM. L'hôte de destination est dorénavant l'hôte primaire.
• Etape 5 : Activation : La machine virtuelle est activée sur l'hôte cible et la table de routage du switch est mise à jour[7] - [8] - [10] - [11] - [12].

Cette implémentation de la migration en temps réel, présentée par Brandford[13], est implémentée par la plupart des hyperviseurs (Xen, VMWare, KVM). Elle a l'avantage d'être simple et de ne pas nécessiter d'inter-connexion rapide entre les hôtes[8] - [12] - [14].

Il existe d'autres stratégies de migration de la mémoire lors de migration à chaud.

La migration de machines virtuelles par internet est particulièrement utile dans le cadre des grilles informatiques, elle permet de reconfigurer une grille par migration sans pour autant en arrêter le service. Chaque ordinateur connecté à internet devient donc un hôte potentiel pour héberger une machine virtuelle[15].

En virtualisation, la mémoire de la machine virtuelle étant généralement stockée sur un système partagé (Network File System[N 4]), il est nécessaire que la machine cible ait également accès à l'espace de stockage de la machine source[15] - [16].

Durant cette phase, l'hyperviseur copie toutes les pages mémoire de l'hôte source à l'hôte cible alors que la machine virtuelle est toujours opérationnelle. Si une ou plusieurs pages mémoire sont modifiées, elles seront recopiées d'un hôte à un autre durant la phase itérative suivante jusqu'au moment où le taux de pages salies deviendra inférieur au taux de pages copiées[17].

C'est lors de cette phase que la machine virtuelle est arrêtée sur l'hôte source, l'état de la machine et les dernières pages sales sont copiées sur l'hôte cible et la machine virtuelle est re-démarrée sur celui-ci. C'est le downtime de la VM, il ne dure en général que quelques millisecondes, dépendant du nombre de pages restant à copier[18]. L'enjeu principal de la migration est donc de minimiser ce downtime afin de donner au maximum l'illusion que la machine ne s'est jamais arrêtée[19].

La pré-copie a fait ses preuves pour les applications nécessitant beaucoup de lectures mémoire. Cependant, dans le cas d'applications qui écrivent sur la mémoire de manière intensive, cette approche de migration ne sera pas performante, dans les pires cas elle ne fonctionnera même pas[20].

Cette étape nécessite, dans un premier temps, l'arrêt du système sur l'hôte source. L'état du processeur est copié sur l'hôte cible et la machine est ensuite redémarrée sur l'hôte cible. Ensuite, les pages mémoire sont copiées à l'aide d'une combinaison de 4 techniques. La première, demand-paging[N 5], permet à l'hôte cible de demander une page mémoire manquante à l'hôte source, cette méthode implique inévitablement un ralentissement du système de par la lenteur du réseau. Active-push permet à l'hôte source d'envoyer à la cible les pages mémoire fautives qui n'ont pas encore été demandées par l'hôte cible. Le pre-paging[N 6] est un système permettant à l'hôte source de prédire la prochaine page fautive sur l'hôte cible en fonction des défauts de page récents. Dynamic self balooning[21] permet quant à lui de réduire le nombre de transferts des pages non allouées[22] - [23].

En post-copie le downtime est moins long qu'en pré-copie étant donné que seul l'état du CPU et du matériel, soit quelques Ko, doivent être migrés durant cette inactivité. Le temps total de migration est court et déterministe étant donné que les pages ne sont pas salies sur l'hôte source durant la migration[8].

La post-copie est plus optimisée pour les applications nécessitant beaucoup d'écritures en mémoire[20].

En post-copie hybride, une seule phase de pré-copie est effectuée avant la phase de post-copie, de cette manière l'hôte cible dispose déjà de toute la mémoire, seules les pages sales devront être transférées en post-copie[8]. Pendant la copie des pages mémoire d'un hôte à un autre, la machine virtuelle continue de fonctionner sur l'hôte source. Une fois la copie effectuée, la machine virtuelle est stoppée, l'état du processeur et les pages modifiées sont copiées à leur tour sur la machine cible. La machine virtuelle est ensuite redémarrée sur l'hôte cible et la phase de post-copie commence. Ce système fonctionne bien pour les applications nécessitant un grand nombre de lectures mémoire, tout comme la migration par post-copie. Il fournit également un temps de migration déterministe pour les applications nécessitant un grand nombre d'écritures mémoire[23] - [24].

La mémoire de masse est, dans la majorité des cas, associée à une mémoire partagée de type NAS et ne nécessite donc pas d'être déplacée[3].

Lors de la migration de mémoire par pré-copie, plus les services écrivent sur la mémoire plus il y aura de défauts de pages. Ce nombre de défauts de page important impliquera par conséquent un downtime du système plus important[24].

Pour ce type de service il est donc préférable d'utiliser la migration par post-copie, pour laquelle les défauts de page n'entrent pas en compte lors de l'arrêt de la machine virtuelle. La migration de mémoire par post-copie hybride reste un choix judicieux pour ce type de service[8].

La migration par internet permet de transférer l'environnement d'exécution des machines virtuelles d'un cloud à un autre. Ce type de migration peut engendrer des problématiques d'adressage liées au changement de réseaux[25] - [26].

Chaque VM localisée dans un cloud définit un état réseau qui inclut une adresse IP ainsi qu'une liste des connexions ouvertes. Lors d'une migration sur le même réseau, une mémoire partagée peut résoudre le problème d'adressage en y stockant l'état réseau en vue d'une restauration sur l'hôte cible. Cependant lors d'une migration au travers d'internet, il est fort probable que la machine cible n'ait pas accès à cette mémoire partagée[27].

Lors d'une migration à chaud par Internet, il est nécessaire que le service soit maintenu. Cela implique que l'adresse IP publique de la VM reste la même. Il est également nécessaire que la migration n'interfère pas avec les protocoles de communication au niveau applicatif (TCP/UDP), ou avec la mémoire partagée[26] - [28].

Une des solutions à ces problèmes est d'utiliser un protocole d'IP mobile[29], permettant un déplacement d'un réseau d'IP vers un autre tout en gardant la même adresse IP ainsi que les connexions actives.

Une autre solution, proposée par Bradford[13], implique la résolution DNS. Lors de la migration, les VMs gardent leurs noms canoniques et la nouvelle adresse IP est enregistrée avec le nom du serveur. De cette manière la recherche d'une VM de par son nom canonique va permettre de résoudre la nouvelle adresse IP attribuée à la machine. La problématique de cette solution réside dans la gestion de ce changement d'IP au niveau applicatif[26].

Cloudnet[30], utilise une combinaison de réseaux privés en couche réseau 3 (réseau privé virtuel) et de service privé LAN en couche réseau 2 (Virtual Private LAN Service) pour fournir un routage, multipoint-à-multipoint, au travers différents réseaux à l'aide de ponts LANs[26].