Migration à chaud
La migration à chaud permet de déplacer une machine virtuelle d’un nœud physique à un autre sans interruption de service, ce qui rend le processus totalement transparent pour l’utilisateur. Le processus de migration à chaud d’une machine virtuelle d’un hôte source vers un hôte de destination se compose de six étapes principales :
Réservation : L’hôte source envoie la requête de migration à l’hôte de destination et attend sa confirmation de disponibilité des ressources. L’hôte de destination réserve par la suite la mémoire nécessaire à la machine virtuelle.
Copie itérative de pages mémoire : Pendant la première itération toutes les pages mémoire de la machine virtuelle source sont copiées sur l’hôte de destination dans la mémoire qui lui est allouée. Dans les itérations ultérieures, seulement les pages mémoire modifiées (dirty pages) durant la phase de transfert précédente sont copiées.
Stop et copie : La machine virtuelle est mise en pause afin de permettre une ultime copie des pages mémoire modifiées. L’hôte transfère également les registres processeur ainsi que l’état des périphériques à la machine de destination. À la fin du transfert, la VM cible devient une copie parfaite de la VM source. Redirection : L’hôte de destination indique à l’hôte source qu’il a correctement reçu l’image de la VM. Activation de la machine virtuelle : La machine virtuelle migrée est activée et peut continuer son exécution.
Mise à jour des informations réseau : Un message de mise à jour est envoyé au switch physique afin d’adapter sa table de routage. De ce fait, les paquets à destination de la machine virtuelle ne passent plus par le même port physique.
Problèmes réseau lors de la migration
Dans cette section, nous définissons les problèmes liés à la migration inter-site des machines virtuelles appartenant à la même grappe virtuelle. Une grappe virtuelle est un ensemble de machines virtuelles utilisées pour l’exécution d’une application distribuée. Initialement nous supposons que toutes les VMs de la grappe virtuelle se trouvent sur le même cloud .
Ensuite, nous considérons un scénario où nous désirons migrer certaines VMs sur un autre cloud. Ceci nous conduit à trois cas problématiques possibles. Le premier cas se présente si la migration se fait seulement sur une partie des VMs de la grappe virtuelle . Dans ce cas, il y a deux possibilités :
La première possibilité est de garder les adresses IP des VMs migrées. Dans ce cas l’adresse IP de la VM migrée est la même mais le chemin à suivre pour lui transmettre des messages n’est plus le même. Il peut y avoir également un conflit d’adressage avec d’autres VMs déjà hébergées sur le cloud de destination (une de ces VMs peut avoir la même adresse que celle de la VM migrée). La seconde possibilité consiste à mettre à jour les adresses IP des VMs migrées. Dans ce cas l’ensemble des VMs est incapable de connaître la nouvelle adresse IP de la VM migrée. Le deuxième cas problématique consiste à migrer entièrement la grappe virtuelle . Ceci peut être considéré comme un cas particulier du premier. Il est résoluble si les trois conditions, ci-dessous, seront satisfaites : Éliminer tous les conflits entre les adresses IP des VMs migrées et celles des VMs déjà hébergées sur le cloud de destination. Éliminer également tous les conflits entre les adresses Ethernet. Ne pas utiliser des routeurs entre les VMs à migrer.
Le dernier cas problématique apparaît lors de la migration d’une VM communiquant avec un utilisateur extérieur ne faisant pas partie de la grappe virtuelle . Ceci entraîne deux possibilités similaires à celles vues dans le premier cas problématique. Si la VM garde son adresse IP, l’utilisateur envoie les messages à destination de la VM au cloud source au lieu de les envoyer au cloud de destination. Par contre si la VM met à jour son adresse IP, l’utilisateur est incapable de la connaître.
Mécanismes permettant la migration inter-site
Protocole Mobile IPv6 : Le but du protocole Mobile IPv6 est de rendre joignable à tout instant un périphérique mobile. Le même principe peut s’appliquer par analogie pour rendre joignable à tout instant une machine virtuelle migrable . Initialement le nœud mobile est lié à un réseau géré par un agent mère. Après le déplacement du nœud mobile, il sera attaché à un nouveau réseau administré par un agent étranger . Dans un premier temps le nœud mobile envoie un message de mise à jour à son agent mère pour l’informer de son nouvel emplacement. Si l’agent mère détecte un nouveau correspondant souhaitant communiquer avec le nœud mobile, il transmet d’abord le paquet à ce dernier et envoie à son tour un message de mise à jour au nœud correspondant. Le nœud correspondant crée par la suite un tunnel direct entre lui et le nœud mobile, évitant ainsi de passer par l’agent mère.
Réseaux virtuels : Les réseaux virtuels prennent de plus en plus place dans la communauté réseau et offrent de nouvelles perspectives pour l’internet du futur, tout en permettant le déploiement de différentes architectures et de différents protocoles sur une infrastructure physique partagée. La virtualisation réseau consiste à virtualiser à la fois les nœuds et les liens. La virtualisation des nœuds est fondée sur l’isolation et le partitionnement des ressources du nœud physique. D’autre part, chaque lien physique peut transporter plusieurs liens virtuels. L’interconnexion de ces nœuds
virtuels et liens virtuels permet la création d’un réseau virtuel. Ainsi les réseaux virtuels permettent d’optimiser l’utilisation des infrastructures physiques et de mieux les gérer. Ce concept peut également avoir des intérêts économiques. Par exemple le partage d’une infrastructure physique entre différents opérateurs réseaux réduit considérablement le coût de propriété. L’architecture de la plupart des réseaux virtuels s’appuie sur un réseau overlay. Un réseau overlay est un réseau au-dessus d’un réseau physique ou d’un autre réseau overlay. Les réseaux overlay sont généralement décentralisés, distribués et sans organisation hiérarchique. Dans ce cas ils sont appelés des réseaux pair-à-pair ou P2P (peer-to-peer ). Chaque nœud d’un réseau overlay, appelés pair, joue à la fois le rôle de serveur et de client. L’organisation dans un tel réseau repose sur l’ensemble des pairs, sans avoir une entité chargée de l’administrer.
Un réseau virtuel utilise les services offerts par le réseau overlay sous-jacent telle qu’une table de hachage distribuée (ou DHT pour Distributed Hash Table) . Nous considérons deux machines virtuelles VM1 et VM2, appartenant au même réseau virtuel, mais hébergées sur deux hôtes physiques qui appartiennent à des réseaux physiques différents. Quand VM1 envoie un paquet à VM2, l’hôte physique qui l’héberge (hôte 1) l’intercepte.
Prise en compte des schémas de communication pour la migration d’applications distribuées
Une application distribuée est une application composée de plusieurs processus communiquant entre eux et pouvant être distants géographiquement. Les composants d’une application distribuée peuvent communiquer entre eux à travers le passage des messages, en utilisant par exemple MPI , ou à travers d’autres mécanismes. Les processus d’une application distribuée ne communiquent pas forcément entre eux de la même façon. Par conséquent les applications distribuées peuvent avoir des schémas de communication différents. Pour assurer de bonnes performances, la migration inter-site de telles applications doit tenir compte de ces schémas de communication. En effet, migrer sur deux clouds différents des processus qui communiquent beaucoup entre eux pénaliserait les performances. Par exemple dans l’application CG des NAS Parallel Benchmarks, les nœuds forment des groupes de communication. Dans ce cas, il faudrait faire en sorte de migrer uniquement des groupes de communication complets.
Plusieurs travaux ont été réalisés pour la détection de schémas de communication des applications distribuées . La plupart d’entre eux se basent sur la librairie MPI. Les mécanismes utilisés consistent à apporter des modifications à cette librairie. Dans les travaux réalisés la détection de schémas de communication ne nécessite aucune modification de la librairie MPI, mais elle se fait en utilisant les traces de communication MPI. Enfin, les travaux menés sont indépendant de la librairie MPI. Ils se fondent sur l’analyse du trafic réseau en capturant les paquets TCP. Pour réaliser une migration dynamique tenant compte de ces schémas de communication d’une façon transparente, il serait plus intéressant de détecter les schémas de communication en analysant le trafic réseau des machines virtuelles depuis l’hyperviseur. Ces informations sur le trafic nous permettraient de détecter les groupes de communication éventuels formés par l’application distribuée.
Table des matières
Introduction
1 État de l’art
1.1 Virtualisation et migration à chaud
1.1.1 Virtualisation
1.1.2 Migration à chaud
1.2 Problèmes réseau lors de la migration
1.3 Mécanismes permettant la migration inter-site
1.3.1 Protocole Mobile IPv6
1.3.2 Réseaux virtuels
1.3.3 Bilan des mécanismes étudiés
1.4 Prise en compte des schémas de communication pour la migration d’applications distribuées
1.5 Conclusion
2 Objectifs de stage
3 Les Réseaux virtuels VNET et IPOP
3.1 VNET
3.1.1 Architecture
3.1.2 Évaluation
3.2 IPOP
3.2.1 Architecture
3.2.2 Évaluation
4 Système de migration dynamique
4.1 Intérêts et contexte
4.2 Modèle proposé
4.2.1 Capteur de paquets
4.2.2 Collecteur
4.2.3 Gestionnaire de migration
4.2.4 Gestionnaire d’application
4.3 Mise en œuvre
4.3.1 Capteur de paquets
4.3.2 Collecteur
4.3.3 Gestionnaire de migration
4.4 Évaluation
Conclusion
