Etat de lart du Cloud Computing et adaptation au Logiciel Libre

Maurice Audin 2009

Typographie Les termes suivis dun astrisque (*) seront dnis dans le glossaire. e e

License Ce document est sous license Creative Commons

By-NC-SA 2.0 .

Table des mati`res e

Introduction Le cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . cloud . . . . . . . . . . . . . . . . . . . . . . . Intrt du ee 6 6 7 8 9 10 10 11 12 12 13 16 16 17 20 20 21 21 23 24 24

Le logiciel libre . . . . . . . . . . . . . . . . . . . . . . . . . Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Dnition des concepts e 1.1 1.2 1.3 1.4 1.5 Cest quoi ? . . . . . . . . . . . . . . . . . . . . . . . . Usages du cloud . . . . . . . . . . . . . . . . . . . . Les autres . . . . . . . . . . . . . . . . . . . . . . . . . Caractristiques . . . . . . . . . . . . . . . . . . . . . . e Mode de fonctionnement typique . . . . . . . . . . . .

2 Ores commerciales 2.1 2.2 Historique . . . . . . . . . . . . . . . . . . . . . . . . . Ores . . . . . . . . . . . . . . . . . . . . . . . . . . . cloud

3 Points ngatifs du e 3.1 3.2 3.3 3.4

Probl`mes thiques . . . . . . . . . . . . . . . . . . . . e e Inconvnients politiques . . . . . . . . . . . . . . . . . e Forfaits actuellement proposs . . . . . . . . . . . . . . e Stress test . . . . . . . . . . . . . . . . . . . . . . . . .

4 Solutions libres 4.1 Ct client . . . . . . . . . . . . . . . . . . . . . . . . . oe

4.2 4.3 4.4 4.5

Services de base . . . . . . . . . . . . . . . . . . . . . . Applications . . . . . . . . . . . . . . . . . . . . . . . . Plateforme . . . . . . . . . . . . . . . . . . . . . . . . . Infrastructure . . . . . . . . . . . . . . . . . . . . . . .

24 24 25 25 26 26 26 27 27 28 28 29 29 29 30 31 32 32 35 37 41 42

5 Virtualisation 5.1 5.2 Concept . . . . . . . . . . . . . . . . . . . . . . . . . . Solutions majeures . . . . . . . . . . . . . . . . . . . .

6 Etude du framework Vertebra 6.1 6.2 6.3 Fonctionnement . . . . . . . . . . . . . . . . . . . . . . Interface . . . . . . . . . . . . . . . . . . . . . . . . . . Intrts . . . . . . . . . . . . . . . . . . . . . . . . . . ee

7 Mise en place 7.1 7.2 7.3 7.4 Pr-requis . . . . . . . . . . . . . . . . . . . . . . . . . e Serveur frontal . . . . . . . . . . . . . . . . . . . . . . Machines virtuelles . . . . . . . . . . . . . . . . . . . . Compatible libre ? . . . . . . . . . . . . . . . . . . . . .

8 Communication 8.1 8.2 8.3 8.4 XMPP . . . . . . . . . . . . . . . . . . . . . . . . . . . Message passing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Comparaison des deux mthodes e

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . .

9 Load Balancing

9.1 9.2 9.3

Gestion dynamique des machines virtuelles . . . . . . . Load balancing, HAProxy et round-robin . . . . . . . . Conclusion . . . . . . . . . . . . . . . . . . . . . . . . .

42 44 46 48 52 53 54

Conclusion Glossaire Table des gures Bibliographie

Introduction
Le cloud computing , ou informatique dans les nuages, est un paradigme assez rcent. La premi`re nonciation de ce concept date de 1960 (John McCarthy), mais e e e sa relle mise en application a pris place au dbut des annes 2000 et le web 2.0 e e e (1999 pour Google et Yahoo). Le cloud consiste en une communication entre le serveur frontal et un ensemble de machines virtuelles qui hbergent une ou plusieurs e applications. Ainsi, le visiteur a acc`s a des applications dont lexcution ne dpend e ` e e pas du serveur web, et qui ninuent donc thoriquement pas sur son temps de e rponse. e La contre-partie est que le client na pas directement acc`s a ses donnes. Il dpend e ` e e donc totalement du fournisseur et doit lui faire enti`rement conance pour ce qui e est de leur condentialit et de leur sauvegarde. e Le probl`me est donc de savoir : e quels sont les avantages rels du cloud du point de vue du fournisseur ; e quelles sont les solutions techniques disponibles et leur mthode de taricae tions ; quelles sont les critiques (thiques et lgales) lies au cloud computing et e e e comment y remdier. e

Le

cloud
cloud computing , ou informatique dans les nuages, de Wikipedia

La dnition du e est la suivante :

Linformatique dans les nuages (en anglais, cloud computing) est un concept majeur faisant rfrence ` lutilisation de la mmoire et des ee a e capacits de calcul des ordinateurs et des serveurs rpartis dans le monde e e entier et lis par un rseau, tel Internet. e e Le cloud (Cf. gure 1) permet donc de fournir un ensemble dapplications sans utiliser la mmoire, la puissance de calcul et la capacit de stockage dun seul sere e veur. Le visiteur se connecte sur le site du client des services de cloud , utilise les applications qui lui sont proposes sans avoir conscience quil acc`de a des mae e ` chines (virtuelles ou non) direntes, et utilisent les applications proposes pour e e ventuellement stocker des donnes personnelles sur des serveurs distants. De plus, e e le client na pas dacc`s direct a ses donnes. e ` e Il existe un autre type de cloud , dit priv, qui est similaire mais limit ` un e e a rseau priv, il ne sera donc pas trait sparment. e e e e e

Figure 1 Fonctionnement du

cloud

Intert du e

cloud

De la mme faon que la virtualisation(*), un syst`me de cloud e c e permet une grande volutivit. On peut facilement et sans danger pour les applications dj` e e ea disponibles rajouter des machines au cloud pour une plus grande ractivit ou pour e e fournir des applications supplmentaires. De plus, sil est fait avec des machines e virtuelles (ce qui est toujours le cas), le cloud permet une rduction relle des e e cots (plusieurs dizaines de milliers dentreprises gres sur 1 000 serveurs pour u ee prendre lexemple de Salesforce.com). De plus, les ressources utilises sont mieux e rentabilises (plus de 10 ou 20 % des ressources utilises...). e e Dun point de vue de la scurit, les donnes tant centralises, elles sont plus faciles e e e e e a protger mais le client perd le contrle sur elles. De plus, si une application prsente ` e o e une faille, seul le syst`me qui laccueille pourra tre mis en danger. Ainsi, toutes les e e autres applications ainsi que la machine frontale sont protges. e e Les donnes et les applications tant hberges et souvent sauvegardes sur des e e e e e machines distantes, on peut y accder de mani`re permanente et de nimporte quel e e endroit et tre assur de leur prennit. e e e e

Enn, le cloud peut reposer enti`rement sur des technologies libres comme par e exemple : Xen ou KVM pour les machines virtuelles ; Syst`me GNU/Linux pour les OS (Debian) ; e Serveur web libre (Apache) ; Serveur dapplications libre (framework dpendant du langage utilis) ; e e Base de donnes MySQL ; e Firefox comme explorateur.

Le logiciel libre
Le but de ce document tant dtudier la possibilit et lintrt du cloud compue e e ee ting dans une socit dveloppant du logiciel libre, il faut dabord dnir cette ee e e notion. Le mouvement du logiciel libre a dbutt au dbut des annes 80 a linitiative de e e e e ` Richard Stallman qui lance la Free Software Foundation. Selon Stallman, un logiciel est dit libre sil permet les quatres liberts fondamentales : e 0. La libert dexcution quelquen soit le but. e e 1. La libert dtudier le fonctionnement du programme et de le modier pour e e quil se conforme a ses besoins. ` 2. La libert de redistribuer le programme dans un but dentraide. e 3. La libert damliorer ou simplement de modier le programme et de poue e voir redistribuer les versions modies au prot de la communaut. e e Un logiciel orant ces quatre liberts est dit libre, sinon, il est dit privateur. Selon la e license propose par le projet GNU (le syst`me dexploitation lanc par Stallman et e e e qui utilise actuellement le noyau Linux), un logiciel sous license libre doit le rester, cest ` dire que les versions modies et redistribues doivent garder une license libre a e e (ce nest pas le cas de la license BSD). Le terme de Free est ambigu car il signie ` la fois libre a et gratuit . Sa relle signication est libre , ce qui veut dire que lon peut faire commerce du e logiciel (vendre les binaires compils dun programme par exemple), de mme que e e fournir un service payant bas sur lutilisation de logiciel libre. e Parmis les noms les plus connus du monde du libre, on peut citer le syst`me GNU/e Linux (et ses distributions rputes telles que Debian, Ubuntu ou Red Hat), lexploe e rateur Firefox (produit et dvelopp par la socit Mozilla et qui rattrape petit ` e e ee a petit Internet Explorer, son concurrent privateur dvelopp par Microsoft), le lecteur e e multimdia VLC, ou le serveur web Apache (largement majoritaire sur le march de e e lhbergement). e

Les intrts de lutilisation de logiciels libres sont nombreux. Pour un particuee lier, ils fournissent lassurance, mme sil ne peut pas lui-mme le vrier, que les e e e dveloppeur ne cherchent pas a introduire des fonctions malveillantes dans leur code. e ` Ils permettent aussi une volution constante, que ce soit au niveau des performances, e de lergonomie ou de la scurit, grce a une communaut tr`s active. Pour des proe e a ` e e fessionnels, un logiciel libre est une assurance de prennit car il ne dpend pas e e e ou peu de ltat nancier dune socit. De plus, malgr la croyance populaire, un e ee e logiciel libre ne prsente pas plus de probl`mes de scurit quun logiciel privateur. e e e e En eet, la posibilit, y compris pour la socit qui utilise ce type de logiciel, de e ee pouvoir tudier le code source permet une meilleure ractivit face ` dventuelles e e e a e failles, de mme que la possibilit de le modier et donc de corriger ces failles. e e En ce qui concerne le cloud , la majorit (voir la totalit) des solutions sont e e privatrices ou Open Source au mieux (le client ne dispose que de la libert 0). Il est e donc intressant dtudier si une proposition enti`rement libre est envisageable. e e e

Objectifs
Plusieurs objectifs ont motiv la cration de ce document : e e Donner une explication claire du concept de cloud computing , de son utilit et de ses inconvnients ; e e fournir les donnes concernant les ores commerciales qui existent actuellee ment ; dnir les technologies et les logiciels a utiliser pour une ore de cloud , e ` faire des comparatifs pour rgler certaines concurences entre eux ; e Expliquer la mise en place de ce service avec les outils choisis.

1
1.1

Dnition des concepts e

Cest quoi ?

Le cloud computing est (si on cherche a dpasser leet buzz word ) un ` e paradigme de programmation qui permet de concevoir les ressources (comprendre machines virtuelles, le cloud ) comme des services accessibles par internet. Le cloud permet de grer la relation entre les programmes sur lordinateur et sur le e web. Lutilisateur na pas conscience du cloud en utilisant ce type de services, de mme quil na aucun contrle dessus. On trouve gnralement un ou plusieurs e o e e des concepts suivants dans un cloud : Infrastructure as a service (IaaS), une plateforme de virtualisation ; Platform as a service (PaaS), pour faciliter le dploiement dapplications ; e Software as a service (SaaS), permettant lacc`s a des applications sur le e ` web. On peut en fait diviser le cloud computing en deux catgories bien distinctes e (mme si un fournisseur peut proposer les deux) : e Stockage Les donnes du client sont sauvegardes sur plusieurs serveurs, par exemple e e Amazon Simple Storage Service (ou Amazon S3), souvent accompagn de e copies de sauvegardes (voir la section inconvnients politiques). Ce type de e cloud permet, si lon a stock des applications sur le serveur dy accder e e et de les excuter, et ressemble alors ` un syst`me de chier partag (de type e a e e AFS(*)), accessible depuis son explorateur internet. Logiciels Sur ce point, le cloud computing est similaire au Software as a Service si ce nest que le propritaire du logiciel nest pas forcment le propritaire du e e e matriel. On peut distinguer alors deux philosophies. Amazon vend du temps e sur une machine virtuelle, avec ses ores Elastic Compute Cloud (Amazon EC2) et Simple Storage Service (S3), alors que Microsoft, avec Microsoft Azure, et Google, avec Google App Engine, proposent lutilisation de leurs langages et de leurs bibloth`ques, ce qui rend la maintenance plus aise (elle e e ne dpend plus des besoins du client), mais beaucoup moins exible pour le e client.

10

Le

cloud

dpend des composants suivants (Cf. la section solutions libres) : e

Client Logiciel permettant a un internaute de se connecter au cloud . Gnralement, ` e e un explorateur internet sut, mais dautres moyens peuvent tre utiliss e e suivant les services proposs par lhbergeur ou par lacheteur du service de e e cloud . Service Protocoles proposs par lhbergeur ou par le client (paiement, mapping, e e chat, mail, ...) Application Les applications sont soit proposes de base par lhbergeur, soit dveloppes e e e e par le client. Chacune delles dispose dune ou plusieurs machines virtuelles. Plate-forme Syst`me dhbergement des applications. e e Stockage Moyen de stockage mis a disposition du client. La plupart des hbergeurs ` e proposent une base de donnes SQL sur laquelle le client na pas dacc`s e e direct, ce qui peut tre chang (avec un gain considrable de libert). Il est e e e e aussi envisageable de lui fournir un syst`me de stockage classique (syst`me e e de chier accessible en FTP par exemple). Infrastructure Il sagit du serveur frontal.

1.2

Usages du

cloud

Les usages dun cloud dpendent du point de vue adopt. Un cloud e e se destine dune part au client, une entreprise ou autre (gouvernement, association, ...), qui administre un syst`me de cloud , et dautre part aux employs ou aux e e clients de cette entreprise, qui sont les utilisateurs de ce syst`me. e Pour lentreprise, le cloud va permettre de fournir un ensemble dapplications a ses employs, et cel` o` quils se trouvent. On pourra trouver, par exemple, une ` e a u messagerie, un agenda, un syst`me de messagerie instantane, voire un syst`me de e e e vote, de partage de documents, ... (applications proposes par dfaut ou dveloppes e e e e par le client du service). Cest donc une extension de son service informatique. Il peut aussi tre utilis comme moyen de vendre un logiciel dvelopp en faisant payer e e e e lacc`s au cloud . Enn, il peut servir de moyen de sauvegarde de ses donnes. e e Pour lutilisateur, le cloud est un moyen daccder aux services fournis par cette e entreprise. Que ce soit un service gratuit (dans le cas dun employ) ou payant (dans e le cas dun client utilisant un acc`s achet), il peut avoir acc`s ` ces services quel e e e a 11

que soit lordinateur quil utilise (plus besoin dinstaller des logiciels quivalents a e ` ceux propos sur chacun de ses ordinateurs), sans soucis de versions e car lapplication fonctionne de mani`re identique sous GNU/Linux, Mac, Windows ou tout e autre syst`me disposant dun explorateur internet (Freerunner, iPhone, Android, e Blackberry, PDA, ...).

1.3

Les autres

Le cloud computing peut facilement tre confondu avec dautres paradigmes. e Sil ne faut pas les confondre, il faut aussi avoir conscience que ces concepts sont parfois lis. Voici les principaux exemples de ces autres paradigmes et leur relation e avec le cloud . Le grid computing Dans un syst`me de grid, un super-ordinateur contrle un ensemble de e o syst`mes et leur rpartit des calculs ` eectuer dans un but unique (calcul e e a scientique, analyse sismique, ...). Dans la plupart des cloud , on trouve toujours un syst`me de grid mais dans lequel lapplication nest pas unique e et o` le super-ordinateur u a pour but de pointer vers le syst`me correse pondant ` la demande et non de rpartir le calcul. a e Lutility computing Lutility computing est simplement en une dlocalisation dun syst`me de e e calcul ou de stockage. Il est videmment utilis dans un cloud mais nime e plique pas forcment un rseau de calcul ou de stockage comme le cloud . e e Lautonomic computing Paradigme dans lequel un syst`me informatique est capable de sauto-administer e en sadaptant ` des changements imprvisibles. Il peut tre compos de a e e e syst`mes dauto-conguration, dauto-rparation (dtection et correction dere e e reurs), dauto-optimisation (contrle et rpartition des ressources) et dautoo e protection (dtection et protection contre des attaques). Lautonomic come puting na ` priori rien ` voir avec le cloud computing mais un cloud coma a prend gnralement des lment autonomes (auto-optimisation par exemple). e e ee

1.4

Caractristiques e

Le but dun cloud est de crer un syst`me totalement dcentralis (par exemple e e e e BitTorrent ou Skype), mme si la plupart se basent encore sur des grids ou des e utilities et sont donc encore centraliss. e Les ores commerciales permettent de faire payer au client en fonction des ressources utilises (forfait bass sur llectricit ou sur le matriel e e e e e utilis) e 12

Comme le client na pas de contrle direct sur le matriel, il peut rapidement y avoir o e une sur-utilisation des ressources disponibles, mme si une bonne bande passante e permet thoriquement le mme temps de rponse quun syst`me centralis clasique. e e e e e La plupart des architectures utilises pour le cloud computing e centers et des serveurs avec plusieurs niveau de virtualisation. sont des data-

1.5

Mode de fonctionnement typique

De mani`re gnral, un cloud e e e prsente les lments suivants, certains tant e ee e optionnels mais amliorent sa qualit (ractivit), Cf. gure 2 : e e e e Proxy HTTP Point dentre des demandes, g`re le SSL(*). e e Cache HTTP Permet de rpondre plus rapidement ` une requte en plaant une partie du e a e c contenu dans un cache. Serveur frontal G`re les requtes en lanant des machines virtuelles adquates ou en come e c e muniquant avec des machines virtuelles adquates dj` lances. e ea e Machines virtuelles Ensemble de serveurs (serveurs Ruby avec framework (*) web par exemple) accueillant chacune une application. Elles doivent pouvoir tre lances rapie e dement et indpendemment pour rpondre le mieux possibles aux demandes e e des visiteurs. Base de donnes SQL ou syst`me de stockage e e Base de donnes pour chaque application, avec duplication et tlchargement e ee pour le client (la base de donne peut tre externe au cloud ), syst`me e e e de stockage prsentant les mmes avantages. e e Cache mmoire e Cache mmoire pour les applications web permettant un acc`s rapide (par e e exemple ` des fragments de pages). a

Chaque machine virtuelle (Debian, Cf. gure 3) accueille un environnement spcique e au langage utilis par le client. Une application utilise une ou plusieurs machine vire tuelle suivant sa complexit. Le syst`me de chier peut tre en lecture seule (les e e e donnes tant stockes ailleurs, il sut de pouvoir excuter lapplication prsente e e e e e sur la machine virtuelle). Lenvironnement doit accueillir un serveur dapplications lui aussi spcique au lane gage utilis qui accueillera le serveur web. e 13

Figure 2 Fonctionnement dtaill e e

14

Figure 3 VM

Enn, le serveur accueille lapplication du client. Dans un souci de gnricit, on peut e e e concevoir que lensemble des applications soient stocks sur un serveur de stockage et e que la machine virtuelle y acc`de au moment de lexcution (par AFS par exemple). e e Ainsi, on peut crer des images de machines virtuelles typiques, valables pour un e grand nombre dapplications, et plus lg`res dun point de vue taille. e e

15

2
2.1

Ores commerciales
Historique
cloud (sans le nom), date de 1960, et de

La premi`re nonciation de lide de e e e John McCarthy.

Computation may someday be organized as a public utility. (Les ressources informatiques deviendront un jour dutilit publique) e John McCarthy Le mot cloud est apparu au dbut des annes 90 pour dsigner des rseaux e e e e disposant dun mode de transfert asynchrone, et lexpression cloud computing il y a une dizaine dannes et a pris de plus en plus dimportance. e Salesforce.com fut le premier hbergeur de cloud e en 1999, suivi en 2002 par Amazon qui proposa un ensemble dhbergement dapplication, de stockage et dore e demploi (Le Mechanical Turk). Amazon dveloppa ses services en 2005 (Amazon Web Services) et en 2006 (Elastic e Compute Cloud ou EC2). Ce dernier fut le premier service de cloud rellement accessible (selon Jeremy e Allaire, PDG de Brightcove, autre fournisseur de SaaS). En 2007, Google, IBM et des universits lanc`rent un projet de recherche sur le e e cloud qui permit de lui faire gagner en popularit et en consistance. e Cest en 2009 que la relle explosion du cloud survint avec larrive sur le march e e e de socits comme Google (Google App Engine), Microsoft (Microsoft Azure), IBM ee (IBM Smart Business Service), Sun (Sun Cloud) et Canonical Ltd (Ubuntu Enterprise Cloud).

16

2.2

Ores
cloud computing (valables

Voici les prix de quelques fournisseurs de services de a la date du 7 dcembre 2009) : ` e

Amazon Stockage (S3 et EC2) ; Applications fournies ; De 0,17 $ le Go pour les 10 premiers To a 0,10 $ le Go pour plus 150 To. ` Google App Engine Stockage ; Applications fournies, possibilit de dvelopper en Java et Python ; e e 0,10 $ par heure dutilisation de CPU, 0,15 $ par Go. Microsoft Azure Stockage ; Applications fournies, possibilit de dvelopper en .NET ; e e Voir la section sur les forfaits. 3Tera Stockage ; Possibilit de dvelopper des applications (tous langages confondus) ; e e 2 500 $ par mois pour 8 CPUs, 16 Go de RAM, 6 To de stockage. Appistry Stockage ; Application de base, possibilit de dvelopper en .NET, Java et C++ ; e e Syst`me de cloud e interne. Cassatt Rpartition dynamique des ressources de calcul ; e Solution de syst`me de cloud e interne. Joyent Stockage ; Possibilit de dvelopper en Rails et PHP ; e e De 125 ` 250 $ par mois pour 1 Go. a Legal Cloud Dploiement de services et de stockage rapide ; e Dstin aux entreprises davocats. e e Skytap Possibilit de dvelopper en Java ; e e A partir de 500 $ par mois.

17

 AgathonGroup Stockage, Ruby, PHP ; 50 $ par mois pour 0,25 CPU, 384 Mo de RAM, 15 Go de stockage ; 380 $ par mois pour 3 CPU, 4 608 Mo de RAM, 180 Go de stockage ; 980 $ par mois pour 8 CPUs, 12 288 Mo de RAM, 480 Go de stockage. ElasticHosts Stockage ; Possibilit de dvelopper (tous langages confondus) ; e e De 0.04 par heure a 29 par mois ; ` comparatif. Flexiscale Stockage ; Possibilit de dvelopper (tous langages confondus) ; e e 96 pour 1 Go de RAM, 1 CPUs, 200 Go de stockage. GoGrid Stockage 1,52 $ par heure pour 6 CPUs, 8 Go de RAM, 480 Go de stockage RackspaceCloud Stockage 10,95 $ par mois pour 10 Go de stockage et 256 Mo de RAM ; 21,90 $ par mois pour 20 Go de stockage et 512 Mo de RAM ; 43,80 $ par mois pour 40 Go de stockage et 1 024 Mo de RAM ; 87,60 $ par mois pour 80 Go de stockage et 2 048 Mo de RAM ; 175,20 $ par mois pour 160 Go de stockage et 4 096 Mo de RAM ; 350,40 $ par mois pour 320 Go de stockage et 8 192 Mo de RAM ; 700,80 $ par mois pour 620 Go de stockage et 15 872 Mo de RAM. NewServers Stockage Possibilit de dvelopper en Java e e 0,11 $ par heure pour 1 CPU, 1 Go de RAM, 36 Go de stockage 0,17 $ par heure pour 2 CPUs, 2 Go de RAM, 146 Go de stockage 0,25 $ par heure pour 4 CPUs (1 x E5405), 4 Go de RAM, 250 Go de stockage 0,38 $ par heure pour 8 CPUs (2 x E5405), 8 Go de RAM, 1 To de stockage 0,53 $ par heure pour 4 CPUs (1 x E5450), 4 Go de RAM, 600 Go de stockage

18

 Aptana Stockage ; Possibilit de dvelopper en Rails et PHP ; e e 35 $ par mois pour 256 Mo de RAM et 5 Go de stockage ; 72 $ par mois pour 512 Mo de RAM et 10 Go de stockage ; 137 $ par mois pour 1024 Mo de RAM et 15 Go de stockage ; 267 $ par mois pour 2048 Mo de RAM et 25 Go de stockage. Heroku Stockage Possibilit de dvelopper en Ruby e e 15 $ par mois pour 50 Mo de stockage. 50 $ par mois pour 500 Mo de stockage. 200 $ par mois pour 1 CPU et 500 Go de stockage. 400 $ par mois pour 5 CPUs et 1 To de stockage. 1600 $ par mois pour 20 CPUs et 2 To de stockage.

19

3
3.1

Points ngatifs du e
Probl`mes thiques e e

cloud

La principale critique du cloud computing est que le client ne poss`de pas phye siquement le stockage de ses donnes et laisse donc le contrle total au fournisseur. e o Le London Times a par exemple compar cette technique aux syst`mes centrae e liss des annes 50-60 (connexion depuis un dumb-terminal e e a un super` ordinateur ). En eet, le client ne peut pas installer de nouveaux logiciels et a besoin de lautorisation du fournisseur pour la plupart des tches dadministration. a De plus, en cas de probl`mes techniques de la part du fournisseur, le client na plus e aucun moyen daccder a ses donnes. e ` e Sur le mme ton, Richard Stallman condamne cette technologie par laquelle lutie lisateur cone aveuglment ses donnes prives ` un fournisseur qui peut alors le e e e a piger en le forant ` utiliser des logiciels privateurs et en augmentant ses forfaits. e c a Just like non-free software, software as a service is incompatible with your freedom. (Comme les logiciels privateurs, les logiciels comme services ne sont pas compatibles avec votre libert) e Richard M. Stallman En eet, il est impossible, pour les utilisateurs et dans la plupart des cas pour le client lui-mme, de pouvoir vrier lattitude relle des machines virtuelles qui ace e e cueillent les applications car ils ny ont pas acc`s. Le probl`me des logiciels privateurs e e qunonce Stallman est que lutilisateur, par lusage de ces logiciels, doit avoir une e conance aveugle envers le dveloppeur. Dans le cas du cloud computing , il doit e accorder la mme conance non seulement au dveloppeur mais aussi ` lhbergeur, e e a e ce qui rend le cloud encore plus dangeureux que le logiciel propritaire. e

20

3.2

Inconvnients politiques e

Le cloud computing apporte de nombreux dbats politiques qui forcent les e hbergeurs ` sadapter constemment a de nouvelles rglementations, devant la plue a ` e part du temps limiter lacc`s a certaines zones (Amazon EC2 Availability Zone). e ` Aux Etats-Unis, les syst`mes de cloud se confrontent par exemple au Patriot Act, e qui interdit aux socit les proposant de stocker certaines donnes sur des serveurs ee e hors du territoire amricain, de mme quil leur faut bloquer par dfaut certaines e e e requtes (par exemple en ce concerne le syst`me bancaire ou celui de sant). e e e On peut supposer que des socits comme Google ou Microsoft arriveront facilement ee a saccomoder de ces lgislations, mais la plupart des hbergeurs se retrouvent dans ` e e des positions diciles (comme par exemple lorganisation bancaire internationnale SWIFT, qui veut mettre en place un datacenter en Suisse mais ne peut y faire traiter que les donnes bancaires europenne). e e De plus, des rglementations comme le Stored Communications Act (encore aux e Etats Unis), permettent aux gouvernements davoir un acc`s direct aux messages de e leur concitoyens et sont donc rebuts par des hbergements dans dautres pays. e e

3.3

Forfaits actuellement proposs e

Comme vu plus haut, les facturations des service de cloud sont alatoires et assez e oues. En eet, et cela concerne surtout les socit proposant du cloud ee Open Source, le nombre de clients et dutilisateurs est dicile (voire impossible) ` obtenir, a les tarifs sont xs sur des bases peu ables et ne permettent pas pour un client e dvaluer clairement le prix rel quil aura ` payer. e e a Le probl`me est que deux types de facturations sont disponibles, la facturation par e nombre dutilisateurs et la facturation par ressources utlises. e

21

 Facturation par ressources utilises e La plupart des hbergeurs proposent des facturations bases sur les rese e sources utilises. Le client va donc payer par nombre dheures utilises sur e e une machine virtuelle, o`, parfois, chaque heure commence est facture. u e e De plus, la plupart demande un paiement supplmentaire en fonction du e nombre de tlchargement (au Go, avec le mme genre de pi`ge pour les Go ee e e commencs que pour les heures). e Dans le cas extrme, Microsoft Azure, on trouve mme les prix suivants e e (qui sappliquent tous) : 0,12 dollar lheure dutilisation du CPU ; 0,15 dollar le Go de stockage (par mois) ; 0,01 dollar pour 10 000 transactions de stockage ; 0,10 dollar par connexion ; 0,15 dollar par Go de transfert ; 9,99 dollars pour une base de donnes SQL (99,99 $ pour la version Busie ness) ; 0,10 dollar par connexion a la base de donnes ; ` e 0,15 dollar par Go de transfert avec la base de donne ; e 0,15 dollar par 100 000 oprations de message (DBus et jetons dacc`s e e inclus). Facturation par utilisateur Une partie des fournisseurs de cloud fournit une facturation par nombre dutilisateurs. Linconvnient de cette mthode (pourtant transparente) est e e quelle ne prend pas en compte les ressources utilises. En eet, un client e mettant en place plusieurs dizaines, voir plusieurs centaines dapplications, payera le mme prix au mois quun client ne disposant que des services de e bases et ne demandant quasiment pas de ressources (sil a le mme nombre e dutilisateurs). Pour lhbergeur, cette solution nest pas viable car un client e peut facilement le faire devenir dcitaire si son nombre dapplications dee vient trop important. Ainsi, les modes de paiements actuellement mis en place ne sont clairement pas satisfaisants. Prenons lexemple dune socit ayant besoin dun syst`me de cloud ee e pour envoyer 100 Go de donnes en 10 000 heures, elle devra payer 3 410 $ en utilisant le e service dAmazon EC2 (0,34 x 10 000 + 0,10 x 100). Chez Microsoft, le prix sera de 1 230,19 $, sans prendre en compte les messages DBus et en supposant que les donnes ont t transfres en une seule fois (0,12 x e ee ee 10 000 + 0,15 x 100 + 0,10 x 1 + 0,15 x 100 + 9,99 + 0,10 x 1). Enn, chez Google, il sera de 1 015 $ (0,15 x 100 + 0,10 x 10 000). 22

Les tarifs qui prc`dent sont des valuations rapides de ce que devra payer la socit, e e e ee mais ils ne prennent pas en comptes de nombreux param`tres diciles a valuer e ` e (nombre de connections total pour envoyer les donnes, nombre dappel ` la base de e a donnes, utilisation des CPUs, etc). e On peut cependant voir la complexit pour une entreprise dvaluer ses factures sur e e un moyen ou long terme ainsi que de dnir lhbergeur qui lui sera le plus rentable e e en fonction de ses besoins.

3.4

Stress test

Une rcente tude a montr que les plus grands syst`mes de cloud (ceux dAmae e ` e e zon, de Microsoft et de Google) prsentent des variations du temps de rponse dun e e facteur 20, suivant lheure dacc`s. Cette mme tude met en vidence de graves e e e e probl`mes lis a ces variations. Par exemple, le syst`me de Google ne permet pas e e ` e doprations dpassant 30 secondes. De plus, les syst`mes de monitoring(*) ne pere e e mettent pas dtudier prcisemment les origines de ces ralentissements. e e Ainsi, la promesse des hbergeurs de fournir un acc`s au moins aussi rapide a un e e ` cloud qu` un syst`me autre peut rapidement se rvler fausse en cas de grande a e e e utilisation. En eet, le stress test a rvl des taux derreurs montant jusqu` 12%, comme on e ee a peut le voir sur leurs rsultats : e http ://backoce.ajb.com.au//images/news/amazonunswerrors.gif. http ://backoce.ajb.com.au//images/news/googleunswerrors.gif.

23

Solutions libres

La plupart des hbergeurs proposent des solutions bases sur des logiciels Open e e Source. Cependant, il est regrettable de constater un manque vident de transpae rence au niveau des forfaits proposs. Dans loptique de fournir un service bas sur e e des logiciels libres, il faut maintenant sintresser aux dirents outils disponibles e e pour chacun des composants du cloud . Evidemment, lensemble du code produit doit tre publi sous license libre (GPL v.3, License BSD), et ne sappuyer que sur e e des protocoles et des biblioth`ques libres. e

4.1

Ct client o e

On ne peut videmment pas forcer un client ` utiliser un logiciel libre pour accder e a e au service fourni, mais des solutions libres peuvent lui tre proposes. Pour pouvoir e e accder aux applications hberges, il sut dun explorateur internet (Firefox, Kone e e queror, Epiphany, ...). Pour ce qui est de la mise en place de ses applications, un simple envoi des sources ou des binaires peut seectuer par FTP et une interface de test et de mise en production peut tre envisageable (criture ou envoi des sources, e e compilation, test sur une adresse prive). e

4.2

Services de base

Un ensemble de services de base est souvent fourni avec lhbergement dun cloud . e Parmis les plus courants, on trouve une messagerie (par exemple base sur Postx, e Procmail, Fetchmail, SpamBayes, Courier-imap, Mutt et SquirrelMail), un syst`me e didentit (OpenID), de paiement (Paypal, mais non-libre...), une messagerie instane tanne (XMPP) et de recherche. e

4.3

Applications

Lutilisateur peut accder aux services du cloud par des applications autres que e lexplorateur. De mme que pour lexplorateur, des solutions libres peuvent lui tre e e proposes. Pour les applications de bases, on peut citer : e Messagerie : Thunderbird, Kmail, ... Identit : OpenID Enabled e Chat : Pidgin, Gajim, Kopete, ... Le reste dpend des applications proposes par le client (client FTP pour du transe e fert, lecteur audio/vido, ...). e 24

4.4

Plateforme

La plateforme (chaque nud de la grid ) est compos dun syst`me virtuel (Dee e bian), avec des serveurs dpendant des langages utiliss (OpenJDK pour du code e e Java, Django pour du Python, Mongrel ou Thin pour du Ruby). Elle peut tre ace compagne de biblioth`ques ncessaires au fonctionnement de lapplication hberge. e e e e e

4.5

Infrastructure

Linfrastructure est le serveur frontal, et donc peut accueillir un syst`me GNU/Linux e adapt comme Debian. Sil hberge aussi des nuds de la grid , il utilise Xen e e comme syst`me de virtualisation. Il dispose videmment dun serveur web Apache. e e

25

Virtualisation

Le cloud computing dpendant fortement de la virtualisation, un bref rappel du e concept ainsi que des solutions majeures disponible simpose. Pour une description plus prcise, regardez Livre blanc : Virtualisation. e

5.1

Concept

La virtualisation permet dmuler a partir dun syst`me rel sur une machine phye ` e e sique un ou plusieurs autres syst`mes. On peut ainsi disposer de plusieurs syst`mes e e apparemment spars, disposant chacun de leurs services. Plusieurs utilisations sont e e possibles (possder plusieurs versions dun mme logiciel, liminer les conits entre e e e logiciels, pouvoir jouer ` des jeux Windows sous GNU/Linux, ...), mais le princia pal intrt est de ne pas avoir, pour un hbergeur, a maintenir plusieurs serveurs ee e ` sous-exploits mais de rassembler plusieurs services sur une mme machine physique. e e

5.2

Solutions majeures

Parmis les solutions majeures (et libres), on peut citer nottemment Xen et KVM, avec chacun leurs avantages. KVM Le projet KVM est un projet intgr au noyau Linux et bas sur QEMU. e e e Son avantage majeur par rapport ` Xen est que le syst`me utilis comme a e e hyperviseur est en fait un syst`me GNU/Linux, et donc lquipe dveloppant e e e KVM na pas a se soucier de cette partie. Il est facile dutilisation, stable, ` et de plus en plus utilis (soutenu par Red-Hat), y compris pour ce qui est e de lhbergement (Lost Oasis en France, Blue Room Hosting en Angleterre, e OpenHosting aux Etats-Unis, ...). Xen Xen est moins facile dacc`s mais plus puissant. Cest un syst`me de vire e tualisation avec hyperviseur, ce qui veut dire que lensemble des ressources matrielles sont partages entre les machines virtuelles (et non monopoe e lises par le syst`me principal). Le fait de devoir rimplmenter un syst`me e e e e e pour lhyperviseur permet de ne disposer que des fonctionnalits propres e a la virtualisation, et donc de fournir un syst`me de virtualisation plus ` e ecace. Cest un excellent choix pour la virtualisation dans le cadre de lhbergement. e 26

Etude du framework Vertebra

Vertebra est un framework permettant de superviser lensemble des processus et des serveurs qui constituent un cloud . Il est publi sous license libre LGPL et permet e dassurer scurit, portabilit et tolrance aux pannes. e e e e Scurit e e Possibilit de grer facilement des permissions par client ou par utilisateur, e e possibilit de crer des liens entre plusieurs clouds e e utilisant Vertbra. Portabilit e Ecrit pour pouvoir fonctionner sur sa propre architecture comme sur des syst`mes dj` existant (Amazon EC2 ou le VCloud de VMware). e ea Tolrance aux pannes e Larrt non-prvu dun ou plusieurs des composants principaux ne fait pas e e sarrter lensemble du syst`me, ils sont relancs et les autres composants e e e en dpendant attendent simplement leur disponibilit. e e

6.1

Fonctionnement

Un syst`me de cloud e bas sur Vertebra peut contenir les composants suivants, e en sachant que seuls les trois premiers sont indispensables. Server XMPP Pour la communication entre les dirents serveurs. e Agent Herault Assure la scurit et le syst`me dannonces. e e e Agent utilisateur Vide par dfaut, accueille les applications du client. e Agent entrept o Permet de stocker les informations sur lensemble des utilisateurs (noms, prols, mots de passe, ...). Agent cavalcade Contrle lautomatisation des processus. o Agent sawmill Permet un syst`me de login distribu. e e

27

6.2

Interface

An de pouvoir administer son cloud , Vertebra est accompagn dun shell propre e permettant une administration rapide et ventuellement automatisable. De plus, e grce a cet outil, le client peut facilement dvelopper ou faire dvelopper une apa ` e e plication graphique (utilisant le shell) pour administrer ses services en faisant des appels aux fonctions de ce shell. Il est mme enviseageable pour un hbergeur de e e fournir une interface web au client donnant acc`s a lensemble des fonctionnalites e ` e proposes. e Enn, on peut facilement et de mani`re invisible, donner lacc`s ` une personne ` une e e a a application du cloud , que ce soit une application classique ou ventuellement lape plication dadministration, ce qui permet ` un client de regrouper plusieurs syst`mes a e de ces syst`mes hbergs sur dirents comptes. e e e e

6.3

Intrts e e

Vertebra est sous license LGPL et est donc un candidat parmi les logiciels exploitables dans le but de fournir un service de cloud bas sur des logiciels libres. Il e fournit de base un serveur XMPP sur lequel le service voulu pourrait facilement se dployer, et une grande partie de son code est en Erlang, langage prvu pour tout e e ce qui est communication rseau et avec lequel on dsire travailler. e e Il sav`re donc que Vertebra est un framework quil faut utiliser, ou au moins sinse pirer de ses fonctionnalites, pour le service de cloud e envisag. e Il permet, grce entre autre ` son mode dadministration, de fournir au client un sera a vice a la fois complet et permettant un respect de ses liberts ainsi que la possibilit ` e e de runir son cloud e avec celui dun autre hbergeur. e

28

7
7.1

Mise en place
Pr-requis e

Etant donn quun syst`me de stockage en cloud e e ne prsente pas de dicult e e technique particuli`re (syst`me de chiers partags avec ventuellement une base de e e e e donnes permettant un acc`s plus rapide), nous allons nous concentrer sur la gestion e e dun service de cloud avec dveloppement dapplications. e On veut aussi nutiliser que des logiciels libres et que le code dvelopp soit sous e e license libre. On cherchera aussi a fournir au client la possibilit de dvelopper ses ` e e applications dans le langage de son choix. Pour la gestion des serveurs dapplications, ils seront enregistrs dans une base e de donnes SQL, avec deux identiants, un concernant lapplication hberge (pas e e e dunicit) et un identiant unique (incrmentation automatique) pour faciliter la e e communication. Tout ce qui concerne la communication entre le serveur frontal et les machines virtuelles sera trait dans le chapitre suivant. e

7.2

Serveur frontal

On utilise pour le serveur frontal une Debian avec un serveur web Apache et une base de donnes SQL (linstallation du syst`me et la mise en place dApache et e e de MySQL ne seront pas dtailles ici). Le but est de fournir un syt`me qui, lors e e e dune demande spcique au cloud e (lien vers une application, achage dune application sur une partie de la page), lance le serveur hbergeant lapplication sil e est teint ou surcharg, ou communique avec lui sinon. e e Dans ce but, il faut crire une fonction de lancement qui prend en argument un e identiant de lapplication (nom ou id) et qui eectue les actions suivantes : Vrier les droits de lutilisateur eectuant la demande ; e Vrier si une machine virtuelle correspondant a cette application ` dj` t e ` a eae e lance (requte ` la base de donnes) ; e e a e Si aucune nest prsente, en lancer une et linscrire dans la base de donnes ; e e Si une ou plusieurs machines sont dj` lances, vrier leur capacit daccueil ea e e e par le syst`me de communication (dcrit plus loin) : e e Si une des machines peut accepter une connexion, commencer la communication avec cette machine ; Sinon, lancer une nouvelle machine virtuelle, lenregistrer dans la base de donnes et commencer la communication. e

29

Note : La principale dirence entre le cloud computing e et le reste des solutions techniques dj` existantes consiste en son syst`me de communication entre les ea e machines ou entre les processus, lui permettant de fournir un rseau de machines dye namique (en fonction du nombre dutilisateurs ou de la quantit de donnes stockes e e e ou utilises). Un chapitre est donc ddi aux solutions possibles pour grer ces come e e e munications. Une fois la connexion tablie, le serveur frontal peut envoyer les requtes de lutilisae e teur a la machine virtuelle et soit recevoir les informations demandes (par XMPP) ` e et les acher, soit acher directement le serveur dapplications fourni par cette machine. De plus, il faut fournir au client un moyen de tests et de mise en production de ses applications. On peut limiter ce syst`me ` un utilitaire en ligne de commande e a de type SVN ou Git, ou un syst`me interactif accessible par un explorateur (avec e un syst`me denvoi des sources ou des binaires), de lancement sur un serveur priv e e de tests, puis de mise en production. Il faut aussi intgrer un moyen pour le client e de donner des droits sur ses applications pour pouvoir limiter lacc`s de certaines e applications aux seules personnes concernes. e

7.3

Machines virtuelles

Les machines virtuelles accueillant les applications du client sont heberges sur un e ensemble de serveurs permettant la virtualisation. On utilise Xen comme syst`me e de virtualisation (encore une fois, se rfrer au Livre blanc sur la virtualisation). ee Xen est bas sur des chiers de congurations propres a chaque machine virtuelle. e ` Le chier est sous la forme suivant : name = nom du syst`me e vcpus = nombre de CPU virtuels memory = nombre de Mo de RAM que vous voulez allouer kernel = chemin vers le kernel voulu ramdisk = chemin vers la RAM vif = rseau (adresse MAC, IP, bridge) e disk = disques a utiliser (chemin, droits, etc...) ` root = partition a utiliser pour / `

30

Chaque machine virtuelle accueille un ensemble de logiciels lis au(x) langage(s) dans e le(s)quel(s) est crite lapplication. Voici les solutions libres pour quelques langages : e Ruby on Rails machine virtuelle excutant le code : YARV, sous license libre Ruby ; e serveur dapplications : Thin, bas sur Mongrel, sous license libre Ruby. e Java machine virtuelle : JVM, sous license libre a partir de la version 7 ; ` serveur dapplications : JBoss application server, sous license GLPL. Erlang serveur web : Yaws ; interprteur erlang. e Python framework django.

7.4

Compatible libre ?

Pour rsoudre les probl`mes thiques lis au cloud computing , de nombreux e e e e choix peu ou pas proposs par les autres hbergeurs sont a mettre en uvre. e e ` Pour ce qui est de la visibilit du syst`me, il faut fournir au client et aux utilisateurs e e les images des machines virtuelles (avec les applications si le client veut mettre les mettre sous license libre, et sans dans le cas contraire). De plus, dans le but de prouver lutilisation des images dvoiles, il faut mettre en place un syst`me de e e e monitoring permettant de publier en temps rel les serveurs tant en fonctionnement e e et les applications lances dessus. e Du ct du client, il faut lui donner un acc`s direct a lensemble de ses donnes et oe e ` e lui assurer une transparence totale sur le syst`me de sauvegardes (avec acc`s sur les e e machines les hbergeant). e Dun point de vue des forfaits, il faut viter les forfaits pi`ges proposs par la majorit e e e e des hbergeurs. Sur ce point, il existe peu de solutions satisfaisantes et il faudrait e envisager un nouveau type de forfait qui serait a la fois clair et avantageux pour ` le client, mais sans prsenter de risques pour lhbergeur. On peut envisager, dans e e ce but, un forfait bas uniquement sur le nombre dapplications et dutilisateurs, e permettant ainsi un prix assez stable dans le temps (ne dpend pas du nombre de e donnes transites, du nombre de connexions, ...) et retant bien lutilisation du e e e cloud (son utilisation dpendant principalement du nombre dutilisateurs, et le e matriel requis du nombre dapplications proposes). e e

31

Communication

Le but de ce chapitre est dtudier le moyen le plus avantageux pour eectuer la e communication entre le serveur et les machines virtuelles accueillant les applications. Plusieurs moyens peuvent tre mis en oeuvre : e Utilisation du protocole XMPP avec un bot par machine ; Utilisation du syst`me de message passing e du Erlang ; Utilisation du protocole TCP avec un syst`me client/serveur crit en Erlang. e e Le protocole XMPP est un standard ouvert qui prsente plusieurs avantages (sere veur inclus dans le framework Vertebra, syst`me Publish/Subscribe, existence dune e biblioth`que ecace en Erlang). De plus, les communications sont eectues par e e change de documents XML, ce qui permet par exemple un passage dobjet(*) ee cace ainsi quun bon syst`me de passage de directives. e Le message passing de Erlang est aussi avantageux car il est extrmement e simple ` mettre en place (quelques lignes de code pour le squelette du server, une a ligne pour un envoi de message). De plus, il prsente des performances excellentes e (comparaison Erlang/Java). Enn, son utilisation peut servir a passer des objets de ` faon assez intuitive. c Enn, le protocole TCP ne prsente aucun avantage particulier, mais servira doutil e de comparaison classique pour valuer les deux prcdents. e e e

8.1

XMPP

Prsentation e
XMPP (Extensible Messaging and Presence Protocol) est un protocole dchange e de documents XML. Dans le but de ne pas dpendre dun fournisseur, un serveur e XMPP peut tre mis en place a lintrieur dune socit ou chez un particulier. Il e ` e ee existe des moyens puissants de scuriser ce protocole (ce qui est important, que ce e soit pour une communication humain/humain ou serveur/serveur), tels que SASL(*) et TLS(*).

32

Une utilisation autre que celle de la messagerie instantane consiste a transformer e ` XMPP en moyen dobserver et dadministrer un serveur a distance. En eet, en ` envoyant un message format de faon prdnie par le possesseur du serveur, il est e c e e facile de lui passer des commandes. Voici un exemple ctif et excessivement simple pour provoquer larrt dun serveur : e <?xml version="1.0" encoding=UTF-8?> <halt> <delay> 15min </delay> </halt> Ici, si le serveur a t correctement congur, il peut comprendre quil doit sarrter `ee e e dans 15 minutes. Evidemment, cet exemple ne prsente aucune scurit. Si une e e e personne quelconque envoie ce message, le serveur steindra. On peut alors limiter e lexcution de telles commandes ` certaines adresses du rseau ou a certaines identit e a e ` e (gres par XMPP), la scurit sera alors assure par lidentication du bot (*) ee e e e ou de ladministrateur aupr`s du serveur ejabberd. e De plus, le XML est un moyen pratique de communiquer un objet dun ordinateur a ` un autre, de sauvegarde dobjets, ou mme de modication dobjets sans passer par le e langage utilis, ce qui le rend tr`s intressant dans un syst`me de cloud , surtout e e e e si on rajoute le fait que les messages peuvent tre envoys par HTTP, facilitant e e encore plus la communication dans le cadre dun serveur web dapplications. Enn, XMPP permet un syst`me de Publish/Suscribe, cest-`-dire un moyen de pue a blier des messages dans un syst`me de classes sans savoir qui (comprendre : quelle e autre machine) est intress par la rception de ce message. On peut donc diuser e e e un message a un ensemble de serveurs, sans se procupper de la rception. Ainsi, ` e e ce syst`me permet de diuser a la fois des informations de maintenance ou de sure ` veillance et des messages contenant des ordres ou du transfert dobjet entre serveurs (un serveur vers lensemble des serveurs intresss ). e e

Utilisation
Un serveur Jabber doit tre utilis pour permettre une communication base sur e e e le protocole XMPP. Il serait envisageable dutiliser un des nombreux fournisseurs (gratuits) de comptes jabber. Cependant, an dassurer une plus grande scurit et e e surtout une plus grande ractivit, il est prfrable dinstaller son propre serveur e e ee Jabber. Comme le but est dimplmenter une partie du code en Erlang, le choix le plus e judicieux est dutiliser ejabberd, un serveur Jabber libre, crit exclusivement en e Erlang. 33

Les points importants du chier de conguration (/etc/ejabberd/ejabberd.cfg) sont : {hosts, ["your.host.name"]}. : dnit le nom du serveur auquel lon e pourra se connecter. {acl, admin, {user, "user name", "localhost"}}. : dnit ladminise trateur du serveur. e e {s2s use starttls, true}. : force la connexion scurise. {s2s certfile, "/path/to/the/certificat.pem"}. : chemin du certicat ` utiliser. a Une fois le serveur ejabberd install et lanc, on peut utiliser la commande ejabe e berdctl pour ladministrer (ajout dutilisateur, sauvegarde des utilisateurs, ...), et utiliser iptables pour limiter lacc`s au serveur uniquement aux syst`mes faisant e e partis du cloud pour assurer une meilleure scurit (Cf. gure 5). e e Un syst`me de e cloud peut par exemple disposer des utilisateurs suivants : frontserver : utilis par un daemon(*) recevant et traitant les demandes e eectues aupr`s du serveur frontal. e e monitor : utilis par un daemon (pas forcment lanc sur le serveur frontal), e e e recevant lensemble des informations constituant les logs et le service de monitoring. e e e appserver n : utilis par un daemon lanc sur la n-i`me machine accueillant les applications, traitant les ordres que lui passent, principalement, le serveur frontal. Il faut dnir lensemble des commandes qui peuvent tre envoyes. Dans un premier e e e temps, le serveur frontal (qui recoit les demandes des utilisateurs), peut envoyer vers les machines virtuelles accueillant les applications les requtes suivantes : e create name : cre une VM compl`te pour lapplication name. e e delete name : supprime lensemble des chiers et des congurations pour lapplication name. start time : dmarre les services ncessaires, time tant la planication du e e e lancement (now, in n minutes, at hour :minute...), renvoie une conrmation. halt time : idem pour larrt. e reload time : idem pour le redmarrage des services. e whoisthere : envoie la liste des personnes connectes au services et le nombre e total de personnes. status : envoie le status des services (up, inaccessible, down, erreur, ...). uptime [VM/services] : envoie la dure depuis laquelle la machine est lance, e e celle depuis laquelle les services sont accessibles. ping : attend pong comme rponse. e

34

Cette liste nest videmment pas exhaustive. La deuxi`me srie de requtes concerne e e e e des communications entre machines virtuelles accueillant une mme application dise tribue ou un ensemble dapplications connctes. Les commandes seraient alors les e e e mmes avec, en plus, des commandes spciques ` ces applications et pouvant alors e e a utiliser toutes les possiblits du XML, et en particulier la facilit a passer des objets. e e`

8.2

Message passing

Prsentation e
Le langage Erlang est muni de base dun syst`me de message passing e intuitif. Le message passing est un moyen denvoyer des messages, informations, ordres, donnes, dun processus ` un autre. Il est intuitif car son criture est simplie : e a e e Pid ! Data Les donnes envoyes sont souvent des tuples(*) dont le premier est le Pid(*) de la e e fonction qui envoie le message, ce qui permet ` la fonction rceptrice denvoyer un a e accus de rception, ou simplement de continuer la communication avec lmetteur. e e e Pour obtenir son Pid, une fonction fait simplement appel ` la fonction : a self() Le nombre dlements dans le tuple est libre, ce qui permet de pouvoir facilement e envoyer des objets. On peut envoyer (exemple extrmement simpli pour expliquer e e le concept) : StockObjs ! {self(), cl1, a, 1, b, test} Le serveur recevant ce message pourra alors instancier un objet de classe cl1 , initialis aux valeurs 1 et test e pour les attributs a et b . En passant ainsi lensemble des valeurs des attributs dun objet, on peut le sauvegarder sur un serveur de stockage. De mme, pour passer une commande a eectuer, on peut tout ` fait envisager le e ` a mme syst`me de communication, ce qui fait du message passing e e une relle e alternative au protocole XMPP et ` son transfert de XML (Cf. gure 4). a

Utilisation
Les exemples prcdents ne fonctionnent que dans le cas dune communication ine e terne a une machine. Pour pouvoir envoyer des messages entre deux processus lancs ` e sur deux machines distinctes, certaines manipulations supplmentaires sont a eece ` tuer.

35

Tout dabord, il faut lancer linterprteur Erlang (erl) comme cela : e # erl - name name_n - setcookie cookie_name \ - pa / path / to / binary - name name_n donne le nom name n@hostname hostname . - setcookie cookie_name assigne le cookie(*) cookie name a linterprteur. Les cookies doivent ` e tre identiques sur tous les nuds qui veulent pouvoir communiquer. e - pa / path / to / binary permet dutiliser les fonctions compiles et dont les chier .beam sont placs e e dans /path/to/binary. Une fois cela fait, les processus enregistrs peuvent communiquer entre eux. Pour e enregistrer un processus, on utilise la fonction suivante : global:register name(name, PidDeLaFonction). Une fois cela fait, pour entammer la communication entre le nud metteur et le e nud accueillant la fonction enregistre, on lance : e net adm:ping(node@hostname). Enn, pour envoyer une message a cette fonction, on utilise : ` {name, node@hostname} ! Message. La variable Message peut tre nimporte quel type de variable, en particulier des e tuples contenant autant de variables que ncessaire, tout comme le XML et ses e mthodes pour envoyer des objets. e a linterprteur lanc sur la machine ` e e

36

8.3

Comparaison des deux mthodes e

Implmentation e
Les deux mthodes de communications envisages sont simples a implmenter. e e ` e Le Message Passing tant une fonctionnalit native de Erlang, il est dautant plus e e simple a implmenter (une ligne pour enregistrer la fonction, une ligne pour eectuer ` e un ping , une ligne pour envoyer le message). Pour ce qui est de lutilisation du protocole XMPP, la biblioth`que exmpp pour e Erlang a t retenue. Elle est ecace, et facile a prendre en main, mme si la seule ee ` e documentation fournie (projet rcent) est celle issue de la compilation (le code est e cependant tr`s bien comment). e e Le seul rel probl`me dimplmentation concerne le protocole XMPP et lutilisation e e e dexmpp. En eet, Erlang, et le concept de langage fonctionnel pur de mani`re e gnrale, nest pas forcment le mieux adapt au format XML car on ne peut pas e e e e modier les variables sauf a linstanciation. Ainsi, sur certaine fonctions denvois de ` messages, on peut se retrouver avec 6 ou 7 variables, chacune tant une modication e mineure de la prcdente. Si cela ne semble pas poser de probl`me dun point de vue e e e de la mmoire ou du temps dexecution, cette approche nest pas vidente pour un e e dveloppeur habitu ` la programmation itrative. Cependant, ceci est un probl`me e ea e e mineur qui est rapidement rsolu (lecture du code de exmpp, criture de fonctions e e basiques de retouche de messages reus, ...) c

Test basique de charge

Le premier test a avoir t ectu tait un envoi massif de messages (test avec ` ee e ee e 10 000, 100 000, 1 000 000 messages). Le Message Passing a alors prouv son efe cacit : 2 secondes pour lenvoi et la rception de 1 000 000 000 de messages. e e Par contre, la rception des messages envoy par le protocole XMPP a montr des e e e rsultats beaucoup moins bons : pour un envoi de 1 000 messages (envoi quasie instantan), le rcepteur met plus de 2 minutes 30 avant de recevoir le dernier. En e e eet, les messages semblent arriver par groupe dune dizaine avec un temps dattente entre chaque groupe. Ainsi, le premier test, certes basique et peu reprsentatif (utilisation de la congue ration par dfaut dejabberd), tait clairement au dsavantage du protocole XMPP. e e e Cependant, un simple test de charge, avec un envoi anormalement massif de messages ne pouvait pas tre le seul moyen de dcision. e e

37

Maquettes fonctionnelles
Apr`s ce test basique, deux maquettes fonctionnelles, minimalistes, ont t ralises. e ee e e Les deux taient heberges sur les mmes machines virtuelles, utilisaient yaws comme e e e serveur web, achaient les mmes pages. La premi`re utilisait le syst`me de Message e e e Passing et la deuxi`me le protocole XMPP (deux schmas expliquent le fonctionnee e ment ci-dessous). Les deux maquettes utilisaient chacune deux machines virtuelles, lune jouant le rle du serveur frontal, lautre celle dun serveur dapplication. Lapplication quil o hbergeait tait un simple hello world e e (puis un acheur dheure). Concernant la ractivit, les deux taient, dun point de vue de lutilisateur, simie e e laires. Elles permettaient un achage aussi rapide que pour un simple site heberg e sur un serveur unique. Dun point de vue du dveloppeur, il a fallu mettre un delai e suprieur avant la redirection (temps dattente crit en dur pour que le message e e arrive et que le serveur web se lance sur le serveur dapplication) dans le cas de la maquette XMPP. Cependant, ce dlai supplmentaire est ngligeable (de lordre de e e e la centaine de milliseconde). Pour ce qui est des possibilits et de la claret dans le schma de communication, e e e cest l` que XMPP dvoile ses possibilits. En eet, il est beaucoup plus clair davoir a e e un client jabber par machine prsente dans le cloud , avec en plus des clients e particuliers pour certaines tches (monitoring, envoi de message ne demandant pas a de rponse, ...), plutt que des fonctions enregistres dans un interprteur identi e o e e e par un cookie. Malgr ce que lon peut voir sur le schma, le bot XMPP qui rpartit lensemble des e e e requtes nest pas forcment lanc sur le serveur frontal. De mme, le serveur ejabe e e e berd et le bot de monitoring tait hbergs sur le serveur frontal dans la maquette e e e ralise, mais ceci nest pas ncessaire (on peut, par exemple, ddier une machine e e e e compl`te pour le contrle du cloud ). e o

38

Figure 4 Communication par Message Passing

39

Figure 5 Communication par protocole XMPP

40

8.4

Conclusion

Les deux moyens de communications envisags sont tous les deux performants et gloe balement faciles a implmenter. Lutilisation du protocole XMPP ralentit lg`rement ` e e e la rception, et donc le traitement, des messages. Le Message Passing quand ` lui e a est dune facilit dimplmentation et dune ecacit sans pareil. e e e Cependant, lutilisation du protocole XMPP permet non seulement de clarier le rseau, de centraliser la gestion des requtes et denvisager lutilisation de capacits e e e dja dveloppes (syst`me de publish/subscribe, syst`me de prsence, ...) ou de e e e e e e proter de laspect extensible du protocole pour dvelopper des extensions ddies e e e au cloud (module de publication de ltat dune machine virtuelle, ...). e Au nal, malgr une certaine lenteur par rapport au Message Passing, cest lutilie sation du protocole XMPP qui semble la plus approprie. En eet, ce protocole (qui e est un standard ouvert), est assez ractif pour que ne pas ralentir le cloud e de mani`re abusive. De plus, cest lui qui permet la plus grande extensibilit. Enn, e e le schma de dploiement des bots XMPP correspond au schma dorganisation du e e e cloud , ce qui permet de clarier le code dune part, et dviter une duplication e de code (seul un bot reoit les requtes, les traite, et envoie des demandes spciques c e e aux bots des serveurs dapplications).

41

Load Balancing

Le deuxi`me aspect particulier du cloud e est son syst`me de rpartition des e e charges et la gestion dynamique des machines qui le composent. En eet, dans un cloud on trouve non seulement un syst`me de rpartition de charge clase e sique (pour lequel des solutions existent dj`), mais surtout un syst`me de ea e dtection des besoins : le cloud ragit en fonction des demandes des utilisateurs, e e grant les machines accessibles (comprendre ici : les machines virtuelles dmarres) e e e pour minimiser leur nombre et maximiser la ractivit des dirents services. Cet e e e algorithme est tr`s utilis et rpond totalement totalement aux attentes dun algoe e e rithme de rpartition de charges dans un cloud e (facilit dimplmentation et e e rpartition quitable). e e

9.1

Gestion dynamique des machines virtuelles

Pour proposer un service de cloud computing performant et cohrent avec le e concept, il faut fournir un syst`me de gestion dynamique des machines disponibles. e En eet, si peu dutilisateurs se connectent au cloud , il nest pas utile davoir une multitude de serveurs lancs et sous-exploits. A linverse, si de nombreux utilie e ` sateurs tentent de se connecter au service simultanment, ils ne doivent pas observer e un service ralenti. Pour pouvoir assurer ce service, le fournisseur doit possder un e syst`me de lancement et darrt de machines coordonn avec les demandes. e e e Ainsi, quand le premier serveur (frontaux, SQL ou dapplication) a atteint ses capacits maximales, un deuxi`me serveur est lanc, et les requtes sont alors rparties e e e e e quitablement entre les deux serveurs prsents. Quand les n serveurs prsents ont ate e e teint leur capacits maximales (de mani`re globale), on lance un (n+1)-i`me serveur, e e e et on rparti les requtes sur les n+1 serveurs. e e Certains fournisseurs g`rent les machines disponibles grce a un syst`me interactif, e a ` e potentiellement mis ` disposition du client, mais cela implique une prsence humaine a e ddie de mani`re quasi-permanente a la surveillance du cloud . Le syst`me le e e e ` e plus judicieux et le plus avantageux est dimplmenter un monitoring automatique e du cloud et de lui faire grer le lancement et larrt des serveurs. Evidemment, un e e tel syst`me sera surveill et mis a jour pour que ses performances soient maximises, e e ` e ce qui implique un prsence humaine (au moins les premiers temps). e

42

Il y a trois types de serveurs ` grer dynamiquement : a e Lensemble des serveurs frontaux. Lensemble des serveurs SQL. Lensemble des serveurs dapplication.

Serveurs frontaux
Pour dnir le besoin dajout ou de suppression de serveurs frontaux, on doit tudier e e le temps de rponse du serveur web a une demande classique. Le serveur frontal e ` nhbergeant aucune application, il sut donc dtudier son temps de rponse sur e e e une simple requte (un ping par exemple). Si le temps de rponse est anormalee e ment long, le syst`me de monitoring fait une requte pour lancer un serveur frontal e e supplmentaire (la gestion de multiples serveurs pour un service unique sera trait e e dans la partie suivante). Si le temps est normal ou acceptable, rien nest ectu. e e Enn, si le temps est anormalement court, le syst`me de monitoring peut demander e la suppression dun ou plusieurs serveurs frontaux. Tout le probl`me est de dnir e e anormalement long et anormalement court . Ces limites sont globalement arbitraires et dpendent des capacits de lhbergeur et des demandes du client. e e e

Serveurs SQL
Concernant lajout ou la supression de serveur SQL, il faut tudier le temps de e rponse de la base de donnes, en eectuant, par exemple, une ou plusieurs requtes e e e ` partir des rsultats, pr-dnies et en tudiant le temps de rponse de la base. A e e e e e et en appliquant le mme principe que pour les serveurs frontaux en comparant le e temps de rponse de ces requtes a des valeurs arbitraires xes. e e ` e Direntes rpartitions sont envisageables : e e plusieurs serveurs grant chacun une partie des donnes dune application ; e e plusieurs serveurs sur la mme base de donnes avec un syst`me complexe de e e e mise-`-jour lors des critures et/ou une sparation des serveurs permettant a e e la lecture et ceux permettant lcriture. e

43

Serveurs dapplication
Enn, pour les serveurs dapplications, le calcul peut tre plus compliqu. On doit e e non-seulement valuer le temps de rponse du serveur web qui ectue lachage e e e comme sur les serveurs frontaux, mais aussi direntes valeurs qui, dans le cas de e lhbergement dune application, deviennent signicatives (utilisation du CPU, oce cupation de la mmoire, charge, ...). On peut aussi pondrer ces valeurs pour fournir e e une valuation simple (par exemple un score compris entre 0 et 100) dans le but e de clarier les cas de lancement ou darrt des serveurs. De mme que les valeurs e e arbitraires des deux premiers cas, la pondration est arbitraire et dpend des besoins e e du client, des capacits du fournisseur mais aussi de lapplication elle mme. e e

Le lancement de serveurs supplmentaires ainsi que larrt de serveurs superus (du e e moins les algorithmes retenus ici) reposent donc enti`rement sur des valeurs xes. e e Le plus important dans limplmentation est donc la gestion de ces valeurs : e valeurs pour les serveurs frontaux ` ajuster selon les besoins du client et les a capacits du fournisseur, e valeurs pour les serveurs SQL a ajuster selon les mmes crit`res, ` e e valeurs pour les serveurs dapplication a ajuster sparment pour chaque ` e e application en prenant en compte : les besoins du client concernant cette application, les capacits du fournisseurs, e les demandes de lapplication en ressource.

9.2

Load balancing, HAProxy et round-robin

Load balancing
Une fois le nombre de machines virtuelles adquat atteint, il faut rpartir les dee e mandes entre ces machines. Cest le principe de load balancing a proprement ` parler. De nombreux outils existent pour rpartir la charge entre plusieurs serveurs, de e mme que plusieurs algorithmes de rpartition. e e

44

On peut eectuer du load balancing a plusieurs niveaux du mod`le OSI(*) : ` e Couche 7 : la couche application , on peut forcer des redirections vers dautres adresses IP, comme par exemple avec lutilisation du mod proxy de apache (directive BalancerMember) ou HAProxy, dtaill plus loin. e e Couche 4 : la couche transport , en redirigeant d`s larriver de la requte e e (sans passer par la couche applicative ), avec lutilisation de Linux Virtual Server (LVS), solution de virtualisation pour cluster de serveurs. Voici quelques uns des dirents algorithmes : e Redirection alatoire : envoie des requtes vers un des serveurs disponibles e e de mani`re alatoire. Ce syst`me est simple ` implmenter, mais nest pas e e e a e ecace. Round-robin : eectue une rotation rguli`re de ladresse IP du serveur qui e e va recevoir les demandes. Cet algorithme est implment dans la totalit e e e des syst`me de load balancing e et peut facilement tre amlior par une e e e allocation de poids ` certaines IP. a Moins utilis : le byrequest o` le serveur qui a reu le moins de connexions e u c reoit la suivante. Dstin ` de longues sessions. c e ea bybusiness : redirection vers le serveur le moins utilis. e source : eectue un hash sur ladresse du client pour lassigner a une adresse ` IP. Cet algorithme permet dassurer quun mme client se connectera toue jours ` un mme serveur. a e

Round-robin
Le Round-Robin est un algorithme dordonnancement mais dont le principe a t ee adapt a la rpartition de charge. Le Round-Robin de base fournit une rpartition e` e e quitable entre plusieurs serveurs, ce qui veut dire que les serveurs doivent tous tre e e identiques pour une ecacit optimale. Cependant, le Round-Robin pondr nest e ee pas beaucoup plus compliqu ` implmenter et prsent dans la plupart des logiciels ea e e de rpartition de charge. e

HAProxy
HAProxy est un logiciel libre (HAPROXYs license) de rpartition de charge et de e gestion de proxy adapt a des sites recevant de nombreuses connexions (et donc e ` adapt a un service de type cloud , Cf. gure 6). Il est congur dans un chier e` e de conguration unique, haproxy.cfg , et se lance facilement avec la commande : # haproxy -D -f / etc / haproxy . cfg

45

Dans le cas dun service de cloud , les IP disponibles pour un service sont dynamique, et demandent donc une modication de ce chier. Cependant, on peut recongurer dynamiquement HAProxy avec : # haproxy -f / etc / haproxy . cfg - sf PidDeHaproxy

9.3

Conclusion

Le syst`me de load balancing en lui mme est simple a mettre en place car des loe e ` giciels existent dj` pour le grer. HAProxy semble tre la solution idale : simple ea e e e a congurer, ` re-congurer, capable de grer la rpartition a plusieurs niveaux, ` a e e ` prsentant une tr`s bonne scurit (pas une faille de scurit en sept ans), et, e e e e e e videmment, libre. e Le rel probl`me dans le cas du cloud computing est la dynamicit du rseau et e e e e la mani`re de la grer. Il faut en eet tre capable dadapter le rseau aux demandes e e e e des utilisateurs, cest-`-dire ajouter des serveurs supplmentaires ncessaires a de a e e ` nombreuses requtes ou en supprimer si la demande est faible. Le moyen le plus e simple est de grer manuellement les capacits du rseau, et donc de faire lancer ou e e e arrter les serveurs par un humain. Cependant, cette approche est coteuse tant dun e u point de vue temps que dun point de vue moyens, il est donc prfrable de mettre ee en place un service automatis de gestion du rseau qui vrie de mani`re rguli`re e e e e e e les capacits de rponse du cloud e e et qui lajuste aux besoin des utilisateurs. Une telle gestion du rseau prsentera des incohrence et demandera des adaptae e e tions dans les premiers temps de la mise en production dun cloud . La prsence e humaine reste donc une obligation, mais seulement le temps dajuster ce syst`me e aux besoins propres ` un service de cloud . a

46

Figure 6 HAProxy

47

Conclusion
Le cloud computing est une mode rcente o` de plus en plus de clients ont e u tendance a sengourer, et donc de nombreux hbergeurs ont mis en place des pro` e positions de solutions de cloud . Pourtant, ces propositions prsentent toutes (ou e quasiment toutes) des aspects inadmissibles du point de vue de lthique du libre e (forfaits, syst`mes proposs sans aucun moyen de contrle), ou simplement trop e e o ous. Pourtant, un cloud peut prsenter des intrts vidents pour une entreprise. e ee e Grce ` un tel syst`me, elle peut proposer un ensemble dapplications ` ses employs a a e a e sans avoir ` se soucier de sa maintenance ou son administration, tout en ayant lasa surance dun syst`me moins consommateur (la quantit des ressources doit sadapter e e a lutilisation du cloud ) et donc plus conome (labonnement doit tre fonction ` e e des capacits mises en place). Certaines peuvent mme utiliser le cloud e e pour commercialiser un service par le biais dapplications web. Lutilisation du libre (et surtout un total respect de son thique) permettrait dassurer un double objectif : e Apporter une vision du cloud computing nouvelle par sa transparence, ce qui amliorerait limage dune telle technologie dans lesprit de la come munaut libriste et qui forcerait peut-tre une volution des ores dj` exise e e ea tante. Fournir aux clients une relle garantie sur la faon de traiter leurs donnes, e c e leur assurer un rel contrle sur elles, et donc pouvoir enn proter des e o possibilits techniques quapporte le cloud computing e sans devoir faire preuve dune conance aveugle en lhbergeur. e

48

Particularits e La dirence principale entre un syst`me de cloud e e et un hbergement clase sique est la gestion du rseau complexe qui le compose, gestion principalement e fonde sur deux points : e La communication entre les serveurs : pour assurer le lancement, larrt, e la communication de donnes entre les machines, il faut mettre en place e un syst`me de communication complet (pour permettre, par exemple, du e passage dobjet) et automatisable (et donc dnir une grammaire des ordres e que les serveurs peuvent senvoyer). Le syst`me de Load balancing : qui permet de grer ltat du cloud en e e e fonction des demandes des utilisateurs, soit automatiser le lancement, larrt e ou la modication de capacit des serveurs en fonction de leur temps de e rponse. Cest en ce sens quun cloud e se distingue dun syst`me de e grid computing .

Pour assurer ces deux syst`mes, les choix retenus sont : e Lutilisation du protocole XMPP, hberg par un serveur ejabberd, et une e e implmentation des bots en Erlang grce ` la biblioth`que exmpp. e a a e Lutilisation du logiciel HAProxy pour eectuer le Load balancing, avec une implementation compl`te du ou des scripts analysant le besoin du rseau et e e demandant lajout ou la suppression de serveurs.

La gestion dynamique du rseau est le point le plus obscur ` mettre en place. En e a eet, cette gestion demande une analyse complexe de ltat des serveurs, qui dpend e e du rle du serveur observ, de ses capacits, de son tat (utilisation des ressources, o e e e nombre de connexions, ...) et. videmment, des capacits disponibles chez lhbereur e e e ainsi que les demandes particuli`res du client (demande de maximisation de la qualit e e de rponse, de minimalisation des cots, ...). e u

Une approche extrmement basique de voir ce probl`me est de faire un appel a un e e ` serveur, dtudier son temps de rponse, et den dduire laction a eectuer : e e e ` Si le temps de rponse est trop e court, on demande larrt de serveurs. e Si le temps de rponse est susant, on ne fait rien. e Si le temps de rponse est trop long, on demande le lancement de serveurs e supplmentaires. e

49

Dans le but de fournir un ensemble de scripts rpondant de mani`re optimale a e e ` ce probl`me, il faut sparer les dirents serveurs suivants leurs rles et adapter le e e e o script basique : Les serveurs frontaux doivent assurer un temps de rponse correcte aux e requtes HTTP. e Les serveurs de bases de donnes doivent assurer une tr`s grande rapidit e e e aux requtes SQL. e Les serveurs dapplication doivent assurer un temps de rponse correcte aux e requtes HTTP ainsi quune capacit de calcul constante. e e Lavantage de HAProxy dans le cas du cloud computing est sa capacit a e ` pouvoir prendre en compte les modications du chier de conguration sans avoir a ` tre arrt. e ee

Vision libriste Malgr tous les points ngatifs non-rfutables formuls ` lgard du cloud compue e e e a e ting , le fait de sopposer aux hbergeurs fournissant un service, comme le soul`ve e e Stallman, qui va ` lencontre des liberts du client et de lutilisateur nest pas a e ngligeable. Le pire tant que certains de ces fournisseurs privateurs e e le font en basant leur publicits sur lutilisation de logiciels Open Source, prouvant une fois e de plus la dirence fondamentale entre ces deux mouvements. e De plus, apr`s de nombreuses recherches et rexions sur le concept, des moyens e e divers peuvent tre mis en place pour librer e e le cloud . En eet, il est tout a fait envisageable de fournir : ` Une architecture totalement libre (syst`me dexploitation, logiciels et code e mis en place par lhbergeur). e Un monitoring complet et permanent des serveurs qui constituent le cloud . Un moyen simple daccder a ces serveurs pour eectuer un monitoring local. e ` Lensemble des images qui sont utilises comme images syst`me (dans le e e cadre de la virtualisation). Le principal point a dvelopper et a mettre en avant est laccessibilit et le contrle ` e ` e o par le client (et a un certain niveau par lutilisateur) sur ses donnes, ainsi quun ` e moyen pour lui de les scuriser vis-`-vis de lhbergeur, et quil nait ` aucun moment e a e a de doute sur leur utilisation ou leur visibilit. e

50

Inconvnients e En plus du ct buzz mdiatique oe e du cloud , cette technologie prsente des e inconvnients dont il faut tre conscient en tant quhbergeur : e e e Dun point de vue thique du libre, le cloud reste dviant dun des objece e tifs du monde du libre, permettre aux utilisateurs de se rapproprier loutil e informatique (mais nest pas, alors, pire quun hbergement classique ). e Le cloud doit se plier ` des lois spciques variant dun Etat a lautre, a e ` rendant dicile, par exemple, certaines migrations. Les facturations actuelles des services sont ` la fois complexes et dsavantageuses a e du point de vue du client, ce qui force soit ` proposer une facturation a irrespectueuse pour le client, soit ` se dmarquer nettement des autres a e hbergeurs. e Les syst`mes de cloud e actuels prsentent des failles dun point de vue e de la qualit, un nouveau type dhbergement se doit donc de pallier ces e e faiblesses pour pouvoir marquer une relle volution. e e

Ces inconvnients (au moins pour les deux derniers points) sont des contraintes pour e lesquelles les solutions nexistent pas encore (ou du moins ne sont pas majoritaires), et sont donc les points cls pour une nouvelle ore de cloud . e

Bilan Au nal, plusieurs points amm`ne a vouloir proposer une ore de e ` cloud : proter du ct buzzword ; oe proposer une vision du cloud respectueuse de lthique du libre ; e pouvoir adapter certains aspects de cette technologie aux services actuels (les implmentations, scripts de lancement de serveurs, load balancing, come munication XMPP, sont totalement rutilisables). e

51

Glossaire
AFS Andrew File System : syst`me darchivage distribu. e e Bot Programme informatique eectuant des tches automatises (rponses automatiques a e e et/ou traitement de messages par exemple). Cookie Fichier stock par le navigateur sur le disque de linternaute, permettant denregise trer des informations et de les communiquer au site visit. e Daemon Processus sexcutant en arri`re plan de mani`re permanente. e e e Framework Ensemble de biblioth`que permettant le dveloppement dapplications. e e Mod`le OSI e Mod`le de communication entre ordinateurs propos par lISO. e e Monitoring Surveillance et mesure dun ensemble de processus. Objet Dnition de caractristiques propres a un lment informatique. e e ` ee Pid Process Identier : Code unique attribu a un processus. e` SASL Simple Authentication and Security Layer : cadre dauthentication. SSL / TLS Secure Sockets Layer ou Transport Layer Security : protocole de scurisation des e changes sur Internet. e Virtualisation Technique permettant de faire fonctionner sur une seule machine un ensemble de syst`mes dexploitations. e 52

Table des gures

Table des gures

1 2 3 4 5 6 Fonctionnement du cloud . . . . . . . . . . . . . . . . . . . . . . 7 Fonctionnement dtaill . . . . . . . . . . . . . . . . . . . . . . . . . 14 e e VM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Communication par Message Passing . . . . . . . . . . . . . . . . . . 39 Communication par protocole XMPP . . . . . . . . . . . . . . . . . . 40 HAProxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

53

Bibliographie

Wikipedia - Cloud Computing URL Wikipedia - Load Balancing URL Wikipedia - Load Balancing URL Site ociel dErlang URL Cration de bots XMPP en Erlang e URL 1 URL 2 URL 3 Site du protocole XMPP URL Site de HAProxy URL Livre blanc sur la virtualisation par Lucas Bonnet URL

54

Sites des direntes ores commerciales e Amazon EC2 Amazon S3 Google App Engine Microsoft Azure 3Tera Appistry Joyent Legal Cloud Skytap Agathon Group Elastic Hosts Flexiscale GoGrid Rackspace NewServers Aptana Heroku

55