• Aucun résultat trouvé

3.1 Architecture générale de la solution proposée

3.2.4 Mise en oeuvre des communications

Nous étudions maintenant comment les requêtes de communications soumises au périphé- rique virtuel peuvent être traitées. Nous montrons en particulier en quoi l’interface choisie permet des transferts de donnés efficaces en mémoire partagée comme sur réseau rapide et discutons de l’impact des migrations de machines virtuelles sur le traitement des communica- tions.

3.2.4.1 Transferts de données

Chacun des deux canaux de communication proposés permettent de mettre en oeuvre les tech- niques natives de passage de messages étudiées précédemment.

3.2. Un périphérique virtuel pour le passage de message 77

FIGURE3.6: Transfert de message par accès mémoire distant

Tampons de communication

Une fois qu’un tampon de communication a été soumis au périphérique virtuel pour envoi, si la machine virtuelle de destination se situe sur la même machine physique, un simple échange de pointeur permet d’insérer le tampon de communication dans la file de réception. En effet, puisque l’on considère que les machines virtuelles qui communiquent se font confiance, tous les tampons de communication peuvent être partagés entre les machines virtuelles. L’échange de pointeur peut même être effectué directement dans le contexte de l’invité émetteur, sans impliquer l’hôte dans la communication.

Si les machines virtuelles sont hébergées sur des hôte différents, l’hôte hébergeant la machine virtuelle émettrice doit transférer les données sur le réseau (voir Figure 3.5). Puisque les trans- ferts se font entre des tampons de communication prédéfinis ils peuvent être enregistrés auprès du réseau hôte pour un transfert rapide sans copie intermédiaire. Lorsqu’un hôte détecte l’arri- vée de données dans un tampon de communication, il l’insère dans la bonne file de réception. Les copies supplémentaires sont donc évitées, mais le surcoût en latence induit par le chan- gement de contexte entre invité et hôte ne peut être facilement contourné dans le cas général. Une solution consiste néanmoins à utiliser un éventuel coeur libre de l’hôte pour l’émulation du périphérique virtuel.

Accès mémoire distants

Les transferts par accès direct se font entre zones mémoire préalablement enregistrées et défi- nies par un ensemble d’adresses physiques virtuelles. Cela permet à l’hôte d’y accéder simple- ment, indépendemment des translations d’adresses mises en place par l’invité. Il lui suffit de déterminer les adresses de l’hôte correspondant à ces zones mémoire et de transférer les don- nées entre elles. Lorsque les machines virtuelles sont co-hébergées, cela revient à une simple copie mémoire. Dans le cas contraire l’hôte peut profiter de l’étape d’enregistrement virtuel pour enregistrer les zones mémoire utilisées auprès du réseau physique et transférer ensuite les données sans copies intermédiaires (voir Figure 3.6). Puisque ce canal de communication sera uniquement utilisé pour des transferts de taille importante la latence induite par les chan- gements de contexte est moins problématique.

3.2.4.2 Cas des migrations

Migrer une machine virtuelle utilisant un périphérique Ethernet virtuel pour communiquer est relativement simple. La machine virtuelle peut simplement être détruite sur l’hôte source puis recréée dans le même état sur l’hôte de destination. Puisque le réseau Ethernet n’assure pas la fiabilité des données, les paquets qui sont envoyés à la machine virtuelle pendant la durée de la migration peuvent simplement être ignorés. Le protocole de niveau supérieur utilisé par les machines virtuelles, généralement TCP, se charge alors de retransmettre les paquets perdus. Nos choix de conception complexifient la gestion de la migration de machines virtuelles uti- lisant notre périphérique, et ce à deux niveaux. Tout d’abord, puisque nous assurons la fiabi- lité des communications, il est de la responsabilité de l’hôte de faire en sorte que les données transmises pendant les migrations soient correctement délivrées. Par ailleurs, dans le cas des communications en mémoire partagée, les machines virtuelles peuvent être amenées à direc- tement manipuler les files de réception de machines virtuelles co-hébergées, pour éviter les changements de contexte. Il faut donc s’assurer que les machines virtuelles ne sont pas mi- grées lorsqu’elles effectuent des opérations critiques afin de ne pas compromettre l’intégrité des données.

Avant chaque migration, l’hôte notifie toutes les machines virtuelles co-hébergées qu’une mi- gration va avoir lieu, par l’intermédiaire d’une interruption déclenchée par le périphérique virtuel. Elles doivent alors interrompre leur communications directes en mémoire partagée et en informer l’hôte. Lorsque toutes les communications en mémoire partagée sont stoppées, la migration peut avoir lieu et l’hôte notifie les machines virtuelles restantes que les communica- tions en mémoire partagée peuvent reprendre.

Pour assurer la fiabilité des transferts, nous utilisons une technique similaire, mais appliquée au niveau des communications entre les hôtes. Avant chaque migration, l’hôte source diffuse un message à tous les hôtes impliqués dans la grappe virtuelle afin de leur demander d’arrêter d’envoyer des données concernant la machine virtuelle qui va migrer. Une fois que tous les hôtes ont accusé réception de cette requête, la machine virtuelle est transférée vers son hôte de destination. Celui-ci diffuse alors la nouvelle adresse de la machine virtuelle ce qui permet aux communications la concernant de reprendre.

Cette technique à l’intérêt d’être indépendante du nombre de machines virtuelles mises en jeu, son coût dépendant uniquement du nombre d’hôtes utilisés par la grappe virtuelle. En outre, une fois qu’une machine virtuelle est prête à être migrée, on est assuré qu’il n’y a plus de données la concernant en transit. Cela signifie que l’on peut utiliser le même algorithme pour effectuer des protections reprises de grappes virtuelles. En effet, en demandant simultanément l’arrêt des communications pour toutes les machines virtuelles on s’assure qu’il n’y a plus au- cune donnée en cours d’envoi sur le réseau et que l’ensemble des machines virtuelles peuvent être sauvegardées dans un état cohérent.

3.3 Bilan

Dans ce chapitre, nous avons présenté plusieurs techniques destinées à l’exécution d’applica- tions parallèles virtualisées selon le paradigme du passage de messages. Nous proposons de les intégrer au sein d’un support exécutif capable d’embarquer efficacement chaque tâche dans sa machine virtuelle dédiée. Cet environnement permet de tirer profit de la flexibilité offerte par la virtualisation, notamment en terme de migrations de machines virtuelles, tout en minimisant les difficultés de mise en oeuvre ainsi que le coût en performance.

3.3. Bilan 79 Pour cela, nous avons tout d’abord introduit une opération de fork pour machines virtuelles permettant d’instancier très rapidement une grappe virtuelle. En outre, nous offrons la possibi- lité d’exécuter des applications depuis le système de fichiers hôte, avec des machines virtuelles légères, afin de rendre l’utilisation de la virtualisation la plus transparente possible. Pour finir, nous avons proposé un périphérique virtuel nouveau, à l’interface bien adaptée au passage de messages ente machines virtuelles. L’objectif est de pouvoir exploiter aussi efficacement les architectures à mémoire partagée – lorsque les machines virtuelles sont co-hébergées – que les réseaux rapides. Nous allons maintenant présenter les principaux points d’implémentation de ces diverses fonctionnalités, ainsi que d’une bibliothèque MPI basée sur notre périphérique virtuel.

Chapitre 4

Éléments d’implémentation

Sommaire

4.1 Intégration à l’hyperviseur Linux/KVM . . . 82

4.1.1 Architecture de KVM . . . 82