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

Transcription

1 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

2 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.

3 Table des matières 1 Introduction 1 2 État de l'art Le cloud Introduction L'avant cloud Limites et nouvelles perspectives Naissance du cloud ) Convergences de technologies ) Dénition ) Caractéristiques et avantages ) Modèles de déploiement cloud ) Modèles de services Exemples d'implémentation du cloud ) OpenNebula ) Amazon Web Services Nouveaux challenges Introduction Dénition Réponses ) Haizea ) VMWare/DRS ) Autre Problème restant ouvert Description du problème et solution Base du problème Introduction Besoin d'une application Surprovision Utilisation d'iaas Nouvelle solution Modélisation mathématique ) Coûts liés à l'écart entre provision et charge réelle ) Partage des coûts ) Partage des gains Comparaison Cloud et Pool Analyse des gains et des coûts de la nouvelle solution ) Clients i

4 2) Providers Applicabilité Introduction Utilisateurs de type SP ) Applications aux requirements spéciaux ) Démonstrations live ) Exemple : MMOG Utilisateurs de type B ) Caractéristiques des services oerts ) Exemple : service Boinc Implémentation de la solution Description de la solution Introduction Modèle d'acteurs Diagramme de séquence d'utilisation Langage de programmation et drivers Communication entre les acteurs ) Messagerie standard RabbitMQ ) Standardisation des messages Cycle de vie d'une VM dans le pool Modelisation objet ) Modèle ) Abstractions Persistance des données et comptabilité ) SQLite ) Structure des bases de données Comptes rendus ) Dénitions ) Dénition des ensembles ) Comptes Boinc ) Comptes SP Installation de la solution ) Requirements ) Conguration et personnalisation ) Démarrer le programme Tests Introduction Dummy VM : cas simple Dummy VM : cas composé ONE VM ) Lab : OpenNebula ) VM : couple Jeos et Boinc : seti@home ) Test en laboratoire Conclusion ii

5 5 Conclusion Further work Implémentation de diérents clouds Implémentation de diérents services Un processeur, deux vms Aide humanitaire Diérencier les pools iii

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

7 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

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

9 2.1 Le cloud 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 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 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 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 htt://leagueoflegends.com 4

10 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 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

11 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 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) : National Institute of Standards and Technology : 6

12 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 Spot instances 9. Reserved instances 10. Amazon Web Service 7

13 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 html 8

14 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 Software development kit 9

15 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 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: // 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) CustomerRelationshipManagement

16 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 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 :

17 analyserons deux en particuliers. Enn nous déterminerons les questions restant ouvertes qui feront l'objet de la suite du mémoire 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 une_panne.html 12

18 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 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 Exemple tiré (et traduit) de leur site 13

19 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]

20 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

21 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 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

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

23 3.1 Base du problème 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 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 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

24 Figure 3.1 Réactivité dans le modèle surprovision 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

25 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 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

26 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

27 Figure 3.5 Réactivité dans le modèle pool 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).α

28 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

29 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

30 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

31 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

32 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) = Comparaison Cloud et Pool Cloud t 0 gib b (t) dt 27

33 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

34 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é 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

35 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é 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 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

36 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 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 : 31

37 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 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 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

38 Figure 3.10 Architecture d'un projet Boinc( 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 : 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 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

39 Un exemple de projet populaire disponible via Boinc est le projet 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 : 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