Etat

de lart du Cloud Computing

et adaptation au Logiciel Libre
Maurice Audin
2009

Typographie
Les termes suivis dun asterisque (*) seront definis dans le glossaire.

License
Ce document est sous license Creative Commons

By-NC-SA 2.0 .

Table des mati`

eres
Introduction
Le

cloud  . . . . . . . . . . . . . . . . . . . . . . . . . . .

Interet du

cloud  . . . . . . . . . . . . . . . . . . . . . . .

Le logiciel libre . . . . . . . . . . . . . . . . . . . . . . . . .

Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1 D
efinition des concepts

10

1.1

Cest quoi ? . . . . . . . . . . . . . . . . . . . . . . . .

10

1.2

Usages du

cloud  . . . . . . . . . . . . . . . . . . . .

11

1.3

Les autres . . . . . . . . . . . . . . . . . . . . . . . . .

12

1.4

Caracteristiques . . . . . . . . . . . . . . . . . . . . . .

12

1.5

Mode de fonctionnement typique . . . . . . . . . . . .

13

2 Offres commerciales

16

2.1

Historique . . . . . . . . . . . . . . . . . . . . . . . . .

16

2.2

Offres . . . . . . . . . . . . . . . . . . . . . . . . . . .

17

3 Points n
egatifs du

cloud

20

3.1

Probl`emes ethiques . . . . . . . . . . . . . . . . . . . .

20

3.2

Inconvenients politiques . . . . . . . . . . . . . . . . .

21

3.3

Forfaits actuellement proposes . . . . . . . . . . . . . .

21

3.4

Stress test . . . . . . . . . . . . . . . . . . . . . . . . .

23

4 Solutions libres
4.1

24

Cote client . . . . . . . . . . . . . . . . . . . . . . . . .

24

4.2

Services de base . . . . . . . . . . . . . . . . . . . . . .

24

4.3

Applications . . . . . . . . . . . . . . . . . . . . . . . .

24

4.4

Plateforme . . . . . . . . . . . . . . . . . . . . . . . . .

25

4.5

Infrastructure . . . . . . . . . . . . . . . . . . . . . . .

25

5 Virtualisation

26

5.1

Concept . . . . . . . . . . . . . . . . . . . . . . . . . .

26

5.2

Solutions majeures . . . . . . . . . . . . . . . . . . . .

26

6 Etude
du framework Vertebra

27

6.1

Fonctionnement . . . . . . . . . . . . . . . . . . . . . .

27

6.2

Interface . . . . . . . . . . . . . . . . . . . . . . . . . .

28

6.3

Interets . . . . . . . . . . . . . . . . . . . . . . . . . .

28

7 Mise en place

29

7.1

Pre-requis . . . . . . . . . . . . . . . . . . . . . . . . .

29

7.2

Serveur frontal . . . . . . . . . . . . . . . . . . . . . .

29

7.3

Machines virtuelles . . . . . . . . . . . . . . . . . . . .

30

7.4

Compatible libre ? . . . . . . . . . . . . . . . . . . . . .

31

8 Communication

32

8.1

XMPP . . . . . . . . . . . . . . . . . . . . . . . . . . .

32

8.2

Message passing  . . . . . . . . . . . . . . . . . . . .

35

8.3

Comparaison des deux methodes

. . . . . . . . . . . .

37

8.4

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

41

9 Load Balancing

42

9.1

Gestion dynamique des machines virtuelles . . . . . . .

42

9.2

Load balancing, HAProxy et round-robin . . . . . . . .

44

9.3

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

46

Conclusion

48

Glossaire

52

Table des figures

53

Bibliographie

54

Introduction
Le  cloud computing , ou informatique dans les nuages, est un paradigme assez
recent. La premi`ere enonciation de ce concept date de 1960 (John McCarthy), mais
sa reelle mise en application a pris place au debut des annees 2000 et le web 2.0
(1999 pour Google et Yahoo). Le  cloud  consiste en une communication entre le
serveur frontal et un ensemble de machines virtuelles qui hebergent une ou plusieurs
applications. Ainsi, le visiteur a acc`es a` des applications dont lexecution ne depend
pas du serveur web, et qui ninfluent donc theoriquement pas sur son temps de
reponse.
La contre-partie est que le client na pas directement acc`es a` ses donnees. Il depend
donc totalement du fournisseur et doit lui faire enti`erement confiance pour ce qui
est de leur confidentialite et de leur sauvegarde.
Le probl`eme est donc de savoir :
quels sont les avantages reels du  cloud  du point de vue du fournisseur ;
quelles sont les solutions techniques disponibles et leur methode de tarifications ;
quelles sont les critiques (ethiques et legales) liees au  cloud computing et
comment y remedier.

Le

cloud 

La definition du  cloud computing , ou informatique dans les nuages, de Wikipedia

est la suivante :
Linformatique dans les nuages (en anglais, cloud computing) est un
concept majeur faisant reference `a lutilisation de la memoire et des
capacites de calcul des ordinateurs et des serveurs repartis dans le monde
entier et lies par un reseau, tel Internet.
Le  cloud  (Cf. figure 1) permet donc de fournir un ensemble dapplications sans
utiliser la memoire, la puissance de calcul et la capacite de stockage dun seul serveur. Le visiteur se connecte sur le site du client des services de  cloud , utilise
les applications qui lui sont proposees sans avoir conscience quil acc`ede a` des machines (virtuelles ou non) differentes, et utilisent les applications proposees pour
eventuellement stocker des donnees personnelles sur des serveurs distants. De plus,
le client na pas dacc`es direct a` ses donnees.
Il existe un autre type de  cloud , dit prive, qui est similaire mais limite `a un
reseau prive, il ne sera donc pas traite separement.

Figure 1 Fonctionnement du

Inter
et du

cloud 

cloud 

De la meme facon que la virtualisation(*), un syst`eme de  cloud  permet une

grande evolutivite. On peut facilement et sans danger pour les applications dej`a
disponibles rajouter des machines au cloud pour une plus grande reactivite ou pour
fournir des applications supplementaires. De plus, sil est fait avec des machines
virtuelles (ce qui est toujours le cas), le  cloud  permet une reduction reelle des
co
uts (plusieurs dizaines de milliers dentreprises gerees sur 1 000 serveurs pour
prendre lexemple de Salesforce.com). De plus, les ressources utilisees sont mieux
rentabilisees (plus de 10 ou 20 % des ressources utilisees...).
Dun point de vue de la securite, les donnees etant centralisees, elles sont plus faciles
a` proteger mais le client perd le controle sur elles. De plus, si une application presente
une faille, seul le syst`eme qui laccueille pourra etre mis en danger. Ainsi, toutes les
autres applications ainsi que la machine frontale sont protegees.
Les donnees et les applications etant hebergees et souvent sauvegardees sur des
machines distantes, on peut y acceder de mani`ere permanente et de nimporte quel
endroit et etre assure de leur perennite.

Enfin, le  cloud  peut reposer enti`erement sur des technologies libres comme par
exemple :
Xen ou KVM pour les machines virtuelles ;
Syst`eme GNU/Linux pour les OS (Debian) ;
Serveur web libre (Apache) ;
Serveur dapplications libre (framework dependant du langage utilise) ;
Base de donnees MySQL ;
Firefox comme explorateur.

Le logiciel libre
Le but de ce document etant detudier la possibilite et linteret du  cloud computing  dans une societe developpant du logiciel libre, il faut dabord definir cette
notion.
Le mouvement du logiciel libre a debutte au debut des annees 80 a` linitiative de
Richard Stallman qui lance la Free Software Foundation. Selon Stallman, un logiciel
est dit libre sil permet les quatres libertes fondamentales :
0. La liberte dexecution quelquen soit le but.
1. La liberte detudier le fonctionnement du programme et de le modifier pour
quil se conforme a` ses besoins.
2. La liberte de redistribuer le programme dans un but dentraide.
3. La liberte dameliorer ou simplement de modifier le programme et de pouvoir redistribuer les versions modifiees au profit de la communaute.
Un logiciel offrant ces quatre libertes est dit libre, sinon, il est dit privateur. Selon la
license proposee par le projet GNU (le syst`eme dexploitation lance par Stallman et
qui utilise actuellement le noyau Linux), un logiciel sous license libre doit le rester,
cest `a dire que les versions modifiees et redistribuees doivent garder une license libre
(ce nest pas le cas de la license BSD).
Le terme de  Free  est ambigu car il signifie `a la fois  libre  et  gratuit .
Sa reelle signification est  libre , ce qui veut dire que lon peut faire commerce du
logiciel (vendre les binaires compiles dun programme par exemple), de meme que
fournir un service payant base sur lutilisation de logiciel libre.
Parmis les noms les plus connus du monde du libre, on peut citer le syst`eme GNU/Linux (et ses distributions reputees telles que Debian, Ubuntu ou Red Hat), lexplorateur Firefox (produit et developpe par la societe Mozilla et qui rattrape petit `a
petit Internet Explorer, son concurrent privateur developpe par Microsoft), le lecteur
multimedia VLC, ou le serveur web Apache (largement majoritaire sur le marche de
lhebergement).

Les interets de lutilisation de logiciels libres sont nombreux. Pour un particulier, ils fournissent lassurance, meme sil ne peut pas lui-meme le verifier, que les
developpeur ne cherchent pas a` introduire des fonctions malveillantes dans leur code.
Ils permettent aussi une evolution constante, que ce soit au niveau des performances,
de lergonomie ou de la securite, grace a` une communaute tr`es active. Pour des professionnels, un logiciel libre est une assurance de perennite car il ne depend pas
ou peu de letat financier dune societe. De plus, malgre la croyance populaire, un
logiciel libre ne presente pas plus de probl`emes de securite quun logiciel privateur.
En effet, la posibilite, y compris pour la societe qui utilise ce type de logiciel, de
pouvoir etudier le code source permet une meilleure reactivite face `a deventuelles
failles, de meme que la possibilite de le modifier et donc de corriger ces failles.
En ce qui concerne le  cloud , la majorite (voir la totalite) des solutions sont
privatrices ou Open Source au mieux (le client ne dispose que de la liberte 0). Il est
donc interessant detudier si une proposition enti`erement libre est envisageable.

Objectifs
Plusieurs objectifs ont motive la creation de ce document :
Donner une explication claire du concept de  cloud computing , de son
utilite et de ses inconvenients ;
fournir les donnees concernant les offres commerciales qui existent actuellement ;
definir les technologies et les logiciels a` utiliser pour une offre de  cloud ,
faire des comparatifs pour regler certaines concurences entre eux ;
Expliquer la mise en place de ce service avec les outils choisis.

1
1.1

D
efinition des concepts
Cest quoi ?

Le  cloud computing  est (si on cherche a` depasser leffet  buzz word ) un

paradigme de programmation qui permet de concevoir les ressources (comprendre
machines virtuelles, le  cloud ) comme des services accessibles par internet. Le
 cloud  permet de g
erer la relation entre les programmes sur lordinateur et sur le
web. Lutilisateur na pas conscience du  cloud  en utilisant ce type de services,
de meme quil na aucun controle dessus. On trouve generalement un ou plusieurs
des concepts suivants dans un  cloud  :
Infrastructure as a service (IaaS), une plateforme de virtualisation ;
Platform as a service (PaaS), pour faciliter le deploiement dapplications ;
Software as a service (SaaS), permettant lacc`es a` des applications sur le
web.
On peut en fait diviser le  cloud computing  en deux categories bien distinctes
(meme si un fournisseur peut proposer les deux) :
Stockage
Les donnees du client sont sauvegardees sur plusieurs serveurs, par exemple
Amazon Simple Storage Service (ou Amazon S3), souvent accompagne de
copies de sauvegardes (voir la section inconvenients politiques). Ce type de
 cloud  permet, si lon a stock
e des applications sur le serveur dy acceder
et de les executer, et ressemble alors `a un syst`eme de fichier partage (de type
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 proprietaire du logiciel nest pas forcement le proprietaire du
materiel. On peut distinguer alors deux philosophies. Amazon vend du temps
sur une machine virtuelle, avec ses offres 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`eques, ce qui rend la maintenance plus aisee (elle
ne depend plus des besoins du client), mais beaucoup moins flexible pour le
client.

10

Le

cloud  depend des composants suivants (Cf. la section solutions libres) :

Client
Logiciel permettant a` un internaute de se connecter au  cloud . Generalement,
un explorateur internet suffit, mais dautres moyens peuvent etre utilises
suivant les services proposes par lhebergeur ou par lacheteur du service de
 cloud .
Service
Protocoles proposes par lhebergeur ou par le client (paiement, mapping,
chat, mail, ...)
Application
Les applications sont soit proposees de base par lhebergeur, soit developpees
par le client. Chacune delles dispose dune ou plusieurs machines virtuelles.
Plate-forme
Syst`eme dhebergement des applications.
Stockage
Moyen de stockage mis a` disposition du client. La plupart des hebergeurs
proposent une base de donnees SQL sur laquelle le client na pas dacc`es
direct, ce qui peut etre change (avec un gain considerable de liberte). Il est
aussi envisageable de lui fournir un syst`eme de stockage classique (syst`eme
de fichier accessible en FTP par exemple).
Infrastructure
Il sagit du serveur frontal.

1.2

Usages du

cloud

Les usages dun  cloud  dependent du point de vue adopte. Un  cloud  se

destine dune part au client, une entreprise ou autre (gouvernement, association,
...), qui administre un syst`eme de  cloud , et dautre part aux employes ou aux
clients de cette entreprise, qui sont les utilisateurs de ce syst`eme.
Pour lentreprise, le  cloud  va permettre de fournir un ensemble dapplications
a` ses employes, et cel`a o`
u quils se trouvent. On pourra trouver, par exemple, une
messagerie, un agenda, un syst`eme de messagerie instantanee, voire un syst`eme de
vote, de partage de documents, ... (applications proposees par defaut ou developpees
par le client du service). Cest donc une extension de son service informatique. Il
peut aussi etre utilise comme moyen de vendre un logiciel developpe en faisant payer
lacc`es au  cloud . Enfin, il peut servir de moyen de sauvegarde de ses donnees.
Pour lutilisateur, le  cloud  est un moyen dacceder aux services fournis par cette
entreprise. Que ce soit un service gratuit (dans le cas dun employe) ou payant (dans
le cas dun client utilisant un acc`es achete), il peut avoir acc`es `a ces services quel
11

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

1.3

Les autres

Le  cloud computing  peut facilement etre confondu avec dautres paradigmes.

Sil ne faut pas les confondre, il faut aussi avoir conscience que ces concepts sont
parfois lies. Voici les principaux exemples de ces autres paradigmes et leur relation
avec le  cloud .
Le grid computing
Dans un syst`eme de grid, un  super-ordinateur controle un ensemble de
syst`emes et leur repartit des calculs `a effectuer dans un but unique (calcul
scientifique, analyse sismique, ...). Dans la plupart des  cloud , on trouve
toujours un syst`eme de grid mais dans lequel lapplication nest pas unique
et o`
u le  super-ordinateur  a pour but de pointer vers le syst`eme correspondant `a la demande et non de repartir le calcul.
Lutility computing
Lutility computing est simplement en une delocalisation dun syst`eme de
calcul ou de stockage. Il est evidemment utilise dans un  cloud  mais nimplique pas forcement un reseau de calcul ou de stockage comme le  cloud .
Lautonomic computing
Paradigme dans lequel un syst`eme informatique est capable de sauto-administer
en sadaptant `a des changements imprevisibles. Il peut etre compose de
syst`emes dauto-configuration, dauto-reparation (detection et correction derreurs), dauto-optimisation (controle et repartition des ressources) et dautoprotection (detection et protection contre des attaques). Lautonomic computing na `a priori rien `a voir avec le  cloud computing  mais un  cloud  comprend generalement des element autonomes (auto-optimisation par exemple).

1.4

Caract
eristiques

Le but dun  cloud  est de creer un syst`eme totalement decentralise (par exemple
BitTorrent ou Skype), meme si la plupart se basent encore sur des  grids  ou des
 utilities  et sont donc encore centralis
es.
Les offres commerciales permettent de faire payer au client en fonction des ressources
utilisees (forfait bases sur lelectricite ou sur le  materiel  utilise)
12

Comme le client na pas de controle direct sur le materiel, il peut rapidement y avoir
une sur-utilisation des ressources disponibles, meme si une bonne bande passante
permet theoriquement le meme temps de reponse quun syst`eme centralise clasique.
La plupart des architectures utilisees pour le  cloud computing  sont des datacenters et des serveurs avec plusieurs niveau de virtualisation.

1.5

Mode de fonctionnement typique

De mani`ere general, un  cloud  presente les elements suivants, certains etant

optionnels mais ameliorent sa qualite (reactivite), Cf. figure 2 :
Proxy HTTP
Point dentree des demandes, g`ere le SSL(*).
Cache HTTP
Permet de repondre plus rapidement `a une requete en placant une partie du
contenu dans un cache.
Serveur frontal
G`ere les requetes en lancant des machines virtuelles adequates ou en communiquant avec des machines virtuelles adequates dej`a lancees.
Machines virtuelles
Ensemble de serveurs (serveurs Ruby avec framework (*) web par exemple)
accueillant chacune une application. Elles doivent pouvoir etre lancees rapidement et independemment pour repondre le mieux possibles aux demandes
des visiteurs.
Base de donnees SQL ou syst`eme de stockage
Base de donnees pour chaque application, avec duplication et telechargement
pour le client (la base de donnee peut etre externe au  cloud ), syst`eme
de stockage presentant les memes avantages.
Cache memoire
Cache memoire pour les applications web permettant un acc`es rapide (par
exemple `a des fragments de pages).

Chaque machine virtuelle (Debian, Cf. figure 3) accueille un environnement specifique

au langage utilise par le client. Une application utilise une ou plusieurs machine virtuelle suivant sa complexite. Le syst`eme de fichier peut etre en lecture seule (les
donnees etant stockees ailleurs, il suffit de pouvoir executer lapplication presente
sur la machine virtuelle).
Lenvironnement doit accueillir un serveur dapplications lui aussi specifique au langage utilise qui accueillera le serveur web.
13

Figure 2 Fonctionnement detaille

14

Figure 3 VM

Enfin, le serveur accueille lapplication du client. Dans un souci de genericite, on peut

concevoir que lensemble des applications soient stockes sur un serveur de stockage et
que la machine virtuelle y acc`ede au moment de lexecution (par AFS par exemple).
Ainsi, on peut creer des images de machines virtuelles typiques, valables pour un
grand nombre dapplications, et plus leg`eres dun point de vue taille.

15

2
2.1

Offres commerciales
Historique

La premi`ere enonciation de lidee de

John McCarthy.

cloud  (sans le nom), date de 1960, et de

Computation may someday be organized as a public utility.

(Les ressources informatiques deviendront un jour dutilite publique)
John McCarthy
Le mot  cloud  est apparu au debut des annees 90 pour designer des reseaux
disposant dun mode de transfert asynchrone, et lexpression  cloud computing  il
y a une dizaine dannees et a pris de plus en plus dimportance.
Salesforce.com fut le premier hebergeur de  cloud  en 1999, suivi en 2002 par
Amazon qui proposa un ensemble dhebergement dapplication, de stockage et doffre
demploi (Le Mechanical Turk).
Amazon developpa ses services en 2005 (Amazon Web Services) et en 2006 (Elastic
Compute Cloud ou EC2).
Ce dernier fut le premier service de  cloud  reellement accessible (selon Jeremy
Allaire, PDG de Brightcove, autre fournisseur de SaaS).
En 2007, Google, IBM et des universites lanc`erent un projet de recherche sur le
 cloud  qui permit de lui faire gagner en popularit
e et en consistance.
Cest en 2009 que la reelle explosion du  cloud  survint avec larrivee sur le marche
de societes comme Google (Google App Engine), Microsoft (Microsoft Azure), IBM
(IBM Smart Business Service), Sun (Sun Cloud) et Canonical Ltd (Ubuntu Enterprise Cloud).

16

2.2

Offres

Voici les prix de quelques fournisseurs de services de  cloud computing  (valables

a` la date du 7 decembre 2009) :
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, possibilite de developper en Java et Python ;
0,10 $ par heure dutilisation de CPU, 0,15 $ par Go.
Microsoft Azure
Stockage ;
Applications fournies, possibilite de developper en .NET ;
Voir la section sur les forfaits.
3Tera
Stockage ;
Possibilite de developper des applications (tous langages confondus) ;
2 500 $ par mois pour 8 CPUs, 16 Go de RAM, 6 To de stockage.
Appistry
Stockage ;
Application de base, possibilite de developper en .NET, Java et C++ ;
Syst`eme de  cloud  interne.
Cassatt
Repartition dynamique des ressources de calcul ;
Solution de syst`eme de  cloud  interne.
Joyent
Stockage ;
Possibilite de developper en Rails et PHP ;
De 125 `a 250 $ par mois pour 1 Go.
Legal Cloud
Deploiement de services et de stockage rapide ;
Destine aux entreprises davocats.
Skytap
Possibilite de developper en Java ;
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 ;
Possibilite de developper (tous langages confondus) ;
De 0.04 par heure a` 29 par mois ;
comparatif.
Flexiscale
Stockage ;
Possibilite de developper (tous langages confondus) ;
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
Possibilite de developper en Java
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 ;
Possibilite de developper en Rails et PHP ;
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
Possibilite de developper en Ruby
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 n
egatifs du

cloud 

Probl`
emes
ethiques

La principale critique du  cloud computing  est que le client ne poss`ede pas physiquement le stockage de ses donnees et laisse donc le controle total au fournisseur.
Le London Times a par exemple compare cette technique aux syst`emes centralises des annees 50-60 (connexion depuis un  dumb-terminal  a` un  superordinateur ). En effet, le client ne peut pas installer de nouveaux logiciels et a
besoin de lautorisation du fournisseur pour la plupart des taches dadministration.
De plus, en cas de probl`emes techniques de la part du fournisseur, le client na plus
aucun moyen dacceder a` ses donnees.
Sur le meme ton, Richard Stallman condamne cette technologie par laquelle lutilisateur confie aveuglement ses donnees privees `a un fournisseur qui peut alors le
pieger en le forcant `a utiliser des logiciels privateurs et en augmentant ses forfaits.
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 liberte)
Richard M. Stallman
En effet, il est impossible, pour les utilisateurs et dans la plupart des cas pour le
client lui-meme, de pouvoir verifier lattitude reelle des machines virtuelles qui accueillent les applications car ils ny ont pas acc`es. Le probl`eme des logiciels privateurs
quenonce Stallman est que lutilisateur, par lusage de ces logiciels, doit avoir une
confiance aveugle envers le developpeur. Dans le cas du  cloud computing , il doit
accorder la meme confiance non seulement au developpeur mais aussi `a lhebergeur,
ce qui rend le  cloud  encore plus dangeureux que le logiciel proprietaire.

20

3.2

Inconv
enients politiques

Le  cloud computing  apporte de nombreux debats politiques qui forcent les

hebergeurs `a sadapter constemment a` de nouvelles reglementations, devant la plupart du temps limiter lacc`es a` certaines zones (Amazon EC2 Availability Zone).

Aux Etats-Unis,
les syst`emes de  cloud  se confrontent par exemple au Patriot Act,
qui interdit aux societe les proposant de stocker certaines donnees sur des serveurs
hors du territoire americain, de meme quil leur faut bloquer par defaut certaines
requetes (par exemple en ce concerne le syst`eme bancaire ou celui de sante).
On peut supposer que des societes comme Google ou Microsoft arriveront facilement
a` saccomoder de ces legislations, mais la plupart des hebergeurs se retrouvent dans
des positions difficiles (comme par exemple lorganisation bancaire internationnale
SWIFT, qui veut mettre en place un datacenter en Suisse mais ne peut y faire traiter
que les donnees bancaires europeenne).
De plus, des reglementations comme le Stored Communications Act (encore aux

Etats
Unis), permettent aux gouvernements davoir un acc`es direct aux messages de
leur concitoyens et sont donc rebutes par des hebergements dans dautres pays.

3.3

Forfaits actuellement propos

es

Comme vu plus haut, les facturations des service de  cloud  sont aleatoires et assez
floues. En effet, et cela concerne surtout les societe proposant du  cloud  Open
Source, le nombre de clients et dutilisateurs est difficile (voire impossible) `a obtenir,
les tarifs sont fixes sur des bases peu fiables et ne permettent pas pour un client
devaluer clairement le prix reel quil aura `a payer.
Le probl`eme est que deux types de facturations sont disponibles, la facturation par
nombre dutilisateurs et la facturation par ressources utlisees.

21

 Facturation par ressources utilisees

La plupart des hebergeurs proposent des facturations basees sur les ressources utilisees. Le client va donc payer par nombre dheures utilisees sur
une machine virtuelle, o`
u, parfois, chaque heure commencee est facturee.
De plus, la plupart demande un paiement supplementaire en fonction du
nombre de telechargement (au Go, avec le meme genre de pi`ege pour les Go
commences que pour les heures).
Dans le cas extreme, Microsoft Azure, on trouve meme les prix suivants
(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 donnees SQL (99,99 $ pour la version Business) ;
0,10 dollar par connexion a` la base de donnees ;
0,15 dollar par Go de transfert avec la base de donnee ;
0,15 dollar par 100 000 operations de message (DBus et jetons dacc`es
inclus).
Facturation par utilisateur
Une partie des fournisseurs de  cloud  fournit une facturation par nombre
dutilisateurs. Linconvenient de cette methode (pourtant transparente) est
quelle ne prend pas en compte les ressources utilisees. En effet, un client
mettant en place plusieurs dizaines, voir plusieurs centaines dapplications,
payera le meme prix au mois quun client ne disposant que des services de
bases et ne demandant quasiment pas de ressources (sil a le meme nombre
dutilisateurs). Pour lhebergeur, cette solution nest pas viable car un client
peut facilement le faire devenir deficitaire si son nombre dapplications devient trop important.
Ainsi, les modes de paiements actuellement mis en place ne sont clairement pas
satisfaisants.
Prenons lexemple dune societe ayant besoin dun syst`eme de  cloud  pour envoyer 100 Go de donnees en 10 000 heures, elle devra payer 3 410 $ en utilisant le
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 donnees ont ete transferees en une seule fois (0,12 x
10 000 + 0,15 x 100 + 0,10 x 1 + 0,15 x 100 + 9,99 + 0,10 x 1).
Enfin, chez Google, il sera de 1 015 $ (0,15 x 100 + 0,10 x 10 000).
22

Les tarifs qui prec`edent sont des evaluations rapides de ce que devra payer la societe,
mais ils ne prennent pas en comptes de nombreux param`etres difficiles a` evaluer
(nombre de connections total pour envoyer les donnees, nombre dappel `a la base de
donnees, utilisation des CPUs, etc).
On peut cependant voir la complexite pour une entreprise devaluer ses factures sur
un moyen ou long terme ainsi que de definir lhebergeur qui lui sera le plus rentable
en fonction de ses besoins.

3.4

Stress test

Une recente etude a` montre que les plus grands syst`emes de  cloud  (ceux dAmazon, de Microsoft et de Google) presentent des variations du temps de reponse dun
facteur 20, suivant lheure dacc`es. Cette meme etude met en evidence de graves
probl`emes lies a` ces variations. Par exemple, le syst`eme de Google ne permet pas
doperations depassant 30 secondes. De plus, les syst`emes de monitoring(*) ne permettent pas detudier precisemment les origines de ces ralentissements.
Ainsi, la promesse des hebergeurs de fournir un acc`es au moins aussi rapide a` un
 cloud  qu`
a un syst`eme autre peut rapidement se reveler fausse en cas de grande
utilisation.
En effet, le stress test a revele des taux derreurs montant jusqu`a 12%, comme on
peut le voir sur leurs resultats :
http ://backoffice.ajb.com.au//images/news/amazonunswerrors.gif.
http ://backoffice.ajb.com.au//images/news/googleunswerrors.gif.

23

Solutions libres

La plupart des hebergeurs proposent des solutions basees sur des logiciels Open
Source. Cependant, il est regrettable de constater un manque evident de transparence au niveau des forfaits proposes. Dans loptique de fournir un service base sur
des logiciels libres, il faut maintenant sinteresser aux differents outils disponibles
pour chacun des composants du  cloud . Evidemment, lensemble du code produit
doit etre publie sous license libre (GPL v.3, License BSD), et ne sappuyer que sur
des protocoles et des biblioth`eques libres.

4.1

C
ot
e client

On ne peut evidemment pas forcer un client `a utiliser un logiciel libre pour acceder
au service fourni, mais des solutions libres peuvent lui etre proposees. Pour pouvoir
acceder aux applications hebergees, il suffit dun explorateur internet (Firefox, Konqueror, Epiphany, ...). Pour ce qui est de la mise en place de ses applications, un
simple envoi des sources ou des binaires peut seffectuer par FTP et une interface de
test et de mise en production peut etre envisageable (ecriture ou envoi des sources,
compilation, test sur une adresse privee).

4.2

Services de base

Un ensemble de services de base est souvent fourni avec lhebergement dun  cloud .
Parmis les plus courants, on trouve une messagerie (par exemple basee sur Postfix,
Procmail, Fetchmail, SpamBayes, Courier-imap, Mutt et SquirrelMail), un syst`eme
didentite (OpenID), de paiement (Paypal, mais non-libre...), une messagerie instantannee (XMPP) et de recherche.

4.3

Applications

Lutilisateur peut acceder aux services du  cloud  par des applications autres que
lexplorateur. De meme que pour lexplorateur, des solutions libres peuvent lui etre
proposees. Pour les applications de bases, on peut citer :
Messagerie : Thunderbird, Kmail, ...
Identite : OpenID Enabled
Chat : Pidgin, Gajim, Kopete, ...
Le reste depend des applications proposees par le client (client FTP pour du transfert, lecteur audio/video, ...).
24

4.4

Plateforme

La plateforme (chaque nud de la  grid ) est compose dun syst`eme virtuel (Debian), avec des serveurs dependant des langages utilises (OpenJDK pour du code
Java, Django pour du Python, Mongrel ou Thin pour du Ruby). Elle peut etre accompagnee de biblioth`eques necessaires au fonctionnement de lapplication hebergee.

4.5

Infrastructure

Linfrastructure est le serveur frontal, et donc peut accueillir un syst`eme GNU/Linux

adapte comme Debian. Sil heberge aussi des nuds de la  grid , il utilise Xen
comme syst`eme de virtualisation. Il dispose evidemment dun serveur web Apache.

25

Virtualisation

Le  cloud computing  dependant fortement de la virtualisation, un bref rappel du

concept ainsi que des solutions majeures disponible simpose. Pour une description
plus precise, regardez Livre blanc : Virtualisation.

5.1

Concept

La virtualisation permet demuler a` partir dun syst`eme reel sur une machine physique un ou plusieurs autres syst`emes. On peut ainsi disposer de plusieurs syst`emes
apparemment separes, disposant chacun de leurs services. Plusieurs utilisations sont
possibles (posseder plusieurs versions dun meme logiciel, eliminer les conflits entre
logiciels, pouvoir jouer `a des jeux Windows sous GNU/Linux, ...), mais le principal interet est de ne pas avoir, pour un hebergeur, a` maintenir plusieurs serveurs
sous-exploites mais de rassembler plusieurs services sur une meme machine physique.

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 integre au noyau Linux et base sur QEMU.
Son avantage majeur par rapport `a Xen est que le syst`eme utilise comme
hyperviseur est en fait un syst`eme GNU/Linux, et donc lequipe developpant
KVM na pas a` se soucier de cette partie. Il est facile dutilisation, stable,
et de plus en plus utilise (soutenu par Red-Hat), y compris pour ce qui est
de lhebergement (Lost Oasis en France, Blue Room Hosting en Angleterre,

OpenHosting aux Etats-Unis,

...).
Xen
Xen est moins facile dacc`es mais plus puissant. Cest un syst`eme de virtualisation avec hyperviseur, ce qui veut dire que lensemble des ressources
materielles sont partagees entre les machines virtuelles (et non monopolisees par le syst`eme principal). Le fait de devoir reimplementer un syst`eme
pour lhyperviseur permet de ne disposer que des fonctionnalites propres
a` la virtualisation, et donc de fournir un syst`eme de virtualisation plus
efficace. Cest un excellent choix pour la virtualisation dans le cadre de
lhebergement.
26

Etude
du framework Vertebra

Vertebra est un framework permettant de superviser lensemble des processus et des

serveurs qui constituent un  cloud . Il est publie sous license libre LGPL et permet
dassurer securite, portabilite et tolerance aux pannes.
Securite
Possibilite de gerer facilement des permissions par client ou par utilisateur,
possibilite de creer des liens entre plusieurs  clouds  utilisant Vertbra.
Portabilite

Ecrit
pour pouvoir fonctionner sur sa propre architecture comme sur des
syst`emes dej`a existant (Amazon EC2 ou le VCloud de VMware).
Tolerance aux pannes
Larret non-prevu dun ou plusieurs des composants principaux ne fait pas
sarreter lensemble du syst`eme, ils sont relances et les autres composants
en dependant attendent simplement leur disponibilite.

6.1

Fonctionnement

Un syst`eme de  cloud  base sur Vertebra peut contenir les composants suivants,
en sachant que seuls les trois premiers sont indispensables.
Server XMPP
Pour la communication entre les differents serveurs.
Agent Herault
Assure la securite et le syst`eme dannonces.
Agent utilisateur
Vide par defaut, accueille les applications du client.
Agent entrepot
Permet de stocker les informations sur lensemble des utilisateurs (noms,
profils, mots de passe, ...).
Agent cavalcade
Controle lautomatisation des processus.
Agent sawmill
Permet un syst`eme de login distribue.

27

6.2

Interface

Afin de pouvoir administer son  cloud , Vertebra est accompagne dun shell propre
permettant une administration rapide et eventuellement automatisable. De plus,
grace a` cet outil, le client peut facilement developper ou faire developper une application graphique (utilisant le shell) pour administrer ses services en faisant des
appels aux fonctions de ce shell. Il est meme enviseageable pour un hebergeur de
fournir une interface web au client donnant acc`es a` lensemble des fonctionnalitees
proposees.
Enfin, on peut facilement et de mani`ere invisible, donner lacc`es `a une personne `a une
application du  cloud , que ce soit une application classique ou eventuellement lapplication dadministration, ce qui permet `a un client de regrouper plusieurs syst`emes
de ces syst`emes heberges sur differents comptes.

6.3

Int
er
ets

Vertebra est sous license LGPL et est donc un candidat parmi les logiciels exploitables dans le but de fournir un service de  cloud  base sur des logiciels libres. Il
fournit de base un serveur XMPP sur lequel le service voulu pourrait facilement se
deployer, et une grande partie de son code est en Erlang, langage prevu pour tout
ce qui est communication reseau et avec lequel on desire travailler.
Il sav`ere donc que Vertebra est un framework quil faut utiliser, ou au moins sinspirer de ses fonctionnalitees, pour le service de  cloud  envisage.
Il permet, grace entre autre `a son mode dadministration, de fournir au client un service a` la fois complet et permettant un respect de ses libertes ainsi que la possibilite
de reunir son  cloud  avec celui dun autre hebergeur.

28

7
7.1

Mise en place
Pr
e-requis

Etant
donne quun syst`eme de stockage en  cloud  ne presente pas de difficulte
technique particuli`ere (syst`eme de fichiers partages avec eventuellement une base de
donnees permettant un acc`es plus rapide), nous allons nous concentrer sur la gestion
dun service de  cloud  avec developpement dapplications.
On veut aussi nutiliser que des logiciels libres et que le code developpe soit sous
license libre. On cherchera aussi a` fournir au client la possibilite de developper ses
applications dans le langage de son choix.
Pour la gestion des serveurs dapplications, ils seront enregistres dans une base
de donnees SQL, avec deux identifiants, un concernant lapplication hebergee (pas
dunicite) et un identifiant unique (incrementation automatique) pour faciliter la
communication. Tout ce qui concerne la communication entre le serveur frontal et
les machines virtuelles sera traite dans le chapitre suivant.

7.2

Serveur frontal

On utilise pour le serveur frontal une Debian avec un serveur web Apache et une
base de donnees SQL (linstallation du syst`eme et la mise en place dApache et
de MySQL ne seront pas detaillees ici). Le but est de fournir un syt`eme qui, lors
dune demande specifique au  cloud  (lien vers une application, affichage dune
application sur une partie de la page), lance le serveur hebergeant lapplication sil
est eteint ou surcharge, ou communique avec lui sinon.
Dans ce but, il faut ecrire une fonction de lancement qui prend en argument un
identifiant de lapplication (nom ou id) et qui effectue les actions suivantes :
Verifier les droits de lutilisateur effectuant la demande ;
Verifier si une machine virtuelle correspondant a` cette application `a dej`a ete
lancee (requete `a la base de donnees) ;
Si aucune nest presente, en lancer une et linscrire dans la base de donnees ;
Si une ou plusieurs machines sont dej`a lancees, verifier leur capacite daccueil
par le syst`eme de communication (decrit plus loin) :
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
donnees et commencer la communication.

29

Note : La principale difference entre le  cloud computing  et le reste des solutions techniques dej`a existantes consiste en son syst`eme de communication entre les
machines ou entre les processus, lui permettant de fournir un reseau de machines dynamique (en fonction du nombre dutilisateurs ou de la quantite de donnees stockees
ou utilisees). Un chapitre est donc dedie aux solutions possibles pour gerer ces communications.
Une fois la connexion etablie, le serveur frontal peut envoyer les requetes de lutilisateur a` la machine virtuelle et soit recevoir les informations demandees (par XMPP)
et les afficher, soit afficher 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`eme `a un utilitaire en ligne de commande
de type SVN ou Git, ou un syst`eme interactif accessible par un explorateur (avec
un syst`eme denvoi des sources ou des binaires), de lancement sur un serveur prive
de tests, puis de mise en production. Il faut aussi integrer un moyen pour le client
de donner des droits sur ses applications pour pouvoir limiter lacc`es de certaines
applications aux seules personnes concernees.

7.3

Machines virtuelles

Les machines virtuelles accueillant les applications du client sont hebergees sur un
ensemble de serveurs permettant la virtualisation. On utilise Xen comme syst`eme
de virtualisation (encore une fois, se referer au Livre blanc sur la virtualisation).
Xen est base sur des fichiers de configurations propres a` chaque machine virtuelle.
Le fichier est sous la forme suivant :
name = nom du syst`
eme
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 = r
eseau (adresse MAC, IP, bridge)
disk = disques a
` utiliser (chemin, droits, etc...)
root = partition a
` utiliser pour /

30

Chaque machine virtuelle accueille un ensemble de logiciels lies au(x) langage(s) dans
le(s)quel(s) est ecrite lapplication. Voici les solutions libres pour quelques langages :
Ruby on Rails
machine virtuelle executant le code : YARV, sous license libre Ruby ;
serveur dapplications : Thin, base sur Mongrel, sous license libre Ruby.
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 ;
interpreteur erlang.
Python
framework django.

7.4

Compatible libre ?

Pour resoudre les probl`emes ethiques lies au  cloud computing , de nombreux

choix peu ou pas proposes par les autres hebergeurs sont a` mettre en uvre.
Pour ce qui est de la visibilite du syst`eme, il faut fournir au client et aux utilisateurs
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 devoilees, il faut mettre en place un syst`eme de
monitoring permettant de publier en temps reel les serveurs etant en fonctionnement
et les applications lancees dessus.
Du cote du client, il faut lui donner un acc`es direct a` lensemble de ses donnees et
lui assurer une transparence totale sur le syst`eme de sauvegardes (avec acc`es sur les
machines les hebergeant).
Dun point de vue des forfaits, il faut eviter les forfaits pi`eges proposes par la majorite
des hebergeurs. Sur ce point, il existe peu de solutions satisfaisantes et il faudrait
envisager un nouveau type de forfait qui serait a` la fois clair et avantageux pour
le client, mais sans presenter de risques pour lhebergeur. On peut envisager, dans
ce but, un forfait base uniquement sur le nombre dapplications et dutilisateurs,
permettant ainsi un prix assez stable dans le temps (ne depend pas du nombre de
donnees transitees, du nombre de connexions, ...) et refletant bien lutilisation du
 cloud  (son utilisation d
ependant principalement du nombre dutilisateurs, et le
materiel requis du nombre dapplications proposees).

31

Communication

Le but de ce chapitre est detudier le moyen le plus avantageux pour effectuer la

communication entre le serveur et les machines virtuelles accueillant les applications.
Plusieurs moyens peuvent etre mis en oeuvre :
Utilisation du protocole XMPP avec un  bot  par machine ;
Utilisation du syst`eme de  message passing  du Erlang ;
Utilisation du protocole TCP avec un syst`eme client/serveur ecrit en Erlang.
Le protocole XMPP est un standard ouvert qui presente plusieurs avantages (serveur inclus dans le framework Vertebra, syst`eme Publish/Subscribe, existence dune
biblioth`eque efficace en Erlang). De plus, les communications sont effectuees par
echange de documents XML, ce qui permet par exemple un passage dobjet(*) efficace ainsi quun bon syst`eme de passage de directives.
Le  message passing  de Erlang est aussi avantageux car il est extremement
simple `a mettre en place (quelques lignes de code pour le squelette du server, une
ligne pour un envoi de message). De plus, il presente des performances excellentes
(comparaison Erlang/Java). Enfin, son utilisation peut servir a` passer des objets de
facon assez intuitive.
Enfin, le protocole TCP ne presente aucun avantage particulier, mais servira doutil
de comparaison  classique  pour evaluer les deux precedents.

8.1

XMPP

Presentation
XMPP (Extensible Messaging and Presence Protocol) est un protocole dechange
de documents XML. Dans le but de ne pas dependre dun fournisseur, un serveur
XMPP peut etre mis en place a` linterieur dune societe ou chez un particulier. Il
existe des moyens puissants de securiser ce protocole (ce qui est important, que ce
soit pour une communication humain/humain ou serveur/serveur), tels que SASL(*)
et TLS(*).

32

Une utilisation autre que celle de la messagerie instantanee consiste a` transformer

XMPP en moyen dobserver et dadministrer un serveur a` distance. En effet, en
envoyant un message formate de facon predefinie par le possesseur du serveur, il est
facile de lui passer des commandes. Voici un exemple fictif et excessivement simple
pour provoquer larret dun serveur :
<?xml version="1.0" encoding=UTF-8?>
<halt>
<delay>
15min
</delay>
</halt>
Ici, si le serveur a` ete correctement configure, il peut comprendre quil doit sarreter

dans 15 minutes. Evidemment,

cet exemple ne presente aucune securite. Si une
personne quelconque envoie ce message, le serveur seteindra. On peut alors limiter
lexecution de telles commandes `a certaines adresses du reseau ou a` certaines identite
(gerees par XMPP), la securite sera alors assuree par lidentification du  bot (*)
ou de ladministrateur aupr`es du serveur ejabberd.
De plus, le XML est un moyen pratique de communiquer un objet dun ordinateur a`
un autre, de sauvegarde dobjets, ou meme de modification dobjets sans passer par le
langage utilise, ce qui le rend tr`es interessant dans un syst`eme de  cloud , surtout
si on rajoute le fait que les messages peuvent etre envoyes par HTTP, facilitant
encore plus la communication dans le cadre dun serveur web dapplications.
Enfin, XMPP permet un syst`eme de Publish/Suscribe, cest-`a-dire un moyen de publier des messages dans un syst`eme de classes sans savoir qui (comprendre : quelle
autre machine) est interesse par la reception de ce message. On peut donc diffuser
un message a` un ensemble de serveurs, sans se preocupper de la reception. Ainsi,
ce syst`eme permet de diffuser a` la fois des informations de maintenance ou de surveillance et des messages contenant des ordres ou du transfert dobjet entre serveurs
(un serveur vers lensemble des serveurs  interesses ).

Utilisation
Un serveur Jabber doit etre utilise pour permettre une communication basee sur
le protocole XMPP. Il serait envisageable dutiliser un des nombreux fournisseurs
(gratuits) de comptes jabber. Cependant, afin dassurer une plus grande securite et
surtout une plus grande reactivite, il est preferable dinstaller son propre serveur
Jabber.
Comme le but est dimplementer une partie du code en Erlang, le choix le plus
judicieux est dutiliser ejabberd, un serveur Jabber libre, ecrit exclusivement en
Erlang.
33

Les points importants du fichier de configuration (/etc/ejabberd/ejabberd.cfg) sont :

{hosts, ["your.host.name"]}. : definit le nom du serveur auquel lon
pourra se connecter.
{acl, admin, {user, "user name", "localhost"}}. : definit ladministrateur du serveur.
{s2s use starttls, true}. : force la connexion securisee.
{s2s certfile, "/path/to/the/certificat.pem"}. : chemin du certificat `a utiliser.
Une fois le serveur ejabberd installe et lance, on peut utiliser la commande  ejabberdctl  pour ladministrer (ajout dutilisateur, sauvegarde des utilisateurs, ...),
et utiliser iptables pour limiter lacc`es au serveur uniquement aux syst`emes faisant
partis du  cloud  pour assurer une meilleure securite (Cf. figure 5).
Un syst`eme de

cloud  peut par exemple disposer des utilisateurs suivants :

frontserver : utilise par un daemon(*) recevant et traitant les demandes

effectuees aupr`es du serveur frontal.
monitor : utilise par un daemon (pas forcement lance sur le serveur frontal),
recevant lensemble des informations constituant les logs et le service de
monitoring.
appserver n : utilise par un daemon lance sur la n-i`eme machine accueillant
les applications, traitant les ordres que lui passent, principalement, le serveur
frontal.
Il faut definir lensemble des commandes qui peuvent etre envoyees. Dans un premier
temps, le serveur frontal (qui recoit les demandes des utilisateurs), peut envoyer vers
les machines virtuelles accueillant les applications les requetes suivantes :
create name : cree une VM compl`ete pour lapplication name.
delete name : supprime lensemble des fichiers et des configurations pour
lapplication name.
start time : demarre les services necessaires, time etant la planification du
lancement (now, in n minutes, at hour :minute...), renvoie une confirmation.
halt time : idem pour larret.
reload time : idem pour le redemarrage des services.
whoisthere : envoie la liste des personnes connectees au services et le nombre
total de personnes.
status : envoie le status des services (up, inaccessible, down, erreur, ...).
uptime [VM/services] : envoie la duree depuis laquelle la machine est lancee,
celle depuis laquelle les services sont accessibles.
ping : attend pong comme reponse.

34

Cette liste nest evidemment pas exhaustive. La deuxi`eme serie de requetes concerne
des communications entre machines virtuelles accueillant une meme application distribuee ou un ensemble dapplications connectees. Les commandes seraient alors les
memes avec, en plus, des commandes specifiques `a ces applications et pouvant alors
utiliser toutes les possiblites du XML, et en particulier la facilite a` passer des objets.

8.2

Message passing 

Presentation
Le langage Erlang est muni de base dun syst`eme de  message passing  intuitif.
Le  message passing  est un moyen denvoyer des messages, informations, ordres,
donnees, dun processus `a un autre. Il est intuitif car son ecriture est simplifiee :
Pid ! Data
Les donnees envoyees sont souvent des tuples(*) dont le premier est le Pid(*) de la
fonction qui envoie le message, ce qui permet `a la fonction receptrice denvoyer un
accuse de reception, ou simplement de continuer la communication avec lemetteur.
Pour obtenir son Pid, une fonction fait simplement appel `a la fonction :
self()
Le nombre delements dans le tuple est libre, ce qui permet de pouvoir facilement
envoyer des objets. On peut envoyer (exemple extremement simplifie pour expliquer
le concept) :
StockObjs ! {self(), cl1, a, 1, b, test}
Le serveur recevant ce message pourra alors instancier un objet de classe  cl1 ,
initialise aux valeurs 1 et  test  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 meme, pour passer une commande a` effectuer, on peut tout `a fait envisager le
meme syst`eme de communication, ce qui fait du  message passing  une reelle
alternative au protocole XMPP et `a son transfert de XML (Cf. figure 4).

Utilisation
Les exemples precedents ne fonctionnent que dans le cas dune communication interne a` une machine. Pour pouvoir envoyer des messages entre deux processus lances
sur deux machines distinctes, certaines manipulations supplementaires sont a` effectuer.

35

Tout dabord, il faut lancer linterpreteur Erlang (erl) comme cela :

# erl - name name_n - setcookie cookie_name \
- pa / path / to / binary

- name name_n
donne le nom  name n@hostname  a` linterpreteur lance sur la machine
 hostname .

- setcookie cookie_name
assigne le cookie(*)  cookie name  a` linterpreteur. Les cookies doivent
etre identiques sur tous les nuds qui veulent pouvoir communiquer.

- pa / path / to / binary
permet dutiliser les fonctions compilees et dont les fichier .beam sont places
dans /path/to/binary.

Une fois cela fait, les processus enregistres peuvent communiquer entre eux. Pour
enregistrer un processus, on utilise la fonction suivante :
global:register name(name, PidDeLaFonction).
Une fois cela fait, pour entammer la communication entre le nud emetteur et le
nud accueillant la fonction enregistree, on lance :
net adm:ping(node@hostname).
Enfin, pour envoyer une message a` cette fonction, on utilise :
{name, node@hostname} ! Message.
La variable Message peut etre nimporte quel type de variable, en particulier des
tuples contenant autant de variables que necessaire, tout comme le XML et ses
methodes pour envoyer des objets.

36

8.3

Comparaison des deux m

ethodes

Implementation
Les deux methodes de communications envisagees sont simples a` implementer.
Le Message Passing etant une fonctionnalite native de Erlang, il est dautant plus
simple a` implementer (une ligne pour enregistrer la fonction, une ligne pour effectuer
un  ping , une ligne pour envoyer le message).
Pour ce qui est de lutilisation du protocole XMPP, la biblioth`eque exmpp pour
Erlang a ete retenue. Elle est efficace, et facile a` prendre en main, meme si la seule
documentation fournie (projet recent) est celle issue de la compilation (le code est
cependant tr`es bien commente).
Le seul reel probl`eme dimplementation concerne le protocole XMPP et lutilisation
dexmpp. En effet, Erlang, et le concept de langage fonctionnel pur de mani`ere
generale, nest pas forcement le mieux adapte au format XML car on ne peut pas
modifier les variables sauf a` linstanciation. Ainsi, sur certaine fonctions denvois de
messages, on peut se retrouver avec 6 ou 7 variables, chacune etant une modification
mineure de la precedente. Si cela ne semble pas poser de probl`eme dun point de vue
de la memoire ou du temps dexecution, cette approche nest pas evidente pour un
developpeur habitue `a la programmation iterative. Cependant, ceci est un probl`eme
mineur qui est rapidement resolu (lecture du code de exmpp, ecriture de fonctions
basiques de retouche de messages recus, ...)

Test basique de charge

Le premier test a` avoir ete effectue etait un envoi massif de messages (teste avec
10 000, 100 000, 1 000 000 messages). Le Message Passing a alors prouve son efficacite : 2 secondes pour lenvoi et la reception de 1 000 000 000 de messages.
Par contre, la reception des messages envoye par le protocole XMPP a montre des
resultats beaucoup moins bons : pour un envoi de 1 000 messages (envoi quasiinstantane), le recepteur met plus de 2 minutes 30 avant de recevoir le dernier. En
effet, les messages semblent arriver par groupe dune dizaine avec un temps dattente
entre chaque groupe.
Ainsi, le premier test, certes basique et peu representatif (utilisation de la configuration par defaut dejabberd), etait clairement au desavantage du protocole XMPP.
Cependant, un simple test de charge, avec un envoi anormalement massif de messages ne pouvait pas etre le seul moyen de decision.

37

Maquettes fonctionnelles
Apr`es ce test basique, deux maquettes fonctionnelles, minimalistes, ont ete realisees.
Les deux etaient hebergees sur les memes machines virtuelles, utilisaient yaws comme
serveur web, affichaient les memes pages. La premi`ere utilisait le syst`eme de Message
Passing et la deuxi`eme le protocole XMPP (deux schemas expliquent le fonctionnement ci-dessous).
Les deux maquettes utilisaient chacune deux machines virtuelles, lune jouant le
role du serveur frontal, lautre celle dun serveur dapplication. Lapplication quil
hebergeait etait un simple  hello world  (puis un afficheur dheure).
Concernant la reactivite, les deux etaient, dun point de vue de lutilisateur, similaires. Elles permettaient un affichage aussi rapide que pour un simple site heberge
sur un serveur unique. Dun point de vue du developpeur, il a fallu mettre un delai
superieur avant la redirection (temps dattente ecrit en dur pour que le message
arrive et que le serveur web se lance sur le serveur dapplication) dans le cas de la
maquette XMPP. Cependant, ce delai supplementaire est negligeable (de lordre de
la centaine de milliseconde).
Pour ce qui est des possibilites et de la clarete dans le schema de communication,
cest l`a que XMPP devoile ses possibilites. En effet, il est beaucoup plus clair davoir
un client jabber par machine presente dans le  cloud , avec en plus des clients
particuliers pour certaines taches (monitoring, envoi de message ne demandant pas
de reponse, ...), plutot que des fonctions enregistrees dans un interpreteur identifie
par un cookie.
Malgre ce que lon peut voir sur le schema, le bot XMPP qui repartit lensemble des
requetes nest pas forcement lance sur le serveur frontal. De meme, le serveur ejabberd et le bot de monitoring etait heberges sur le serveur frontal dans la maquette
realisee, mais ceci nest pas necessaire (on peut, par exemple, dedier une machine
compl`ete pour le controle du  cloud ).

38

Figure 4 Communication par Message Passing

39

Figure 5 Communication par protocole XMPP

40

8.4

Conclusion

Les deux moyens de communications envisages sont tous les deux performants et globalement faciles a` implementer. Lutilisation du protocole XMPP ralentit leg`erement
la reception, et donc le traitement, des messages. Le Message Passing quand `a lui
est dune facilite dimplementation et dune efficacite sans pareil.
Cependant, lutilisation du protocole XMPP permet non seulement de clarifier le
reseau, de centraliser la gestion des requetes et denvisager lutilisation de capacites
deja developpees (syst`eme de publish/subscribe, syst`eme de presence, ...) ou de
profiter de laspect extensible du protocole pour developper des extensions dediees
au  cloud  (module de publication de letat dune machine virtuelle, ...).
Au final, malgre une certaine lenteur par rapport au Message Passing, cest lutilisation du protocole XMPP qui semble la plus appropriee. En effet, ce protocole (qui
est un standard ouvert), est assez reactif pour que ne pas ralentir le  cloud  de
mani`ere abusive. De plus, cest lui qui permet la plus grande extensibilite. Enfin,
le schema de deploiement des bots XMPP correspond au schema dorganisation du
 cloud , ce qui permet de clarifier le code dune part, et d
eviter une duplication
de code (seul un bot recoit les requetes, les traite, et envoie des demandes specifiques
aux bots des serveurs dapplications).

41

Load Balancing

Le deuxi`eme aspect particulier du  cloud  est son syst`eme de repartition des

charges et la gestion dynamique des machines qui le composent. En effet, dans un
 cloud 
on trouve non seulement un syst`eme de repartition de charge  classique  (pour lequel des solutions existent dej`a), mais surtout un syst`eme de
detection des besoins : le  cloud  reagit en fonction des demandes des utilisateurs,
gerant les machines accessibles (comprendre ici : les machines virtuelles demarrees)
pour minimiser leur nombre et maximiser la reactivite des differents services. Cet
algorithme est tr`es utilise et repond totalement totalement aux attentes dun algorithme de repartition de charges dans un  cloud  (facilite dimplementation et
repartition equitable).

9.1

Gestion dynamique des machines virtuelles

Pour proposer un service de  cloud computing  performant et coherent avec le

concept, il faut fournir un syst`eme de gestion dynamique des machines disponibles.
En effet, si peu dutilisateurs se connectent au  cloud , il nest pas utile davoir
` linverse, si de nombreux utiliune multitude de serveurs lances et sous-exploites. A
sateurs tentent de se connecter au service simultanement, ils ne doivent pas observer
un service ralenti. Pour pouvoir assurer ce service, le fournisseur doit posseder un
syst`eme de lancement et darret de machines coordonne avec les demandes.
Ainsi, quand le premier serveur (frontaux, SQL ou dapplication) a atteint ses capacites maximales, un deuxi`eme serveur est lance, et les requetes sont alors reparties
equitablement entre les deux serveurs presents. Quand les n serveurs presents ont atteint leur capacites maximales (de mani`ere globale), on lance un (n+1)-i`eme serveur,
et on reparti les requetes sur les n+1 serveurs.
Certains fournisseurs g`erent les machines disponibles grace a` un syst`eme interactif,
potentiellement mis `a disposition du client, mais cela implique une presence humaine
dediee de mani`ere quasi-permanente a` la surveillance du  cloud . Le syst`eme le
plus judicieux et le plus avantageux est dimplementer un monitoring automatique

du  cloud  et de lui faire gerer le lancement et larret des serveurs. Evidemment,

un
tel syst`eme sera surveille et mis a` jour pour que ses performances soient maximisees,
ce qui implique un presence humaine (au moins les premiers temps).

42

Il y a trois types de serveurs `a gerer dynamiquement :

Lensemble des serveurs frontaux.
Lensemble des serveurs SQL.
Lensemble des serveurs dapplication.

Serveurs frontaux
Pour definir le besoin dajout ou de suppression de serveurs frontaux, on doit etudier
le temps de reponse du serveur web a` une demande classique. Le serveur frontal
nhebergeant aucune application, il suffit donc detudier son temps de reponse sur
une simple requete (un  ping  par exemple). Si le temps de reponse est anormalement long, le syst`eme de monitoring fait une requete pour lancer un serveur frontal
supplementaire (la gestion de multiples serveurs pour un service unique sera traite
dans la partie suivante). Si le temps est normal ou acceptable, rien nest effectue.
Enfin, si le temps est anormalement court, le syst`eme de monitoring peut demander
la suppression dun ou plusieurs serveurs frontaux. Tout le probl`eme est de definir
 anormalement long 
et  anormalement court . Ces limites sont globalement
arbitraires et dependent des capacites de lhebergeur et des demandes du client.

Serveurs SQL
Concernant lajout ou la supression de serveur SQL, il faut etudier le temps de
reponse de la base de donnees, en effectuant, par exemple, une ou plusieurs requetes
` partir des resultats,
pre-definies et en etudiant le temps de reponse de la base. A
et en appliquant le meme principe que pour les serveurs frontaux en comparant le
temps de reponse de ces requetes a` des valeurs arbitraires fixees.
Differentes repartitions sont envisageables :
plusieurs serveurs gerant chacun une partie des donnees dune application ;
plusieurs serveurs sur la meme base de donnees avec un syst`eme complexe de
mise-`a-jour lors des ecritures et/ou une separation des serveurs permettant
la lecture et ceux permettant lecriture.

43

Serveurs dapplication
Enfin, pour les serveurs dapplications, le calcul peut etre plus complique. On doit
non-seulement evaluer le temps de reponse du serveur web qui effectue laffichage
comme sur les serveurs frontaux, mais aussi differentes valeurs qui, dans le cas de
lhebergement dune application, deviennent significatives (utilisation du CPU, occupation de la memoire, charge, ...). On peut aussi ponderer ces valeurs pour fournir
une evaluation simple (par exemple un score compris entre 0 et 100) dans le but
de clarifier les cas de lancement ou darret des serveurs. De meme que les valeurs
arbitraires des deux premiers cas, la ponderation est arbitraire et depend des besoins
du client, des capacites du fournisseur mais aussi de lapplication elle meme.

Le lancement de serveurs supplementaires ainsi que larret de serveurs superflus (du

moins les algorithmes retenus ici) reposent donc enti`erement sur des valeurs fixees.
Le plus important dans limplementation est donc la gestion de ces valeurs :
valeurs pour les serveurs frontaux `a ajuster selon les besoins du client et les
capacites du fournisseur,
valeurs pour les serveurs SQL a` ajuster selon les memes crit`eres,
valeurs pour les serveurs dapplication a` ajuster separement pour chaque
application en prenant en compte :
les besoins du client concernant cette application,
les capacites du fournisseurs,
les demandes de lapplication en ressource.

9.2

Load balancing, HAProxy et round-robin

Load balancing
Une fois le nombre de machines virtuelles adequat atteint, il faut repartir les demandes entre ces machines. Cest le principe de  load balancing  a` proprement
parler.
De nombreux outils existent pour repartir la charge entre plusieurs serveurs, de
meme que plusieurs algorithmes de repartition.

44

On peut effectuer du  load balancing  a` plusieurs niveaux du mod`ele OSI(*) :

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, detaille plus loin.
Couche 4 : la couche  transport , en redirigeant d`es larriver de la requete
(sans passer par la couche  applicative ), avec lutilisation de Linux Virtual
Server (LVS), solution de virtualisation pour cluster de serveurs.
Voici quelques uns des differents algorithmes :
Redirection aleatoire : envoie des requetes vers un des serveurs disponibles
de mani`ere aleatoire. Ce syst`eme est simple `a implementer, mais nest pas
efficace.
Round-robin : effectue une rotation reguli`ere de ladresse IP du serveur qui
va recevoir les demandes. Cet algorithme est implemente dans la totalite
des syst`eme de  load balancing  et peut facilement etre ameliore par une
allocation de poids `a certaines IP.
Moins utilise : le byrequest o`
u le serveur qui a recu le moins de connexions
recoit la suivante. Destine `a de longues sessions.
bybusiness : redirection vers le serveur le moins utilise.
source : effectue un hash sur ladresse du client pour lassigner a` une adresse
IP. Cet algorithme permet dassurer quun meme client se connectera toujours `a un meme serveur.

Round-robin
Le Round-Robin est un algorithme dordonnancement mais dont le principe a ete
adapte a` la repartition de charge. Le Round-Robin de base fournit une repartition
equitable entre plusieurs serveurs, ce qui veut dire que les serveurs doivent tous etre
identiques pour une efficacite optimale. Cependant, le Round-Robin pondere nest
pas beaucoup plus complique `a implementer et present dans la plupart des logiciels
de repartition de charge.

HAProxy
HAProxy est un logiciel libre (HAPROXYs license) de repartition de charge et de
gestion de proxy adapte a` des sites recevant de nombreuses connexions (et donc
adapte a` un service de type  cloud , Cf. figure 6). Il est configure dans un fichier
de configuration 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 modification de ce fichier. Cependant, on peut
reconfigurer dynamiquement HAProxy avec :
# haproxy -f / etc / haproxy . cfg - sf PidDeHaproxy

9.3

Conclusion

Le syst`eme de load balancing en lui meme est simple a` mettre en place car des logiciels existent dej`a pour le gerer. HAProxy semble etre la solution ideale : simple
a` configurer, `a re-configurer, capable de gerer la repartition a` plusieurs niveaux,
presentant une tr`es bonne securite (pas une faille de securite en sept ans), et,
evidemment, libre.
Le reel probl`eme dans le cas du  cloud computing  est la dynamicite du reseau et
la mani`ere de la gerer. Il faut en effet etre capable dadapter le reseau aux demandes
des utilisateurs, cest-`a-dire ajouter des serveurs supplementaires necessaires a` de
nombreuses requetes ou en supprimer si la demande est faible. Le moyen le plus
simple est de gerer manuellement les capacites du reseau, et donc de faire lancer ou
arreter les serveurs par un humain. Cependant, cette approche est co
uteuse tant dun
point de vue temps que dun point de vue moyens, il est donc preferable de mettre
en place un service automatise de gestion du reseau qui verifie de mani`ere reguli`ere
les capacites de reponse du  cloud  et qui lajuste aux besoin des utilisateurs.
Une telle gestion du reseau presentera des incoherence et demandera des adaptations dans les premiers temps de la mise en production dun  cloud . La presence
humaine reste donc une obligation, mais seulement le temps dajuster ce syst`eme
aux besoins propres `a un service de  cloud .

46

Figure 6 HAProxy

47

Conclusion
Le  cloud computing  est une mode recente o`
u de plus en plus de clients ont
tendance a` sengouffrer, et donc de nombreux hebergeurs ont mis en place des propositions de solutions de  cloud . Pourtant, ces propositions presentent toutes (ou
quasiment toutes) des aspects inadmissibles du point de vue de lethique du libre
(forfaits, syst`emes proposes sans aucun moyen de controle), ou simplement trop
flous.
Pourtant, un  cloud  peut presenter des interets evidents pour une entreprise.
Grace `a un tel syst`eme, elle peut proposer un ensemble dapplications `a ses employes
sans avoir `a se soucier de sa maintenance ou son administration, tout en ayant lassurance dun syst`eme moins consommateur (la quantite des ressources doit sadapter
a` lutilisation du  cloud ) et donc plus econome (labonnement doit etre fonction
des capacites mises en place). Certaines peuvent meme utiliser le  cloud  pour
commercialiser un service par le biais dapplications web. Lutilisation du libre (et
surtout un total respect de son ethique) permettrait dassurer un double objectif :
Apporter une vision du  cloud computing  nouvelle par sa transparence,
ce qui ameliorerait limage dune telle technologie dans lesprit de la communaute libriste et qui forcerait peut-etre une evolution des offres dej`a existante.
Fournir aux clients une reelle garantie sur la facon de traiter leurs donnees,
leur assurer un reel controle sur elles, et donc pouvoir enfin profiter des
possibilites techniques quapporte le  cloud computing  sans devoir faire
preuve dune confiance aveugle en lhebergeur.

48

Particularit
es
La difference principale entre un syst`eme de  cloud  et un hebergement  classique  est la gestion du reseau complexe qui le compose, gestion principalement
fondee sur deux points :
La communication entre les serveurs : pour assurer le lancement, larret,
la communication de donnees entre les machines, il faut mettre en place
un syst`eme de communication complet (pour permettre, par exemple, du
passage dobjet) et automatisable (et donc definir une grammaire des ordres
que les serveurs peuvent senvoyer).
Le syst`eme de  Load balancing  : qui permet de gerer letat du  cloud  en
fonction des demandes des utilisateurs, soit automatiser le lancement, larret
ou la modification de capacite des serveurs en fonction de leur temps de
reponse. Cest en ce sens quun  cloud  se distingue dun syst`eme de
 grid computing .

Pour assurer ces deux syst`emes, les choix retenus sont :

Lutilisation du protocole XMPP, heberge par un serveur ejabberd, et une
implementation des bots en Erlang grace `a la biblioth`eque exmpp.
Lutilisation du logiciel HAProxy pour effectuer le Load balancing, avec une
implementation compl`ete du ou des scripts analysant le besoin du reseau et
demandant lajout ou la suppression de serveurs.

La gestion dynamique du reseau est le point le plus obscur `a mettre en place. En

effet, cette gestion demande une analyse complexe de letat des serveurs, qui depend
du role du serveur observe, de ses capacites, de son etat (utilisation des ressources,
nombre de connexions, ...) et. evidemment, des capacites disponibles chez lhebereur
ainsi que les demandes particuli`eres du client (demande de maximisation de la qualite
de reponse, de minimalisation des co
uts, ...).

Une approche extremement basique de voir ce probl`eme est de faire un appel a` un

serveur, detudier son temps de reponse, et den deduire laction a` effectuer :
Si le temps de reponse est  trop  court, on demande larret de serveurs.
Si le temps de reponse est suffisant, on ne fait rien.
Si le temps de reponse est trop long, on demande le lancement de serveurs
supplementaires.

49

Dans le but de fournir un ensemble de scripts repondant de mani`ere optimale a`

ce probl`eme, il faut separer les differents serveurs suivants leurs roles et adapter le
script basique :
Les serveurs frontaux doivent assurer un temps de reponse correcte aux
requetes HTTP.
Les serveurs de bases de donnees doivent assurer une tr`es grande rapidite
aux requetes SQL.
Les serveurs dapplication doivent assurer un temps de reponse correcte aux
requetes HTTP ainsi quune capacite de calcul constante.
Lavantage de HAProxy dans le cas du  cloud computing  est sa capacite a`
pouvoir prendre en compte les modifications du fichier de configuration sans avoir a`
etre arrete.

Vision libriste
Malgre tous les points negatifs non-refutables formules `a legard du  cloud computing , le fait de sopposer aux hebergeurs fournissant un service, comme le soul`eve
Stallman, qui va `a lencontre des libertes du client et de lutilisateur nest pas
negligeable. Le pire etant que certains de ces fournisseurs  privateurs  le font
en basant leur publicites sur lutilisation de logiciels Open Source, prouvant une fois
de plus la difference fondamentale entre ces deux mouvements.
De plus, apr`es de nombreuses recherches et reflexions sur le concept, des moyens
divers peuvent etre mis en place pour  liberer  le  cloud . En effet, il est tout
a` fait envisageable de fournir :
Une architecture totalement libre (syst`eme dexploitation, logiciels et code
mis en place par lhebergeur).
Un monitoring complet et permanent des serveurs qui constituent le  cloud .
Un moyen simple dacceder a` ces serveurs pour effectuer un monitoring local.
Lensemble des images qui sont utilisees comme images syst`eme (dans le
cadre de la virtualisation).
Le principal point a` developper et a` mettre en avant est laccessibilite et le controle
par le client (et a` un certain niveau par lutilisateur) sur ses donnees, ainsi quun
moyen pour lui de les securiser vis-`a-vis de lhebergeur, et quil nait `a aucun moment
de doute sur leur utilisation ou leur visibilite.

50

Inconv
enients
En plus du cote  buzz mediatique  du  cloud , cette technologie presente des
inconvenients dont il faut etre conscient en tant quhebergeur :
Dun point de vue ethique du libre, le  cloud  reste deviant dun des objectifs du monde du libre, permettre aux utilisateurs de se reapproprier loutil
informatique (mais nest pas, alors, pire quun hebergement  classique ).

Le  cloud  doit se plier `a des lois specifiques variant dun Etat

a` lautre,
rendant difficile, par exemple, certaines migrations.
Les facturations actuelles des services sont `a la fois complexes et desavantageuses
du point de vue du client, ce qui force soit `a proposer une facturation
irrespectueuse pour le client, soit `a se demarquer nettement des autres
hebergeurs.
Les syst`emes de  cloud  actuels presentent des failles dun point de vue
de la qualite, un nouveau type dhebergement se doit donc de pallier ces
faiblesses pour pouvoir marquer une reelle evolution.

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

Bilan
Au final, plusieurs points amm`ene a` vouloir proposer une offre de

cloud  :

profiter du cote  buzzword  ;

proposer une vision du  cloud  respectueuse de lethique du libre ;
pouvoir adapter certains aspects de cette technologie aux services actuels
(les implementations, scripts de lancement de serveurs, load balancing, communication XMPP, sont totalement reutilisables).

51

Glossaire
AFS
Andrew File System : syst`eme darchivage distribue.
Bot
Programme informatique effectuant des taches automatisees (reponses automatiques
et/ou traitement de messages par exemple).
Cookie
Fichier stocke par le navigateur sur le disque de linternaute, permettant denregistrer des informations et de les communiquer au site visite.
Daemon
Processus sexecutant en arri`ere plan de mani`ere permanente.
Framework
Ensemble de biblioth`eque permettant le developpement dapplications.
Mod`ele OSI
Mod`ele de communication entre ordinateurs propose par lISO.
Monitoring
Surveillance et mesure dun ensemble de processus.
Objet
Definition de caracteristiques propres a` un element informatique.
Pid
Process Identifier : Code unique attribue a` un processus.
SASL
Simple Authentication and Security Layer : cadre dauthentification.
SSL / TLS
Secure Sockets Layer ou Transport Layer Security : protocole de securisation des
echanges sur Internet.
Virtualisation
Technique permettant de faire fonctionner sur une seule machine un ensemble de
syst`emes dexploitations.
52

Table des figures

Table des figures

1

Fonctionnement du

Fonctionnement detaille . . . . . . . . . . . . . . . . . . . . . . . . . 14

VM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Communication par Message Passing . . . . . . . . . . . . . . . . . . 39

Communication par protocole XMPP . . . . . . . . . . . . . . . . . . 40

HAProxy

cloud  . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

53

Bibliographie

Wikipedia - Cloud Computing

URL
Wikipedia - Load Balancing
URL
Wikipedia - Load Balancing
URL
Site officiel dErlang
URL
Creation de bots XMPP en Erlang
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 differentes offres commerciales

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