SINF2990 : Travail de n d'études Allocation en temps réel de machines virtuelles dans un cloud

SINF2990 : Travail de n d'études Allocation en temps réel de machines virtuelles dans un cloud Hesmans Benjamin Université catholique de Louvain-La-Neuve, Belgique Promoteur : Van Roy Peter Promoteur : Sabri Skhiri (Euranova) benjamin.hesmans@student.uclouvain.ac.be 20 août 2012

Merci aux personnes qui m'ont soutenu pendant l'élaboration de ce mémoire : Ivan Frain (Euranova) pour l'établissement de l'état de l'art, Nam-Luc Tran (Euranova) pour le modèle et la rédaction, les relectures, ainsi que la gestion du laboratoire, Peter Van Roy pour les présentations pendant l'année et les relectures, Ma famille pour leur soutien, leur patience, leur présence, en particulier ma maman qui a relu consciencieusement ce mémoire Un remerciement particulier pour Jürgen Kurz, mon parrain, et Jean-Christophe Hesmans, mon frère, qui m'ont transmis (sans le savoir!) la passion pour l'informatique.

Table des matières 1 Introduction 1 2 État de l'art 3 2.1 Le cloud...................................... 4 2.1.1 Introduction................................ 4 2.1.2 L'avant cloud............................... 4 2.1.3 Limites et nouvelles perspectives.................... 4 2.1.4 Naissance du cloud............................ 5 1) Convergences de technologies................. 5 2) Dénition............................ 6 3) Caractéristiques et avantages................. 6 4) Modèles de déploiement cloud................ 8 5) Modèles de services...................... 9 2.1.5 Exemples d'implémentation du cloud.................. 10 1) OpenNebula.......................... 10 2) Amazon Web Services..................... 11 2.2 Nouveaux challenges............................... 11 2.2.1 Introduction................................ 11 2.2.2 Dénition................................. 12 2.2.3 Réponses................................. 13 1) Haizea.............................. 13 2) VMWare/DRS......................... 14 3) Autre.............................. 16 2.2.4 Problème restant ouvert......................... 16 3 Description du problème et solution 17 3.1 Base du problème................................. 18 3.1.1 Introduction................................ 18 3.1.2 Besoin d'une application......................... 18 3.1.3 Surprovision................................ 18 3.1.4 Utilisation d'iaas............................. 19 3.1.5 Nouvelle solution............................. 20 3.1.6 Modélisation mathématique....................... 22 1) Coûts liés à l'écart entre provision et charge réelle..... 22 2) Partage des coûts....................... 23 3) Partage des gains....................... 26 3.1.7 Comparaison Cloud et Pool....................... 27 3.1.8 Analyse des gains et des coûts de la nouvelle solution......... 29 1) Clients............................. 29 i

2) Providers............................ 29 3.2 Applicabilité................................... 30 3.2.1 Introduction................................ 30 3.2.2 Utilisateurs de type SP......................... 30 1) Applications aux requirements spéciaux........... 30 2) Démonstrations live...................... 30 3) Exemple : MMOG....................... 31 3.2.3 Utilisateurs de type B.......................... 31 1) Caractéristiques des services oerts............. 31 2) Exemple : service Boinc.................... 31 4 Implémentation de la solution 35 4.1 Description de la solution............................ 36 4.1.1 Introduction................................ 36 4.1.2 Modèle d'acteurs............................. 36 4.1.3 Diagramme de séquence d'utilisation.................. 37 4.1.4 Langage de programmation et drivers................. 38 4.1.5 Communication entre les acteurs.................... 39 1) Messagerie standard RabbitMQ............... 39 2) Standardisation des messages................. 39 4.1.6 Cycle de vie d'une VM dans le pool.................. 42 4.1.7 Modelisation objet............................ 43 1) Modèle............................. 43 2) Abstractions.......................... 43 4.1.8 Persistance des données et comptabilité................ 45 1) SQLite............................. 45 2) Structure des bases de données................ 45 4.1.9 Comptes rendus............................. 46 1) Dénitions........................... 46 2) Dénition des ensembles.................... 46 3) Comptes Boinc......................... 47 4) Comptes SP.......................... 47 4.1.10 Installation de la solution........................ 48 1) Requirements.......................... 48 2) Conguration et personnalisation............... 49 3) Démarrer le programme.................... 49 4.2 Tests........................................ 51 4.2.1 Introduction................................ 51 4.2.2 Dummy VM : cas simple......................... 51 4.2.3 Dummy VM : cas composé....................... 55 4.2.4 ONE VM................................. 62 1) Lab : OpenNebula....................... 62 2) VM : couple Jeos et Boinc : seti@home........... 62 3) Test en laboratoire....................... 62 4.2.5 Conclusion................................ 63 ii

5 Conclusion 64 5.1 Further work................................... 65 5.1.1 Implémentation de diérents clouds................... 65 5.1.2 Implémentation de diérents services.................. 65 5.1.3 Un processeur, deux vms........................ 65 5.1.4 Aide humanitaire............................. 66 5.1.5 Diérencier les pools........................... 66 iii

Chapitre 1 Introduction...There's a green one and a pink one and a blue one and a yellow one... M. Reynolds - Little Boxes

De nos jours, l'utilisation du cloud se répand de plus en plus grâce aux avantages qu'il apporte aux solutions d'infrastructures informatiques classiques. Néanmoins il reste des challenges à relever dans ce domaine et la technologie n'est pas encore totalement aboutie. Dans ces challenges, nous en relèverons ici un en particulier : le temps d'obtention d'une ressource pour une application. Ce temps est variable sur le cloud car beaucoup de paramètres peuvent entrer en ligne de compte chez des grands providers. Par exemple, le temps pour obtenir une machine virtuelle chez Amazon EC2 peut varier entre 15 secondes et 5 minutes. Les applications pour lesquelles une ressource en retard est une ressource inutile se voient donc dans l'obligation de sur-provisionner leur infrastructure an d'absorber tous les pics possibles de charges. Un exemple concret est celui des MMOG. Le coût engendré par la sur-provision est donc important. An de mitiger ce coût, nous proposons une solution qui permette de rentabiliser un maximum les machines en sur-provision tout en gardant une très grande réactivité. L'idée est d'allouer les machines non-utilisées qui sont en sur-provision à des clients qui acceptent qu'on puisse leur couper leurs ressources à tout moment : dès que les clients dont c'est la sur-provision en ont besoin. Ce genre de clients pourraient par exemple utiliser des services de calculs qu'on puisse interrompre facilement comme Boinc. Nous présenterons un modèle complet de cette solution ainsi qu'une implémentation. Nous montrerons à l'aide du modèle et de tests que cette solution est économiquement viable et qu'elle apporte un gain nancier tout en gardant une réactivité très proche de celle de la sur-provision. La suite du mémoire est organisée de la manière suivante : Dans la première partie de ce mémoire, nous allons tout d'abord voir d'où provient le cloud et ce qu'il apporte. Nous verrons ensuite l'état des connaissances et technologies actuelles disponibles dans le domaine du cloud. Nous établirons ensuite quelques challenges restants, ainsi que les pistes de solutions déjà abordées. Pour nir cette partie, nous sélectionnerons un problème en particulier, qui subsiste encore et sur lequel nous travaillerons pendant la suite du mémoire. Dans la seconde partie, nous décrirons une solution possible au problème soulevé, nous donnerons ensuite une modélisation mathématique de cette nouvelle solution et enn nous analyserons et comparerons la nouvelle solution à celles qui existent déjà. Dans la troisième partie, nous détaillerons l'implémentation du concept présenté dans la partie précédente ainsi que les divers moyens de la personnaliser. Nous présenterons également la marche à suivre pour mettre en place la solution. Enn nous montrerons les tests que nous avons réalisés sur la solution dans le laboratoire d'euranova. Dans la dernière section, nous reprendrons les conclusions du travail et nous proposerons des pistes pour continuer le projet. 2

Chapitre 2 État de l'art...and they're all made out of ticky tacky... M. Reynolds - Little Boxes

2.1 Le cloud 2.1.1 Introduction Dans cette section, nous verrons dans un premier temps comment et pourquoi le cloud est né. Nous verrons ensuite les diérentes caractéristiques et les diérents modèles de clouds qui co-existent à l'heure actuelle ainsi que leurs avantages. Enn nous nous pencherons sur deux implémentations de cloud ayant des objectifs diérents. 2.1.2 L'avant cloud Avant la naissance du cloud, toutes les entreprises qui avaient besoin de machines pour faire fonctionner leurs applications (que ce soit des sites web, des services de messageries électroniques, des systèmes internes de comptabilité, de gestion, etc.) disposaient de machines réelles. Ce qui entraînait un double coût : 1. Coût xe au départ : achat des machines, lieu pour les mettre, installation de celles-ci (OS, logiciel,...) 2. Coût de fonctionnement : consommation électrique, entretien des lieux pour maintenir les machines (systèmes de sécurité, de refroidissement,...), maintien de l'infrastructure,... Les entreprises pouvaient tout de même choisir de louer des machines dans des data centers, mais l'ore était très rigide. 2.1.3 Limites et nouvelles perspectives Dans ce modèle, nous mettrons ici en avant deux problèmes : 1. Le manque de souplesse d'une telle solution : certaines applications peuvent avoir des besoins variables pour répondre aux charges. Nous donnons ici 2 exemples : si nous considérons une société de vente sur internet tel que Pixmania 1, le nombre de serveurs nécessaires pour répondre à la demande des clients, une semaine avant noël, ne sera pas le même qu'au milieu du mois de mai. si nous considérons des jeux en ligne tel que le jeu gratuit League of legends 2, le nombre de serveurs nécessaires pour faire tourner le jeu n'est pas le même entre 16h et 02h00 et le reste de la journée. Il existe des statistiques qui peuvent être consultées sur http://mmodata.blogspot.be/ A cause de ce problème, si une société voulait faire face à tous les pics possibles de consommation de ressources, elle était obligée de mettre des machines en surprovision. En conséquence, les machines en provision tournaient la plus part du temps sans charge, entraînant une consommation d'énergie (et donc des coûts) importante. 2. le manque de consolidation : la plupart du temps, les applications n'utilisent pas les capacités des machines à 100%, néanmoins les machines continuent à consommer de l'énergie même si elles n'ont pas de charges, il faudrait donc trouver un moyen pour augmenter l'utilisation des machines pour mieux les rentabiliser. 1. http://www.pixmania.com/ 2. htt://leagueoflegends.com 4

2.1.4 Naissance du cloud 1) Convergences de technologies Comme expliqué dans [5], la naissance du cloud est due à la convergence de 4 technologies comme on peut le voir sur la gure 2.1 Figure 2.1 Convergence des technologies [5] 1. Virtualisation : cette technologie existe depuis des décennies, popularisée par VMWare dans la n des années 90 et supportée par les processeurs Intel et AMD depuis l'an 2000. Les avantages sont principalement l'isolation, la consolidation et la migration possible des charges de travail, représentés sur la gure 2.2. Nous trouverons plus de détails dans [23]. Les principaux acteurs dans le domaine de la virtualisation sont : VMWare ESXi (et tout son écosystème). Logiciel payant, mais gratuit dans des versions allégées. Xen, hyperviseur (libre) utilisé par des logiciels commerciaux, notamment par Oracle [1] KVM qui est l'hyperviseur par défaut pour OpenNebula, mais aussi utilisé par Nimbus et Eucalyptus [17]. 2. Web Services, Service-oriented Architecture : les services sur internet se développent, les sociétés proposent des APIS en utilisant des langages standards de communication (xml, JSON, BSON,...). Par exemple : l'api de google pour google map 3 ou bien encore l'api de twitter 4. 3. http://www.google.com/enterprise/earthmaps/maps.html 4. https://dev.twitter.com/ 5

3. Utilité et Grid computing : permet l'utilisation de ressources distribuées de manière transparente pour des calculs scientiques comme par exemple la modélisation de médicaments. Exemple de grid : European Grid Infrastructure 5. 4. Autonomic computing : comme décrit dans [11], les quatre caractéristiques sont : Self-conguration, self-optimization, self-healing, self-protection. Pour plus de détails, voir [13] Figure 2.2 Avantages de la virtualisation [23] 2) Dénition La notion même de cloud, fait encore débat à l'heure actuelle et nous pouvons trouver un nombre conséquent de dénitions du cloud dans diverses publications. Certaines personnes ont déjà essayé d'uniformiser les notions relatives au cloud en mettant en commun toutes ces publications, par exemple dans [25] ou [26]. Même si aucun n'y est vraiment parvenu, ils constatent cependant des points communs entre toutes les dénitions et nous avons choisi ici de donner la dénition donnée par le NIST 6 dans [12] : Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of congurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management eort or service provider interaction. This cloud model is composed of ve essential characteristics, three service models, and four deployment models Nous décrirons dans les prochains points, les caractéristiques, les modèles de déploiements et les modèles de services. 3) Caractéristiques et avantages Nous relevons ici les quatre caractéristiques principales du cloud qui ressortent des multiples dénitions existantes (et non de celle présentée par le NIST) : 5. http://www.egi.eu/ 6. National Institute of Standards and Technology : http://www.nist.gov/ 6

Pay-per-use De même que nous ne payons que l'eau que nous utilisons en ouvrant le robinet et que électricité que nous utilisons en branchant un appareil, nous ne voulons payer pour des machines que quand nous les utilisons vraiment. Cette analogie a été développée par beaucoup d'auteurs et notamment dans [7]. Les clients du cloud vont donc recevoir des tarications, les plus précises possibles, pour les ressources qu'ils utilisent. Si nous regardons la tarication d'amazon 7, on voit qu'elle est très large et peut s'adapter à une grande partie des clients. Les ressources sont de tailles variables et avec des garanties variables : cela va d'une micro machine virtuelle à $0.02 par heure (voire moins cher encore avec le système d'enchères et de prix qui uctuent 8 ) avec des garanties moindres jusqu'à $3.10 par heure pour des grosses machines virtuelles. Au niveau du stockage, les prix sont de l'ordre de $0.1 par mois. Il existe aussi des formes des pré-réservations : le client paye une somme une fois au départ et pendant un laps de temps donné, il pourra demander une machine moins chère à l'heure 9. L'illusion de ressources innies Les clients du cloud disposent de ressources beaucoup plus grandes que ce qu'ils pourraient se permettre s'ils avaient dû utiliser leur propre infrastructure. Des providers tel que Amazon ont des ressources tellement grandes, que pour un client cela peut s'apparenter à des ressources innies! Du moins tant que ses nances le lui permettent... Un système de self-service Les clients du cloud doivent pouvoir demander des ressources et les avoir le plus rapidement possible sans se soucier de l'intervention d'un opérateur humain. Typiquement, pour les clouds, des API sont disponibles an que les applications elles-mêmes puissent contacter les providers quand elles ont besoin de plus de ressources ou au contraire quand elles désirent rendre des ressources. Dans le cas d'amazon, nous pouvons observer qu'ils font beaucoup d'eorts pour que l'accès soit facile : nous pouvons voir sur la page de documentation pour les développeurs qu'il existe des SDK pour java, android, ios,.net, PHP, ruby... Ils ont même créé des plugins pour Éclipse an de pouvoir réaliser des projets de types AWS 10. Des ressources virtualisées adaptables Les ressources qui sont empruntées sur le cloud (qu'il s'agisse de stockage ou bien d'unité de calcul) sont virtualisées. Ceci permet notamment de faire tourner plusieurs OS en même temps sur une même machine physique tout en assurant l'isolation. Des plus elles sont facilement adaptables, nous pouvons ainsi créer des ressources qui sont spécialisées 7. http://aws.amazon.com/ec2/pricing/ 8. Spot instances 9. Reserved instances 10. Amazon Web Service 7

pour l'utilisation qu'en fait une application. Nous noterons cependant qu'il existe des catalogues de ressources pré-congurées an de faciliter leur utilisation. Pour avoir une idée : Amazon EC2 met à disposition des ses utilisateurs 1197 images 11 à l'heure à laquelle ce rapport est écrit! 4) Modèles de déploiement cloud Il existe quatre modèles de déploiement cloud dénis dans [12] Public Le cloud est provisionné pour être utilisé par n'importe qui (société, personne isolée...). Il peut appartenir et être maintenu par une société (e.g. un cloud provider), une université, une organisation gouvernementale... Des exemples de clouds publics sont : Amazon 12, rackspace 13, google 14, salesforce 15 Privé Le cloud est provisionné uniquement pour une seule organisation qui contient de multiples clients (diérentes unités qui travaillent sur diérents projets par exemple). L'infrastructure peut appartenir à l'organisation ou à une tierce partie. Des exemples d'outils qui permettent de réaliser des clouds privés : OpenNebula 16, eucalyptus 17 Pour ces clouds, il est tiré avantage de la consolidation de l'infrastructure d'une société. Dans [4], l'exemple d'intel est donné. Ils avaient plus de 100 datacenters répartis dans le monde, en 2008 ils ont réussi à diminuer le nombre de datacenters à 75, réduisant ainsi leur coût de 95 millions de dollars. Communautaire Le cloud est provisionné pour être utilisé par des utilisateurs dont le centre d'intérêt est commun. Nous pourrions par exemple penser aux clouds inter-universitaires qui sont en train de se développer 18. Hybride L'infrastructure est une composition des modèles précédents. Ce type de cloud utilise une des technologies standardisées an de pouvoir utiliser diérents clouds en même temps. 11. https://aws.amazon.com/amis?_encoding=utf8&jiveredirect=1 12. http://aws.amazon.com/ec2/ 13. http://www.rackspace.com/cloud/cloudi_hosting_products/ 14. https://developers.google.com/appengine/ 15. http://www.salesforce.com/ 16. http://opennebula.org/ 17. http://www.eucalyptus.com/ 18. http://www.educpros.fr/detail-article/h/d337fabe56/a/cloud-universitaire-francilien-une-etude-sur-le html 8

Ce genre de cloud permet à la fois de consolider les ressources internes (privées) d'une entreprise et à la fois de répondre à des pics de demandes sans avoir des sur-provision en utilisant des ressources publiques. Ce genre de cloud est notamment soutenu par Open- Nebula que nous décrirons plus loin. 5) Modèles de services Nous distinguons principalement trois modèles de service (sous forme de couches) oerts par le cloud, représentés sur la gure 2.3. Ces 3 modèles sont décrits dans [12] et [5] Figure 2.3 Modèles de services dans le cloud [24] Infrastructure as a Service (IaaS) L'ore est alors constituée de ressources virtualisées à la demande. Ces ressources peuvent être : du stockage ou des capacités de calcul. Le client peut donc provisionner son infrastructure sur demande en fonction de ses besoins. Dans ce modèle nous parlerons souvent de machines virtuelles (VM). Un des grands exemples dans le domaine est Amazon EC2 19 Platform as a Service (PaaS) Dans ce modèle, en plus de l'infrastructure, le provider ore une framework pour développer de nouvelles applications indépendamment de la conguration physique sous-jacente. Par exemple une application ne va pas forcément savoir qu'elle tourne sur plusieurs processeurs ou même sur plusieurs machines physiques. Un des grands exemples dans le domaine est Google App Engine 20 qui fournit des SDK 21 pour Java, python et Go. 19. http://aws.amazon.com/ec2/ 20. https://developers.google.com/appengine/ 21. Software development kit 9

Software as a Service (SaaS) Dans ce derniers cas, le provider ore un programme qui fonctionne directement sur le cloud, souvent accessible depuis une interface Web. Nous voyons ce genre d'application se développer de plus en plus de nos jours, il est par exemple possible d'ouvrir des chiers words directement sur google Docs 22 D'autres programmes plus commerciaux sont également disponibles comme par exemple des CRM 23 disponibles sur Salesforce.com 24 2.1.5 Exemples d'implémentation du cloud Il existe à l'heure actuelle une poignée de logiciels de cloud management qui ont des caractéristiques diverses et qui ont déjà fait l'objet de comparaisons [15]. Dans cette section nous présentons brièvement deux implémentations de clouds qui ont des objectifs diérents. 1) OpenNebula Une large documentation est disponible sur le site ociel d'opennebula(one) : http: //www.opennebula.org. ONE est une plate-forme de management de cloud qui est Open- Source et fortement personnalisable (driver-based archtitecture). En eet ONE est écrit sous forme de framework dans lequel on peut introduire (avec plus ou moins de facilité, quoi qu'ils en disent sur leur site) de multiples drivers. Les drivers que l'on peut changer sont : les hyperviseurs, le réseau, les systèmes stockages, les accès aux clouds extérieurs et le scheduler [21]. Les hyperviseurs disponibles actuellement sont : Xen, KVM, et VMWare. Pour les clouds publics, principalement EC2. Les schedulers disponibles sont : celui à défaut et le scheduler Haizea 25 qui sera décrit plus bas. L'infrastructure globale d'opennebula est présentée sur la gure 2.4. ONE n'est en fait installé que sur une seule des machines (appelée front-end) de l'infrastructure et commande les autres (les hosts) via leur hyperviseur. Les images des vms sont quant à elles stockées, soit localement sur le front-end (elles seront alors transférées sur les hosts par ssh), soit sur un espace de stockage réseau accessible depuis tous les hosts. Le management des machines dans le cloud peut se faire par de multiples moyens : Via le CLI d'one dont les commandes sont décrites dans la documentation Via les diérentes API (xml RPC, java, ruby) Via une GUI (web service) qui s'appelle sunstone Ce genre de cloud peut être utilisé comme cloud privé ou hybride grâce à sa capacité à se connecter sur des clouds publics. Au niveau du modèle de service ; les 3 sont possibles mais l'utilisation générale d'opennebula est plutôt orientée IaaS. D'après leur site, ONE est téléchargé des milliers de fois par mois et est utilisé par de nombreuses sociétés (une liste non-exhaustive est par ailleurs disponible sur leur site). 22. http://docs.google.com/ 23. CustomerRelationshipManagement 24. http://www.salesforce.com/ 25. http://haizea.cs.uchicago.edu/ 10

Figure 2.4 Structure générale d'opennebula [21] Pour nos tests, c'est ONE qui sera déployé sur le laboratoire mis à notre disposition chez Euranova. 2) Amazon Web Services Amazon est probablement un des clouds le plus connu au monde et un des plus utilisés. Il arrive régulièrement en tête lors de divers ranking. Au début en 2002, AWS (Amazon Web Services) ne proposait que de quelques services pour les autres sites web. Mais le projet a rapidement pris de l'ampleur suite au lancement en 2006 du service EC2. Il s'agit d'un cloud public qui propose une ore très large dans des domaines variés 26 : des ores IaaS (exemple : EC2 27 lancé en 2006), des ores SaaS (exemple : dynamodb 28 lancé en 2012 : ore une base de données NoSQL scalable), des ores PaaS (exemple : Elastic Beanstalk 29 : framework pour déployer des applications sur le cloud d'amazon). Chaque service étant livré avec une ou plusieurs API. Le système de tarication appliqué par Amazon dépend du service, de la qualité et de la quantité demandée. Les tarications peuvent être complexes et éventuellement variables (il existe des systèmes d'enchères sur des VM (Spot instances) par exemple). 2.2 Nouveaux challenges 2.2.1 Introduction Dans cette section, nous commencerons par relever les challenges encore présents de nos jours dans le domaine du cloud. Ensuite nous allons extraire un challenge en particulier et voir quelles sont les réponses déjà existantes ainsi que leurs performances. Nous en 26. Liste des services : http://en.wikipedia.org/wiki/amazon_web_services#list_of_aws_products 27. http://aws.amazon.com/documentation/ec2/ 28. http://aws.amazon.com/documentation/ec2/ 29. http://aws.amazon.com/documentation/elasticbeanstalk/ 11

analyserons deux en particuliers. Enn nous déterminerons les questions restant ouvertes qui feront l'objet de la suite du mémoire. 2.2.2 Dénition Grâce au cloud, on a vu qu'il était possible d'adapter la taille de son infrastructure, en fonction des besoins d'une application. Cependant, on peut se demander si l'utilisation de machines virtualisées (et délocalisées) ne peut pas entraîner des problèmes de performances? Comme premier exemple : si une machine située en Belgique doit communiquer avec des machines virtuelles situées aux Etats-Unis, il peut y avoir des délais. Les applications sont plus ou moins sensibles à ce genre de problèmes selon leur nature. Prenons le cas des jeux en ligne massivement multi-joueurs où les temps de réponse des serveurs (Ping) doivent être le plus petit possible (de l'ordre de 100ms), nous remarquons que les clients du jeu sélectionnent systématiquement des serveurs qui sont les plus proches possibles des joueurs an de ne pas entraîner de latences. Au contraire, si nous prennons des applications qui font de gros calculs par bloc (batch), le temps de réponse est moins critique. Nous noterons cependant qu'avec la bre optique, ce genre de problème est moins important. D'autre part, la centralisation peut aussi amener des pannes à plus grandes échelles. Que se passe t-il quand un grand provider tombe en panne? C'est arrivé à Amazon (plusieurs fois!), ces pannes ont impacté une grande partie du web (surtout aux États-Unis) et auraient eu des retombées économiques lourdes, dicilement quantiables 30. On peut également se demander quels sont les impacts des éventuelles migrations en live que les providers peuvent opérer durant l'utilisation des ressources virtuelles, sachant également que certains providers se laissent le droit de réaliser des migrations à tout moment. D'autre part, on décrit souvent le temps d'obtention d'une ressource par le plus vite possible. Néanmoins les garanties ne sont pas toujours bien dénies par les providers et beaucoup d'éléments peuvent faire varier le temps d'obtention d'une ressource. Ce temps pour délivrer est appelé preparation overhead dans [20].Dans cet article, ils prennent en considération : le temps de transfert d'une image jusqu'à l'host (qui dépend lui même des capacités du réseau ainsi que de son occupation et de l'état des host disponibles) le temps de booter sur l'image (dépend de la machine physique sous-jacente, de l'os, des stacks de services à démarrer...) Certaines applications spéciques, que nous décrirons dans le prochain chapitre peuvent être particulièrement sensibles à ce problème. Pour certaines applications, une ressource qui arrive trop tard est une ressource inutile. Dès lors certaines solutions ont été trouvées pour essayer de palier au problème. Nous en décrirons deux dans la section suivante : le scheduler Haizea (utilisable dans OpenNebula) qui introduit la notion de réservation pour les ressources et le scheduler DRS (VMWare) qui réalloue les ressources à la volée. 30. http://www.informaticien.be/news_item-14368-amazon_web_services_encore_touche_par_ une_panne.html 12

2.2.3 Réponses Suite au problème depreparation overhead nous analyserons ici deux solutions permettant de réduire l'impact de ce problème. 1) Haizea Pour écrire cette section, nous nous sommes basés sur deux articles des créateurs d'haizea 31 : [19] et [20]. Haizea est en fait un scheduler qui ne dépend pas du cloud sur lequel il fonctionne. Introduction Les créateurs d'haizea introduisent le nouveau concept de réservations avancées pour les ressources (AR). L'idée est de pouvoir préparer un planning an de pouvoir être sûr de disposer de ressources à un moment prédéni sans délais. Ainsi, pour peu qu'on sache à l'avance quand on a besoin des ressources, Haiza assure que les ressources seront disponibles (Haizea suspendra des ressources virtuelles en cours d'utilisation si besoin est). On peut formuler une AR d'haizea en français comme étant : J'ai besoin de 10 noeuds, ayant chacun 2 CPU et 4Go de mémoire entre 14h et 16h 32. Modélisation An de réaliser leur projet, les auteurs sont passés par une modélisation mathématique du problème. Ils considèrent un lease comme étant un ensemble de machines virtuelles de taille N qui ont les mêmes requirements (processeur, mémoire, disque dur), à déployer sur ensemble d'hosts de taille P disposant ou non d'un système de chier global f. La taille des machines images étant déni par m et le taux en mégabytes par seconde auquel une machine se suspend s.on note également n i le nombre de machines virtuelles à destination de l'host i. Enn, ils dénissent e : le temps de communication des commandes depuis le cloud manager jusqu'à l'host. Le temps pour éteindre une machine devient : { max(n0, n t s = N.e + 1...n P ). m s sif = local N. m s sif = global On obtient de manière similaire le temps pour allumer une machine en remplaçant s par r le taux en mégabytes par seconde auquel une machine reprend. Graphiquement, on peut voir sur la gure 2.5 qu'ils essayent de prédire les temps t s = C B et t r = D E. Les machines entre C et D étant les machines qui font partie de l'ar. Expérience Les auteurs ont ensuite fait des expériences an de pouvoir déterminer des valeurs de e,s et r. Ils développent ensuite le scheduler sur base des temps calculés et testent leur scheduler dans un laboratoire avec la conguration décrite dans [20]. Ils présentent ensuite graphiquement (voir g 2.6) leurs résultats en calculant la précision(a) de leur modèle comme étant le rapport entre le temps observé( t s ) et le temps attendu(t s ) : a = t s ts. On 31. http://haizea.cs.uchicago.edu/ 32. Exemple tiré (et traduit) de leur site 13

Figure 2.5 Calcul Ts et Tr [19] remarque que le modèle tend à surestimer le temps nécessaire pour reprendre ou suspendre une machine sauf dans le cas où il a beaucoup de machines virtuelles sur un même host. En conséquence avec ce modèle, on arrivera la plus part du temps, à allouer les ressources avant la deadline. Conclusion Le système proposé par Haizea permet donc en eet d'empêcher qu'une ressource arrive après qu'on en ait besoin, cependant le problème majeur de cette solution est qu'il faut pouvoir prédire précisément à l'avance quand on aura besoin de ressources, ce qui n'est pas toujours possible. Si nous reprennons l'exemple des jeux vidéos massivement multijoueurs, nous ne pouvons pas prédire avec exactitude le nombre de ressources nécessaires pour faire fonctionner les serveurs, même si des modèles de prédictions existent. 2) VMWare/DRS Introduction DRS (Distributed Resource Scheduler) est un scheduler pour la suite VMWare qui travaille avec VMotion 33 (gestion des migrations live) qui permet l'optimisation des ressources de manière automatique et du placement et des migrations des machines virtuelles [16]. 33. http://www.vmware.com/fr/products/datacenter-virtualization/vsphere/vmotion/overview 14

Figure 2.6 Précision du modèle utilisé par le scheduler Haizea [20] Modèle La suite de cette section se base sur l'article [8]. DRS utilise pour chaque VM 3 valeurs sur lesquelles se baser pour déterminer les choix de placement : 1. Reservation : ressources minimales garanties. Ceci est donc la borne inférieure. 2. Limit : ressources maximales qu'une machine virtuelle peut obtenir. C'est la borne supérieure. 3. Shares : traduit l'importance relative d'une machine. Si l'entièreté du système est à sa limite, cette machine aura une fraction des ressources relatives à cette valeur. Ils étendent ensuite le concept à des pools de machines an de pouvoir donner une certaine isolation entre des groupes logiques. Graphiquement nous nous référons à la gure 2.7. Ceci permet une certaine souplesse par rapport à des clouds comme ONE ; il est en eet possible avec VMWare DRS de changer les ressources attribuées à une machine à la volée (changer la taille du processeur virtuel, de la RAM etc). DRS va en eet essayer d'allouer mieux les ressources sur base des besoins réels d'une VM, tout en étant contraint par leur triplet de valeur : reservation, limit et share. Conclusion 15

Figure 2.7 Partage des ressources avec DRS : arbre de ressources [8] L'objectif de ce scheduler est d'obtenir une meilleure consolidation des ressources, en ayant un minium de garanties pour chacune des VM. Il résout au passage en partie le problème de l'overhead de démarrage des machines dans la mesure où il est possible d'agrandir les ressources d'une machine sans en allumer une nouvelle. Cependant, ceci ne peut-être fait que dans une certaine limite (le maximum d'un processeur). Après, il faudra quand même allumer de nouvelles machines et le problème reste entier dans ce cas là. On notera aussi que ce genre de solution dépend des capacités de l'hyperviseur à adapter dynamiquement la taille des machines virtuelles. 3) Autre D'autre scheduler expérimentaux ont vu le jour comme par exemple : [18]. Néanmoins l'objectif n'est pas de réduire le temps de démarrage des machines virtuelles, mais bien d'augmenter la consolidation dans les clouds privés. Ceci ne répond donc pas au problème que nous soulevons ici. 2.2.4 Problème restant ouvert Nous avons vu dans les points précédents qu'il existait actuellement diérents scheduler pour les clouds privés principalement, mais qu'aucun ne permettait l'accélération du démarrage de nouvelles machines virtuelles. Dès lors, nous proposons dans la suite de ce rapport une nouvelle approche qui permet de disposer de nouvelles ressources très rapidement, qui pourrait s'adapter aux systèmes qui ont besoin d'une très grande réactivité. 16

Chapitre 3 Description du problème et solution...all went to the university... M. Reynolds - Little Boxes

3.1 Base du problème 3.1.1 Introduction Certaines applications ont des besoins en termes d'infrastructures qui peuvent être très variables. Des applications de ce type existent depuis longtemps et tendent à se multiplier de nos jours avec l'apparition de nouvelles applications gourmandes en ressources mais pour des temps limités (google vocal traduction, VoIP,...). Nous noterons que la perte due à une surprovision est fonction directe de la quantité de provision en trop et non de l'application alors que la perte quand l'infrastructure est insusante est fonction de la quantité de sous provision mais aussi du type d'application ainsi que du temps depuis la début de la surcharge. Nous décrirons dans la suite, les diérentes solutions adoptées pour ce problème et nous introduirons ensuite une nouvelle solution. Nous donnerons aussi des graphiques qui donnent l'intuition des gains et coûts des diérentes solutions. Ensuite, nous créerons un modèle mathématique adapté à la nouvelle solution proposée sur lequel nous pourrons raisonner. Enn, nous comparerons la solution cloud et pool pour déterminer les avantages et les inconvénients des deux solutions. 3.1.2 Besoin d'une application Quand nous parlerons de besoins d'une application dans les points suivants, nous parlerons des besoins en CPU (et RAM) mais pas des besoins en espaces disques, souvent beaucoup moins variables et également moins coûteux de nos jours. Nous distinguerons dans les prochains points trois catégories d'applications aux besoins diérents. 1. les applications aux besoins constants 2. les applications aux besoins variables légers 3. les applications aux besoins fortement variables 3.1.3 Surprovision Avant la naissance du cloud, si une application pouvait potentiellement avoir de gros besoins, on avait tendance à créer une infrastructure large capable d'absorber les pics de charges sans problème. Bien que cette solution permette de répondre à la charge dans la plus part des cas, elle nous oblige aussi à supporter le coût de fonctionnement (électricité principalement) d'une telle infrastructure même quand on ne l'utilise pas à 100%. Ce sur-coût peut être très grand si l'application à des besoins très variables. Cette solution est pourtant la meilleure si les charges de l'application sont constantes. Graphiques Voir gure 3.1. Si les besoins d'une applications sont constants, on peut facilement prévoir la provision exacte nécessaire (et susante) pour l'application. C'est ce qui est représenté sur le premier graphique. Dans le second cas et le troisième cas, nous voyons que les ressources disponibles ne sont pas toujours susantes et parfois sont inutiles. Cette provision constante n'est donc adaptée que quand les besoins sont constants (ou prévisibles) ; dans le cas où l'on a des besoins plus variables, il faudra trouver une solution plus souple telle que celle apportée par le cloud. 18

Figure 3.1 Réactivité dans le modèle surprovision 3.1.4 Utilisation d'iaas Depuis quelques années maintenant, certaines applications ont la possibilité d'étendre leurs capacités quand le besoin se fait sentir à l'aide d'infrastructure sur demande. Nous pouvons par exemple penser à certains sites Internet qui peuvent avoir un nombre de serveurs variables qui travaillent derrière un load balancer (dont nous pouvons voir la représentation sur la gure 3.2) pour s'adapter aux charges qui sont fonction du nombre de clients. On essaye donc maintenant, de coller de plus près à la demande, an de ne pas avoir de surplus ni de manque. Figure 3.2 Exemple d'application scalable Bien que cette solution puisse paraître optimale, nous devons penser au temps qu'il faut pour mettre des nouvelles ressources à la disposition pour l'application. Si les nouvelles ressources proviennent d'une infrastructure externe, le temps d'obtention peut être très variable, tout comme les performances (exemple d'amazon : le temps pour obtenir une machine varie entre 15 secondes et 5 minutes). Si les nouvelles ressources sont internes, on peut plus facilement prédire le temps qu'elles mettront à arriver (avec des techniques comme celles d'haizea (voir 1)). Néanmoins, variables ou constantes, il existe un temps d'obtention minimal avant de pouvoir utiliser ces nouvelles ressources (temps pour lancer la machine (virtuelle), lancer et congurer les services liés à l'application). Certaines applications ont une tolérance au niveau du temps d'obtention de ces ressources tandis que d'autres en ont moins et pour celles-là une ressource qui arrive avec du retard est une ressource inutile et donc une perte nancière sèche. Nous pouvons citer l'exemple des jeux de type MMORPG. Cet exemple sera développé dans la section 3) 19

Graphiques Voir gure 3.3. Nous voyons sur le premier graphique que le cloud permet de répondre à une demande constante. En eet, dans ce cas, il sut que la demande en machines virtuelles reste constante. Nous voyons sur le deuxième et le troisième graphique que le cloud est capable de s'adapter à une demande variable. Cependant, nous voyons aussi que l'obtention de nouvelles ressources se fait par pallier, en conséquence, les ressources disponibles ne sont parfois pas susantes pendant un certain laps de temps (qui dépend du temps pour obtenir une ressources virtuelle). On voit dans le dernier graphique, que si les besoins sont fortement variables, il se peut que les ressources arrivent en retard et qu'elles ne soient donc plus utiles. Nous nous retrouvons aussi, parfois, avec trop de ressources à cause d'un pic précédent mais qui s'est déjà atténué. Figure 3.3 Réactivité dans le modèle cloud 3.1.5 Nouvelle solution L'idée de la nouvelle solution que nous proposons dans ce point est de coller le plus possible à la courbe des besoins. Pour se faire, il faut trouver un moyen pour réduire le temps de démarrage et d'arrêt d'une machine virtuelle. An d'avoir un temps de démarrage réduit, nous voudrions que les ressources soient toujours prêtes (et donc pré-démarrées et pré-congurées) pour être utilisées directement. Ceci réduit à 0 le temps de boot d'une machine virtuelle. Le problème étant que si on démarre une machine et qu'on lance les services mais que l'on ne l'utilise pas, cela revient utiliser l'ancien système de sur-provision. Nous aimerions donc trouver un moyen pour rentabiliser ces machines démarrées, mais inutilisées, le plus possible. Nous introduisons maintenant deux types de clients, aux besoins diérents, que nous utiliserons dans notre solution : 1. Les clients dont l'application nécessite une surprovision car leur application ne permet qu'une latence très faible. Ils forment un ensemble de clients que nous appellerons les clients de type SP. 2. Les clients qui veulent utiliser des services distribués ne nécessitant pas de garanties strictes sur les ressources (Nous décrirons un service de ce type dans la section : 2) appelé Boinc). Le service oert à ces clients est en eet susceptible d'être interrompu à n'importe quel moment sans délais. Ils forment un ensemble de clients que nous appellerons les clients de type B. L'idée est que les clients de type SP mettent leurs machines de sur-provision dans un pool, et à disposition des clients de type B quand ils n'en ont pas besoin. Cependant, certaines garanties sont apportées pour chacun des clients : 20

1. Pour les clients de type SP, ils peuvent à tout moment récupérer leurs machines (qu'elles soient utilisées par un client de type B ou non) avec un temps extrêmement réduit : le temps d'arrêter le service du client de type B. 2. Pour les clients de type B, des prix attractifs, moins chers que des ressources dédiées équivalentes mais avec des garanties moindres. Les clients de type SP rentabilisent donc mieux leurs machines car ils louent leurs ressources aux clients de type B quand ils n'en ont pas besoin tout en gardant une réactivité très grande. Du côté des clients de type B, ils protent de machines à coûts réduits. An d'assurer l'équité pour les clients de type SP, les gains générés par l'emprunt des machines de surprovision seront redistribués dans une proportion égale aux machines qu'ils ont mis à disposition. Le mécanisme de pool est présenté sur la gure 3.4. Nous voyons sur le schéma les utilités possible d'une machine, soit utilisée par un client de type SP, soit utilisée par un client de type B, soit utilisée par personne : pool. Nous remarquons aussi qu'il y a des opérations en pointillés, cela signie qu'aucune garantie n'est assurée sur ces actions. Figure 3.4 Système de pool : haut niveau Graphiques Voir gure 3.5. On voit sur le premier graphique que quand la demande est prévisible, le pool permet de coller parfaitement aux besoins. On voit dans le deuxième et le troisième graphique, que la courbe des besoins est mieux approximée par les ressources disponibles. Cela vient du fait que le temps mis pour mettre en route les ressources est plus court. En eet, le temps pour obtenir une ressource est maintenant réduit au temps qu'il faut pour interrompre le service qu'utilise le client de type B. Typiquement sous linux l'arrêt de service (via la commande service) est quasi instantané, le test a été eectué sur une machine virtuelle avec un service boinc : il faut en moyenne 50 msec pour éteindre le service. Ce temps peut varier en fonction des services, mais devra toujours rester très court. En conséquence, il y a moins de sur-provision et il y a moins de sous-provision. On voit sur le dernier graphique qu'il y a aussi moins de retard sur la disponibilité des ressources. Dans le cloud, le temps d'obtention d'une ressource dépend de beaucoup d'éléments. A titre d'exemple l'obtention d'une machine virtuelle sur Amazon varie entre 15 secondes et 5 minutes. Dans le cas de notre solution, le temps pour disposer d'une ressource est uniquement réduit au temps qu'il faut pour arrêter le service des clients B. 21

Figure 3.5 Réactivité dans le modèle pool 3.1.6 Modélisation mathématique Nous décrirons ici un modèle mathématique qui nous permettra de mieux comprendre les graphiques ainsi que les enjeux du problème. Nous avons entièrement créé ce modèle. 1) Coûts liés à l'écart entre provision et charge réelle On dénit (en rose sur les graphiques) la fonction représentant la charge réelle dont l'application a besoin pour fonctionner correctement (sans latences...). r(t) : T C T représente un intervalle de temps et C l'ensemble des charges possibles. On dénit (en vert sur les graphiques) la fonction représentant charge acceptable (ce qui est provisionné) a(t) : T C On dénit ensuite la fonction : diérence entre charges réelles et acceptables. d(t) : r(t) a(t) On dénit les fonctions : sous-provision (p ) et sur-provision (p + ) p (t) = { d(t) si d(t) > 0 0 sinon p + (t) = { d(t) si d(t) < 0 0 sinon A l'aide des fonctions précédentes, nous pouvons maintenant dénir la fonction : coût total généré par l'écart entre les charges réelles et les charges acceptables. t t cp(t) = ( d (t) dt).β + ( d + (t) dt).α 0 0 22

Nous avons ici introduit deux nouveaux facteurs : α et β. Le facteur alpha, dans le cas de la sur-provision, est directement lié au coût de fonctionnement des machines en trop et est indépendant du type d'application. Le facteur β, dans le cas de la sous-provision, est lié à l'application elle-même : en eet, certaines applications peuvent admettre une certaine latence, la valeur de β sera alors petite, voire égale à 0, pour d'autres applications, il se peut que la latence ne soit pas permise et entraîne un coût important, dans ce cas là, la valeur de β peut être grande. 2) Partage des coûts Premier modèle Pour ce premier modèle, nous considérons qu'il existe un client dont l'application nécessite de la sur-provision (a) disposant (constamment) de n vms de surprovision et un client qui désire avoir des machines pour faire des calculs à bas prix mais dont les garanties sont moindres (b), le service de b pouvant à tout moment être interrompu. Nous noterons γ le coût normal d'une machine virtuelle, δ la réduction de coût pour un client de type B et donc par extension γ δ le coût d'une machine quand un client de type B en demande une. On considère que le coût de fonctionnement instantané de n machines pour le client a au moment t est constant et vaut γ. c(t) = ci(t) = n.γ t 0 ci(t) dt = n.γ.t Avec la solution du pool, le client a va donner un accès (limité) à ses machines en trop à un prix attractif pour b, sachant que b n'aura pas beaucoup de garanties sur les vms dont il disposera. An que ce soit attractif pour b, le prix d'une machine doit être inférieur au prix d'une machine normale (γ) orant des garanties supplémentaires. On notera cette diérence δ. Le prix d'une machine pour b est donc γ δ. Le nombre de machines louées au moment t par b est noté : l(t) : t {0, 1,..., n} Le coût constant supporté par le client a est noté : cca(t) = n.δ Le coût variable supporté par le client a est noté : cva(t) = (n l(t)).(γ δ) Le coût total supporté par le client a est noté : ctai(t) = cca(t) + cva(t) cta(t) = t 0 23 ctai(t) dt

En développant ctai(t) : ctai(t) = cca(t) + cva(t) = nδ + (n l(t)).(γ δ) = nδ + nγ nδ l(t)γ + l(t)δ = nγ l(t)(γ δ) Le premier terme est donc le prix standard de n machine virtuelle alors que le deuxième terme reprend la réduction provenant de l'utilisation des machines par les utilisateurs de types B. Le coût constant supporté par le client b est 0 et le coût variable est noté : cvb(t) = l(t).(γ δ) Le coût total supporté par le client b est noté ctb(t) = t 0 cvb(t) dt Au nal, le coût c(t) est partagé entre le client a et le client b. c(t) = cta(t) + ctb(t) Ce qui, graphiquement peut être vu comme sur la gure 3.6. Le premier graphique montre le coût d'une machine virtuelle en provision, si on n'utilise pas le système de pool. Dans le second et troisième graphique on voit le partage des coûts si on utilise le système de pool. L'aire, entre la courbe rose et la courbe rouge, est le coût constant minium pour le client SP. C'est en quelque sorte le prix qu'il paye pour pouvoir récupérer sa machine très rapidement, à l'inverse c'est la réduction pour le client B qui a moins de garanties. Ensuite, on voit le partage des coûts entre client SP et B par la courbe verte qui divise en 2 parties l'aire du rectangle formé par l'abscisse et la courbe rose. Le coût total du client SP est donc la surface verte tandis que le coût du client B est la surface bleue. Deuxième modèle Pour ce deuxième modèle, nous ajoutons plusieurs nouveaux éléments : il y a ɛ clients qui ont de la surprovision (SP) et qui forment l'ensemble S = {1,.., ɛ} il y a ζ clients qui veulent faire des calculs à bas prix et qui forment l'ensemble B = {1,..., ζ} le nombre de machines mises dans le pool par les clients qui surprovisionnent est variable Le nombre de machines mises par un client SP s S à un moment t dans le pool est noté : p s (t) = n (n N) 24

Figure 3.6 Partage des coûts de fonctionnement des VMS Étant donné qu'il y a plusieurs clients de type SP, nous devons maintenant savoir pour chacun des clients SP, s'ils utilisent leurs machines qui sont dans le pool pour eux-même ou non (elles sont donc soit idle, soit utilisées par un client B dans ce cas là). Ceci nous permettra plus tard de répartir les gains provenant de l'utilisation des machines SP équitablement entre tous les clients SP. Nous modélisons ceci avec deux fonctions : u représentant le nombre de machines utilisées à des ns personnelles et v celles qui ne le sont pas pour chacun des client SP s S : u s (t) = n {0,.., p s (t)} v s (t) = p s (t) u s (t) Nous reprenons également le concept du nombre de machines utilisées par chacun des clients B b B comme étant : l b (t) = n {0,..., s S v s (t)} avec la contrainte : l b (t) v s (t) s S b B Le coût constant supporté par un client est 0 et le coût variable supporté par un client B b B au temps t et le coût total sont donc : cvb b (t) = l b (t).(γ δ) ctb b = t 0 cvb b (t) dt 25

Passons maintenant au client de type SP s S au temps t. Son coût constant peut être décrit comme : cca s (t) = p s (t)δ et son coût variable : s S cva s (t) = u s (t)(γ δ) + v s (t) v s(t) b B l b(t) s S v (γ δ) s(t) Dans cette formule, le terme de gauche représente l'utilisation des vms par un client SP pour lui-même. Le terme de droite représente le coût de la non-utilisation (par les clients de type B) des vms libres présentes dans le pool. La fraction permet de répartir le coût équitablement entre tous les clients SP en fonction du nombre de machines et du temps qu'elles ont été mises à disposition pour les clients de type B. Le coût total pour un client SP s S devenant donc : ctai s (t) = cca s (t) + cva s (t) cta s (t) = t 0 ctai s (t) dt Comme pour la première modélisation nous pouvons développer ctai s (t) : ctai s (t) = cca s (t) + cva s (t) s S = p s (t)δ + u s (t)(γ δ) + v s (t) v s(t) b B l b(t) s S v (γ δ) s(t) s S = p s (t)δ + (p s (t) v s (t))(γ δ) + v s (t) v s(t) b B l b(t) s S v (γ δ) s(t) = p s (t)δ + p s (t)γ p s (t)δ v s (t)γ + v s (t)δ + v s (t) = p s (t)γ v s (t)(γ δ) + v s (t) = p s (t)γ v s (t)(γ δ)(1 = p s (t)γ v s (t)(γ δ)( b B = p s (t)γ v s (t)(γ δ)( l b(t) s S v s(t) ) b B = p s (t)γ v s (t) l b(t) s S v (γ δ) s(t) s S v s(t) b B l b(t) s S v (γ δ) s(t) s S v s(t) b B l b(t) s S v ) s(t) s S v s(t) ( s S v s(t) b B l b(t)) s S v s(t) s S v s(t) b B l b(t) s S v (γ δ) s(t) ) De même que pour la première modélisation, nous pouvons dire du terme de gauche que c'est le prix standard pour les machines virtuelles créées par un client SP tandis que le terme de droite est la réduction qui vient de l'utilisation des machines du pool par les clients B 3) Partage des gains Premier modèle 26

Au niveau des gains obtenus par le client a : Et ceux obtenus par le client b : gia(t) = (γ δ).l(t) ga(t) = t 0 gia(t) dt gib(t) = (δ).l(t) gb(t) = t 0 gib(t) dt Graphiquement : gure 3.7. La surface verte : les gains du client a, la surface bleue, les gains du client b. Figure 3.7 Gains par client Deuxième modèle Au niveau des gains obtenus par un client de type SP s S : b B gia s (t) = v s (t) l b(t) s S v (γ δ) s(t) ga s (t) = t 0 gia s (t) dt Et ceux obtenus par les client de type B b B : gib b (t) = (δ).l b (t) gb b (t) = 3.1.7 Comparaison Cloud et Pool Cloud t 0 gib b (t) dt 27

Si nous considérons un laps de temps donné et que nous considérons le facteur α constant (nous considérons que le coût des machines dans le cloud est constant), le coût d'écart entre provision et charges réelles n'est plus lié qu'au facteur β. Si β vaut 0, cela signie que l'application n'est pas du tout sensible au latence et qu'elle peut sans problème attendre l'arrivée d'une ressource. Au plus β est grand, au plus les latences tolérées par l'application sont petites. Pool Si nous considérons un laps de temps donné et que nous considérons le facteur β nul car nous considérons qu'il n'y a plus aucune perte liée à une sous-provision, car les ressources arrivent toujours à temps, le coût ne dépend plus que de la sur-provision qui est considérée dans le facteur α. Dans la solution du pool, la valeur de ce facteur dépend de l'utilisation des clients de type B des services oerts par les machines qui sont dans le pool. Nous pouvons donc déterminer 3 cas principaux (sur la gure 3.8) : 1. Si l'utilisation des ressources du pool est à 0%, la surprovision coûtera le plus cher possible. Nous nous trouvons donc sur la droite horizontale la plus haute 2. Si l'utilisation des ressources du pool est à 100%, le coût de la surprovision est le moins cher possible. Nous nous trouvons donc sur la courbe horizontale la plus basse sur le graphique 3. enn, l'utilisation du pool peut varier entre ces deux cas limites, nous nous trouvons alors sur une droite horizontale qui se trouve entre les deux sur le schéma Graphiquement Voir gure 3.8. En rouge, on voit le coup de l'écart de provision dans le cas du cloud, qui dépend directement de β et en vert, nous voyons plusieurs courbes représentatives de valeur de α diérentes. On voit donc sur ce graphique que la solution pool est intéressante après l'intersection des courbes. Figure 3.8 Comparaison cloud VS pool 28

3.1.8 Analyse des gains et des coûts de la nouvelle solution Nous analyserons dans le point suivant les gains et les coûts pour les deux acteurs en présence dans ce modèle : d'une part nous avons les gestionnaires de l'application que nous appellerons clients et d'autre part nous avons les fournisseurs d'infrastructure (IaaS) que nous appellerons providers. 1) Clients Coûts machines Nous distinguons les 3 cas pour le coût de fonctionnement d'une machine. 1. Sur-provision : les machines appartiennent à la société. Le coût xe d'une machine est le coût d'achat de celle-ci. Ensuite, il y a le coût variable qui comprend notamment la consommation électrique, la maintenance, le bâtiment qui les contient, la sécurité... 2. Cloud : dans le cas du cloud, le coût de fonctionnement d'une machine est fonction du temps de consommation 3. Pool : le coût constant est fonction du nombre de machines de sur-provision dont on dispose, on doit rajouter à cela un coût variable qui dépend du pourcentage d'utilisation des machines qui sont restées dans le pool. Pertes liées à la provision La perte liée à une mauvaise provision peut être représentée comme l'aire entre les courbes des graphiques présentés. On distingue cependant deux cas : 1. Si les charges acceptables sont au-dessus des charges réelles, la perte est fonction directe du coût de fonctionnement des machines. Le coût de fonctionnement des machines étant lui fonction du modèle utilisé. Ce coût est donc α l'intégrale de la diérence des deux fonctions quand les charges acceptables sont supérieures aux charges réelles. 2. Si les charges acceptables sont au-dessous des charges réelles, la perte n'est plus fonction du modèle mais bien de l'application elle-même. Certaines applications ont une tolérance aux latences, alors que d'autres n'en ont pas. Ce coût est donc β l'intégrale de la diérence des deux fonctions quand les charges acceptables sont inférieures aux charges réelles. 2) Providers Sur-provision Dans le cas de la sur-provision, ce sont les clients eux-mêmes qui s'occupent de leur propre parc de machines. Il n'y a donc pas d'acteur provider dans ce cas. Cloud Pour le cloud, les providers ont comme coût xe, l'achat des machines et comme coût variable le fonctionnement des machines. Ce coût est donc déplacé depuis les clients jusqu'au provider. Mais ce dernier utilise les mêmes machines pour plusieurs clients réalisant ainsi des gains de mise à l'échelle. Les providers vont cependant essayer de réduire le coût de fonctionnent de leur parc, en mettant le plus possible les machines inutilisées en veille, ou bien éteintes. Ce système, bien qu'économique engendre une latence quand les clients demandent des nouvelles VM. 29

Pool L'idée du pool se base celle du cloud, mais en pré-démarrant des machines, ce qui a pour eet d'accélérer l'allocation des machines aux clients. Le problème est que les machines qui sont dans ce pool consomment de l'énergie et sont donc coûteuses pour le provider pendant le temps qu'elles ne font rien dans le pool. L'idée pour essuyer cette perte est d'une part de rendre le service pour les clients plus cher (nous mettons une valeur sur le temps d'allocation court de la machine) ainsi qu'un coût xe réduit pour disposer de l'accès à ce pool et d'autre part, d'allouer les machines qui sont dans le pool, à d'autres types de clients, dont les besoins sont grands mais donc les calculs peuvent être facilement arrêtés. 3.2 Applicabilité 3.2.1 Introduction Dans cette section nous expliquerons les diérentes possibilités d'applications du concept. Nous donnerons d'abord les applications pour les clients de type SP et ensuite les celles pour les clients de type B. 3.2.2 Utilisateurs de type SP Pour rappel, les clients SP sont ceux dont les applications ne supportent pas les délais quand elles ont besoin de ressources. 1) Applications aux requirements spéciaux De manière générale, la première applicabilité est celle dont toutes les applications nécessitent une grande puissance de calcul sur des moments très courts. Typiquement ces applications vont avoir des besoins en ressources très variables. Exemple Dans cette catégorie d'application : traduction vocale instantanée (sur des smartphones Android par exemple 1 ), la puissance de calcul requise, pour traduire instantanément la parole, est élevée et nécessite beaucoup de ressources. Mais, d'une part, nous ne savons pas quand les clients vont appeler, il est donc dicile de savoir quand nous aurons besoin des ressources et d'autre part, le client ne désire pas attendre 5 minutes avant de pouvoir passer son coup de téléphone. Nous sommes donc bien dans le cas d'une application à besoins fortement variables non-prédictibles. 2) Démonstrations live Dans l'article [10]. Steve Jin, membre senior du sta technique chez VMWare, fondateur de VMware Infrastructure (vsphere) Java API et auteur du livre [9] présente une utilisation possible du système de pool pour des présentations live qui supportent mal une attente de 5 minutes avant qu'une machine virtuelle ne soit disponible pour une démonstration. 1. http://googletranslate.blogspot.be/2011/10/start-conversation-with-google.html 30

3) Exemple : MMOG Nous donnerons dans cette section un exemple concret basé sur le cas des Jeux en ligne massivement multi-joueurs. Pour ce faire, nous nous sommes basés sur les résultats de [14] et [6]. Le problème principal pour les jeux de type MMOG est qu'ils nécessitent une garantie très forte en termes de réactivité. En eet si deux joueurs s'arontent mais qu'un des deux peut envoyer 10 commandes avant même que l'autre ait pu se rendre compte de quoi que ce soit, le jeu perd fortement de son intérêt...un temps de réponse classique pour ce genre de jeux est de maximum 100ms. Par ailleurs, les ressources nécessaires à un temps donné sont dicilement prévisibles, car elles dépendent du nombre de joueurs mais également du nombre de commandes qu'ils envoient au serveur. En conséquence, les sociétés qui commercialisent ce genre de jeu, utilisent de grandes infrastructures statiques capables d'absorber des grands pics d'utilisation mais qui ne sont, pour la plus part du temps, pas utilisées entraînant un coût important en infrastructure. Les auteurs tentent donc de changer l'allocation statique en allocation dynamique tout en gardant la qualité de jeu. Dans leurs expériences, ils montrent, qu'ils peuvent arriver à produire un système dont l'utilisation des ressources serait entre 5 et 10 fois meilleure. Cependant : ils montrent aussi que la qualité de jeu peut-être parfois dégradée, quand des ressources arrivent en retard. Notre solution permettrait donc ici, d'arriver à apporter les machines plus rapidement pour ne pas dégrader la qualité de jeu, tout en mitigeant le prix de la surprovision, en orant des services à bas prix. Si on considère l'évolution de la popularité des ces jeux ces dernières années, comme on peut le voir sur la gure 3.9, l'économie apportée par ce système pourrait être conséquente. 3.2.3 Utilisateurs de type B Pour rappel, les utilisateurs de ce type sont des utilisateurs qui veulent exploiter des ressources de calculs à prix moindre mais avec peu de garanties. 1) Caractéristiques des services oerts Les clients peuvent demander une quantité des ressources pour un service donné, qui pourra leurs être attribuée selon les disponibilités. Il doivent être prêts à utiliser le service quand on leur fournit les ressources. Dans le même temps, les ressources peuvent être retirées à tout moment. Le service sera alors immédiatement stoppé, sans délais. La facture se calcule uniquement sur l'utilisation réelle des ressources par les utilisateurs. 2) Exemple : service Boinc Dans cette section nous donnerons un exemple de service pouvant être utilisé via le pool appelé BOINC. Les documents ayant servis de base à la construction de cette section sont ceux disponibles sur le site ociel de boinc : http://boinc.berkeley.edu/ 31

Figure 3.9 Évolution du nombre de joueurs pour les jeux MMOG [14] Introduction à Boinc Boinc est un middleware qui permet de réaliser des calculs distribués sur un grand nombre de noeuds dont la première release date d'avril 2002. Le principe de boinc est d'avoir un serveur central qui va ordonnancer les calculs à faire sur chacun des noeuds, exécuter les calculs sur les noeuds et ensuite récupérer les résultats pour les contrôler et les intégrer, s'ils sont considérés comme corrects (plusieurs noeuds peuvent faire le même calcul an de voir si tous s'accordent sur le résultat). Schématiquement, l'architecture d'un projet de type Boinc est représenté sur la gure 3.10. Pour pouvoir utiliser Boinc, il faut donc avoir un projet dont les calculs sont facilement divisibles en petites tâches. Isolation et accès à distance Le service Boinc garantit l'isolation des calculs qui sont faits sur la machine. Le service n'ore aucun accès au reste de la machine qui fait les calculs. De plus, il est possible de gérer le service à distance, via une CLI disponible sur le site BOINC 2. Il ne faut donc pas être localement sur la machine pour contrôler le service. Boinc société VS bénévole Boinc à deux types d'utilisation : 1. L'utilisation par une société privée : pour ce faire, elle doit installer un serveur Boinc, le congurer et puis installer les clients sur les diérents noeuds qui serviront pour réaliser les calculs 2. L'utilisation bénévole : Boinc met à disposition, sur son site, des clients qui peuvent être utilisés pour participer à des calculs bénévolement, pour ce faire, il sut d'installer un client Boinc, choisir son projet et congurer le client. Il est notamment 2. http://boinc.berkeley.edu/wiki/controlling_boinc_remotely 32

Figure 3.10 Architecture d'un projet Boinc(http://www.boinc-wiki.info/) possible d'utiliser boinc quand le processeur ne fait rien. Ceci permet de récupérer des unités de calculs sans altérer les performances de l'ordinateur qui met à disposition sa machine. Pour donner une idée de l'ampleur de l'utilisation d'un tel système, en date de l'écriture de ce mémoire : 270 milliers de volontaires 405 milliers d'ordinateurs +/ 50 projets directement disponibles sur le site ociel. De nombreux autres projets sont disponibles non-ociellement Moyenne de calcul sur 24 heures : 5.925 PetaFLOPS 3. A titre de comparaison, l'ordinateur le plus puissant en juin 2012 est le super-ordinateur IBM Sequoia avec 16,32 petaflops 4 comptabilisant 1.572.864 cores...et un ordinateur de bureau avec un processeur peut disposer de 100 gigaflops. 2 projets sont même dans les dépôts ociels Ubuntu (SETI@Home 5 et MILKY- WAY@Home 6 ), rendant l'accès au projet possible en un clic. Exemples de projet 3. FLoating point Operations Per Second : unité de mesure de la vitesse informatique d'un système 4. http://www.top500.org/lists/2012/06 5. http://setiathome.berkeley.edu/ 6. http://milkyway.cs.rpi.edu/milkyway/ 33

Un exemple de projet populaire disponible via Boinc est le projet SETI@Home 7 : projet qui vise à détecter toute forme de vie intelligente extraterrestre. Les noeuds analysent des données provenant de l'observatoire d'arecibo 8 qu'on peut voir sur la gure : 3.11. Le ux de donnés provenant de cette antenne étant très important et les moyens pour les traiter limités : Boinc s'avère très utile pour ce genre de calculs. Figure 3.11 Observatoire d'arecibo utilisé dans le projet SETI@Home Un autre exemple de projet est Hashclash. Ce projet est actuellement terminé, l'objectif était de montrer des vulnérabilités dans MD5. Le programme dont ils se sont servis, décrit dans [22], s'est servi du framework Boinc (avec succès) pour accélérer le processus. 7. Search for ExtraTerrestrial Intelligence 8. http://www.naic.edu/ 34

Chapitre 4 Implémentation de la solution...where they were put in boxes... M. Reynolds - Little Boxes

4.1 Description de la solution 4.1.1 Introduction Dans cette section, nous décrirons l'implémentation qui a été faite de la solution. Dans un premier temps, nous présenterons le modèle d'acteurs ainsi qu'un diagramme de séquence reprenant les principales actions disponibles dans le programme. Nous décrirons ensuite les techniques des communications utilisées ainsi que les formats des messages qui seront échangés entre les diérents acteurs. Nous donnerons ensuite le modèle objet qui a servi de base à la construction du serveur et qui permet la personnalisation du projet. Ensuite, nous expliquerons les algorithmes utilisés pour calculer les factures des diérents clients ainsi que les moyens mis en place pour conserver toutes les traces des utilisations. Nous terminerons avec léger manuel de l'application ainsi qu'une procédure d'installation. 4.1.2 Modèle d'acteurs Dans ce point, nous énumérerons les 4 types d'acteurs qui rentrent en compte dans la solution et nous dénirons leurs rôles. Client SurProvision SP Ce sont les clients qui ont des machines en surprovision (clients SP) et qui veulent les rentabiliser un maximum. Pour cela, ils doivent pouvoir : 1. Ajouter/supprimer de nouvelles vm dans un pool. 2. Demander en retour une des vm qui leur appartient pour l'utiliser 3. Rendre une des vm qu'ils utilisent pour la remettre dans le pool 4. Demander l'état actuel de leur compte Client Boinc B Nous les nommons ainsi, car il s'agit du seul service (dans cette implémentation) qui puisse être utilisé quand des vms sont dans le pool. Pour cela, ils doivent pouvoir : 1. Augmenter/diminuer leur demande en vms pour le service 2. Demander l'état actuel de leur compte Administrateur Il doit pouvoir eectuer plusieurs tâches pour la gestion du (des) pool(s) : 1. Ajouter/supprimer des clients de type SP ou bien de type B 2. Ajouter/supprimer des nouveaux pools de vms 3. Voir l'état des pools 4. Générer la comptabilité des Pools Le serveur pool 36

C'est le serveur que les clients/administrateurs vont devoir contacter pour leurs demandes. Il doit pouvoir répondre aux demandes des diérents acteurs. De plus, le serveur peut-être interrogé localement par un utilisateur, pour voir l'état du pool (à l'aide d'une CLI 1 ). Ce serveur sera principalement constitué de 3 threads : 1. Le premier thread servira pour recevoir les commandes provenant des clients qu'ils soient de type SP ou bien de type B. 2. Le deuxième thread servira pour recevoir les commandes provenant des administrateurs. 3. Le troisième thread servira pour pouvoir utiliser un CLI directement sur le serveur, an de pouvoir l'interroger directement sur l'état du pool. Par ailleurs chaque commande reçue depuis un client ou bien depuis un administrateur sera lancée dans un nouveau thread qui se terminera tout seul une fois la commande exécutée. Graphiquement on peut voir la gure 4.1 Figure 4.1 Les acteurs du pool 4.1.3 Diagramme de séquence d'utilisation Nous allons maintenant nous intéresser à une séquence d'action classique que pourraient faire les utilisateurs du pool. Pour illustrer le propos, nous pouvons d'abord regarder le diagramme de séquence présenté dans la gure 4.2. Les 4 acteurs présents sont ceux décrits dans le point précédent. Pour ne pas compliquer le schéma, nous considérons ici qu'il n'y a qu'un seul client SP, un seul client B et un seul administrateur. Dans la pratique, il pourrait y en avoir beaucoup plus. Nous pouvons voir que les premières actions sont eectuées par l'administrateur. Celui-ci va commencer par initialiser un pool vide qui pourra par la suite être utilisé par les clients. Il va ensuite créer deux nouveaux clients, un premier client de type SP qui pourra donc ajouter (et enlever) des nouvelles machines dans un pool, qui resteront à sa disposition dès qu'il en fait la demande et un client de type B qui pourra ainsi disposer des machines libres du pool pour le service de type Boinc. 1. Command Line Interface 37

Ensuite, c'est le client de type SP qui ajoute deux machines virtuelles dans le pool. Ces deux machines sont maintenant dans le pool mais ne sont encore utilisées par personne. Ensuite, le client de type B augmente sa demande à 2. Comme il y a deux machines inutilisées dans le pool, il les reçoit et peut les utiliser directement. Ensuite le client de type SP demande une de ses machines virtuelles, comme elles sont toutes les deux utilisées par un client de type B, le serveur en prend une, interrompt le service boinc, prévient le client de type B qu'il ne dispose plus que d'une seule machine et donne cette machine au client de type SP. Après que celui-ci s'en soit servi, il la rend, et le serveur la rend à son tour au client de type B qui peut de nouveau utiliser cette machine. Le client SP décide alors de retirer complètement une de ses machines du pool. Le serveur la retire donc et prévient le client de type B qu'il ne dispose plus de cette machine. La demande du client de type B n'est cependant pas modiée, et dès qu'une nouvelle machine est libre, elle lui sera directement attribuée. Enn, nous voyons que l'administrateur demande une facturation, tout à la n, an de voir l'état des comptes des deux parties. Figure 4.2 Diagramme de séquence 4.1.4 Langage de programmation et drivers L'application est entièrement écrite en java cependant an de pouvoir utiliser les outils nécessaires au fonctionnement du programme, nous nous sommes servis des drivers suivants 38

rabbitmq client java disponible sur : http://www.rabbitmq.com/download.html sqlite driver java disponible sur : http://files.zentus.com/sqlitejdbc/sqlitejdbc-v056. jar. Il est cependant à noter, qu'en java, nous nous sommes servis du package java.sql qui ne prend donc pas en compte le type réel de base de données, il est donc très facile de changer de base de données si SQLite ne convient pas. OpenNebula java binding disponible sur : http://opennebula.org/documentation: rel3.6:java. Le programme a été créé de telle sorte que l'on puisse facilement implémenter un(des) autre(s) cloud(s) car le programme ne manipule que des machines abstraites. 4.1.5 Communication entre les acteurs Comme il s'agit d'un système distribué comme nous l'avons vu plus haut, nous avons dû choisir un mode de communication entre les diérents acteurs. Nous avons ici utilisé un système de messagerie standard (rabbitmq [2]) qui lui-même implémente les spécications AMQP 2 décrites dans [3] et mis en place des messages standards pour les commandes. 1) Messagerie standard RabbitMQ La messagerie rabbitmq en implémentant les spécications AMQP permet d'assurer les communications entre clients et serveur de manière sûre (unicité, ack, etc). De plus, AMQP étant un protocole wire-level, le serveur peut-être contacté par d'autres clients implémentant les même normes, rendant le programme facilement inter-opérable avec n'importe quel autre programme écrit dans un langage au choix. Il existe d'autres implémentations du protocole comme par exemple stormmq 3 ou Apache Qpid 4 qui propose des clients pour java, C, python, ruby,.net... 2) Standardisation des messages An d'avoir une interface standard pour les utilisateurs, nous décrivons, ici, le format des messages standards que le serveur est capable de comprendre. Format standard Le format standard d'un message est très simple, il s'agit d'un entier sur 4 bytes, suivi d'une chaîne de caractères éventuellement vide, se terminant par le caractère :' \0', contenant les paramètres de la commande. ------------------------- ID(4 bytes) param(var) ------------------------- Messages 2. Advanced message queuing protocol 3. http://stormmq.com/ 4. http://qpid.apache.org/ 39

createspclient ID : 4 (CommondCmd.CREATESPCLIENT) Acteur : Administrateur Paramètre : Aucun Description : Permet à un administrateur de rajouter un nouveau client de type SP sur le serveur. Ce client pourra par la suite ajouter ou retirer des vms dans le pool et les utiliser de manière quasi instantanée dès qu'il le désire Retour : Identiant du nouvel utilisateur SP créé Re-allocation : Non createbclient ID : 3 (CommondCmd.CREATEBCLIENT) Acteur : Administrateur Paramètre : aucun Description : Permet à un administrateur de rajouter un nouveau client de type B sur le serveur. Ce client pourra augmenter ou diminuer sa demande pour le service Boinc. Retour : Identiant du nouvel utilisateur B créé Re-allocation : Non bill ID : 11 (CommondCmd.BILL) Acteur : Administrateur Paramètre : Aucun OU un numéro de facture existant OU virtual Description : Permet à un administrateur de demander une facture pour le pool. Le calcul de la facture est décrit dans ref. Cette commande s'exécute de 3 façons diérentes en fonction du paramètre : 1. Aucun : le serveur génère alors un nouveau numéro de facture, et clôture la session au temps courant. 2. Numéro de facture existant : le serveur génère à nouveau la facture demandée et ne change rien aux données. 3. virtual : le serveur génère une facture sur base du temps courant, mais ne la clôture pas. C'est-à-dire : il n'attribue pas de numéro de facture et ne classe pas encore les données. Retour : Une description détaillée de la facture par client. Re-allocation : Non addvm ID : 5 (CommondCmd.ADDVM) Acteur : Client de type SP Paramètre : L'identiant du client qui veut ajouter une nouvelle VM dans le pool. Description : Crée une nouvelle machine virtuelle pour le client SP passé en paramètre si c'est possible. La machine ne sera créée que si l'identiant passé en paramètre est valide (il s'agit bien d'un client de type SP existant sur le serveur) et si les ressources nécessaires à la création de la vm sont disponibles. Une fois la machine créée, elle est directement mise à disposition des clients de type B mais le client à qui appartient réellement la machine peut la reprendre à tout moment. 40

Retour : Si la vm a été créée, renvoi les crédits de cette vm. Sinon renvoi Erreur, suivi d'une description du problème Re-allocation : Oui, si il existe un client de type B dont la demande n'est pas satisfaite, on peut directement lui attribuer cette VM. rmvm ID : 6 (CommondCmd.RMVM) Acteur : Client de type SP Paramètre : L'identiant du client qui veut retirer une machine virtuelle du pool Description : Supprime et libère les ressources d'une machine virtuelle du pool pour le client passé en paramètre si c'est possible (si le client détient bien au moins une VM dans le pool). Nous essayerons d'éviter de retirer une machine qui est employée par un client de type B si c'est possible Retour : Si une machine a été retirée, renvoi les crédits de la machine retirée. Sinon renvoi Erreur, suivi d'une description du problème. Re-allocation : Oui, dans le cas où la VM retirée était utilisée par un client de type B, on va essayer de lui ré-allouer une autre machine libre du pool. getspvm ID : 7 (CommondCmd.GETSPVM) Acteur : Client de type SP Paramètre : L'identiant du client qui demande à récupérer une de ses machines du pool Description : Récupère une machine du pool pour le client passé en paramètre si c'est possible (si le client dispose encore d'une machine qui ne lui soit pas encore attribuée dans le pool). Lors de la sélection de la machine nous favorisons les machines qui ne sont pas utilisées par un client de type B. Si nous devons quand même choisir une machine utilisée par Boinc, le service sera d'abord coupé sur cette machine avant de la rendre à son propriétaire. Retour : Si une machine a été trouvée, renvoi les crédits de cette machine sinon renvoi Erreur, suivi d'une description du problème. Re-allocation : Oui, si la machine sélectionnée était utilisée par un client B, on va essayer de lui ré-allouer une nouvelle machine du pool. retspvm ID : 8 (CommondCmd.RETSPVM) Acteur : Client de type SP Paramètre : L'identiant du client qui souhaite rendre une machine SP ainsi que les crédits de la machine qu'il veut rendre. Description : Remet la machine correspondant aux crédits passés en paramètre par le client passé en paramètre lui aussi dans le pool si c'est possible (les crédits correspondent bien à une machine existante et appartenant au client). La machine une fois remise dans le pool est de nouveau disponible pour des clients de type B. Retour : OK si la machine a pu être rendue, sinon Erreur suivi d'une description du problème. Re-allocation : Oui, si des clients de type B qui ont une demande non satisfaite, nous pouvons leur allouer la machine qui vient de rentrer à nouveau dans le pool getbvm 41

ID : 9 (CommondCmd.GETBVM) Acteur : Client de type B Paramètre : L'identiant du client de type B Description : Augmente la demande en machines pour le client passé en paramètre et essaye de lui allouer tout de suite une machine si c'est possible. Dans la cas contraire, la demande est enregistrée et le client sera prévenu dès qu'une nouvelle machine lui est allouée Retour : OK et les crédits de la machine allouée si il y en a une de disponible sinon Pending Re-allocation : Non retbvm ID : 10 (CommondCmd.RETBVM) Acteur : Client de type B Paramètre : L'identiant du client de type B Description : Diminue la demande du client passé en paramètre si c'est possible (client identiable sur le serveur). Si la demande du client est supérieure à ce dont il dispose réellement, alors on diminue simplement la demande de une unité, sinon (si la demande est entièrement satisfaite) nous stoppons le service Boinc sur une des machines lui appartenant et on la remet dans le pool. Retour : Ok suivi des crédits de la vm qui est retournée dans le pool (si c'est le cas) sinon renvoi Erreur suivi d'une description du problème. Re-allocation : Oui, si le client rend une machine qu'il utilisait pour le service Boinc, un autre utilisateur B pourrait en avoir besoin. 4.1.6 Cycle de vie d'une VM dans le pool An de mieux comprendre le cycle de vie d'une machine virtuelle dans pool, nous pouvons regarder la gure 4.3. Nous voyons sur ce schéma que l'état d'entrée d'une machine est OUT. C'est à dire que cette machine n'existe pas encore, qu'elle n'a pas encore été créée et qu'elle n'utilise aucune ressource. Nous remarquerons que nous pouvons retourner dans cet état depuis n'importe quel autre état en utilisant la commande rmvm. Le seul moyen de sortir de cet état est d'utiliser la comande addvm, qui va créer un nouvelle machine virtuelle dans le cloud (et donc utiliser des ressources) et placer cette nouvelle machine dans l'état Idle/Pool. Dans l'état pool/idle c'est le propriétaire de la machine (celui qui l'a créée) qui prend en charge l'entièreté du fonctionnement de celle-ci même si personne ne l'utilise mais la mise à disposition de cette machine est comptabilisée pour le propriétaire de la machine. Quand une machine est dans cet état elle peut passer dans 2 états diérents, soit elle passe dans l'état SPused suite à une commande getspvm de la part du propriétaire de la VM, soit elle passe dans l'état BoincUsed suite une commande getbvm de la part d'un client de type B (ou équivalent : une ré-allocation). Dans l'état SPUsed, le propriétaire de la machine récupère la machine qu'il avait mise dans le pool pour son utilisation personnelle et aussi longtemps qu'il le désire. Le propriétaire prend alors tous les coûts de fonctionnement en charge, le temps d'utilisation est retiré du temps de mise à disposition de la vm et aucun client de type B ne peut avoir 42

accès à cette machine. Le propriétaire peut décider de rendre sa machine et de la remettre dans le pool via une commande retspvm ou simplement décider de retirer la machine du circuit via la commande rmvm. Dans l'état BUsed, le propriétaire de la machine loue sa machine à prix favorable à un client de type B néanmoins le propriétaire de la machine peut à tout moment décider de récupérer cette machine pour son utilisation personnelle grâce à la commande getspvm ou de simplement retirer sa machine du circuit à l'aide de la commande rmvm. Le client B peut quant à lui utiliser le service aussi longtemps qu'il n'est pas délogé par le propriétaire ou bien qu'il décide de rendre la machine via la commande retbvm. Figure 4.3 Cycle de vie d'une machine virtuelle dans le pool 4.1.7 Modelisation objet 1) Modèle Nous montrons sur la gure 4.4 le modèle objet simplié utilisé pour le serveur. Le modèle objet des clients n'est pas montré ici, car il est très simple et ne sert qu'à envoyer des commandes formatées au serveur qui les traite. 2) Abstractions Le corps du programme qui réalise cette solution ne manipule pas directement des implémentations concrètes de machines virtuelles et il ne manipule pas non plus directement les services Boinc. L'objectif de ce modèle est de pouvoir par la suite adapter ce programme pour diérents clouds (qu'il soient privés ou publics) et/ou pour diérents services. Pour les machines, le programme manipule des instances de classes abstraites qui représentent les machines virtuelles (adserver.vmif.java). Cette classe dispose de plusieurs méthodes abstraites qui sont listées ci-dessous : 43

Figure 4.4 Modèle objet du serveur public abstract boolean startvm(); public abstract boolean stopvm(); public abstract boolean startboinc(); public abstract boolean stopboinc(); public abstract String getspcredits(); public abstract String getbcredits(); Les deux premières sont respectivement appelées au moment de la création et de la destruction d'une machine virtuelle dans le cloud pour les commandes addvm et rmvm. Les deux suivantes sont quant à elles appelées respectivement, au moment de démarrer et d'éteindre le service pour les clients de type B pour les commandes getbvm et retbvm. Mais stopboinc() pourra aussi être appelé suite aux commandes getspvm ou bien rmvm. De même startboinc() pourra être appelé quand il y a une re-allocation pour les clients de type B. Les deux dernières, sont quant à elles, présentes pour préciser les crédits des machines ou bien des services. En eet, l'identication des machines peut-être variable selon les clouds, de même les crédits nécessaires pour l'utilisation de services peuvent être variables. Nous fournissons avec le code une première implémentation de cette classe abstraite an de vérier le prototype dans le chier adserver.dummyvm. Cette implémentation se 44

contente de simuler chacune des actions liées au VM. Nous fournissons également une seconde implémentation qui utilise un vrai cloud qui fonctionne avec OpenNebula (déployé dans le laboratoire de Euranova) et qui utilise comme service un Boinc personnalisé (SETI@home). Pour plus de détails voir section 4.2.4. Pour les diérents clouds, nous pourrions penser à utiliser des clouds publics comme Amazon, rackspace, etc., ou bien d'autres clouds privés comme eucalyptus etc. Pour les autres services, tout service distribué que nous pourrions facilement arrêter pourrait être utilisé (voir section 3.2.3). 4.1.8 Persistance des données et comptabilité Pour l'implémentation, nous avons dû choisir un mécanisme qui permette de stocker les informations dont on dispose, que ce soit sur les clients ou sur les machines virtuelles. Nous avons fait le choix d'utiliser une base de données pour stocker toutes les informations. Nous avons choisi en particulier SQLite car il s'agit d'une base de données très légère et facile d'utilisation. Ce choix n'est cependant pas dénitif, car il sut de changer les drivers dans la class adserver.dbpool.java pour en utiliser une autre. 1) SQLite SQLite est une librairie (dont la première release date d'août 2000) qui permet d'utiliser une base de données transactionnelle ACID, sans serveur et sans conguration. D'après leur site, SQLite serait la base de données SQL la plus déployée au monde. Le code source appartient au domaine public et des sponsors tels que Oracle, Mozilla ou encore Adobe supportent le projet. Le déploiement d'une base de données de ce genre est extrêmement simple. 2) Structure des bases de données An de pouvoir garder les informations nécessaires au bon fonctionnement du programme, nous utilisons une base de données qui contient trois tables : User Cette première table permet de conserver les informations importantes liées aux utilisateurs du pool. Elle contient quatre colonnes : 1. id integer : l'identiant du client qui sera utilisé pour déterminer à qui appartient une vm, qui est en train d'utiliser le service Boinc ou bien encore à attribuer une action à un utilisateur 2. type smallint : le type de client peut être soit 0 (Client.BCLIENT) pour un client de type B, soit 1 (Client.SPClient) pour un client de type SP. 3. nom varchar(255) : le nom (ou une description) du client. 4. demande integer : la demande du client en termes de services boinc. Ce champs n'est utilisé que pour les clients de type Boinc, les clients de type SP auront toujours leur demande égale à 0. Vm 45

Cette seconde table permet de garder les informations importantes liées au vms qui se trouvent actuellement dans le cloud. Elle contient quatre colonnes : 1. id integer : l'identiant de la vm qui sera utilisé dans les actions pour savoir sur quelles machines ont lieu les actions. 2. SPOwner integer : correspond à l'identiant du client à qui appartient cette machine virtuelle 3. BOwner integer : correspond à l'identiant du client qui utilise cette machine pour un service boinc si il existe. Si aucun client Boinc n'utilise cette machine : -1 (client.nobody) 4. SPUsed smallint : 1 si le propriétaire de la vm utilise la machine pour lui, 0 sinon. Action Cette troisième table permet de garder les informations importantes qui permettront de re-créer l'histoire des machines qui sont (ou ont été) dans le pool. Cette table permet de répondre à la question : Qui a fait quoi, avec quelle machine, à quel moment?. Elle contient quatre colonnes : 1. who integer : L'identiant de l'auteur de l'action. 2. what integer : L'action qui a été faite (correspond aux identiants de commande cités dans 2)) 3. vm integer : L'identiant de la machine virtuelle concernée 4. at time : Le moment auquel l'action a eu lieu. Dans la pratique, il s'agit d'un timestamp classique (à la seconde près). 5. fact integer : identie la facture à laquelle est liée cette action, si l'action n'a pas encore été facturée : cette colonne est mise à 1 Cette dernière table nous sera d'une grande utilité pour faire les comptes des différents clients. Nous décrivons dans la section suivante la technique utilisée pour réaliser ces comptes. 4.1.9 Comptes rendus Dans cette partie, nous expliquons comment le programme procède pour calculer la facture des clients en se basant uniquement sur les informations disponibles dans la base de données. 1) Dénitions Pour le calcul de la facture nous considérons que le prix d'une machine virtuelle à la seconde équivaut à γ et que le prix à la seconde du service boinc équivaut à γ δ. De plus nous considérons, le temps auquel est établi la facture t clot. 2) Dénition des ensembles Depuis la table user nous pouvons dénir l'ensemble de clients C sur base de leur identiant unique. Cet ensemble est en fait décomposé en deux ensembles basés sur la colonne type : les clients de type SP noté SC et les clients de type B noté BC. La relation entre ces ensembles est C = SC BC SC BC = φ. Concrètement, on peut faire SC = select id from user where type=client.spclient et BC = select * from user where type=client.bclient 46

De même, depuis la table vm, nous pouvons dénir l'ensemble M sur base de leur identiant unique. Concrètement nous pouvons faire M = select id from vm. 3) Comptes Boinc On dénit l'utilisation comme étant un triplet de valeur (vm,start,stop) Pour un client boinc donné b BC, nous pouvons retrouver toutes les utilisations qu'il a faites de chacune des machines m M depuis la table action. Nous commençons par déterminer l'ensemble des couples (vm,start) (noté BS). Concrètement BS = select vm, at from action where who= b and what=getbvm. Ensuite il faut trouver le moment d'arrêt pour trouver l'ensemble des triplets notés BU. Pour un couple donné, on calcule stop comme étant : stop = select at from action where who= b and what=retbvm and vm = vm and at> start order by at limit 1. Si cette requête ne renvoi rien alors on considère stop=t clot Pour un client boinc donné b B le total de ses utilisations est donc : et la facture : BT ot(b) = (i.stop i.start) i BU F B(b) = BT ot(b) δ On en prote pour dénir BT ot le coût total pour l'ensemble clients de type B : 4) Comptes SP BT ot() = b BC BT ot(b) Pour les clients de type SP il faut dans un premier temps comptabiliser le temps total d'existence des machines virtuelles sur le serveur, ensuite il faut calculer le temps total d'utilisation de ces machines à des ns personnelles et enn il faut calculer la réduction qui provient de la mise à disposition des machines aux clients de type Boinc. Pour un client donné s SC on peut retrouver le temps total d'existence des vms sur le serveur en appliquant la même méthode que celle décrite ci-dessus pour les utilisations de type Boinc mais en remplaçant GETBVM et RETBVM respectivement par ADDVM et RMVM générant ainsi un nouvel ensemble de triplets (vm, start, stop) noté SU. Toujours en suivant la même logique on dénit donc : et ST ot(s) = (i.stop i.start) i SU ST ot() = s SC ST ot(s) 47

Nous devons ensuite calculer le temps pendant lequel les machines n'étaient pas disponibles pour les clients type B car les client SP eux-même utilisaient leur machine. De nouveau nous pouvons appliquer la même procédure, mais cette fois-ci nous changeons GETBVM et RETBVM respectivement par GETSPVM et RETSPVMgénérant ainsi un nouvel ensemble de triplets (vm, start, stop) noté SUsed. A nouveau nous pouvons dénir : SUsedT ot(s) = i SUsed (i.stop i.start) et SUsedT ot() = s SC ST ot(s) Nous disposons donc maintenant de tous les éléments nécessaires pour calculer les réductions à appliquer pour un client donné s SC R(s) = ST ot(s) SUsedT ot(s) ST ot() SUsedT ot() BT ot Dans cette formule, nous voyons que les gains obtenus grâce au prêt des machines de surprovision est réparti équitablement sur tous les clients de type SP. En eet, ils récupèrent une fraction des gains totaux ramenés par les utilisateurs de type B qui est le rapport entre leur mise à disposition de machines et la mise à disposition totale de machines de la part de tous les clients de type SP. Enn, nous pouvons maintenant calculer la facture pour un client de type SP comme étant : F S(s) = ST ot(s)γ R(s)(γ δ) 4.1.10 Installation de la solution Dans cette section, nous décrivons la marche à suivre pour installer, congurer et personnaliser le programme de gestion de pool. Nous décrivons aussi brièvement les outils mis à la disposition des utilisateurs. 1) Requirements rabbitmq RabbitMQ est le service de messagerie utilisé pour la communication entre clients, administrateurs et serveur. Il faut donc installer d'une part le serveur de messagerie : la procédure est décrite sur le site ociel 5 dans la section installation. D'autre part il faut également installer le client java, dont l'installation est également décrite au même endroit. Une fois ceci fait, nous penserons à xer le CLASSPATH pour pouvoir compiler le projet. SQLite 5. http://www.rabbitmq.com 48

C'est la base de données utilisée pour mémoriser les informations. Son installation est décrite sur le site ociel 6. De plus, il faut installer les drivers java disponibles sur le site Zentus 7 et xer le CLASSPATH. ONE java binding Si nous voulons tester l'implémentation relative à OpenNebula, il faut d'une part, installer les binding java sur le front end d'opennebula en suivant la procédure décrite dans http://opennebula.org/documentation:rel3.6:java et d'autre part, il faut rajouter le client OpenNebula (disponible dans le package) au CLASSPATH. Java Le programme a été entièrement écrit en java et nécessite java 1.6 8. Pour la compilation, il est possible de compiler le projet à la main mais pour plus de faciliter, les sources sont accompagnées d'un chier ant( 9 ). Pour compiler il sut donc d'entrer la commande ant compile 2) Conguration et personnalisation Conguration Via le chier de conguration Config.java, nous pouvons xer le nom de la machine sur lequel le serveur rabbitmq est démarré. Il est également possible de changer les drivers utilisés pour la base de données. Personnalisation Il est possible d'implémenter de nouveaux clouds et/ou de nouveaux services via vmif.java comme décrit dans la section 2). 3) Démarrer le programme Serveur Il sut de lancer la commande : java adserver.servermain [rabbitmqserver]. Ceci lancera le serveur et il se connectera au serveur rabbitmq passé en paramètre. Si rien n'est précisé, il se connectera au serveur déni dans le chier de conguration. De plus, cela lancera aussi une invite de commande, qui permet de voir l'état actuel du serveur : les commandes disponibles sont : showclients : ache tous les clients du pool ainsi que les informations que nous avons à leur sujet. showpools : ache tous les pools ainsi que les machines contenues dans ces pools. Indique également l'état dans lequel se trouve les vms. Administrateur 6. http://www.sqlite.org 7. http://www.zentus.com/sqlitejdbc/ 8. disponible sur http://www.java.com 9. disponible http://ant.apache.org/ 49

Il sut de lancer la commande : java adadmin.admincli [rabbitmqserver]. Ce client implémente les fonctionnalités décrites dans 2) pour un administrateur. Les commandes disponibles sont : createspclient : créer un nouveau client de type SP createbclient : créer un nouveau client de type Boinc bill [factnumber virt] : générer une (nouvelle) facture Client Il sut de lancer la commande : java adclient.clientcli [rabbitmqserver]. Ce client implémente les fonctionnalités décrites dans 2) pour un client qu'il soit de type SP ou bien de type B. Les commandes disponibles sont : addvm id : ajoute une nouvelle vm pour le client de type SP id. rmvm id [vm] : retire vm du pool pour le client de type SP id. Si vm n'est pas précisé, sélectionne une machine qui n'est pas utilisée par le client SP getspvm id : récupère une vm du pool pour le client de type SP id. retspvm id vm : rend la machine vm pour le client de type SP id. getbvm id : demande une machine pour le client de type B id. retbvm id : diminue la demande du client de type B id. 50

4.2 Tests 4.2.1 Introduction Dans cette section nous allons évaluer 3 tests pour l'implémentation décrite dans la section précédente. Le premier test, correspondra à la première modélisation mathématique dans 3.1.6, le deuxième test correspondra lui à la deuxième modélisation, enn le troisième et dernier test nous permettra de vérier l'implémentation possible de divers clouds et/ou de services en utilisant OpenNebula et Boinc. 4.2.2 Dummy VM : cas simple Nous commençons par un premier cas simple correspondant au premier modèle mathématique : État initial 1 Client SP 1 Client B Nombre de machines pour le client SP xe : 4 Séquence d'actions Nous présentons ci-dessous la séquence d'actions qui est réalisée, les commandes correspondantes sont dénies dans 2) t 0 : la demande du client Boinc est de 4, et la consommation du client SP est de 3. t 1 : SP rend une machine t 2 : SP rend une machine t 3 : SP rend une machine t 4 : SP reprend une machine t 5 : Établissement de la facture Suivi des actions Pour chacune des actions, nous regardons à l'aide des commandes disponibles sur le serveur, l'état des clients (pour la première commande), ainsi que l'état du pool à chaque commande. 1. t 0 Clients in use : [ SP Client : Client id : 0 Boinc Client : Client id : 1 demand : 4 ] Nous disposons donc bien de deux clients : un de type SP et un de type B dont la demande est xée à quatre Show the pools... [ -> [ PoolId : 0 size : 4] -> VM ID : 0 SP owned by SP Client : Client id : 0 Boinc owned by null used by sp? true used by boinc? false 51

] -> VM ID : 1 SP owned by SP Client : Client id : 0 Boinc owned by null used by sp? true used by boinc? false -> VM ID : 2 SP owned by SP Client : Client id : 0 Boinc owned by null used by sp? true used by boinc? false -> VM ID : 3 SP owned by SP Client : Client id : 0 Boinc owned by Boinc Client : Client id : 1 demand : 4 used by sp? false used by boinc? true 2. t 1 Nous voyons donc les 4 machines présentes dans le pool : trois sont utilisées par le client SP lui-même tandis que la dernière est utilisée par le client B. Show the pools... [ -> [ PoolId : 0 size : 4] -> VM ID : 0 SP owned by SP Client : Client id : 0 Boinc owned by Boinc Client : Client id : 1 demand : 4 used by sp? false used by boinc? true ] -> VM ID : 1 SP owned by SP Client : Client id : 0 Boinc owned by null used by sp? true used by boinc? false -> VM ID : 2 SP owned by SP Client : Client id : 0 Boinc owned by null used by sp? true used by boinc? false -> VM ID : 3 SP owned by SP Client : Client id : 0 Boinc owned by Boinc Client : Client id : 1 demand : 4 used by sp? false used by boinc? true Nous pouvons voir que la VM qui a été rendue par le client SP à tout de suite été 52

3. t 2 4. t 3 5. t 4 ré-allouée au client B dont la demande est 4 mais qui ne dispose toujours que deux machines....... -> VM ID : 1 SP owned by SP Client : Client id : 0 Boinc owned by Boinc Client : Client id : 1demand : 4 used by sp? false used by boinc? true C'est maintenant la VM avec l'id 1 qui est attribuée au client B...... -> VM ID : 2 SP owned by SP Client : Client id : 0 Boinc owned by Boinc Client : Client id : 1demand : 4 used by sp? false used by boinc? true Le client B vient de récupérer la dernière VM de SP. Il dispose maintenant de toutes les machines, mais si SP désire en récupérer une, il lui sera automatiquement retiré d'une machine. Show the pools... [ -> [ PoolId : 0 size : 4] -> VM ID : 0 SP owned by SP Client : Client id : 0 Boinc owned by Boinc Client : Client id : 1 demand : 4 used by sp? false used by boinc? true -> VM ID : 1 SP owned by SP Client : Client id : 0 Boinc owned by Boinc Client : Client id : 1 demand : 4 used by sp? false used by boinc? true -> VM ID : 2 SP owned by SP Client : Client id : 0 Boinc owned by Boinc Client : Client id : 1 demand : 4 used by sp? false used by boinc? true -> VM ID : 3 SP owned by SP Client : Client id : 0 Boinc owned by null used by sp? true used by boinc? false ] 53

Comme il n'y avait plus de machine IDLE, le serveur a dû enlever une machine au client de type B an de la restituer au client SP. 6. t 5 L'établissement de la facture est détaillé dans le point suivant. Facture La facture établie par le programme est la suivante Boinc Bill for client : 1 Use vm 3 from 1343989773 to 1343989804(real) delta 31 Use vm 0 from 1343989782 to 1343989810(real) delta 28 Use vm 1 from 1343989788 to 1343989810(real) delta 22 Use vm 2 from 1343989796 to 1343989810(real) delta 14 Sp user bill for :0 - add/rm vm : Use vm 0 from 1343989773 to 1343989810(real) delta 37 Use vm 1 from 1343989773 to 1343989810(real) delta 37 Use vm 2 from 1343989773 to 1343989810(real) delta 37 Use vm 3 from 1343989773 to 1343989810(real) delta 37 - use its own vm for SP : Use vm 0 from 1343989773 to 1343989782(real) delta 9 Use vm 1 from 1343989773 to 1343989787(real) delta 14 Use vm 2 from 1343989773 to 1343989795(real) delta 22 Use vm 3 from 1343989804 to 1343989810(real) delta 6 ------------------- Start Total bill for Boinc ------------------ Client : 1 Btot * (gamma - delta) price 95 * (gamma - delta) price Total use for all Clients : 95 ------------------- End bill for Boinc -------------------------- ------------------- start bill for SP -------------------------- Client SP : 0 SP for 148 * gamma Reduction : ((SPi-SPi_used)/(GSP-GSP_used)) * GB * (gamma - delta) Reduction : ((148-51)/(148-51)) *95 * (gamma - delta) ------------------- end bill for SP ---------------------------- Nous remarquons que t 0, t 1, t 2, t 3, t 4 valent respectivement : 73, 82, 87, 95, 04, 10. Nous remarquons aussi qu'à chaque fois qu'une VM a été libérée par le client SP, elle a automatiquement été attribuée au client B, car sa demande n'était pas satisfaite. On remarque aussi qu'on lui retire une vm (la 3) en t 3 car le client SP redemande une de ses machines ; mais elles sont toutes utilisées par un client de type B, donc il faut en faire sauter une. Enn, nous remarquons également que les calculs de coût et réduction correspondent bien à ceux établis dans le modèle. 54

4.2.3 Dummy VM : cas composé Nous allons maintenant étendre le problème au cas général en suivant le deuxième modèle mathématique. État initial 3 Clients SP avec chacun zéro machine en provision 2 Clients B avec chacun une demande de 2 et un client Boinc avec une demande de 0 Nombre de machines pour les clients SP : variable Séquence d'actions Nous présentons ci-dessous la séquence d'action qui est réalisée, les commandes correspondantes sont dénies dans 2) t 0 : la demande des clients Boinc 1 et 2 est de 2, et la consommation des clients SP est de 0. t 1 : chaque SP ajoute deux machines t 2 : SP 1 et 2 utilisent chacun une machine t 3 : SP 1 remet sa machine utilisée dans le pool t 4 : SP 1 enlève ses deux machines du pool t 5 : SP 3 rajoute une machine dans le pool t 6 : SP Suivi des actions 1. t 0 Clients in use : [ SP Client : Client id : 0 SP Client : Client id : 1 SP Client : Client id : 2 Boinc Client : Client id : 3 demand : 2 Boinc Client : Client id : 4 demand : 2 Boinc Client : Client id : 5 demand : 0 ] Show the pools... [ -> [ PoolId : 0 size : 0] ] 2. t 1 Nous observons les 5 clients ainsi que le pool qui est encore vide [ -> [ PoolId : 0 size : 6] -> VM ID : 0 SP owned by SP Client : Client id : 0 Boinc owned by Boinc Client : Client id : 3 demand : 2 used by sp? false used by boinc? true -> VM ID : 1 55

] 3. t 2 SP owned by SP Client : Client id : 0 Boinc owned by Boinc Client : Client id : 3 demand : 2 used by sp? false used by boinc? true -> VM ID : 2 SP owned by SP Client : Client id : 1 Boinc owned by Boinc Client : Client id : 4 demand : 2 used by sp? false used by boinc? true -> VM ID : 3 SP owned by SP Client : Client id : 1 Boinc owned by Boinc Client : Client id : 4 demand : 2 used by sp? false used by boinc? true -> VM ID : 4 SP owned by SP Client : Client id : 2 Boinc owned by null used by sp? false used by boinc? false -> VM ID : 5 SP owned by SP Client : Client id : 2 Boinc owned by null used by sp? false used by boinc? false Nous observons que les 6 machines virtuelles ont été créées et que 4 d'entre elles ont été tout de suite attribuées aux 2 clients B qui avaient une demande de 2. Show the pools... [ -> [ PoolId : 0 size : 6] -> VM ID : 0 SP owned by SP Client : Client id : 0 Boinc owned by Boinc Client : Client id : 3 demand : 2 used by sp? false used by boinc? true -> VM ID : 1 SP owned by SP Client : Client id : 0 Boinc owned by null used by sp? true used by boinc? false -> VM ID : 2 SP owned by SP Client : Client id : 1 Boinc owned by Boinc Client : Client id : 4 demand : 2 used by sp? false used by boinc? true -> VM ID : 3 SP owned by SP Client : Client id : 1 56

] 4. t 3 Boinc owned by null used by sp? true used by boinc? false -> VM ID : 4 SP owned by SP Client : Client id : 2 Boinc owned by Boinc Client : Client id : 3demand : 2 used by sp? false used by boinc? true -> VM ID : 5 SP owned by SP Client : Client id : 2 Boinc owned by Boinc Client : Client id : 4demand : 2 used by sp? false used by boinc? true Nous pouvons voir que les clients SP 1 et 2 ont chacun récupéré une machine, en conséquence les clients Boinc ont été déplacés. Les clients Boinc disposent toujours du même nombre de machines, mais ils ont maintenant chacun une machine appartenant au client SP 3. Show the pools... [ -> [ PoolId : 0 size : 6] -> VM ID : 0 SP owned by SP Client : Client id : 0 Boinc owned by Boinc Client : Client id : 3 demand : 2 used by sp? false used by boinc? true -> VM ID : 1 SP owned by SP Client : Client id : 0 Boinc owned by null used by sp? false used by boinc? false -> VM ID : 2 SP owned by SP Client : Client id : 1 Boinc owned by Boinc Client : Client id : 4 demand : 2 used by sp? false used by boinc? true -> VM ID : 3 SP owned by SP Client : Client id : 1 Boinc owned by null used by sp? true used by boinc? false -> VM ID : 4 SP owned by SP Client : Client id : 2 Boinc owned by Boinc Client : Client id : 3 demand : 2 used by sp? false used by boinc? true -> VM ID : 5 57

] 5. t 4 SP owned by SP Client : Client id : 2 Boinc owned by Boinc Client : Client id : 4 demand : 2 used by sp? false used by boinc? true Le client SP 1 rend une de ses machines, mais comme la demande des clients B est déjà satisfaite, sa machine reste dans le pool et est IDLE. Show the pools... [ -> [ PoolId : 0 size : 4] -> VM ID : 2 SP owned by SP Client : Client id : 1 Boinc owned by Boinc Client : Client id : 4 demand : 2 used by sp? false used by boinc? true ] -> VM ID : 3 SP owned by SP Client : Client id : 1 Boinc owned by null used by sp? true used by boinc? false -> VM ID : 4 SP owned by SP Client : Client id : 2 Boinc owned by Boinc Client : Client id : 3 demand : 2 used by sp? false used by boinc? true -> VM ID : 5 SP owned by SP Client : Client id : 2 Boinc owned by Boinc Client : Client id : 4 demand : 2 used by sp? false used by boinc? true 6. t 5 Le client SP1 a retiré ses 2 machines du pool. En conséquence il ne reste plus que 3 machines disponibles pour les clients de type Boinc alors que la demande est de 4. Il y a donc un client dont la demande ne peut être entièrement satisfaite. Show the pools... [ -> [ PoolId : 0 size : 5] -> VM ID : 2 SP owned by SP Client : Client id : 1 Boinc owned by Boinc Client : Client id : 4 demand : 2 used by sp? false used by boinc? true -> VM ID : 3 58

] SP owned by SP Client : Client id : 1 Boinc owned by null used by sp? true used by boinc? false -> VM ID : 4 SP owned by SP Client : Client id : 2 Boinc owned by Boinc Client : Client id : 3 demand : 2 used by sp? false used by boinc? true -> VM ID : 5 SP owned by SP Client : Client id : 2 Boinc owned by Boinc Client : Client id : 4 demand : 2 used by sp? false used by boinc? true -> VM ID : 6 SP owned by SP Client : Client id : 2 Boinc owned by Boinc Client : Client id : 3 demand : 2 used by sp? false used by boinc? true 7. t 6 8. t 7 Le troisième client SP ajoute une nouvelle machine dans le pool. Comme la demande Boinc n'est pas satisfaite, cette nouvelle machine est directement attribuée au client Boinc donc la demande n'est pas satisfaite. Clients in use : [ SP Client : Client id : 0 SP Client : Client id : 1 SP Client : Client id : 2 Boinc Client : Client id : 3 demand : 2 Boinc Client : Client id : 4 demand : 2 Boinc Client : Client id : 5 demand : 1 ] Nous pouvons observer que la demande du troisième client Boinc passe bien à 1. Clients in use : [ SP Client : Client id : 0 SP Client : Client id : 1 SP Client : Client id : 2 Boinc Client : Client id : 3 demand : 2 Boinc Client : Client id : 4 demand : 1 Boinc Client : Client id : 5 demand : 1 ] Show the pools... 59

[ -> [ PoolId : 0 size : 5] -> VM ID : 2 SP owned by SP Client : Client id : 1 Boinc owned by Boinc Client : Client id : 5 demand : 1 used by sp? false used by boinc? true -> VM ID : 3 SP owned by SP Client : Client id : 1 Boinc owned by null used by sp? true used by boinc? false -> VM ID : 4 SP owned by SP Client : Client id : 2 Boinc owned by Boinc Client : Client id : 3 demand : 2 used by sp? false used by boinc? true -> VM ID : 5 SP owned by SP Client : Client id : 2 Boinc owned by Boinc Client : Client id : 4 demand : 1 used by sp? false used by boinc? true -> VM ID : 6 SP owned by SP Client : Client id : 2 Boinc owned by Boinc Client : Client id : 3 demand : 2 used by sp? false used by boinc? true ] Le deuxième client Boinc diminuant sa demande de une unité, la machine qui est libérée est directement ré-alloué au troisième client Boinc dont la demande n'avait pas pu être satisfaite au point précédent. 9. t 8 Analyse de la facture dans la section suivante. Facture établie ------------------ object Boinc Bill for client : 3 Use vm 0 from 1345192627 to 1345193145(real) delta 518 Use vm 1 from 1345192634 to 1345192838(real) delta 204 Use vm 4 from 1345192839 to 1345193497(real) delta 658 Use vm 6 from 1345193256 to 1345193497(real) delta 241 Boinc Bill for client : 4 Use vm 2 from 1345192639 to 1345193420(real) delta 781 Use vm 3 from 1345192645 to 1345192845(real) delta 200 Use vm 5 from 1345192846 to 1345193497(real) delta 651 Boinc Bill for client : 5 60

Use Boinc vm 2 from 1345193420 to 1345193497(real) delta 77 ------------------ end object ------------------ object Sp user bill for :0 - add/rm vm : Use vm 0 from 1345192627 to 1345193145(real) delta 518 Use vm 1 from 1345192634 to 1345193140(real) delta 506 - use its own vm for SP : Use vm 1 from 1345192839 to 1345193025(real) delta 186 Sp user bill for :1 - add/rm vm : Use vm 2 from 1345192639 to 1345193497(real) delta 858 Use vm 3 from 1345192645 to 1345193497(real) delta 852 - use its own vm for SP : Use vm 3 from 1345192846 to 1345193497(real) delta 651 Sp user bill for :2 - add/rm vm : Use vm 4 from 1345192649 to 1345193497(real) delta 848 Use vm 5 from 1345192652 to 1345193497(real) delta 845 Use vm 6 from 1345193256 to 1345193497(real) delta 241 - use its own vm for SP : ------------------ end object ------------------- Start Total bill for Boinc ------------------ Client : 3 Btot * (gamma - delta) 1621 * (gamma - delta) Client : 4 Btot * (gamma - delta) 1632 * (gamma - delta) Client : 5 Btot * (gamma - delta) 77 * (gamma - delta) Total use for all Clients : 3330 ------------------- End bill for Boinc -------------------------- ------------------- start bill for SP -------------------------- Client SP : 0 SP for 1024 * gamma Reduction : ((SPi-SPi_used)/(GSP-GSP_used)) * GB * (gamma - delta) Reduction : ((1024-186)/(4668-837)) *3330 * (gamma - delta) Client SP : 1 SP for 1710 * gamma Reduction : ((SPi-SPi_used)/(GSP-GSP_used)) * GB * (gamma - delta) Reduction : ((1710-651)/(4668-837)) *3330 * (gamma - delta) Client SP : 2 61

SP for 1934 * gamma Reduction : ((SPi-SPi_used)/(GSP-GSP_used)) * GB * (gamma - delta) Reduction : ((1934-0)/(4668-837)) *3330 * (gamma - delta) ------------------- end bill for SP ---------------------------- Nous pouvons observer chacune des étapes de la précédente section dans cette facture et ainsi retracer l'historique de chaque machine virtuelle. Nous remarquons également le partage des gains comme établi dans le modèle mathématique ; en eet, si on additionne les 3 fractions : 1024 186 4668 837 + 1710 651 4668 837 + 1934 0 4668 837 on n'a bien : 1. L'entièreté des gains est donc bien redistribué équitablement entre les diérents clients de type SP en fonction du temps qu'ils ont mis à disposition leurs machines. 4.2.4 ONE VM Dans cette section nous avons testé la capacité du programme à être personnalisé pour un environnement donné. Nous avons donc réalisé une implémentation concrète en nous servant d'un laboratoire et de OpenNebula. 1) Lab : OpenNebula Nous avons décrit OpenNebula dans la section 2.1.5. Nous avons donc installé OpenNebula sur le laboratoire mis à notre disposition par la société Euranova. Nous remarquerons au passage que ce genre d'installation ne se fait pas sans un minimum de connaissances en administration Linux...Nous avons donc dû fournir un travail relativement important pour l'installation d'opennebula. 2) VM : couple Jeos et Boinc : seti@home Pour les machines virtuelles, nous avons choisi d'installer un OS léger qui ne requiert qu'un espace disque limité : Jeos 10. C'est une variante d'ubuntu server prévue spécialement pour la virtualisation. La taille des disques étant dès lors réduite à 2Go, mais l'espace réel utilisé n'est que de 300Mo : ce qui nous laisse encore 1,7Go pour d'autres éventuelles applications. Pour le projet Boinc nous avons choisi un projet volontaire : seti@home, auquel les clients de type B participent. C'est un projet qui vise à découvrir l'existence d'une intelligence extra-terrestre! L'implémentation personnalisée est décrite dans le chier OneVM.java 3) Test en laboratoire Nous avons réalisé les tests des 2 sections précédentes avec cette nouvelle classe. Nous avons pu observer le lancement des machines virtuelles dans le laboratoire (via onevm top et via un manager de vm connecté directement sur les hosts) et le déroulement identique du programme. Nous avons observé le délais au moment de la création des ressources (addvm) de 60 secondes. Une fois ceci fait les machines virtuelles peuvent passer d'un client boinc à un autre très rapidement ou être restituée à son propriétaire extrêmement rapidement aussi. 10. Just Enough Operating System 62

4.2.5 Conclusion Nous avons pu voir à travers ces quelques tests que l'implémentation de la solution respecte bien le modèle établi dans le chapitre précédent et que le système de facturation est correct. Le temps d'obtention des machines (dans le cas du dernier test) est très court et ne dépend que du temps qu'il faut pour stopper le service Boinc. 63

Chapitre 5 Conclusion...And they came out all the same... M. Reynolds - Little Boxes

Nous avons vu dans la première section que même si le cloud amenait son lot d'avantages, il subsistait encore des challenges. Nous avons en particulier pointé le problème concernant le temps d'obtention d'une ressource. Nous avons vu que c'est un point qui peut être critique pour certains types d'applications et auquel les technologies actuelles ne peuvent pas répondre. Nous avons alors proposé une nouvelle solution pour ce problème et décrit un modèle mathématique sur lequel il est possible de raisonner. Nous avons également comparé la nouvelle solution aux systèmes existants et nous avons pu constater que l'accélération de l'allocation des ressources, même si elle engendre un coût peut être utile dans certains cas. Nous en avons d'ailleurs présenté des exemples dans la section applicabilité. Enn, dans la dernière partie, nous avons décrit la réalisation et l'implémentation complète de la solution que nous proposons. Nous avons également fourni un manuel d'utilisation et d'installation. Nous avons aussi discuté de la possibilité d'adapter le programme à diverses situations. Pour conclure, nous avons réalisés des tests sur l'implémentation permettant de valider le modèle. Le problème de départ était donc que certaines applications ne supportent pas les latences et qu'elles doivent donc utiliser une certaine sur-provision qui leur coûtent cher. La solution que nous proposons permet de mitiger ce coût en rentabilisant les machines qui ne sont pas utilisées mais en gardant une très grande réactivité proche de celle de la sur-provision. 5.1 Further work 5.1.1 Implémentation de diérents clouds A l'heure actuelle, l'uniformité entre les clouds n'est pas encore parfaite, il est cependant possible avec le programme fourni d'implémenter d'autres clouds qu'ils soient privés ou publics. Il serait même possible d'implémenter la solution sans cloud, en eet si nous créons un processus standard pour donner les crédits d'une vm, une pourrait décider de donner la gestion des machines de sur-provision à un service comme celui oert par le programme, pour rentabiliser au mieux les machines. 5.1.2 Implémentation de diérents services De la même façon qu'il est possible d'implémenter diérents clouds, il est possible d'implémenter la solution avec d'autres services que Boinc, qui auraient les mêmes caractéristiques. Il faut un service de calculs distribués dont les noeuds peuvent être interrompus à tout moment. 5.1.3 Un processeur, deux vms Nous utilisons dans notre solution une machine virtuelle pour deux utilisateurs différents. An de réduire les risques (de sécurité), on pourrait imaginer que quand le client SP crée une nouvelle ressource, il y ait en réalité deux machines qui soient lancées, mais que ces deux machines ne soient reliées qu'à un seul processeur virtuel. Il faudrait donc deux fois plus de RAM, mais la consommation d'électricité pour les autres éléments reste constante. Une des deux machines serait donc toujours suspendue (c'est-à-dire, elle est en mémoire mais n'a pas accès au processeur). 65

Cette solution est facilement implémentable dans notre programme en créant une nouvelle classe concrète à partir de vmif.java 5.1.4 Aide humanitaire Plutôt que de penser à rentabiliser ces sur-provisions, on pourrait penser à utiliser les machines dans le pool pour soutenir des projets de recherches scientiques bénévolement. Un exemple de recherche : http://www.gpugrid.net/ qui fait de la recherche dans le domaine médical entre-autres contre le cancer et le sida. 5.1.5 Diérencier les pools Même si ce n'est pas décrit dans la solution, le programme intègre, en fait, déjà la gestion de plusieurs pools. Nous pourrions penser à diérencier les pools sur bases des services oerts par exemple, ou bien sur base du type de machines qui sont dedans. 66

Bibliographie [1] Oracle vm 3 :architecture and technical overview. An Oracle White Paper, August 2011. [2] Rabbitmq : messaging that just works. http://www.test.org/doe/, 2012. [3] Sanjay Aiyagari + 18. Advanced message queuing protocol : protocol specication. 2008. [4] E. Brynjolfsson, P. Hofmann, and J. Jordan. Cloud computing and electricity : beyond the utility model. Communications of the ACM, 53(5) :3234, 2010. [5] R. Buyya, J. Broberg, and Andrzej Go sci nski. Cloud computing. Wiley Online Library, 2011. [6] R. Buyya, J. Broberg, and Andrzej Go sci nski. Cloud computing. Wiley Online Library, 2011. [7] N.G. Carr. The Big Switch : Rewiring the World, From Edison to Google. W. W. Norton & Company, 2008. [8] A. Gulati, G. Shanmuganathan, A. Holler, and I. Ahmad. Cloud-scale resource management : Challenges and techniques. Architecture, 2010. [9] S. Jin. VMware VI and VSphere SDK : Managing the VMware Infrastructure and VSphere. Prentice-Hall PTR, 2009. [10] Steve Jin. Cloud architecture patterns : Vm pool. http://www.doublecloud.org/ 2010/11/cloud-architecture-patterns-vm-pool/, November 2010. [11] J.O. Kephart and D.M. Chess. The vision of autonomic computing. Computer, 36(1) :4150, 2003. [12] P. Mell and T. Grance. The nist denition of cloud computing. National Institute of Standards and Technology, 53(6) :50, 2009. [13] R. Murch, Safari Tech Books Online, and Safari Books Online (Firme). Autonomic computing. Prentice Hall Professional Technical Reference, 2004. [14] V. Nae, A. Iosup, S. Podlipnig, R. Prodan, D. Epema, and T. Fahringer. Ecient management of data center resources for massively multiplayer online games. In High Performance Computing, Networking, Storage and Analysis, 2008. SC 2008. International Conference for, pages 112. IEEE, 2008. [15] J. Peng, X. Zhang, Z. Lei, B. Zhang, W. Zhang, and Q. Li. Comparison of several cloud computing platforms. In Information Science and Engineering (ISISE), 2009 Second International Symposium on, pages 2327. Ieee, 2009. [16] VMware Publications. Vmware infrastructure : Resource management with vmware drs. VMWare Best practices, November 2006. 67

[17] P. Sempolinski and D. Thain. A comparison and critique of eucalyptus, opennebula and nimbus. In Cloud Computing Technology and Science (CloudCom), 2010 IEEE Second International Conference on, pages 417426. Ieee, 2010. [18] Y. Song, Y. Li, H. Wang, Y. Zhang, B. Feng, H. Zang, and Y. Sun. A serviceoriented priority-based resource scheduling scheme for virtualized utility computing. High Performance Computing-HiPC 2008, pages 220231, 2008. [19] B. Sotomayor, R.S. Montero, I.M. Llorente, and I. Foster. Capacity leasing in cloud systems using the opennebula engine. In Workshop on Cloud Computing and its Applications, volume 3, 2008. [20] B. Sotomayor, R.S. Montero, I.M. Llorente, and I. Foster. Resource leasing and the art of suspending virtual machines. In High Performance Computing and Communications, 2009. HPCC'09. 11th IEEE International Conference on, pages 5968. IEEE, 2009. [21] B. Sotomayor, R.S. Montero, I.M. Llorente, and I. Foster. Virtual infrastructure management in private and hybrid clouds. Internet Computing, IEEE, 13(5) :1422, 2009. [22] M. Stevens, A. Lenstra, and B. De Weger. Chosen-prex collisions for md5 and colliding x. 509 certicates for dierent identities. Advances in Cryptology-EUROCRYPT 2007, pages 122, 2007. [23] R. Uhlig, G. Neiger, D. Rodgers, A.L. Santoni, F.C.M. Martins, A.V. Anderson, S.M. Bennett, A. Kagi, F.H. Leung, and L. Smith. Intel virtualization technology. Computer, 38(5) :4856, 2005. [24] Maarten van Steen. Distributed systems : Principles and paradigms. http://www. distributed-systems.net/courses/ds-slides/notes.01.pdf, October 2011. [25] L.M. Vaquero, L. Rodero-Merino, J. Caceres, and M. Lindner. A break in the clouds : towards a cloud denition. ACM SIGCOMM Computer Communication Review, 39(1) :5055, 2008. [26] Christof Weinhardt, Arun Anandasivam, Benjamin Blau, Nikolay Borissov, Thomas Meinl, Wibke Michalk, and Jochen Stöÿer. Cloud computing a classication, business models, and research directions. Business and Information Systems Engineering, 1 :391399, 2009. 68