Laboratoire de l Informatique du Parallélisme. École Normale Supérieure de Lyon Unité Mixte de Recherche CNRS-INRIA-ENS LYON-UCBL no 5668

Transcription

1 Laboratoire de l Informatique du Parallélisme École Normale Supérieure de Lyon Unité Mixte de Recherche CNRS-INRIA-ENS LYON-UCBL no 5668 Virtual Clusters Rima Ben Mosbah Encadrée par Novembre 2006 Pascale Primet Rapport de Master 2 Informatique Fondamentale École Normale Supérieure de Lyon 46 Allée d Italie, Lyon Cedex 07, France Téléphone : +33(0) Télécopieur : +33(0) Adresse électronique : lip@ens-lyon.fr

2 Virtual clusters Rima Ben Mosbah Encadrée par Pascale Vicat-Blanc Primet Novembre 2006 Résumé Le modèle d'architecture des grilles repose sur une vision qui consiste à distribuer la puissance de calcul et plus généralement les ressources, afin d'exploiter au mieux les applications. Cependant, la plupart des plateformes Grid actuelles ne supportent pas l isolation de performances, ce qui ne leur permet pas d assurer les exigences de l utilisateur en termes de qualités de services. Ce problème peut être résolu en permettant aux clients autorisés des Grilles de déployer des clusters virtuels établis par des machines virtuelles configurées pour répondre à leurs besoins en termes de matériels et de logiciels. Toutefois, les clusters virtuels doivent passer à l'échelle en résolvant plusieurs problèmes relatifs aux ressources physiques et virtuels. Notamment, ils assurent la correspondance ou mapping entre ressources virtuelles et physiques, l ordonnancement et la réservation des ressources en minimisant l overhead de la virtualisation. Mots clés: Grille, clusters virtuels, virtualisation, machine virtuelle, VMM, ordonnancement, réservation, overhead

3 Table des matières 1 Introduction 3 2 Spéci cation Présentation du système Les exigences du système Gestion des données Gestion des ressources Interconnexion virtuelle Overhead des machines virtuelles Considérations de performance Classi cation Modélisation Les composants du système Formalisation du problème de mapping Résolution L ordonnancement et l allocation des ressources Les étapes de l ordonnacement Dé nition formelle Réservation Contexte Quelques dé nitions Réservations Conclusion Solutions existantes Virtuoso Violin Cluster On Demand (COD) HIPernet Conclusion Conclusion 27 A Installation de XEN 29 1

4 Table des gures 2.1 Spéci cation du problème Modélisation du système Graphe des hôtes Mapping des VMs Architecture de Virtuoso Mécanisme de Violin

5 Chapitre 1 Introduction Une grille informatique ou Grid est une infrastructure virtuelle constituée d un ensemble coordonné de ressources informatiques potentiellement partagées, distribuées, hétérogènes, externalisées et sans administration centralisée [7]. De ce fait, les technologies Grid facilitent l allocation de ressources aux applications dynamiquement. Toutefois les grilles n assurent pas les exigences de l utilisateur en termes de qualités de services. Parmi les problèmes que rencontrent les communautés Grid actuellement est que bien qu ils fournissent un accès à plusieurs ressources hétérogènes, celles disponibles ne répondent pas souvent aux besoins d une application ou un service spéci que. Ces problèmes peuvent être résolus en permettant aux clients autorisés des Grilles de déployer des clusters virtuels établis par des machines virtuelles con gurées pour s adapter aux environnements logiciels et aux demandes d allocations de matériels des clients. En e et, nous parlons de cluster pour désigner des techniques consistant à regrouper plusieurs ordinateurs indépendants pour permettre une gestion globale et dépasser les limitations d un ordinateur pour augmenter la disponibilité, faciliter la montée en charge, permettre une répartition de la charge, faciliter la gestion des ressources (CPU, mémoire, disques, bande passante réseau). En particulier, un cluster virtuel est un groupe de machines virtuelles ou physiques con gurées pour un but commun, avec des comptes et des ressources de stockage pour les utilisateurs, un environnement logiciel spéci que à un chaque utilisateur, un bloc privé d adresse IP et un domaine de nommage DNS. Toutefois, les clusters virtuels doivent passer à l échelle en résolvant plusieurs problèmes relatifs aux ressources physiques et virtuelles, notamment la correspondance ou mapping entre ces deux niveaux d abstraction. 3

6 Chapitre 2 Spéci cation 2.1 Présentation du système Les machines virtuelles fournissent une nouvelle couche d abstraction dans les environnements de calcul distribué. En e et, si les contrôleurs de machines virtuelles sont déja disponibles, il serait possible de déployer des VMs (machines virtuelles) comme des unités statiques de calcul avec des middlewares de grilles. Le middleware désigne les logiciels servant d intermédiaire entre d autres logiciels. On l utilise généralement comme intermédiaire de communication entre des applications complexes, distribuées sur un réseau informatique. De plus, il masque la complexité des échanges inter-applications. Par conséquent, on aura deux niveaux d abstractions : le niveau physique et le niveau virtuel interliés par un middleware(figure 2.1). Le niveau physique est formé par les noeuds physiques de la grille. C est le niveau où les machines virtuelles sont instanciées. Le niveau virtuel correspond aux machines virtuelles provenant des machines physiques. C est le niveau où les applications prennent place. Le middleware permet de relier les deux niveaux et de déployer les machines virtuelles(vcm dans COD [6] et VNET dans Virtuoso [2]). La section suivante présente les exigences d un tel système (machines virtuelles, machines physiques et middleware) et les techniques possibles qui permettent de déployer un modèle dynamique virtuel et de l intégrer avec les solutions des middlewares grid existantes. 2.2 Les exigences du système Gestion des données La gestion des données est une technologie clé pour les grilles de calcul basées sur les VMs, permettant un découplage administratif des fournisseurs de calcul et des utilisateurs d une part. D autre part, cette gestion implique le transfert des images des VMs a n qu elles puissent être instanciées n importe où et migrées si c est nécessaire. De plus, elle supporte un accès indépendant de la location aux chiers des utilisateurs. 4

7 2. Spéci cation 5 Niveau virtuel Middleware Niveau physique Fig. 2.1 Spéci cation du problème En e et, avec un support approprié de gestion de données, le calcul, l état et les données des utilisateurs peuvent résider dans di érents domaines. Transfert de données haute performance Les machines virtuelles supportent une abstraction logique du compte utilisateur. En e et, les VMs invitées dédiées peuvent être attribuées par utilisateur. Les identités des utilisateurs au sein d une VM invitée sont complètement découplées des identités de leurs VMs hôtes. De plus, les machines virtuelles fournissent un environnement où les applications et les OS peuvent être déployés en incluant des services comme les systèmes de chiers virtuels. En d autres termes, les VMs fournissent une couche d abstraction qui supporte les utilisateurs logiques et les systèmes de chiers virtuels. On pourra donc utiliser ces mécanismes d accès haute performance aux images et aux données des utilisateurs Gestion des ressources Les VMs fournissent une nouvelle couche d abstraction dans des environnements de calcul distribués. Cette couche crée de nouvelles opportunités et challenges pour l ordonnancement et la gestion de ressources de la perspective des ressources et celle des applications. Perspective des ressources Dans la perspective des ressources de calcul et de communication qui cherchent les applications, les machines virtuelles fournissent un mécanisme pour contrôler soigneusement comment et quand les ressources sont utilisées, ce qui est important. En

8 2. Spéci cation 6 e et, les propriétaires des ressources sont loin de permettre aux autres d utiliser les ressources, ou de leur donner l accès, s ils ont tel contrôle. Alors qu il existe d autres mécanismes pour fournir un tel contrôle, ils imposent une interface de software système particulière ou des modèles de calcul chez l utilisateur. D autre part, les VMs sont simples et directes, c est-à-dire l utilisateur obtient une "raw" machine sur laquelle il peut tourner tout ce qu il veut. Le propriétaire de ressources à son tour ne voit qu une seule entité à ordonnancer sur ses ressources. Perspective de l application Pour achever une performance appropriée dans un environnement de calcul distibué, les applications doivent typiquement s adapter aux propriétés statiques et dynamiques de la ressource disponible. Les VMs simpli ent ce processus en permettant à l application d apporter ses environnements d exécution. Cependant, la complexité est introduite dans d autres cotés. D une part, les machines virtuelles sont elles même une nouvelle ressource, augmentant ainsi le pool de ressources à considérer. D autre part, les machines virtuelles représentent des collections de partage dans les ressources physiques soujacentes. Par conséquent, pour prédire des performances dans une machine virtuelle particulière ou un groupe de machines virtuelles, l application doit comprendre la mapping et l ordonnancement des ressources virtuelles dans les ressources physiques soujacentes, ou bien il doit y avoir un service qui fait ça pour elle Interconnexion virtuelle Le contrôleur de machines virtuelles peut créer une machine virtuelle. Celle-ci doit être capable de se connecter au réseau accessible par une grille de calcul. Par ailleurs, contrairement au processus tournant dans la machine physique soujacente, la machine virtuelle apparaît au réseau comme étant une ou plusieurs nouvelles interfaces de cartes réseau. Par conséquent, deux scénarios sont possibles : 1. La VM possède une provision d adresses IP qui peuvent être attribuées aux instances dynamiques des VMs. Dans ce scénario, la VM peut obtenir une adresse IP dynamiquement du réseau du hôte (via DHCP). Cette dernière pourra être utilisée par le middleware pour référencier la VM pour la durée de la session. 2. La VM hôte ne fournit pas d adresses IP aux instances des VMs. Dans ce scénario, les techniques de virtualisation du réseau, similaires a VPN [13] (Virtual Private Network), peuvent être appliquées pour attribuer une identité réseau à la VM dans le site de l utilisateur. L approche la plus simple est de tunneliser le tra c au niveau Ethernet, entre les machines virtuelle distantes et le réseau local de l utilisateur. De cette manière, la machine distante apparaîtra connectée au réseau local. Dans ce cas, ça sera facile pour l utilisateur d avoir une adresse attribuée. Si on pourrait établir une connexion TCP au site distant, on pourra l utiliser pour le tunneling. Par exemple, si on utilise SSH pour démarrer une machine, on pourra utiliser les outils de tunneling de SSH. En e et, une extension naturelle à ce simple VPN, dans lequel tous les hôtes distants apparaissent dans le réseau local, permet d établir un réseau overlay parmi les machines virtuelles

9 2. Spéci cation 7 distantes. Le réseau overlay s optimisera en respectant les communications entre les machines virtuelles et les limitations des sites variés sur lesquels elles tournent. 2.3 Overhead des machines virtuelles Un système d exploitation moderne utilise la multiprogrammation, une mémoire virtuelle et des systèmes de chiers pour partager le processeur, la mémoire et les ressources du disque parmi plusieurs processus et utilisateurs. Chaque processus accède aux ressources physiques indirectement, à travers les absractions fournies par le système d exploitation. A la même époque de développement de ces mécanismes, il y avait une autre méthode de partage de ressources, qui est les machines virtuelles. Une machine virtuelle présente une vue dupliquée d une machine physique soujacente, au software qui tourne dedans. Ainsi, plusieurs systèmes d exploitations peuvent exécuter simultanément et multiplexer des ressources dans un ordinateur, processeur, mémoire disque ou réseau. Cette section présente les performances d une instance VM pour les applications scienti ques de calcul intensif Considérations de performance Les avantages des machines virtuelles sont négligeables si elles ne peuvent pas délivrer des performances e caces. Les contrôleurs de machines virtuelles génèrent des overheads de performance quand les applications à travers une VM exécutent des instructions privilégiées qui doivent être émulées. Typiquement, ces overheads sont issus du code du kernel invité durant les appels systèmes, le traitement de la mémoire virtuelle, le changement de contexte et les entrées/sorties. Par ailleurs, un code de niveau utilisateur dans les VMMs s exécute directement dans le materiel sans translation d overhead. L overhead total induit par les VMs dépend alors des caractéristiques du système, incluant l architecture et l implémentation du VMM et le type de la charge du travail qui tourne dans le système. Le domaine d application du calcul intensif est très important dans les grilles de calcul qui supportent des communités d utilisateurs comme des architectures d ordinateurs et des simulations de dispositifs à états solides. Dans d autres domaines d application, où le système et l activité d entrée/sortie est plus fréquente, l impact de la performance d un VMM peut être plus important. Cependant, des expériences précédentes avec des architectures VMMs réussies ont montré qu un tel overhead peut être réduit avec des optimisations d implémentations. Par ailleurs, le chargement du background engendre des overheads qui n existaient pas dans la machine physique. D abord, les switchs anticipent le VMM quand le chargement est appliqué à la machine physique. Ensuite, les switchs du contexte invité induisent l exécution d instructions privilégiées qui sont émulées par le VMM quand le chargement est appliqué à la machine virtuelle. Le résultat principal est que, indépendemment du chargement, les taches de test subissement un ralentissement typique de 10% ou moins dans le cas où elles tournent dans des machines virtuelles.

10 2. Spéci cation Classi cation Le VMM doit être capable d exporter une interface hardware au software dans une machine virtuelle qui soit à peu près équivalente au raw hardware, maintient simultanément le contrôle de la machine et retient la capacité d interposer dans l accès hardware. Plusieurs techniques peuvent aider pour acquérir ce but. Ces techniques o rent di érents modèles d échange. En évaluant ces échanges, les buts de ce modèles de VMMs sont la compatibilité, la performance et la simplicité. La compatibilité est clairement importante à cause de la capacité du VMM à touner des softwares légaux. Le but de la performance, qui est une mesure de l overhead de la virtualisation, est de tourner la machine virtuelle avec la même vitesse que le software pourrait trouver dans une machine réelle. La simplicité est particulièrement importante. En e et, une panne au VMM pourrait engendrer une panne dans toutes les machines virtuelles qui tournent dans l ordinateur. En particulier, fournir une isolation sécurisée requiert que le VMM soit sans bugs. Le software de virtualisation peut être appliqué de di érentes manières pour connecter et adapter les trois composants majeurs du système. L émulation ajoute une exibilité importante. De plus, il peut améliorer l émulation avec l optimisation, en prenant l information spéci que à l implémentation en considération comme elle lui fournit l émulation, ou l optimisation toute seule sans émulation. Par ailleurs, le software de virtualisation peut aussi fournir la réplication de ressources. Par exemple, en donnant l apparance de multiples plateformes à une seule plateforme hardware, chacune d elles sera capable de tourner un OS complet et/ou un ensemble d applications. Finalement, les types variés de machines virtuelles peuvent être composés pour former une large variété d architectures, libérées de plusieurs contraintes traditionnelles de compatibilité.

11 Chapitre 3 Modélisation 3.1 Les composants du système Machine physique : On parle de machine physique pour désigner un ordinateur indépendant qui peut être personnel ou serveur. Cette machine est caractérisée par son processeur, sa mémoire, son disque et son temps CPU. Lien physique : Au niveau du cluster, les noeuds peuvent être interconnectés par Ethernet. Ce lien entre deux noeuds physiques est caractérisé par la latence et la bande passante entre eux. Utilisateur : L utilisateur est un client qui fait une demande pour former un cluster virtuel. Cluster physique : On parle de cluster pour désigner des techniques consistant à regrouper plusieurs ordinateurs indépendants (ensemble d ordinateurs personnels ou de serveurs), reliés par un réseau ultra rapide, mutualisant des ressources uniques (périphériques, chiers, bases de données, etc.). Généralement, le contrôle de l ensemble est con é à l une des machines. Machine virtuelle : Le sens de machine virtuelle est la création de plusieurs environnements d exécution sur un seul ordinateur, dont chacun émule l ordinateur hôte. Cela fournit à chaque utilisateur l illusion de disposer d un ordinateur complet alors que chaque machine virtuelle est isolée des autres. Le logiciel hôte qui fournit cette fonctionnalité est souvent dénommé superviseur ou hyperviseur (exemple : XEN[4], VMWare[12], UML[9]). Ce concept va plus loin que celui des simples temps partagés où chaque utilisateur dispose seulement d un espace de développement personnel, et non d une machine simulée entière. La machine virtuelle est également caractérisée par son processeur, sa mémoire, son disque et son temps CPU. Lien virtuel : Au niveau du cluster virtuel, les instances virtuelles peuvent avoir des liens virtuels entre eux et communiquer. Ces liens sont caractérisés par la latence et la bande passante entre les noeuds virtuels. Cluster virtuel : Un cluster virtuel est un groupe de machines virtuelles con gurées pour un but commun, avec des comptes et des ressources de stockage pour utilisateurs, un environnement logiciel spéci que à chaque utilisateur, un bloc privé d adresse IP et un domaine de nommage DNS. 9

12 3. Modélisation 10 Machine physique Machine virtuelle Lien physique Lien virtuel Middleware pour création de machines virtuelles Middleware pour création de clusters virtuels Utilisateur WAN Fig. 3.1 Modélisation du système La gure 3.1 illustre les liens entre les di érents composants du système. En e et, l utilisateur fait sa demande pour former un cluster virtuel à travers un middleware qui est souvent sous forme d une interface comme Virtuoso [2]. Il spéci e le nombre de machines virtuelles qu il souhaite avoir ainsi que tous leurs caractéristiques. Ces machines virtuelles sont formées à partir des machines physiques par le biais d un middleware approprié. Par conséquent, plusieurs problématiques surgissent comme la sécurité, le problème de nommage et le mapping entre ressources physiques et virtuelles. La section suivante expose le problème de mapping. 3.2 Formalisation du problème de mapping Dans cette partie, nous allons exposer le problème de mapping entre machines virtuelles et machines physiques dans le but de maximiser la capacité de traitement de l application. Le middleware contrôlant le réseau soujacent peut être représenté par un graphe orienté G = (H; E) avec : H : noeuds physiques (hôtes capables de supporter plus qu une machine virtuelle) E : les liens possibles Ce graphe peut ne pas être complet étant donné que certains liens peuvent ne pas être possibles à cause d une gestion particulière du réseau et des contrats de sécurité dans di érents sites [3]. En e et, un graphe est dit complet si pour toute paire de sommets (x ; y), il existe au moins un arc de la forme (x ; y) ou (y ; x). Le graphe

13 3. Modélisation 11 expose également des estimations de la bande passante disponible et les latences à travers chaque lien dans le graphe de topologie. Ces estimations sont décrites par une fonction de bande passante : bp : E! R et une fonction de latence : lat : E! R: D autre part, le middleware collecte des informations sur la capacité de l espace mémoire (en bytes) et la capacité de calcul disponibles pour chaque hôte. Ces informations sont décrites par une fonction de calcul de capacité du hôte : calcul : H! R et une fonction de taille de l espace mémoire : taille : H! R:(Figure 3.2) calcul 2 taille 2 calcul 1 taille 1 bp 12 H 2 bp 24 lat 24 bp 14 lat calcul 4 14 H H 4 1 taille 4 bp 13 lat 12 lat 13 lat 34 H 3 bp 34 calcul 3 taille 3 Fig. 3.2 Graphe des hôtes L ensemble des machines virtuelles participant dans l application est représenté par l ensemble VM. Les demandes en taille est en capacité de calcul faites par chaque VM sont estimées également. Elles sont notées par une fonction de demande de calcul de VM : vm_calcul : V M! R et une fonction de demande d espace : vm_taille : V M! R. Par ailleurs, on aura un outil, qui permet de déduire la topologie de communication de l application pour générer les demandes de tra c de l application. Il génère A, un ensemble de 4-tuples, A i = (s i ; d i ; b i ; l i ) ; i = 1; 2; :::; m avec s i : VM source d i : VM destination b i : demande en bande passante entre la source et la destination l i : demande en latence entre la source et la destination Le but est de trouver un algorithme d adaptation qui utilise les données mesurées et déduites et aboutit à des mécanismes d adaptation pour améliorer la capacité de traitement de l application. En d autres termes, ses objectifs se résument à : un mapping des VMs aux hôtes, vmap : V M! H qui fait correspondre les demandes en taille et capacité de calcul des VMs avec les contraintes des hôtes. De plus, on peut aussi donner un ensemble de contraintes de mapping des VMs aux hôtes qui doivent être maintenus à chaque fois. On les représente par un ensemble de paires ordonnées M i = (vm i ; h i ); vm i 2 V M; h i 2 H un routage R : A! C où C est l ensemble de tous les chemins du graphe G = (H; E), càd pour chaque 4-tuple A i = (s i ; d i ; b i ; l i ) alloue un chemin

14 3. Modélisation 12 c (vmap (s i ) ; vmap (d i )) à travers le graphe d overlay G rencontrant les demandes en application en satisfaisant les contraintes de bande passante et de latence du réseau. Une fois tous les mappings et les chemins sont décidés, chaque arc aura une capacité résiduelle rc a qui est la bande passante restante inutilisée dans cet arc et dans cette direction rc a = bp a Pa2R(A i ) b i Pour chaque chemin mappé, R (A i ), on dé nit son bottleneck de bande passante bb (R (A i )) = min a2r(ai ) frc a g et sa latence totale lt (R (A i )) = P a2r(a i ) (lat a). Le but de l algorithme d adaptation est de maximiser la somme des bottlenecks de la bande passante à travers chaque chemin mappé. L intuition derrière cette fonction d objectif est de laisser la plus grande marge pour l application pour augmenter la performance à travers la con guration courante, ainsi augmenter la capacité de traitement de l application.(figure 3.3) calcul 4 taille 4 H 2 VM 1 H H 1 4 bp 13 lat 13 H 3 s i d i b i l i VM 2 VM 3 A 1 A 2 A 3 A 4 VM 1 VM 2 b 1 l 1 VM 1 VM 3 b 2 l 2 VM 2 VM 3 b 3 l 3 VM 3 VM 1 l 4 b 4 Un ensemble ordonné de 4 tuples, A Fig. 3.3 Mapping des VMs Dans la gure 3.3, on doit avoir b 1 + b 2 bp 13 et l 1 ; l 2 lat 13 : Résolution On peut formaliser le problème comme suit : Un graphe orienté G = (H; E) Une fonction bp : E! R Une fonction lat : E! R Une fonction calcul : H! R

15 3. Modélisation 13 Une fonction taille : H! R Un ensemble V M = (V M 1 ; V M 2 ; :::; V M n ) ; n 2 N Une fonction vm_calcul : V M! R Une fonction vm_taille : V M! R Un ensemble de 4-tuple A i = f(s i ; d i ; b i ; l i ) js i ; d i 2 V M; b i ; l i 2 R; i = 1; ::mg Un ensemble de paires ordonnées M i = f(vm i ; h i )jvm i 2 V M; h i 2 H; i = 1; 2; ::; r; r ng Nous aurons vmap : V M! H et R : A! C tel que P vmap(vm)=h (vm_calcul(vm)) calcul(h); 8h 2 H P vmap(vm)=h (vm_taille(vm)) taille(h); 8h 2 H h i = vmap(vm i ); 8M i = (vm i ; h i ) 2 M P bp a a2r(a i ) b i 0; 8a 2 E P a2r(a i ) (lat a) l i ; 8a 2 E P m i=1 (min a2r(a i ) frc a g);avec rc a = bp a Pa2R(A i ) b i est maximisée 3.3 L ordonnancement et l allocation des ressources Le problème de scheduling ou ordonnancement des applications parallèles dans les Grilles[11] est connu comme étant di cile. En e et, les ordonnanceurs doivent considérer l hétérogénéité des ressources concernées et les systèmes de gestion. De plus, ils demandent souvent aux utilisateurs de leur fournir des informations sur le comportement attendu des applications. Par ailleurs, l ordonnancement dans les Grilles est dé ni comme étant un processus d ordonnancement dont la décision implique l utilisation de plusieurs domaines administratifs. Plusieurs scénarios sont possibles : chercher plusieurs domaines administratifs pour utiliser une seule machine soumettre un job pour des machines indépendantes dans des sites multiples où une seule soumission sera retenue plus tard ordonnancer un seul job pour utiliser des ressources multiples dans un ou plusieurs sites Un job pourrait être une demande de bande passante, une application ou un ensemble d applications qui ont besoin de ressources. Une ressource est tout ce qui peut être ordonnancé comme une machine, un espace de disque, quelques paramètres de QoS des réseaux, etc. La di érence entre un ordonnanceur ordinaire et un ordonnanceur de Grilles est que ce dernier ne possède pas les ressources et par conséquent il n a pas un contrôle total sur eux. De plus, cet ordonnanceur n a pas de contrôle sur l ensemble entier des jobs du système ou ne sait même rien sur eux. Par conséquent, les décisions sur l ensemble entier des jobs à une ressource ne peuvent pas avoir lieu. Ce manque de possession et de contrôle est la source de plusieurs problèmes. De ce fait, cet ordonnancement est réparti sur plusieurs étapes qui sont décrites dans la section suivante Les étapes de l ordonnacement Un utilisateur procède par trois étapes pour ordonnancer un job quand il implique plusieurs sites. La première phase est la découverte de ressources, dans laquelle l utilisateur établit une liste des ressources potentielles à utiliser. La deuxième implique

16 3. Modélisation 14 le collecte d informations concernant ces ressources et le choix du meilleur ensemble à utiliser. Dans la troisième phase, l utilisateur exécute le job. Phase 1 : Découverte de ressources La découverte de ressources implique la selection d un ensemble de ressources pour les examiner en détails dans la phase 2 qui concerne la collecte d informations. Au début de cette phase, l ensemble de ressources potentielles est l ensemble vide. A la n, cet ensemble sera un ensemble qui répond aux demandes minimales de faisabilité. La plupart des utilisateurs e ectuent cette phase en trois étapes : ltre d autorisation, connaissance des demandes du job et le ltre pour correspondre les demandes minimales du job. 1. Filtre d autorisation : Il est généralement assumé qu un utilisateur aura la connaissance sur quelle ressource il aura accès en termes de services basiques. A la n de cette étape, l utilisateur aura une liste de machines ou de ressources auxquelles il aura accès. 2. Dé nition des demandes des applications : Pour procéder à la découverte des ressources, l utilisateur doit être capable de spéci er quelques ensembles minimaux de demandes des jobs pour pouvoir ltrer davantage l ensemble des ressources possibles. Par ailleurs, l ensemble des demandes possibles d un job peut être très large et peut varier d un job à un autre. Il peut inclure des détails statiques, comme le système d exploitation ou le hardware. Des détails dynamiques sont également possibles, par exemple une demande minimale de RAM, une connectivité requise, espace ou temps requis, etc. En général, cette phase peut inclure n importe quelle information concernant le job qui pourrait être spéci ée pour s assurer que le job peut être assorti à un ensemble de ressources. 3. Filtre des demandes minimales : Etant donné un ensemble de ressources auxquelles un utilisateur a accès et l ensemble minimal de demandes que requiert un job, la troisième étape dans la phase de découverte de ressources est de ltrer les ressources qui ne satisfont pas les demandes minimales d un job. L utilisateur fait cette étape généralement en allant dans les listes des ressources et élimine celles qui ne conviennent pas aux demandes de jobs au fur et à mesure qu elles sont connues. Cette étape peut être combinée avec la collecte d informations plus détaillées sur chaque ressource (étape 1, phase 2). Cependant, quand cette partie est faite à la main, si un utilisateur peut éliminer une ressource inappropriée, ceci est fait à ce stade pour simpli er la collecte d informations dans la phase suivante. Phase 2 : Sélection du système Etant donné un groupe de ressources possibles (ou groupe d ensemble de ressources possibles), tous ceux qui conviennent aux demandes minimales d un job, une seule ressource (ou un seul ensemble de ressources) doit être selectionné pour ordonnancer le job sur lui. Ce processus est fait en deux étapes : collecte d informations et prise de décision.

17 3. Modélisation Le collecte d informations (interrogation) : A n d améliorer la correspondance job/ressource, un utilisateur a besoin de collecter des informations dynamiques sur la ressource en question. Plusieurs informations pourraient être requises en fonction de l application et de la ressource en question. Pour l instant on prend un cas simple qui consiste a trouver la meilleure ressource pour un job à exécuter. Un utilisateur pourrait demander le chargement dans plusieurs machines, ou la largeur de la le d attente si elle existe. De plus, les caractéristiques physiques et les demandes logicielles jouent un rôle important (si le compilateur que l utilisateur demande est bien dans la machine, si le disque est assez large pour les données, etc). En outre, il existe les problèmes de localisation et de connectivité et si les machines sont assez proches de la réserve de données. Tous ces problèmes sont multipliés dans le cas de ressources multiples. La réservation à l avance (étape 1, phase 3) pourrait être une partie de cette étape. 2. Choix du (des) système(s) pour l exécution : Etant donné les informations collectées par l étape précédente, on peut prendre une décision sur quelle ressource (ou ensemble de ressources) l utilisateur devrait soumettre un job. Cette décision peut être prise de di érents manières. Nous notons que nous ne traitons pas la situation où un job est soumis à plusieurs ressources. C est la selection d une ressource ou d un ensemble de ressources. Phase 3 : Exécuter un job La troisième phase de l ordonnancement est d exécuter un job. Ceci implique plusieurs étapes qui incluent : 1. Faire une réservation à l avance (optionnel) : Ça pourrait être le cas qui induit la meilleure utilisation d un système donné. En e et, une partie ou toutes les ressources vont être réservés à l avance. En fonction de la ressource, cette réservation pourrait être facile ou di cile à faire. De plus, elle pourrait se faire avec des moyens mécaniques en opposition avec les moyens humains. La réservation peut expirer avec ou sans coût. 2. Soumettre un job aux ressources : Une fois les ressources choisies, l application doit être soumise aux ressources. Cela pourrait être aussi facile que tourner une seule commande ou aussi compliqué que tourner une série de scripts, et peut inclure une installation (étape 3). 3. Préparation de taches : L étape de préparation peut induire une installation, demande de réservation ou autres actions requises pour préparer la ressource pour tourner l application. 4. Contrôle de l avancement (peut revenir à l étape 1, phase 2) : En fonction de l application et de son temps d exécution, les utilisateurs peuvent contrôler l avancement de leur application et probablement changer leur avis sur où et comment l exécuter. 5. Découvrir que le job J est fait : Quand le job est ni, l utilisateur a besoin d être noti é.

18 3. Modélisation Achèvement des tâches : Après qu un job soit exécuté, l utilisateur pourra demander de récupérer des chiers de cette ressource a n d analyser les résultats, rompre avec l environnement, e acer les réglages temporaires, etc Dé nition formelle La partie précédente a dé ni les étapes qu un utilisateur suit pour prendre une décision d ordonnancement à travers plusieurs domaines administratifs à un moment donné. On modélise cette décision par ce qui suit : Un ensemble ni de n jobs Chaque job consiste en une chaîne d opérations Un ensemble ni de m machines Chaque machine peut supporter à la fois une seule opération Chaque opération a besoin d être traitée durant une période non interrompue d une longueur donnée dans une machine donnée Le but est de trouver l ordonnancement, qui est une allocation des opérations aux intervalles de temps et aux machines, le plus court. Une grille (G) consiste en n noeuds Un noeud (N) consiste en m ressources (R) 2! N 1 R! N i =! 11 R 12 R 13 ::: R 1m! N 2!! R 21 R 22 R 23 ::: R 2m R 1 R 2 ::: R m G = 6 N 3 G = 7 6R 31 R 32 R 33 ::: R ::: 5 4 :: :: :: :: :: 5! N R n n1 R n2 R n3 ::: R nm 3.4 Réservation Contexte Un gestionnaire de réservation [1]contrôle les réservations pour une ressource. Il e ectue le contrôle d admission et contrôle la ressource pour améliorer les réservations. Certaines ressources ont déjà la possibilité de travailler avec des réservations à l avance, par conséquent, le gestionnaire de réservation est un simple programme. La plupart des ressources ne peuvent pas s arranger avec les réservations à l avance. Dans ce cas, le gestionnaire de réservation suit la trace des réservations et e ectue le contrôle d admission pour les nouvelles demandes de réservation Quelques dé nitions Réservation : Une promesse de la part du système qu une application recevra un certain niveau de services de la ressource. Créer une réservation : Demander un comportement spéci que de la ressource dans une durée déterminée, dans un intervalle de temps spéci é. E ectuer une réservation : Pour faciliter l utilisation de co-réservations, les utilisateurs doivent choisir d utiliser un protocole de deux phases. Une fois la réser-

19 3. Modélisation 17 vation créée, elle est maintenue pour un temps spéci que. Si la réservation n est pas e ectuée dans cet intervalle de temps, elle est annulée. Fixer la réservation : Certaines réservations ne peuvent pas être instanciées sans l ajout d informations sur le temps d exécution additionnel. L étape de xation est supposée faciliter la création de réservations sans demander une connaissance détaillée sur les attributs demandés. Cependant, pour utiliser réellement la réservation, elle doit être xée, c est à dire que l utilisateur doit fournir les attributs manquants Réservations Les réservations possèdent cinq attributs importants : 1. Temps de départ : Le plus tôt temps où la réservation peut commencer. Une réservation possède toujours un temps de départ, même si c est une réservation immédiate qui commence quand on fait la réservation. 2. Durée : Combien de temps la réservation va durer, en secondes. Toutes les réservations doivent spéci er combien de temps elles vont durer a n que les gestionnaires de réservations soujacents peuvent faire le contrôle d admission approprié pour les réservations attribuées en avance. 3. Type de ressource : Le type de la ressource soujacente, comme un réseau, une machine ou un disque. 4. Type de réservation : Un type particulier de réservation 5. Paramètres spéci ques à la ressource : Paramètres qui sont uniques pour chaque type de ressource comme la bande passante pour une réservation de réseau ou le nombre de noeuds pour une réservation de calcul. Optionnellement, une réservation peut spéci er un attribut "Date de n" de la même manière que le "Temps de départ". Si la di érence entre la "Date de n" et le "Temps de départ" dépasse la valeur de la "Durée", n importe quel intervalle de temps d une durée correcte qui débute après le "Temps de départ" et ne dépasse pas la "Date de n", est accepté pour la réservation. Le vrai "Temps de départ" est e ectué par le gestionnaire de réservation Quand une réservation est acceptée, l application peut faire plusieurs opérations : Modi er la réservation : Un utilisateur peut demander une modi cation pour une réservation existante. Par exemple, il peut demander une augmentation de la bande passante qui est déjà demandée. Une modi cation qui réduit des demandes réussit normalement. Cependant, il existe des facteurs qui peuvent échouer cette modi cation comme des contrats locaux qui ne permettent pas de si petites réservations dans certaines ressources. Annuler la réservation : Un utilisateur peut informer le gestionnaire de réservation qu il n a plus besoin de la réservation. Fixer la réservation : Quand une application est prête à utiliser une réservation, elle pourrait avoir besoin de fournir une information sur le temps d exécution qui n était pas fournie au moment où la réservation été faite. Par exemple, les réservations de réseau requièrent que les numéros de ports soient spéci és, mais ils ne sont pas connus au moment de la réservation.

20 3. Modélisation 18 Défaire la réservation : Une réservation peut être défaite. Elle ne doit plus être utilisable par la personne qui l utilisait. Elle peut être re xée de nouveau avec de nouveaux paramètres d exécution. E ectuer la réservation : Quand une réservation est créée, elle peut être spéci ée comme une réservation a deux phases. Ce genre de réservations expire après une période spéci que à moins que la réservation soit e ectuée. Interrogation de l état de la réservation : Un utilisateur peut découvrir l état de la réservation. L état inclut si le début de la réservation a commencé et si la réservation a été e ectuée. Interrogation des attributs de la réservation : Un utilisateur peut découvrir les attributs associés avec des réservations existentes. Ceci inclut le début et la n d une réservation donnée, et si elle est à deux phases. Elle inclut également des informations spéci ques requises pour utiliser réellement une réservation. 3.5 Conclusion Dans ce chapitre, nous avons modélisé le système avec ses couches d abstraction. En e et, nous avons bien présenté ses composantes. Ensuite, nous avons formalisé le problème de mapping entre la couche physique et la couche virtuelle avec l outil de graphes en exposant les contraintes fonctionnelles et non fonctionnelles du système. Puis, nous avons montré les démarches à faire pour la gestion de l ordonnancement et l allocation des ressources. En n, nous avons présenté la solution de réservation à l avance des ressources pour s assurer que le demandeur de la ressource aura un certain niveau de services de sa part. Le chapitre suivant mettra l accent sur quelques solutions de virtualisation existantes dont chacune s est intéressée à un aspect spéci que de la virtualisation dans les grilles.

21 Chapitre 4 Solutions existantes Dans ce chapitre, nous allons aborder une recherche bibliographique a n de synthétiser un état de l art des di érents travaux de recherches qui ont traité des méthodes de virtualisation des clusters. Ce chapitre est scindé en cinq parties. Les quatre premières exposent quelques approches de virtualisation. La dernière partie conclut par un tableau récapitulatif qui met l accent sur les points de di érence entre ces méthodes. 4.1 Virtuoso Dans ce modèle [2], les auteurs ont développé un middleware, Virtuoso, pour les machines virtuelles du Grid Computing. Ce middleware émule le processus existant d achat, de con guration et d utilisation d un ordinateur basé sur Intel, un processus avec lequel plusieurs utilisateurs et certainement tous les administrateurs systèmes sont familiers avec. En e et, l utilisateur visite un site web qui lui permet de spéci er la con guration matérielle et logicielle d un ordinateur et ses critères de performances. Ensuite, il ordonne un ou plusieurs d entre eux. L utilisateur reçoit une référence à la machine virtuelle qu il pourra ensuite utiliser pour démarrer, arrêter, redémarrer et cloner la machine. Le système présente l illusion que la machine virtuelle est juste à coté de l utilisateur. La console de présentation est retournée à l utilisateur de la machine, le CD-ROM est mandaté à celui de l utilisateur de la machine, la machine virtuelle apparaît d être branchée au réseau côte à côte avec l utilisateur de la machine. L utilisateur pourra ensuite installer des logiciels supplémentaires, incluant des systèmes d exploitation. VNET VNET est la partie de ce système qui crée et maintient l illusion d interconnexion, à savoir l illusion que les machines virtuelles de l utilisateur sont dans son réseau local. C est un simple schéma mandataire qui travaille entièrement au niveau utilisateur. La dépendance primaire du VMM est qu il doit y avoir un mécanisme pour extraire les paquets Ethernet bruts envoyés par la carte réseau virtuelle et un autre pour les injecter dans la carte virtuelle. Les mécanismes spéci ques qu ils ont utilisés sont des ltres 19

22 4. Solutions existantes 20 de paquets, des sockets de paquets, et une interface réseau VMWare d un host-only (spéci que à l hôte). Dans cette méthode, les auteurs ont utilisé cette terminologie : l Utilisateur est le propriétaire des machines virtuelles (ses VMs) qu il y accède en utilisant sa machine de Client. L Utilisateur possède aussi une machine Proxy pour l interconnexion. On note que le Proxy et le Client peuvent être la même machine. Chaque VM tourne sur un Hôte, et plusieurs VMs peuvent tourner sur chaque Hôte. L environnement Local d une VM est le LAN auquel son Hôte est connecté, alors que l environnement Distant est le LAN auquel le Client et le Proxy sont connectés. Les serveurs VNET sont tournés dans l Hôte et dans le Proxy. Ils sont connectés en utilisant une connexion TCP qui peut être optionnellement encryptée avec SSL. En particulier, le serveur VNET qui tourne sur l Hôte ouvre l interface virtuelle de l Hôte en un «promiscuous mode» et installe un ltre de paquets qui fait la correspondance des paquets Ethernet que leurs adresse source est celle de l interface virtuelle de la VM. D autre part, le serveur VNET au Proxy ouvre l interface physique de ce dernier dans un «promiscuous mode» et installe un ltre de paquets qui fait correspondre les paquets Ethernet que leur adresse destination est celle de l interface virtuelle de la VM ou bien dans les adresses Ethernet broadcast et/ou multicast. Quand le serveur VNET du Proxy détecte un paquet assorti, il le sérialise à la connexion TCP du serveur VNET de l Hôte. A la réception du paquet, le serveur VNET du Proxy injecte directement le paquet dans l interface réseau virtuelle du Hôte, ce qui la même à être délivrée à l interface réseau virtuelle de la VM. Quand le serveur VNET du Hôte détecte un paquet assorti, il le sérialise au serveur VNET du Proxy. Ce dernier, à son tour, l injecte directement dans la carte d interface réseau physique, ce qui lui cause d être envoyée dans le LAN du Client.(Figure 4.1) 4.2 Violin Violin [15] réalise les fonctionnalités qui connectent les machines virtuelles résidentes dans di érentes machines hôtes, permettant des communications à travers un réseau IP virtuel sans avoir une présence dans l Internet sous-jacente. Bien qu il soit possible d implémenter les outils Violin en étendant d autres architectures de virtualisation, l implémentation présentée par cette équipe pro te de l avantage de l outil d exécution de niveau utilisateur d UML (User Mode Level) et de son code open source. Les machines virtuelles standard UML sont instanciées comme un processus dans un espace d exécution d utilisateur Linux. Les communications à l extérieur de la machine de l hôte se produisent à travers une interface réseau virtuelle, ou dispositif tap, résidant dans le noyau de l hôte. La machine virtuelle UML contient une interface réseau virtuelle qui connecte au dispositif tap de l utilisateur, et l hôte agit comme un routeur en faisant suivre les paquets entre la machine virtuelle et le réseau physique. Dans ce cas, un utilisateur aura besoin d un privilège de niveau root pour créer, en sécurité, le dispositif tap et gérer la table de routage. De plus, la machine virtuelle a besoin d une adresse IP qui est routable dans le réseau physique pour accéder au réseau à travers le dispositif tap. Violin contourne le besoin pour un dispositif tap et laisse la machine virtuelle

23 4. Solutions existantes 21 Resilient Star Backbone User s LAN Fast path links amongst the VNETs hosting VMs Foreign host LAN 1 Merged matrix as inferred by VTTIF Proxy + VNET IP network VM 1 Host 1 + VNET Foreign host LAN 2 VM 4 Foreign host LAN 4 Host 4 + VNET VM 3 Foreign host LAN 3 Host 3 + VNET VM 2 Host 2 + VNET Fig. 4.1 Architecture de Virtuoso exister dans un espace d adresses IP orthogonal qui est totalement découplé de l Internet. En e et, une machine virtuelle munie de Violin contient une interface réseau virtuelle qui ne se connecte pas à l hôte. En revanche, elle se connecte à un commutateur (switch) virtuel, qui est un démon Violin, tournant dans l espace utilisateur de la machine de l utilisateur. Le switch virtuel se comporte comme un switch physique en acceptant et faisant suivre les fenêtres de la couche virtuelle 2 entre les machines virtuelles. Pour plus d e cacité, les switchs virtuels simulent les liens de réseau physiques en faisant passer les frames réseau via le non able et léger UDP. En utilisant des protocoles de transport comme TCP dans le domaine virtuel, il est possible d achever une abilité de bout en bout entre les machines virtuelles. En passant le tra c de réseau virtuel à travers des connexions de niveau utilisateur au lieu du routage de tra c directement à travers le réseau souacent, Violin crée un réseau virtuel de machines virtuelles avec uniquement des privilèges de niveau utilisateur. (Figure 4.2) 4.3 Cluster On Demand (COD) Les utilisateurs d un cluster partagé devraient être libres de choisir l environnement logiciel qui supporte le mieux leurs noeuds. Cluster-On-Demand [6] est un système qui permet de faire un partitionnement rapide, automatisé, à la volée, d un cluster physique en plusieurs clusters virtuels indépendants. Un cluster virtuel est un groupe de machines virtuelles ou physiques con gurées pour un but commun, avec des comptes et des ressources de stockage pour utilisateurs, un environnement logiciel spéci que à un chaque utilisateur, un bloc privé d adresses IP et un domaine de nommage DNS.