Étude bibliographique:
Transparence des communications réseau dans la migration à chaud de machines virtuelles entre
infrastructures de type cloud computing
Djawida DIB
Master informatique, spécialité Recherche en informatique Établissement: IFSIC, Université de Rennes 1
Encadrants: Pierre RITEAU et Christine MORIN
Équipe: Myriads, IRISA / INRIA Rennes - Bretagne Atlantique 27 janvier 2010
Table des matières
1 Introduction 2
2 Virtualisation et migration à chaud 3
2.1 Virtualisation . . . 3 2.2 Migration à chaud . . . 4 3 Problèmes réseau lors de la migration 5
4 Réseaux virtuels 6
4.1 État de l’art . . . 8 4.2 Classification des différents réseaux virtuels . . . 9 5 Prise en compte des schémas de communication pour la mi-
gration d’applications distribuées 11
6 Conclusion 11
1 Introduction
Le cloud computing ou encorel’informatique dans les nuages est un nou- veau concept dont les prémices remontent à la technologie des grilles de calcul, utilisée pour le calcul scientifique. Une grille de calcul est une fédé- ration de ressources informatiques hétérogènes (postes de travail, grappes de serveurs, ...), distribuées géographiquement et appartenant à différentes organisations. Les grilles informatiques permettent le calcul distribué à large échelle en exploitant un grand nombre de ressources.
Le cloud computing fait référence à l’utilisation des capacités de calcul des ordinateurs distants, où l’utilisateur dispose d’une puissance informa- tique considérable sans avoir à posséder des unités puissantes. L’utilisateur d’un cloud computing a l’impression d’avoir en permanence des ressources de calcul et/ou de stockage illimitées. Il peut donc adapter le niveau des ressources suivant la charge de ses applications. Les services qu’offre le cloud computing sont facturés proportionnellement à l’usage des infrastructures physiques (bande passante utilisée, caractéristiques des ressources) et à la période d’utilisation.
L’approche du cloud computing s’appuie principalement sur la virtualisa- tion, où la virtualisation est un ensemble de techniques permettant de faire fonctionner sur une seule machine plusieurs systèmes d’exploitation et/ou plusieurs applications, isolés les uns des autres. Un cloud est constitué d’un ensemble de machines virtuelles qui utilisent la même infrastructure phy- sique.
Les techniques de virtualisation permettent notamment la migration de machines virtuelles d’un nœud physique à un autre. 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.
La migration à chaud permet à un administrateur de débrancher une machine virtuelle d’une infrastructure physique donnée qui nécessite une maintenance sans soumettre les utilisateurs du système à un temps d’arrêt.
Un autre avantage de la migration est qu’elle permet d’améliorer la tolérance aux fautes. Si une défaillance imminente est suspectée, le problème peut être résolu avant l’interruption du service. La migration à chaud peut également être utilisée pour l’équilibrage de charge, afin d’optimiser l’utilisation des ressources CPU et de mieux gérer et économiser l’énergie.
Dans le cadre du clouds computing, les prix d’hébergement de machines virtuelles dans les clouds peuvent varier au fil du temps et d’un cloud à un autre, ce qui rend la migration des machines virtuelles entre clouds un véritable atout économique du point de vue de l’utilisateur.
Cependant les limitations de la migration à chaud s’inscrivent dans le cas où on souhaite déplacer une machine virtuelle d’un réseau à un autre ou d’un cloud à un autre, ce qu’on appelle lamigration inter-site. Dans ces cir- constances la machine virtuelle déplacée perd ses anciennes communications à cause de conflits d’adressage ou de problèmes de routage. Ce rapport traite cette problématique de migration inter-site.
Dans la suite de ce document, nous présentons la virtualisation et le pro- cessus de la migration à chaud dans la section 2. Ensuite, nous décrivons les problèmes des réseaux physiques lors de la migration des machines virtuelles en section 3. Les solutions actuelles à ces problèmes se fondent principale- ment sur les réseaux virtuels que nous détaillons en section 4. La section 5 introduit la notion de prise en compte des schémas de communication pour la migration d’applications distribuées que nous allons réaliser pendant le stage. Enfin, la section 6 conclut ce rapport bibliographique.
2 Virtualisation et migration à chaud
2.1 Virtualisation
La virtualisation est une technologie permettant l’exécution de plusieurs systèmes d’exploitation et/ou plusieurs applications sur le même ordinateur, ce qui accroît l’utilisation et la flexibilité du matériel.
Un même ordinateur peut ainsi permettre l’exécution de plusieurs ma- chines virtuelles contenant différents systèmes d’exploitation et/ou diffé- rentes applications isolées les unes des autres. La mise en œuvre d’une ma- chine virtuelle(virtual machine ou VM) nécessite l’ajout d’une couche logi- cielle à la machine physique. L’emplacement de cette couche dépend du type d’architecture de la machine virtuelle [1]. Il existe deux types de technolo- gies de machine virtuelle : les machines virtuelles applicatives(process virtual machines) et les machines virtuelles système(system virtual machines).
Dans une machine virtuelle applicative, la nouvelle couche logicielle s’ap- pelleruntime (abréviation deruntime software), et se place entre le système d’exploitation et les applications utilisateur. La machine virtuelle applicative est un programme qui émule dans un système d’exploitation un environne- ment standardisé, isolé et sécurisé. Cela permet au concepteur de l’applica- tion de ne pas avoir à rédiger plusieurs versions de son logiciel pour qu’il soit exécutable dans tous les environnements. La création et la terminaison de ce type de machine virtuelle se fait lors de la création et la terminaison du processus exécutant l’application virtualisée.
En revanche, dans une machine virtuelle système la nouvelle couche lo- gicielle se place entre le matériel et le système d’exploitation et s’appelle hyperviseur ou moniteur de machine virtuelle, en anglaishypervisor ou vir- tual machine monitor (VMM). Une machine virtuelle système fournit un environnement complet qui a son propre système d’exploitation.
Le système d’exploitation qui s’exécute dans une machine virtuelle sys- tème est appeléinvité, en anglaisguest, tandis que la plat-forme sous-jacente qui supporte la machine virtuelle est l’hôte, en anglaishost. Une machine vir- tuelle système offre une copie du matériel et se comporte exactement comme un ordinateur physique contenant ses propres CPU, mémoire RAM, disque dur et cartes d’interface réseau virtuels. En conséquence, le système d’ex- ploitation invité est généralement incapable de faire la différence entre une machine virtuelle et une machine physique.
Dans ce qui suit, nous nous intéressons principalement aux machines vir- tuelles système, car elles offrent certains avantages par rapport aux machines virtuelles applicatives tels que : un support avancé de la migration, ainsi que le support de l’exécution d’applications patrimoniales (legacy application).
Ainsi un environnement d’exécution ne requiert pas de modification pour être exécuté sur une machine virtuelle système.
Il existe deux types d’architecture de machine virtuelle système [2]. Dans le type I le VMM se trouve directement au-dessus de la couche matérielle.
Au-dessus du VMM se trouvent les différentes VMs. Sur une de ces VMs s’exécute le système d’exploitation(Operating System ouOS) de la machine hôte qui gère le partage des ressources entre les autres VMs. Les autres VMs exécutent des OS moins privilégiés. Cette architecture est utilisée notamment par Xen [3].
Dans le type II, c’est l’OS de la machine hôte qui se trouve directe- ment sur la couche matérielle. Au-dessus de celui-ci le VMM prend place.
Au-dessus du VMM se trouve les OS invités des différentes VMs. Cette ar- chitecture est utilisée par des hyperviseurs tel que VMware Workstation[4], KVM [5] ou VirtualBox [6].
2.2 Migration à chaud
La migration à chaud permet de déplacer une machine virtuelle d’un nœud physique à un autre sans interruption de service et doit être tota- lement transparente pour l’utilisateur. Le processus de migration à chaud d’une machine virtuelle d’un hôte source vers un hôte de destination se com- pose de six étapes principales [7] [8] :
1. 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.
2. 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.
3. 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 re- gistres processeur ainsi que l’état des périphériques à la machine de destination. Une fois cette copie terminée, la VM cible est une copie parfaite de la VM source.
4. Redirection
L’hôte de destination indique à l’hôte source qu’il a correctement reçu l’image de la VM.
5. Activation de la machine virtuelle
La machine virtuelle migrée est activée et peut continuer son exécution.
6. Mise à jour des informations réseau
Un message est envoyé au switch physique pour mettre à jour la table ARP. Les paquets à destination de la machine virtuelle ne passent plus par le même port physique.
3 Problèmes réseau lors de la migration
Dans cette section, nous définissons les problèmes réseau concernant la migration des machines virtuelles d’un cloud à un autre et qui font partie de 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 on suppose que toutes les VMs d’une grappe, qui communiquent entre elles, se trouvent sur le même cloud (Figure 1).
Ensuite pour les raisons mentionnées dans l’introduction, on peut avoir besoin de migrer certaines VMs de la grappe sur un autre cloud. Nous consi- dérons trois cas problématiques. Le premier cas est le fait de migrer seulement
Figure 1 – L’état initial du réseau virtuel.
une partie des VMs qui communiquent entre elles (Figure 2). Le deuxième cas consiste à migrer la grappe virtuelle complète (Figure 3). Enfin le troisième cas considère la migration d’une VM qui communique avec un utilisateur extérieur, ne faisant pas partie de la grappe (Figure 4).
Figure2 – Migration d’une partie de la grappe du cloud A vers le cloud B.
Dans les trois cas cités ci-dessus la communication s’interrompt, car les adresses IP des VMs ne sont plus valides. Non seulement la recherche d’un moyen pour résoudre ce problème est nécessaire, mais en plus il faut s’as- surer que les performances soient optimales. Par exemple, si les machines VM 2 et VM 3 de la Figure 2 veulent communiquer, elles doivent utiliser l’infrastructure physique du cloud B sans passer par le cloud A.
L’approche de réseaux virtuels représente un outil très puissant pour résoudre ces différents problèmes.Nous détaillons ce concept dans la section suivante.
4 Réseaux virtuels
Le succès des réseaux privés virtuels(Virtual Private Networks ou VPN) [9] a donné naissance au concept de réseaux virtuels (Virtual Network ou
Figure3 – Migration de la grappe toute entière du cloud A vers le cloud B.
Figure 4 – Migration d’une machine virtuelle qui communique avec un utilisateur de l’extérieur.
VN). Les réseaux virtuels prennent de plus en plus place dans la commu- nauté 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 [10].
La virtualisation réseau consiste à virtualiser à la fois les noeuds et les liens. La virtualisation des nœuds est fondée sur l’isolation et le partitionne- ment des ressources du nœud physique. D’autre part, chaque lien physique peut transporter plusieurs liens virtuels. L’interconnexion de ces noeuds vir- tuels et liens virtuels permet la création d’un réseau virtuel.
Outre l’avantage technique des réseaux virtuels qui permettent d’optimi- ser l’utilisation des infrastructures physiques et de mieux les gérer, ce concept a également des intérêts commerciaux. Par exemple le partage d’une infra- structure physique entre différents opérateurs réseaux réduit considérable- ment le coût de propriété.
4.1 État de l’art
Différentes architectures de réseaux virtuels ont été proposées : Violin [11], ViNe [12], SoftUDC VNET [13], Virtuos VNET [14], PVC [15], N2N [16], OCALA [17] et IPOP [18].
La majorité des réseaux virtuels cités ci-dessus s’appuient sur des réseaux overlay. Les réseaux overlay sont des réseaux décentralisés, distribués, sans organisation hiérarchique, où tous les noeuds, appeléspairs, jouent à la fois le rôle de serveur et de client. L’organisation dans un tel réseau repose sur l’ensemble des pairs, il n’y a pas d’entité chargée d’administrer ce type de réseau. Ces réseaux overlay sont utilisés pour construire une infrastructure de réseau virtuel permettant la communication au niveau 2 (Ethernet) ou au niveau 3 (IP).
ViNe (Virtual Network) [12] est un réseau virtuel pour les grilles dont l’architecture est fondée sur un overlay niveau IP. Un espace d’adressage virtuel est alloué pour chaque réseau physique qui souhaite joindre la grille, afin de permettre l’identification de ses hôtes. ViNe supporte de multiples VNs indépendants dans la même infrastructure physique, et il est facilement configurable pour l’ajout des ressources à la grille. Cependant, la migration n’est pas mentionnée.
OCALA(Overlay Convergence Architecture for Legacy Applications)[17]
est un réseau virtuel permettant un accès simultané à de multiples overlay et donne la possibilité aux hôtes des différents overlay de communiquer entre eux. OCALA impose une coucheOverlay Convergence (OC) entre la couche transport et la couche réseau. La couche OC remplace la couche IP d’Internet et se compose de deux sous-couches :OC-I, une sous-couche indépendante des overlay utilisés etOC-D, une sous-couche dépendante d’un overlay particu- lier. La reconfiguration (ajout et suppression des ressources) et la migration ne sont pas discutées dans cette architecture.
IPOP (IP-over-P2P) [18] est un réseau virtuel P2P, son architecture est fondée également sur un overlay. Dans un système P2P chaque nœud a deux façons d’être adressé : à travers la couche réseau avec une adresse IP, et à travers l’overlay via les adresses P2P. Les adresses IP des machines sont utilisées uniquement pour rejoindre l’overlay et créer les connections du réseau pair à pair ; les adresses P2P sont utilisées lorsque les communications se font à travers l’overlay. IPOP utilise les adresses P2P pour les messages de routage et une table de hachage produite par le système pair à pair ce qui lui permet de supporter une allocation d’adresse distribuée (statique ou dynamique). IPOP supporte l’ajout dynamique de nouvelles ressources, et permet une migration transparente pour les réseau étendus.
VIOLIN (Virtual Interconnecting on Overlay Infrastructure) [11] est un réseau virtuel au-dessus de l’infrastructure overlay qui a son propre espace d’adressage. VIOLIN améliore la virtualisation des réseaux et conduit à l’iso- lation entre un réseau VIOLIN et le réseau IP sous-jacent. Toutes les entités de VIOLIN sont hébergées par les hôtes de l’infrastructure overlay, et il est possible de répéter cette virtualisation plusieurs fois, un Violin niveau-n peut être crée au-dessus d’un VIOLIN niveau-(n-1), sachant que le niveau-0 re- présente l’internet réel. VIOLIN est entièrement reconfigurable et permet l’ajout, la suppression et la migration à la demande.
Le réseau virtuel PVC(Private Virtual Cluster) [15] est conçu pour éta- blir dynamiquement des grappe virtuelles à travers les ressources connectées à Internet. Un de ses objectifs est de permettre l’exécution d’applications grappe, sans aucune modification. Les applications grappes utilisent en gé- néral le modèle de socket comme interface de communication réseau, ce qui explique l’utilisation de la couche IP comme domaine de virtualisation par le réseau virtuel PVC.
Virtuoso VNET [14] est un simple réseau virtuel de couche 2 qui s’appuie sur le VMM pour extraire et injecter les paquets Ethernet transmis par la carte réseau virtuelle. Les mécanismes utilisés sont les filtres de paquets et les sockets de paquets. VNET donne illusion à l’utilisateur qu’il est dans son propre réseau local (Local Area Network). Virtuoso VNET utilise un intergiciel nomméVirtuoso pour les machines virtuelles des grilles de calcul.
Cette architecture de réseau virtuel est reconfigurable et permet la migration des machines virtuelles d’un nœud physique à un autre.
De même, SoftUDC VNET [13] permet aux domaines d’application et d’administration de partager les mêmes ressources physiques en maintenant la fonctionnalité d’isolation. La caractéristique principale de SoftUDC est sa virtualisation au niveau des serveurs, des réseaux et des ressources de stockage. La migration dans SoftUDC est possible mais elle n’est pas discutée pour les réseaux étendus.
N2N (Network To Netwotk) [16] est un réseau privé virtuel pair à pair de couche 2 complètement décentralisé. Les applications VPN existantes peuvent utiliser N2N sans modification. La migration n’est pas discutée pour cette architecture.
Le tableau 1 résume les caractéristiques des réseaux virtuels étudiés.
4.2 Classification des différents réseaux virtuels
Nous distinguons principalement deux types de réseaux virtuels, les ré- seaux virtuels stables et les réseaux virtuels reconfigurables.
Configuration Niveau d’application Migration
Violin Reconfigurable Overlay Migration à
(Niveau application) la demande
ViNe Reconfigurable Overlay Migration non
(Niveau IP) mentionnée SoftUDC VNET Reconfigurable Ethernet Migration possible
mais pas discutée pour les réseaux
étendus.
Virtuoso VNET Reconfigurable Couche 2 Migration possible IPOP Reconfigurable Overlay (P2P) Migration possible
PVC Non reconfigurable IP Migration non
(stable) discutée
N2N Reconfigurable Couche 2 : Ethernet Migration non discutée OCALA Non mentionné Overlay Convergence Migration non
(OC) entre la couche discutée réseau et la couche
transport.
Table 1 – Comparaison des réseaux virtuels étudiés
Un réseau virtuel stable utilise les mêmes liens et les mêmes noeuds pendant toute sa durée de vie, et donc sa topologie ne change pas. L’ad- ministrateur d’un réseau virtuel stable doit réserver toutes les ressources nécessaires pour effectuer ses tâches à la configuration initiale. Les réseaux virtuels stables sont peu adaptés à la migration dynamique entre clouds car ils nécessitent de prévoir l’architecture complète du réseau dès sa création.
En revanche, la topologie d’un réseau virtuel reconfigurable peut chan- ger en fonction des ressources disponibles sur les infrastructures physiques utilisées, afin d’améliorer les performances ou de réduire le coût d’utilisa- tion. Les réseaux virtuels reconfigurables suscitent beaucoup d’intêrets car ils permettent de résoudre les problèmes de migration inter-site cités dans la section 3.
5 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 pro- cessus 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, par exemple en utilisant MPI (Message Passing Interface), ou en utilisant d’autres mécanismes.
Les applications distribuées peuvent avoir des schémas de communica- tion différents. Par exemple, dans l’application CG des NAS Parallel Bench- marks [19], les nœuds forment des groupe de communication. 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.
Pour réaliser une migration tenant compte de ces schémas de commu- nication, il serait possible d’analyser 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. Par exemple, pour l’application CG, il faudrait faire en sorte de migrer uniquement des groupes de communication complets.
6 Conclusion
Dans cette étude, nous avons montré que la migration à chaud, permise par l’utilisation de technologies de virtualisation dans les infrastructures de
type cloud computing, présentent un intérêt important. Nous nous sommes intéressés aux avantages présentés par la migration à chaud de machines virtuelles entre clouds.
Nous avons indiqué les problèmes importants qui se posent dans le contexte de la migration à chaud entre réseaux physiques distincts. Ces problèmes se rencontrent lors de la migration à chaud de machines virtuelles entre clouds et provoquent la perte des communications en cours à cause de conflits d’adres- sage ou de problèmes de routage.
Nous avons étudié les différents systèmes permettant de résoudre ces problèmes réseaux. Ces systèmes permettent la création de réseaux virtuels, en se fondant sur l’utilisation de réseaux overlay pair-à-pair.
Enfin, nous avons introduit la présence de schémas de communication entre processus d’une application distribuée. Afin de garantir un bon niveau de performances, ces schémas de communication doivent être pris en compte lors de la migration à chaud de machines virtuelles.
Durant ce stage, nous nous intéresserons à la problématique de migration à chaud de machine virtuelles entre différentes infrastructures de type cloud computing, et plus précisément à la transparence des communications réseau.
Nous commencerons par tester les mises en œuvre de quelques solutions existantes permettant de migrer une grappe virtuelle complète ou une sous- partie d’une grappe d’un cloud à un autre sans perte de connectivité réseau entre toutes les machines de la grappe. À partir de l’étude de ces solutions, un prototype sera réalisé et évalué sur Grid’5000. Enfin, nous mettrons en œuvre un système de migration dynamique de machines virtuelles respectant les schémas de communication, qui sera validé avec le prototype réalisé.
Références
[1] James E. Smith and Ravi Nair. The architecture of virtual machines.
Computer, 38(5) :32–38, 2005.
[2] R. P. Goldberg. Architecture of virtual machines. InProceedings of the workshop on virtual computer systems, pages 74–112, New York, NY, USA, 1973. ACM.
[3] Paul Barham, Boris Dragovic, Keir Fraser, Steven Hand, Tim Harris, Alex Ho, Rolf Neugebauer, Ian Pratt, and Andrew Warfield. Xen and the art of virtualization. In SOSP ’03 : Proceedings of the nineteenth ACM symposium on Operating systems principles, pages 164–177, New York, NY, USA, 2003. ACM.
[4] http ://www.vmware.com/.
[5] Avi Kivity, Yaniv Kamay, Dor Laor, Uri Lublin, and Anthony Liguori.
kvm : the Linux Virtual Machine Monitor. In Proceedings of the 2007 Linux Symposium, volume 1, pages 225–230, June 2007.
[6] http ://www.virtualbox.org/.
[7] Christopher Clark, Keir Fraser, Steven Hand, Jacob Gorm Hansen, Eric Jul, Christian Limpach, Ian Pratt, and Andrew Warfield. Live migration of virtual machines. In NSDI’05 : Proceedings of the 2nd conference on Symposium on Networked Systems Design & Implementation, pages 273–286, Berkeley, CA, USA, 2005. USENIX Association.
[8] Michael Nelson, Beng-Hong Lim, and Greg Hutchins. Fast transpa- rent migration for virtual machines. In ATEC ’05 : Proceedings of the annual conference on USENIX Annual Technical Conference, Berkeley, CA, USA, 2005. USENIX Association.
[9] http ://www.frameip.com/vpn/.
[10] Jorge Carapinha and Javier Jiménez. Network virtualization : a view from the bottom. InVISA ’09 : Proceedings of the 1st ACM workshop on Virtualized infrastructure systems and architectures, pages 73–80, New York, NY, USA, 2009. ACM.
[11] Xuxian Jiang Dongyan. Violin : Virtual internetworking on overlay infrastructure, 2003.
[12] M. Tsugawa and J.A.B. Fortes. A virtual network (vine) architecture for grid computing. Parallel and Distributed Processing Symposium, International, 0 :123, 2006.
[13] Mahesh Kallahalla, Mustafa Uysal, Ram Swaminathan, David E. Lo- well, Mike Wray, Tom Christian, Nigel Edwards, Chris I. Dalton, and Frederic Gittler. Softudc : A software-based data center for utility com- puting. Computer, 37(11) :38–46, 2004.
[14] Ananth I. Sundararaj, Ashish Gupta, and Peter A. Dinda. Dynamic to- pology adaptation of virtual networks of virtual machines. InLCR ’04 : Proceedings of the 7th workshop on Workshop on languages, compilers, and run-time support for scalable systems, pages 1–8, New York, NY, USA, 2004. ACM.
[15] Ala Rezmerita, Tangui Morlier, Vincent Néri, and Franck Cappello. Pri- vate virtual cluster : Infrastructure and protocol for instant grids. In Euro-Par 2006 Parallel Processing, pages 393–404, 2006.
[16] Luca Deri and Richard Andrews. N2n : A layer two peer-to-peer vpn.
InAIMS ’08 : Proceedings of the 2nd international conference on Auto-
nomous Infrastructure, Management and Security, pages 53–64, Berlin, Heidelberg, 2008. Springer-Verlag.
[17] Dilip Joseph, Jayanth Kannan, Ayumu Kubota, Karthik Lakshmina- rayanan, Ion Stoica, and Klaus Wehrle. Ocala : An architecture for supporting legacy applications over overlays. InIn NSDI, 2006.
[18] David Isaac Wolinsky, Yonggang Liu, Pierre St. Juste, Girish Venkata- subramanian, and Renato Figueiredo. On the design of scalable, self- configuring virtual networks. In SC ’09 : Proceedings of the Confe- rence on High Performance Computing Networking, Storage and Ana- lysis, pages 1–12, New York, NY, USA, 2009. ACM.
[19] Rolf Riesen. Communication patterns [message-passing patterns].
In 20th International Parallel and Distributed Processing Symposium (IPDPS 2006), 2006.
