Migration de machines virtuelles
From Wikipedia, the free encyclopedia
En virtualisation, la migration de machines virtuelles consiste à déplacer l'état d'une machine virtuelle, d'un hôte physique à un autre.
Il existe plusieurs raisons pour lesquelles il est nécessaire de migrer des systèmes d'exploitation, la plus importante étant l'équilibrage de la charge de travail sur les serveurs physiques. Il est également nécessaire de migrer des machines virtuelles lorsqu'un hôte physique est défectueux ou nécessite une maintenance.
Il faut également tenir compte du temps d'arrêt de la machine virtuelle lors de cette migration. La plus grosse charge de travail consistant à migrer la mémoire vive, il est nécessaire d'opter pour des stratégies de migration différentes en fonction des exigences.
La virtualisation est devenue une étape obligatoire dans le développement des clusters[N 1] et du cloud computing[N 2]. Les clouds mettent à disposition des machines virtuelles fonctionnant sur un ou plusieurs hôtes donnant l'illusion à l'utilisateur qu'il dispose d'une certaine quantité de mémoire et de CPU. Les ressources matérielles deviennent des services pour les utilisateurs qui ne payent que pour les ressources qu'ils utilisent, ces ressources se doivent d'être disponibles à la demande. Cette flexibilité implique une nécessité de pouvoir migrer les machines virtuelles d'un hôte à un autre en fonction des ressources nécessaires et disponibles[1].
Pouvoir migrer un système d'exploitation d'un hôte physique à un autre s'avère être quelque chose d'incontournable dans les data centers et dans les clusters. Cela permet de délimiter clairement le matériel du logiciel, de faciliter la gestion des pannes, de répartir de manière uniforme et automatique une charge de travail donnée et surtout de pouvoir organiser la maintenance des machines. Lorsqu'un hôte est surchargé et qu'il n'est plus capable de répondre à la demande, il est nécessaire de migrer l'état de la machine virtuelle vers un hôte plus puissant, ou moins surchargé, qui sera capable de prendre le relais. L'état de la machine virtuelle inclut la mémoire volatile et non-volatile, l'état des CPUs virtuels (VCPU), l'état des périphériques connectés ainsi que l'état des connexions actives[2],[3].
Cependant la majorité des applications et des services reposant sur ces machines virtuelles ne peuvent pas subir d'arrêt prolongé. Il devient alors nécessaire de mettre en place des stratégies de migration différentes, en fonction des contrats de niveau de service établis avec les clients[4].
Stratégies
Migration à froid
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].
Migration à chaud
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].
- 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.
Migration par internet
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].
Migration de la mémoire
Migration de mémoire par pré-copie
Phase d'échauffement
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].
Phase d'arrêt et de copie
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].
Migration de mémoire par post-copie
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].
Migration de mémoire par post-copie hybride
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].
Stockage partagé
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].
