Etat de l`art du Cloud Computing et adaptation au

Transcription

État de l’art du Cloud Computing
et adaptation au Logiciel Libre
Maurice Audin
2009
Typographie
Les termes suivis d’un astérisque (*) seront définis dans le glossaire.
License
Ce document est sous license Creative Commons
2
By-NC-SA 2.0 .
Table des matières
Introduction
Le
6
cloud . . . . . . . . . . . . . . . . . . . . . . . . . . .
Intérêt du
6
cloud . . . . . . . . . . . . . . . . . . . . . . .
7
Le logiciel libre . . . . . . . . . . . . . . . . . . . . . . . . .
8
Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
1 Définition des concepts
10
1.1
C’est quoi ? . . . . . . . . . . . . . . . . . . . . . . . .
10
1.2
Usages du
cloud . . . . . . . . . . . . . . . . . . . .
11
1.3
Les autres . . . . . . . . . . . . . . . . . . . . . . . . .
12
1.4
Caractéristiques . . . . . . . . . . . . . . . . . . . . . .
12
1.5
Mode de fonctionnement typique . . . . . . . . . . . .
13
2 Offres commerciales
16
2.1
Historique . . . . . . . . . . . . . . . . . . . . . . . . .
16
2.2
Offres . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
3 Points négatifs du
cloud
20
3.1
Problèmes éthiques . . . . . . . . . . . . . . . . . . . .
20
3.2
Inconvénients politiques . . . . . . . . . . . . . . . . .
21
3.3
Forfaits actuellement proposés . . . . . . . . . . . . . .
21
3.4
Stress test . . . . . . . . . . . . . . . . . . . . . . . . .
23
4 Solutions libres
4.1
24
Côté client . . . . . . . . . . . . . . . . . . . . . . . . .
3
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 Étude du framework Vertebra
27
6.1
Fonctionnement . . . . . . . . . . . . . . . . . . . . . .
27
6.2
Interface . . . . . . . . . . . . . . . . . . . . . . . . . .
28
6.3
Intérêts . . . . . . . . . . . . . . . . . . . . . . . . . .
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 méthodes
. . . . . . . . . . . .
37
8.4
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . .
41
9 Load Balancing
42
4
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
5
Introduction
Le cloud computing , ou informatique dans les nuages, est un paradigme assez
récent. La première énonciation de ce concept date de 1960 (John McCarthy), mais
sa réelle mise en application a pris place au début des années 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 hébergent une ou plusieurs
applications. Ainsi, le visiteur a accès à des applications dont l’exécution ne dépend
pas du serveur web, et qui n’influent donc théoriquement pas sur son temps de
réponse.
La contre-partie est que le client n’a pas directement accès à ses données. Il dépend
donc totalement du fournisseur et doit lui faire entièrement confiance pour ce qui
est de leur confidentialité et de leur sauvegarde.
Le problème est donc de savoir :
– quels sont les avantages réels du cloud du point de vue du fournisseur ;
– quelles sont les solutions techniques disponibles et leur méthode de tarifications ;
– quelles sont les critiques (éthiques et légales) liées au cloud computing et
comment y remédier.
Le
cloud La définition du cloud computing , ou informatique dans les nuages, de Wikipedia
est la suivante :
L’informatique dans les nuages (en anglais, cloud computing) est un
concept majeur faisant référence à l’utilisation de la mémoire et des
capacités de calcul des ordinateurs et des serveurs répartis dans le monde
entier et liés par un réseau, tel Internet.
Le cloud (Cf. figure 1) permet donc de fournir un ensemble d’applications sans
utiliser la mémoire, la puissance de calcul et la capacité de stockage d’un seul serveur. Le visiteur se connecte sur le site du client des services de cloud , utilise
les applications qui lui sont proposées sans avoir conscience qu’il accède à des machines (virtuelles ou non) différentes, et utilisent les applications proposées pour
éventuellement stocker des données personnelles sur des serveurs distants. De plus,
le client n’a pas d’accès direct à ses données.
Il existe un autre type de cloud , dit privé, qui est similaire mais limité à un
réseau privé, il ne sera donc pas traité séparément.
6
Figure 1 – Fonctionnement du
Interêt du
cloud cloud De la même façon que la virtualisation(*), un système de cloud permet une
grande évolutivité. On peut facilement et sans danger pour les applications déjà
disponibles rajouter des machines au cloud pour une plus grande réactivité ou pour
fournir des applications supplémentaires. De plus, s’il est fait avec des machines
virtuelles (ce qui est toujours le cas), le cloud permet une réduction réelle des
coûts (plusieurs dizaines de milliers d’entreprises gérées sur 1 000 serveurs pour
prendre l’exemple de Salesforce.com). De plus, les ressources utilisées sont mieux
rentabilisées (plus de 10 ou 20 % des ressources utilisées...).
D’un point de vue de la sécurité, les données étant centralisées, elles sont plus faciles
à protéger mais le client perd le contrôle sur elles. De plus, si une application présente
une faille, seul le système qui l’accueille pourra être mis en danger. Ainsi, toutes les
autres applications ainsi que la machine frontale sont protégées.
Les données et les applications étant hébergées et souvent sauvegardées sur des
machines distantes, on peut y accéder de manière permanente et de n’importe quel
endroit et être assuré de leur pérennité.
7
Enfin, le cloud peut reposer entièrement sur des technologies libres comme par
exemple :
– Xen ou KVM pour les machines virtuelles ;
– Système GNU/Linux pour les OS (Debian) ;
– Serveur web libre (Apache) ;
– Serveur d’applications libre (framework dépendant du langage utilisé) ;
– Base de données MySQL ;
– Firefox comme explorateur.
Le logiciel libre
Le but de ce document étant d’étudier la possibilité et l’intérêt du cloud computing dans une société développant du logiciel libre, il faut d’abord définir cette
notion.
Le mouvement du logiciel libre a débutté au début des années 80 à l’initiative de
Richard Stallman qui lance la Free Software Foundation. Selon Stallman, un logiciel
est dit libre s’il permet les quatres libertés fondamentales :
0. La liberté d’exécution quelqu’en soit le but.
1. La liberté d’étudier le fonctionnement du programme et de le modifier pour
qu’il se conforme à ses besoins.
2. La liberté de redistribuer le programme dans un but d’entraide.
3. La liberté d’améliorer ou simplement de modifier le programme et de pouvoir redistribuer les versions modifiées au profit de la communauté.
Un logiciel offrant ces quatre libertés est dit libre, sinon, il est dit privateur. Selon la
license proposée par le projet GNU (le système d’exploitation lancé par Stallman et
qui utilise actuellement le noyau Linux), un logiciel sous license libre doit le rester,
c’est à dire que les versions modifiées et redistribuées doivent garder une license libre
(ce n’est pas le cas de la license BSD).
Le terme de Free est ambigu car il signifie à la fois libre et gratuit .
Sa réelle signification est libre , ce qui veut dire que l’on peut faire commerce du
logiciel (vendre les binaires compilés d’un programme par exemple), de même que
fournir un service payant basé sur l’utilisation de logiciel libre.
Parmis les noms les plus connus du monde du libre, on peut citer le système GNU/Linux (et ses distributions réputées telles que Debian, Ubuntu ou Red Hat), l’explorateur Firefox (produit et développé par la société Mozilla et qui rattrape petit à
petit Internet Explorer, son concurrent privateur développé par Microsoft), le lecteur
multimédia VLC, ou le serveur web Apache (largement majoritaire sur le marché de
l’hébergement).
8
Les intérêts de l’utilisation de logiciels libres sont nombreux. Pour un particulier, ils fournissent l’assurance, même s’il ne peut pas lui-même le vérifier, que les
développeur ne cherchent pas à introduire des fonctions malveillantes dans leur code.
Ils permettent aussi une évolution constante, que ce soit au niveau des performances,
de l’ergonomie ou de la sécurité, grâce à une communauté très active. Pour des professionnels, un logiciel libre est une assurance de pérennité car il ne dépend pas
ou peu de l’état financier d’une société. De plus, malgré la croyance populaire, un
logiciel libre ne présente pas plus de problèmes de sécurité qu’un logiciel privateur.
En effet, la posibilité, y compris pour la société qui utilise ce type de logiciel, de
pouvoir étudier le code source permet une meilleure réactivité face à d’éventuelles
failles, de même 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 intéressant d’étudier si une proposition entièrement libre est envisageable.
Objectifs
Plusieurs objectifs ont motivé la création de ce document :
– Donner une explication claire du concept de cloud computing , de son
utilité et de ses inconvénients ;
– fournir les données concernant les offres commerciales qui existent actuellement ;
– définir les technologies et les logiciels à utiliser pour une offre de cloud ,
faire des comparatifs pour régler certaines concurences entre eux ;
– Expliquer la mise en place de ce service avec les outils choisis.
9
1
1.1
Définition des concepts
C’est quoi ?
Le cloud computing est (si on cherche à dépasser l’effet 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 gérer la relation entre les programmes sur l’ordinateur et sur le
web. L’utilisateur n’a pas conscience du cloud en utilisant ce type de services,
de même qu’il n’a aucun contrôle dessus. On trouve généralement 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 déploiement d’applications ;
– Software as a service (SaaS), permettant l’accès à des applications sur le
web.
On peut en fait diviser le cloud computing en deux catégories bien distinctes
(même si un fournisseur peut proposer les deux) :
– Stockage
Les données du client sont sauvegardées sur plusieurs serveurs, par exemple
Amazon Simple Storage Service (ou Amazon S3), souvent accompagné de
copies de sauvegardes (voir la section inconvénients politiques). Ce type de
cloud permet, si l’on a stocké des applications sur le serveur d’y accéder
et de les exécuter, et ressemble alors à un système 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 n’est que le propriétaire du logiciel n’est pas forcément le propriétaire du
matériel. 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 l’utilisation de leurs
langages et de leurs biblothèques, ce qui rend la maintenance plus aisée (elle
ne dépend plus des besoins du client), mais beaucoup moins flexible pour le
client.
10
Le
cloud dépend des composants suivants (Cf. la section solutions libres) :
– Client
Logiciel permettant à un internaute de se connecter au cloud . Généralement,
un explorateur internet suffit, mais d’autres moyens peuvent être utilisés
suivant les services proposés par l’hébergeur ou par l’acheteur du service de
cloud .
– Service
Protocoles proposés par l’hébergeur ou par le client (paiement, mapping,
chat, mail, ...)
– Application
Les applications sont soit proposées de base par l’hébergeur, soit développées
par le client. Chacune d’elles dispose d’une ou plusieurs machines virtuelles.
– Plate-forme
Système d’hébergement des applications.
– Stockage
Moyen de stockage mis à disposition du client. La plupart des hébergeurs
proposent une base de données SQL sur laquelle le client n’a pas d’accès
direct, ce qui peut être changé (avec un gain considérable de liberté). Il est
aussi envisageable de lui fournir un système de stockage classique (système
de fichier accessible en FTP par exemple).
– Infrastructure
Il s’agit du serveur frontal.
1.2
Usages du
cloud
Les usages d’un cloud dépendent du point de vue adopté. Un cloud se
destine d’une part au client, une entreprise ou autre (gouvernement, association,
...), qui administre un système de cloud , et d’autre part aux employés ou aux
clients de cette entreprise, qui sont les utilisateurs de ce système.
Pour l’entreprise, le cloud va permettre de fournir un ensemble d’applications
à ses employés, et celà où qu’ils se trouvent. On pourra trouver, par exemple, une
messagerie, un agenda, un système de messagerie instantanée, voire un système de
vote, de partage de documents, ... (applications proposées par défaut ou développées
par le client du service). C’est donc une extension de son service informatique. Il
peut aussi être utilisé comme moyen de vendre un logiciel développé en faisant payer
l’accès au cloud . Enfin, il peut servir de moyen de sauvegarde de ses données.
Pour l’utilisateur, le cloud est un moyen d’accéder aux services fournis par cette
entreprise. Que ce soit un service gratuit (dans le cas d’un employé) ou payant (dans
le cas d’un client utilisant un accès acheté), il peut avoir accès à ces services quel
11
que soit l’ordinateur qu’il utilise (plus besoin d’installer des logiciels équivalents à
ceux proposé sur chacun de ses ordinateurs), sans soucis de versions car l’application fonctionne de manière identique sous GNU/Linux, Mac, Windows ou tout
autre système disposant d’un explorateur internet (Freerunner, iPhone, Android,
Blackberry, PDA, ...).
1.3
Les autres
Le cloud computing peut facilement être confondu avec d’autres paradigmes.
S’il ne faut pas les confondre, il faut aussi avoir conscience que ces concepts sont
parfois liés. Voici les principaux exemples de ces autres paradigmes et leur relation
avec le cloud .
– Le grid computing
Dans un système de grid, un super-ordinateur contrôle un ensemble de
systèmes et leur répartit des calculs à effectuer dans un but unique (calcul
scientifique, analyse sismique, ...). Dans la plupart des cloud , on trouve
toujours un système de grid mais dans lequel l’application n’est pas unique
et où le super-ordinateur a pour but de pointer vers le système correspondant à la demande et non de répartir le calcul.
– L’utility computing
L’utility computing est simplement en une délocalisation d’un système de
calcul ou de stockage. Il est évidemment utilisé dans un cloud mais n’implique pas forcément un réseau de calcul ou de stockage comme le cloud .
– L’autonomic computing
Paradigme dans lequel un système informatique est capable de s’auto-administer
en s’adaptant à des changements imprévisibles. Il peut être composé de
systèmes d’auto-configuration, d’auto-réparation (détection et correction d’erreurs), d’auto-optimisation (contrôle et répartition des ressources) et d’autoprotection (détection et protection contre des attaques). L’autonomic computing n’a à priori rien à voir avec le cloud computing mais un cloud comprend généralement des élément autonomes (auto-optimisation par exemple).
1.4
Caractéristiques
Le but d’un cloud est de créer un système totalement décentralisé (par exemple
BitTorrent ou Skype), même si la plupart se basent encore sur des grids ou des
utilities et sont donc encore centralisés.
Les offres commerciales permettent de faire payer au client en fonction des ressources
utilisées (forfait basés sur l’électricité ou sur le matériel utilisé)
12
Comme le client n’a pas de contrôle direct sur le matériel, il peut rapidement y avoir
une sur-utilisation des ressources disponibles, même si une bonne bande passante
permet théoriquement le même temps de réponse qu’un système centralisé clasique.
La plupart des architectures utilisées pour le cloud computing sont des datacenters et des serveurs avec plusieurs niveau de virtualisation.
1.5
Mode de fonctionnement typique
De manière général, un cloud présente les éléments suivants, certains étant
optionnels mais améliorent sa qualité (réactivité), Cf. figure 2 :
– Proxy HTTP
Point d’entrée des demandes, gère le SSL(*).
– Cache HTTP
Permet de répondre plus rapidement à une requête en plaçant une partie du
contenu dans un cache.
– Serveur frontal
Gère les requêtes en lançant des machines virtuelles adéquates ou en communiquant avec des machines virtuelles adéquates déjà lancées.
– Machines virtuelles
Ensemble de serveurs (serveurs Ruby avec framework (*) web par exemple)
accueillant chacune une application. Elles doivent pouvoir être lancées rapidement et indépendemment pour répondre le mieux possibles aux demandes
des visiteurs.
– Base de données SQL ou système de stockage
Base de données pour chaque application, avec duplication et téléchargement
pour le client (la base de donnée peut être externe au cloud ), système
de stockage présentant les mêmes avantages.
– Cache mémoire
Cache mémoire pour les applications web permettant un accès rapide (par
exemple à des fragments de pages).
Chaque machine virtuelle (Debian, Cf. figure 3) accueille un environnement spécifique
au langage utilisé par le client. Une application utilise une ou plusieurs machine virtuelle suivant sa complexité. Le système de fichier peut être en lecture seule (les
données étant stockées ailleurs, il suffit de pouvoir exécuter l’application présente
sur la machine virtuelle).
L’environnement doit accueillir un serveur d’applications lui aussi spécifique au langage utilisé qui accueillera le serveur web.
13
Figure 2 – Fonctionnement détaillé
14
Figure 3 – VM
Enfin, le serveur accueille l’application du client. Dans un souci de généricité, on peut
concevoir que l’ensemble des applications soient stockés sur un serveur de stockage et
que la machine virtuelle y accède au moment de l’exécution (par AFS par exemple).
Ainsi, on peut créer des images de machines virtuelles typiques, valables pour un
grand nombre d’applications, et plus légères d’un point de vue taille.
15
2
2.1
Offres commerciales
Historique
La première énonciation de l’idée 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 d’utilité publique)
John McCarthy
Le mot cloud est apparu au début des années 90 pour désigner des réseaux
disposant d’un mode de transfert asynchrone, et l’expression cloud computing il
y a une dizaine d’années et a pris de plus en plus d’importance.
Salesforce.com fut le premier hébergeur de cloud en 1999, suivi en 2002 par
Amazon qui proposa un ensemble d’hébergement d’application, de stockage et d’offre
d’emploi (Le Mechanical Turk).
Amazon développa ses services en 2005 (Amazon Web Services) et en 2006 (Elastic
Compute Cloud ou EC2).
Ce dernier fut le premier service de cloud réellement accessible (selon Jeremy
Allaire, PDG de Brightcove, autre fournisseur de SaaS).
En 2007, Google, IBM et des universités lancèrent un projet de recherche sur le
cloud qui permit de lui faire gagner en popularité et en consistance.
C’est en 2009 que la réelle explosion du cloud survint avec l’arrivée sur le marché
de sociétés 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 décembre 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 développer en Java et Python ;
– 0,10 $ par heure d’utilisation de CPU, 0,15 $ par Go.
– Microsoft Azure
– Stockage ;
– Applications fournies, possibilité de développer en .NET ;
– Voir la section sur les forfaits.
– 3Tera
– Stockage ;
– Possibilité de développer 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 développer en .NET, Java et C++ ;
– Système de cloud interne.
– Cassatt
– Répartition dynamique des ressources de calcul ;
– Solution de système de cloud interne.
– Joyent
– Stockage ;
– Possibilité de développer en Rails et PHP ;
– De 125 à 250 $ par mois pour 1 Go.
– Legal Cloud
– Déploiement de services et de stockage rapide ;
– Déstiné aux entreprises d’avocats.
– Skytap
– Possibilité de développer 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 développer (tous langages confondus) ;
– De 0.04 £ par heure à 29 £ par mois ;
– comparatif.
– Flexiscale
– Stockage ;
– Possibilité de développer (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 ;
– 700,80 $ par mois pour 620 Go de stockage et 15 872 Mo de RAM.
– NewServers
– Stockage
– Possibilité de développer 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 développer en Rails et PHP ;
– 35 $ par mois pour 256 Mo de RAM et 5 Go de stockage ;
– 267 $ par mois pour 2048 Mo de RAM et 25 Go de stockage.
– Heroku
– Stockage
– Possibilité de développer 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 négatifs du
cloud Problèmes éthiques
La principale critique du cloud computing est que le client ne possède pas physiquement le stockage de ses données et laisse donc le contrôle total au fournisseur.
Le London Times a par exemple comparé cette technique aux systèmes centralisés des années 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 l’autorisation du fournisseur pour la plupart des tâches d’administration.
De plus, en cas de problèmes techniques de la part du fournisseur, le client n’a plus
aucun moyen d’accéder à ses données.
Sur le même ton, Richard Stallman condamne cette technologie par laquelle l’utilisateur confie aveuglément ses données privées à un fournisseur qui peut alors le
piéger en le forçant 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-même, de pouvoir vérifier l’attitude réelle des machines virtuelles qui accueillent les applications car ils n’y ont pas accès. Le problème des logiciels privateurs
qu’énonce Stallman est que l’utilisateur, par l’usage de ces logiciels, doit avoir une
confiance aveugle envers le développeur. Dans le cas du cloud computing , il doit
accorder la même confiance non seulement au développeur mais aussi à l’hébergeur,
ce qui rend le cloud encore plus dangeureux que le logiciel propriétaire.
20
3.2
Inconvénients politiques
Le cloud computing apporte de nombreux débats politiques qui forcent les
hébergeurs à s’adapter constemment à de nouvelles réglementations, devant la plupart du temps limiter l’accès à certaines zones (Amazon EC2 Availability Zone).
Aux États-Unis, les systèmes de cloud se confrontent par exemple au Patriot Act,
qui interdit aux société les proposant de stocker certaines données sur des serveurs
hors du territoire américain, de même qu’il leur faut bloquer par défaut certaines
requêtes (par exemple en ce concerne le système bancaire ou celui de santé).
On peut supposer que des sociétés comme Google ou Microsoft arriveront facilement
à s’accomoder de ces législations, mais la plupart des hébergeurs se retrouvent dans
des positions difficiles (comme par exemple l’organisation bancaire internationnale
SWIFT, qui veut mettre en place un datacenter en Suisse mais ne peut y faire traiter
que les données bancaires européenne).
De plus, des réglementations comme le Stored Communications Act (encore aux
États Unis), permettent aux gouvernements d’avoir un accès direct aux messages de
leur concitoyens et sont donc rebutés par des hébergements dans d’autres pays.
3.3
Forfaits actuellement proposés
Comme vu plus haut, les facturations des service de cloud sont aléatoires et assez
floues. En effet, et cela concerne surtout les société proposant du cloud Open
Source, le nombre de clients et d’utilisateurs est difficile (voire impossible) à obtenir,
les tarifs sont fixés sur des bases peu fiables et ne permettent pas pour un client
d’évaluer clairement le prix réel qu’il aura à payer.
Le problème est que deux types de facturations sont disponibles, la facturation par
nombre d’utilisateurs et la facturation par ressources utlisées.
21
– Facturation par ressources utilisées
La plupart des hébergeurs proposent des facturations basées sur les ressources utilisées. Le client va donc payer par nombre d’heures utilisées sur
une machine virtuelle, où, parfois, chaque heure commencée est facturée.
De plus, la plupart demande un paiement supplémentaire en fonction du
nombre de téléchargement (au Go, avec le même genre de piège pour les Go
commencés que pour les heures).
Dans le cas extrême, Microsoft Azure, on trouve même les prix suivants
(qui s’appliquent tous) :
– 0,12 dollar l’heure d’utilisation 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 données SQL (99,99 $ pour la version Business) ;
– 0,10 dollar par connexion à la base de données ;
– 0,15 dollar par Go de transfert avec la base de donnée ;
– 0,15 dollar par 100 000 opérations de message (DBus et jetons d’accès
inclus).
– Facturation par utilisateur
Une partie des fournisseurs de cloud fournit une facturation par nombre
d’utilisateurs. L’inconvénient de cette méthode (pourtant transparente) est
qu’elle ne prend pas en compte les ressources utilisées. En effet, un client
mettant en place plusieurs dizaines, voir plusieurs centaines d’applications,
payera le même prix au mois qu’un client ne disposant que des services de
bases et ne demandant quasiment pas de ressources (s’il a le même nombre
d’utilisateurs). Pour l’hébergeur, cette solution n’est pas viable car un client
peut facilement le faire devenir déficitaire si son nombre d’applications devient trop important.
Ainsi, les modes de paiements actuellement mis en place ne sont clairement pas
satisfaisants.
Prenons l’exemple d’une société ayant besoin d’un système de cloud pour envoyer 100 Go de données en 10 000 heures, elle devra payer 3 410 $ en utilisant le
service d’Amazon 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 données ont été transférées 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 précèdent sont des évaluations rapides de ce que devra payer la société,
mais ils ne prennent pas en comptes de nombreux paramètres difficiles à évaluer
(nombre de connections total pour envoyer les données, nombre d’appel à la base de
données, utilisation des CPUs, etc).
On peut cependant voir la complexité pour une entreprise d’évaluer ses factures sur
un moyen ou long terme ainsi que de définir l’hébergeur qui lui sera le plus rentable
en fonction de ses besoins.
3.4
Stress test
Une récente étude à montré que les plus grands systèmes de cloud (ceux d’Amazon, de Microsoft et de Google) présentent des variations du temps de réponse d’un
facteur 20, suivant l’heure d’accès. Cette même étude met en évidence de graves
problèmes liés à ces variations. Par exemple, le système de Google ne permet pas
d’opérations dépassant 30 secondes. De plus, les systèmes de monitoring(*) ne permettent pas d’étudier précisemment les origines de ces ralentissements.
Ainsi, la promesse des hébergeurs de fournir un accès au moins aussi rapide à un
cloud qu’à un système autre peut rapidement se révéler fausse en cas de grande
utilisation.
En effet, le stress test a révélé des taux d’erreurs montant jusqu’à 12%, comme on
peut le voir sur leurs résultats :
– http ://backoffice.ajb.com.au//images/news/amazonunswerrors.gif.
– http ://backoffice.ajb.com.au//images/news/googleunswerrors.gif.
23
4
Solutions libres
La plupart des hébergeurs proposent des solutions basées sur des logiciels Open
Source. Cependant, il est regrettable de constater un manque évident de transparence au niveau des forfaits proposés. Dans l’optique de fournir un service basé sur
des logiciels libres, il faut maintenant s’intéresser aux différents outils disponibles
pour chacun des composants du cloud . Evidemment, l’ensemble du code produit
doit être publié sous license libre (GPL v.3, License BSD), et ne s’appuyer que sur
des protocoles et des bibliothèques libres.
4.1
Côté client
On ne peut évidemment pas forcer un client à utiliser un logiciel libre pour accéder
au service fourni, mais des solutions libres peuvent lui être proposées. Pour pouvoir
accéder aux applications hébergées, il suffit d’un 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 s’effectuer par FTP et une interface de
test et de mise en production peut être envisageable (écriture ou envoi des sources,
compilation, test sur une adresse privée).
4.2
Services de base
Un ensemble de services de base est souvent fourni avec l’hébergement d’un cloud .
Parmis les plus courants, on trouve une messagerie (par exemple basée sur Postfix,
Procmail, Fetchmail, SpamBayes, Courier-imap, Mutt et SquirrelMail), un système
d’identité (OpenID), de paiement (Paypal, mais non-libre...), une messagerie instantannée (XMPP) et de recherche.
4.3
Applications
L’utilisateur peut accéder aux services du cloud par des applications autres que
l’explorateur. De même que pour l’explorateur, des solutions libres peuvent lui être
proposées. Pour les applications de bases, on peut citer :
– Messagerie : Thunderbird, Kmail, ...
– Identité : OpenID Enabled
– Chat : Pidgin, Gajim, Kopete, ...
Le reste dépend des applications proposées par le client (client FTP pour du transfert, lecteur audio/vidéo, ...).
24
4.4
Plateforme
La plateforme (chaque nœud de la grid ) est composé d’un système virtuel (Debian), avec des serveurs dépendant des langages utilisés (OpenJDK pour du code
Java, Django pour du Python, Mongrel ou Thin pour du Ruby). Elle peut être accompagnée de bibliothèques nécessaires au fonctionnement de l’application hébergée.
4.5
Infrastructure
L’infrastructure est le serveur frontal, et donc peut accueillir un système GNU/Linux
adapté comme Debian. S’il héberge aussi des nœuds de la grid , il utilise Xen
comme système de virtualisation. Il dispose évidemment d’un serveur web Apache.
25
5
Virtualisation
Le cloud computing dépendant fortement de la virtualisation, un bref rappel du
concept ainsi que des solutions majeures disponible s’impose. Pour une description
plus précise, regardez Livre blanc : Virtualisation.
5.1
Concept
La virtualisation permet d’émuler à partir d’un système réel sur une machine physique un ou plusieurs autres systèmes. On peut ainsi disposer de plusieurs systèmes
apparemment séparés, disposant chacun de leurs services. Plusieurs utilisations sont
possibles (posséder plusieurs versions d’un même logiciel, éliminer les conflits entre
logiciels, pouvoir jouer à des jeux Windows sous GNU/Linux, ...), mais le principal intérêt est de ne pas avoir, pour un hébergeur, à maintenir plusieurs serveurs
sous-exploités mais de rassembler plusieurs services sur une même 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 intégré au noyau Linux et basé sur QEMU.
Son avantage majeur par rapport à Xen est que le système utilisé comme
hyperviseur est en fait un système GNU/Linux, et donc l’équipe développant
KVM n’a pas à se soucier de cette partie. Il est facile d’utilisation, stable,
et de plus en plus utilisé (soutenu par Red-Hat), y compris pour ce qui est
de l’hébergement (Lost Oasis en France, Blue Room Hosting en Angleterre,
OpenHosting aux États-Unis, ...).
– Xen
Xen est moins facile d’accès mais plus puissant. C’est un système de virtualisation avec hyperviseur, ce qui veut dire que l’ensemble des ressources
matérielles sont partagées entre les machines virtuelles (et non monopolisées par le système principal). Le fait de devoir réimplémenter un système
pour l’hyperviseur permet de ne disposer que des fonctionnalités propres
à la virtualisation, et donc de fournir un système de virtualisation plus
efficace. C’est un excellent choix pour la virtualisation dans le cadre de
l’hébergement.
26
6
Étude du framework Vertebra
Vertebra est un framework permettant de superviser l’ensemble des processus et des
serveurs qui constituent un cloud . Il est publié sous license libre LGPL et permet
d’assurer sécurité, portabilité et tolérance aux pannes.
– Sécurité
Possibilité de gérer facilement des permissions par client ou par utilisateur,
possibilité de créer des liens entre plusieurs clouds utilisant Vertbra.
– Portabilité
Écrit pour pouvoir fonctionner sur sa propre architecture comme sur des
systèmes déjà existant (Amazon EC2 ou le VCloud de VMware).
– Tolérance aux pannes
L’arrêt non-prévu d’un ou plusieurs des composants principaux ne fait pas
s’arrêter l’ensemble du système, ils sont relancés et les autres composants
en dépendant attendent simplement leur disponibilité.
6.1
Fonctionnement
Un système 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 différents serveurs.
– Agent Herault
Assure la sécurité et le système d’annonces.
– Agent utilisateur
Vide par défaut, accueille les applications du client.
– Agent entrepôt
Permet de stocker les informations sur l’ensemble des utilisateurs (noms,
profils, mots de passe, ...).
– Agent cavalcade
Contrôle l’automatisation des processus.
– Agent sawmill
Permet un système de login distribué.
27
6.2
Interface
Afin de pouvoir administer son cloud , Vertebra est accompagné d’un shell propre
permettant une administration rapide et éventuellement automatisable. De plus,
grâce à cet outil, le client peut facilement développer ou faire développer une application graphique (utilisant le shell) pour administrer ses services en faisant des
appels aux fonctions de ce shell. Il est même enviseageable pour un hébergeur de
fournir une interface web au client donnant accès à l’ensemble des fonctionnalitées
proposées.
Enfin, on peut facilement et de manière invisible, donner l’accès à une personne à une
application du cloud , que ce soit une application classique ou éventuellement l’application d’administration, ce qui permet à un client de regrouper plusieurs systèmes
de ces systèmes hébergés sur différents comptes.
6.3
Intérêts
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
déployer, et une grande partie de son code est en Erlang, langage prévu pour tout
ce qui est communication réseau et avec lequel on désire travailler.
Il s’avère donc que Vertebra est un framework qu’il faut utiliser, ou au moins s’inspirer de ses fonctionnalitées, pour le service de cloud envisagé.
Il permet, grâce entre autre à son mode d’administration, de fournir au client un service à la fois complet et permettant un respect de ses libertés ainsi que la possibilité
de réunir son cloud avec celui d’un autre hébergeur.
28
7
7.1
Mise en place
Pré-requis
Étant donné qu’un système de stockage en cloud ne présente pas de difficulté
technique particulière (système de fichiers partagés avec éventuellement une base de
données permettant un accès plus rapide), nous allons nous concentrer sur la gestion
d’un service de cloud avec développement d’applications.
On veut aussi n’utiliser que des logiciels libres et que le code développé soit sous
license libre. On cherchera aussi à fournir au client la possibilité de développer ses
applications dans le langage de son choix.
Pour la gestion des serveurs d’applications, ils seront enregistrés dans une base
de données SQL, avec deux identifiants, un concernant l’application hébergée (pas
d’unicité) et un identifiant unique (incrémentation 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 données SQL (l’installation du système et la mise en place d’Apache et
de MySQL ne seront pas détaillées ici). Le but est de fournir un sytème qui, lors
d’une demande spécifique au cloud (lien vers une application, affichage d’une
application sur une partie de la page), lance le serveur hébergeant l’application s’il
est éteint ou surchargé, ou communique avec lui sinon.
Dans ce but, il faut écrire une fonction de lancement qui prend en argument un
identifiant de l’application (nom ou id) et qui effectue les actions suivantes :
– Vérifier les droits de l’utilisateur effectuant la demande ;
– Vérifier si une machine virtuelle correspondant à cette application à déjà été
lancée (requête à la base de données) ;
– Si aucune n’est présente, en lancer une et l’inscrire dans la base de données ;
– Si une ou plusieurs machines sont déjà lancées, vérifier leur capacité d’accueil
par le système de communication (décrit plus loin) :
– Si une des machines peut accepter une connexion, commencer la communication avec cette machine ;
– Sinon, lancer une nouvelle machine virtuelle, l’enregistrer dans la base de
données et commencer la communication.
29
Note : La principale différence entre le cloud computing et le reste des solutions techniques déjà existantes consiste en son système de communication entre les
machines ou entre les processus, lui permettant de fournir un réseau de machines dynamique (en fonction du nombre d’utilisateurs ou de la quantité de données stockées
ou utilisées). Un chapitre est donc dédié aux solutions possibles pour gérer ces communications.
Une fois la connexion établie, le serveur frontal peut envoyer les requêtes de l’utilisateur à la machine virtuelle et soit recevoir les informations demandées (par XMPP)
et les afficher, soit afficher directement le serveur d’applications 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 système à un utilitaire en ligne de commande
de type SVN ou Git, ou un système interactif accessible par un explorateur (avec
un système d’envoi des sources ou des binaires), de lancement sur un serveur privé
de tests, puis de mise en production. Il faut aussi intégrer un moyen pour le client
de donner des droits sur ses applications pour pouvoir limiter l’accès de certaines
applications aux seules personnes concernées.
7.3
Machines virtuelles
Les machines virtuelles accueillant les applications du client sont hebergées sur un
ensemble de serveurs permettant la virtualisation. On utilise Xen comme système
de virtualisation (encore une fois, se référer 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 système
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 = réseau (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 liés au(x) langage(s) dans
le(s)quel(s) est écrite l’application. Voici les solutions libres pour quelques langages :
– Ruby on Rails
– machine virtuelle exécutant le code : YARV, sous license libre Ruby ;
– serveur d’applications : Thin, basé sur Mongrel, sous license libre Ruby.
– Java
– machine virtuelle : JVM, sous license libre à partir de la version 7 ;
– serveur d’applications : JBoss application server, sous license GLPL.
– Erlang
– serveur web : Yaws ;
– interpréteur erlang.
– Python
– framework django.
7.4
Compatible libre ?
Pour résoudre les problèmes éthiques liés au cloud computing , de nombreux
choix peu ou pas proposés par les autres hébergeurs sont à mettre en œuvre.
Pour ce qui est de la visibilité du système, 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 l’utilisation des images dévoilées, il faut mettre en place un système de
monitoring permettant de publier en temps réel les serveurs étant en fonctionnement
et les applications lancées dessus.
Du côté du client, il faut lui donner un accès direct à l’ensemble de ses données et
lui assurer une transparence totale sur le système de sauvegardes (avec accès sur les
machines les hébergeant).
D’un point de vue des forfaits, il faut éviter les forfaits pièges proposés par la majorité
des hébergeurs. 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 présenter de risques pour l’hébergeur. On peut envisager, dans
ce but, un forfait basé uniquement sur le nombre d’applications et d’utilisateurs,
permettant ainsi un prix assez stable dans le temps (ne dépend pas du nombre de
données transitées, du nombre de connexions, ...) et reflétant bien l’utilisation du
cloud (son utilisation dépendant principalement du nombre d’utilisateurs, et le
matériel requis du nombre d’applications proposées).
31
8
Communication
Le but de ce chapitre est d’étudier le moyen le plus avantageux pour effectuer la
communication entre le serveur et les machines virtuelles accueillant les applications.
Plusieurs moyens peuvent être mis en oeuvre :
– Utilisation du protocole XMPP avec un bot par machine ;
– Utilisation du système de message passing du Erlang ;
– Utilisation du protocole TCP avec un système client/serveur écrit en Erlang.
Le protocole XMPP est un standard ouvert qui présente plusieurs avantages (serveur inclus dans le framework Vertebra, système Publish/Subscribe, existence d’une
bibliothèque efficace en Erlang). De plus, les communications sont effectuées par
échange de documents XML, ce qui permet par exemple un passage d’objet(*) efficace ainsi qu’un bon système de passage de directives.
Le message passing de Erlang est aussi avantageux car il est extrêmement
simple à mettre en place (quelques lignes de code pour le squelette du server, une
ligne pour un envoi de message). De plus, il présente des performances excellentes
(comparaison Erlang/Java). Enfin, son utilisation peut servir à passer des objets de
façon assez intuitive.
Enfin, le protocole TCP ne présente aucun avantage particulier, mais servira d’outil
de comparaison classique pour évaluer les deux précédents.
8.1
XMPP
Présentation
XMPP (Extensible Messaging and Presence Protocol) est un protocole d’échange
de documents XML. Dans le but de ne pas dépendre d’un fournisseur, un serveur
XMPP peut être mis en place à l’intérieur d’une société ou chez un particulier. Il
existe des moyens puissants de sécuriser 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 instantanée consiste à transformer
XMPP en moyen d’observer et d’administrer un serveur à distance. En effet, en
envoyant un message formaté de façon prédéfinie par le possesseur du serveur, il est
facile de lui passer des commandes. Voici un exemple fictif et excessivement simple
pour provoquer l’arrêt d’un serveur :
<?xml version="1.0" encoding=’UTF-8’?>
<halt>
<delay>
15min
</delay>
</halt>
Ici, si le serveur à été correctement configuré, il peut comprendre qu’il doit s’arrêter
dans 15 minutes. Évidemment, cet exemple ne présente aucune sécurité. Si une
personne quelconque envoie ce message, le serveur s’éteindra. On peut alors limiter
l’exécution de telles commandes à certaines adresses du réseau ou à certaines identité
(gérées par XMPP), la sécurité sera alors assurée par l’identification du bot (*)
ou de l’administrateur auprès du serveur ejabberd.
De plus, le XML est un moyen pratique de communiquer un objet d’un ordinateur à
un autre, de sauvegarde d’objets, ou même de modification d’objets sans passer par le
langage utilisé, ce qui le rend très intéressant dans un système de cloud , surtout
si on rajoute le fait que les messages peuvent être envoyés par HTTP, facilitant
encore plus la communication dans le cadre d’un serveur web d’applications.
Enfin, XMPP permet un système de Publish/Suscribe, c’est-à-dire un moyen de publier des messages dans un système de classes sans savoir qui (comprendre : quelle
autre machine) est intéressé par la réception de ce message. On peut donc diffuser
un message à un ensemble de serveurs, sans se préocupper de la réception. Ainsi,
ce système permet de diffuser à la fois des informations de maintenance ou de surveillance et des messages contenant des ordres ou du transfert d’objet entre serveurs
(un serveur vers l’ensemble des serveurs intéressés ).
Utilisation
Un serveur Jabber doit être utilisé pour permettre une communication basée sur
le protocole XMPP. Il serait envisageable d’utiliser un des nombreux fournisseurs
(gratuits) de comptes jabber. Cependant, afin d’assurer une plus grande sécurité et
surtout une plus grande réactivité, il est préférable d’installer son propre serveur
Jabber.
Comme le but est d’implémenter une partie du code en Erlang, le choix le plus
judicieux est d’utiliser ejabberd, un serveur Jabber libre, écrit exclusivement en
Erlang.
33
Les points importants du fichier de configuration (/etc/ejabberd/ejabberd.cfg) sont :
– {hosts, ["your.host.name"]}. : définit le nom du serveur auquel l’on
pourra se connecter.
– {acl, admin, {user, "user name", "localhost"}}. : définit l’administrateur du serveur.
– {s2s use starttls, true}. : force la connexion sécurisée.
– {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 l’administrer (ajout d’utilisateur, sauvegarde des utilisateurs, ...),
et utiliser iptables pour limiter l’accès au serveur uniquement aux systèmes faisant
partis du cloud pour assurer une meilleure sécurité (Cf. figure 5).
Un système de
cloud peut par exemple disposer des utilisateurs suivants :
– frontserver : utilisé par un daemon(*) recevant et traitant les demandes
effectuées auprès du serveur frontal.
– monitor : utilisé par un daemon (pas forcément lancé sur le serveur frontal),
recevant l’ensemble des informations constituant les logs et le service de
monitoring.
– appserver n : utilisé par un daemon lancé sur la n-ième machine accueillant
les applications, traitant les ordres que lui passent, principalement, le serveur
frontal.
Il faut définir l’ensemble des commandes qui peuvent être envoyées. Dans un premier
temps, le serveur frontal (qui recoit les demandes des utilisateurs), peut envoyer vers
les machines virtuelles accueillant les applications les requêtes suivantes :
– create name : crée une VM complète pour l’application ’name’.
– delete name : supprime l’ensemble des fichiers et des configurations pour
l’application ’name’.
– start time : démarre les services nécessaires, time étant la planification du
lancement (now, in n minutes, at hour :minute...), renvoie une confirmation.
– halt time : idem pour l’arrêt.
– reload time : idem pour le redémarrage des services.
– whoisthere : envoie la liste des personnes connectées au services et le nombre
total de personnes.
– status : envoie le status des services (up, inaccessible, down, erreur, ...).
– uptime [VM/services] : envoie la durée depuis laquelle la machine est lancée,
celle depuis laquelle les services sont accessibles.
– ping : attend ”pong” comme réponse.
34
Cette liste n’est évidemment pas exhaustive. La deuxième série de requêtes concerne
des communications entre machines virtuelles accueillant une même application distribuée ou un ensemble d’applications connéctées. Les commandes seraient alors les
mêmes avec, en plus, des commandes spécifiques à ces applications et pouvant alors
utiliser toutes les possiblités du XML, et en particulier la facilité à passer des objets.
8.2
Message passing Présentation
Le langage Erlang est muni de base d’un système de message passing intuitif.
Le message passing est un moyen d’envoyer des messages, informations, ordres,
données, d’un processus à un autre. Il est intuitif car son écriture est simplifiée :
Pid ! Data
Les données envoyées sont souvent des tuples(*) dont le premier est le Pid(*) de la
fonction qui envoie le message, ce qui permet à la fonction réceptrice d’envoyer un
accusé de réception, ou simplement de continuer la communication avec l’émetteur.
Pour obtenir son Pid, une fonction fait simplement appel à la fonction :
self()
Le nombre d’élements dans le tuple est libre, ce qui permet de pouvoir facilement
envoyer des objets. On peut envoyer (exemple extrêmement 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 l’ensemble des valeurs des attributs d’un objet, on peut le sauvegarder sur un
serveur de stockage.
De même, pour passer une commande à effectuer, on peut tout à fait envisager le
même système de communication, ce qui fait du message passing une réelle
alternative au protocole XMPP et à son transfert de XML (Cf. figure 4).
Utilisation
Les exemples précédents ne fonctionnent que dans le cas d’une communication interne à une machine. Pour pouvoir envoyer des messages entre deux processus lancés
sur deux machines distinctes, certaines manipulations supplémentaires sont à effectuer.
35
Tout d’abord, il faut lancer l’interpréteur 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̀ l’interpréteur lancé sur la machine
hostname .
–
- setcookie cookie_name
assigne le cookie(*) cookie name à l’interpréteur. Les cookies doivent
être identiques sur tous les nœuds qui veulent pouvoir communiquer.
–
- pa / path / to / binary
permet d’utiliser les fonctions compilées et dont les fichier .beam sont placés
dans /path/to/binary.
Une fois cela fait, les processus enregistrés 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 nœud émetteur et le
nœud accueillant la fonction enregistrée, 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 être n’importe quel type de variable, en particulier des
tuples contenant autant de variables que nécessaire, tout comme le XML et ses
méthodes pour envoyer des objets.
36
8.3
Comparaison des deux méthodes
Implémentation
Les deux méthodes de communications envisagées sont simples à implémenter.
Le Message Passing étant une fonctionnalité native de Erlang, il est d’autant plus
simple à implémenter (une ligne pour enregistrer la fonction, une ligne pour effectuer
un ping , une ligne pour envoyer le message).
Pour ce qui est de l’utilisation du protocole XMPP, la bibliothèque exmpp pour
Erlang a été retenue. Elle est efficace, et facile à prendre en main, même si la seule
documentation fournie (projet récent) est celle issue de la compilation (le code est
cependant très bien commenté).
Le seul réel problème d’implémentation concerne le protocole XMPP et l’utilisation
d’exmpp. En effet, Erlang, et le concept de langage fonctionnel pur de manière
générale, n’est pas forcément le mieux adapté au format XML car on ne peut pas
modifier les variables sauf à l’instanciation. Ainsi, sur certaine fonctions d’envois de
messages, on peut se retrouver avec 6 ou 7 variables, chacune étant une modification
mineure de la précédente. Si cela ne semble pas poser de problème d’un point de vue
de la mémoire ou du temps d’execution, cette approche n’est pas évidente pour un
développeur habitué à la programmation itérative. Cependant, ceci est un problème
mineur qui est rapidement résolu (lecture du code de exmpp, écriture de fonctions
basiques de retouche de messages reçus, ...)
Test basique de charge
Le premier test à avoir été efféctué était 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 l’envoi et la réception de 1 000 000 000 de messages.
Par contre, la réception des messages envoyé par le protocole XMPP a montré des
résultats beaucoup moins bons : pour un envoi de 1 000 messages (envoi quasiinstantané), le récepteur met plus de 2 minutes 30 avant de recevoir le dernier. En
effet, les messages semblent arriver par groupe d’une dizaine avec un temps d’attente
entre chaque groupe.
Ainsi, le premier test, certes basique et peu représentatif (utilisation de la configuration par défaut d’ejabberd), était clairement au désavantage du protocole XMPP.
Cependant, un simple test de charge, avec un envoi anormalement massif de messages ne pouvait pas être le seul moyen de décision.
37
Maquettes fonctionnelles
Après ce test basique, deux maquettes fonctionnelles, minimalistes, ont été réalisées.
Les deux étaient hebergées sur les mêmes machines virtuelles, utilisaient yaws comme
serveur web, affichaient les mêmes pages. La première utilisait le système de Message
Passing et la deuxième le protocole XMPP (deux schémas expliquent le fonctionnement ci-dessous).
Les deux maquettes utilisaient chacune deux machines virtuelles, l’une jouant le
rôle du serveur frontal, l’autre celle d’un serveur d’application. L’application qu’il
hébergeait était un simple hello world (puis un afficheur d’heure).
Concernant la réactivité, les deux étaient, d’un point de vue de l’utilisateur, similaires. Elles permettaient un affichage aussi rapide que pour un simple site hebergé
sur un serveur unique. D’un point de vue du développeur, il a fallu mettre un delai
supérieur avant la redirection (temps d’attente écrit en dur pour que le message
arrive et que le serveur web se lance sur le serveur d’application) dans le cas de la
maquette XMPP. Cependant, ce délai supplémentaire est négligeable (de l’ordre de
la centaine de milliseconde).
Pour ce qui est des possibilités et de la clareté dans le schéma de communication,
c’est là que XMPP dévoile ses possibilités. En effet, il est beaucoup plus clair d’avoir
un client jabber par machine présente dans le cloud , avec en plus des clients
particuliers pour certaines tâches (monitoring, envoi de message ne demandant pas
de réponse, ...), plutôt que des fonctions enregistrées dans un interpréteur identifié
par un cookie.
Malgré ce que l’on peut voir sur le schéma, le bot XMPP qui répartit l’ensemble des
requêtes n’est pas forcément lancé sur le serveur frontal. De même, le serveur ejabberd et le bot de monitoring était hébergés sur le serveur frontal dans la maquette
réalisée, mais ceci n’est pas nécessaire (on peut, par exemple, dédier une machine
complète pour le contrôle 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 envisagés sont tous les deux performants et globalement faciles à implémenter. L’utilisation du protocole XMPP ralentit légèrement
la réception, et donc le traitement, des messages. Le Message Passing quand à lui
est d’une facilité d’implémentation et d’une efficacité sans pareil.
Cependant, l’utilisation du protocole XMPP permet non seulement de clarifier le
réseau, de centraliser la gestion des requêtes et d’envisager l’utilisation de capacités
déja développées (système de publish/subscribe, système de présence, ...) ou de
profiter de l’aspect extensible du protocole pour développer des extensions dédiées
au cloud (module de publication de l’état d’une machine virtuelle, ...).
Au final, malgré une certaine lenteur par rapport au Message Passing, c’est l’utilisation du protocole XMPP qui semble la plus appropriée. En effet, ce protocole (qui
est un standard ouvert), est assez réactif pour que ne pas ralentir le cloud de
manière abusive. De plus, c’est lui qui permet la plus grande extensibilité. Enfin,
le schéma de déploiement des bots XMPP correspond au schéma d’organisation du
cloud , ce qui permet de clarifier le code d’une part, et d’éviter une duplication
de code (seul un bot reçoit les requêtes, les traite, et envoie des demandes spécifiques
aux bots des serveurs d’applications).
41
9
Load Balancing
Le deuxième aspect particulier du cloud est son système de répartition des
charges et la gestion dynamique des machines qui le composent. En effet, dans un
cloud on trouve non seulement un système de répartition de charge classique (pour lequel des solutions existent déjà), mais surtout un système de
détection des besoins : le cloud réagit en fonction des demandes des utilisateurs,
gérant les machines accessibles (comprendre ici : les machines virtuelles démarrées)
pour minimiser leur nombre et maximiser la réactivité des différents services. Cet
algorithme est très utilisé et répond totalement totalement aux attentes d’un algorithme de répartition de charges dans un cloud (facilité d’implémentation et
répartition équitable).
9.1
Gestion dynamique des machines virtuelles
Pour proposer un service de cloud computing performant et cohérent avec le
concept, il faut fournir un système de gestion dynamique des machines disponibles.
En effet, si peu d’utilisateurs se connectent au cloud , il n’est pas utile d’avoir
une multitude de serveurs lancés et sous-exploités. À l’inverse, si de nombreux utilisateurs tentent de se connecter au service simultanément, ils ne doivent pas observer
un service ralenti. Pour pouvoir assurer ce service, le fournisseur doit posséder un
système de lancement et d’arrêt de machines coordonné avec les demandes.
Ainsi, quand le premier serveur (frontaux, SQL ou d’application) a atteint ses capacités maximales, un deuxième serveur est lancé, et les requêtes sont alors réparties
équitablement entre les deux serveurs présents. Quand les n serveurs présents ont atteint leur capacités maximales (de manière globale), on lance un (n+1)-ième serveur,
et on réparti les requêtes sur les n+1 serveurs.
Certains fournisseurs gèrent les machines disponibles grâce à un système interactif,
potentiellement mis à disposition du client, mais cela implique une présence humaine
dédiée de manière quasi-permanente à la surveillance du cloud . Le système le
plus judicieux et le plus avantageux est d’implémenter un monitoring automatique
du cloud et de lui faire gérer le lancement et l’arrêt des serveurs. Évidemment, un
tel système sera surveillé et mis à jour pour que ses performances soient maximisées,
ce qui implique un présence humaine (au moins les premiers temps).
42
Il y a trois types de serveurs à gérer dynamiquement :
– L’ensemble des serveurs frontaux.
– L’ensemble des serveurs SQL.
– L’ensemble des serveurs d’application.
Serveurs frontaux
Pour définir le besoin d’ajout ou de suppression de serveurs frontaux, on doit étudier
le temps de réponse du serveur web à une demande classique. Le serveur frontal
n’hébergeant aucune application, il suffit donc d’étudier son temps de réponse sur
une simple requête (un ping par exemple). Si le temps de réponse est anormalement long, le système de monitoring fait une requête pour lancer un serveur frontal
supplémentaire (la gestion de multiples serveurs pour un service unique sera traité
dans la partie suivante). Si le temps est normal ou acceptable, rien n’est efféctué.
Enfin, si le temps est anormalement court, le système de monitoring peut demander
la suppression d’un ou plusieurs serveurs frontaux. Tout le problème est de définir
anormalement long et anormalement court . Ces limites sont globalement
arbitraires et dépendent des capacités de l’hébergeur et des demandes du client.
Serveurs SQL
Concernant l’ajout ou la supression de serveur SQL, il faut étudier le temps de
réponse de la base de données, en effectuant, par exemple, une ou plusieurs requêtes
pré-définies et en étudiant le temps de réponse de la base. À partir des résultats,
et en appliquant le même principe que pour les serveurs frontaux en comparant le
temps de réponse de ces requêtes à des valeurs arbitraires fixées.
Différentes répartitions sont envisageables :
– plusieurs serveurs gérant chacun une partie des données d’une application ;
– plusieurs serveurs sur la même base de données avec un système complexe de
mise-à-jour lors des écritures et/ou une séparation des serveurs permettant
la lecture et ceux permettant l’écriture.
43
Serveurs d’application
Enfin, pour les serveurs d’applications, le calcul peut être plus compliqué. On doit
non-seulement évaluer le temps de réponse du serveur web qui efféctue l’affichage
comme sur les serveurs frontaux, mais aussi différentes valeurs qui, dans le cas de
l’hébergement d’une application, deviennent significatives (utilisation du CPU, occupation de la mémoire, charge, ...). On peut aussi pondérer ces valeurs pour fournir
une évaluation simple (par exemple un score compris entre 0 et 100) dans le but
de clarifier les cas de lancement ou d’arrêt des serveurs. De même que les valeurs
arbitraires des deux premiers cas, la pondération est arbitraire et dépend des besoins
du client, des capacités du fournisseur mais aussi de l’application elle même.
Le lancement de serveurs supplémentaires ainsi que l’arrêt de serveurs superflus (du
moins les algorithmes retenus ici) reposent donc entièrement sur des valeurs fixées.
Le plus important dans l’implémentation est donc la gestion de ces valeurs :
– valeurs pour les serveurs frontaux à ajuster selon les besoins du client et les
capacités du fournisseur,
– valeurs pour les serveurs SQL à ajuster selon les mêmes critères,
– valeurs pour les serveurs d’application à ajuster séparément pour chaque
application en prenant en compte :
– les besoins du client concernant cette application,
– les capacités du fournisseurs,
– les demandes de l’application en ressource.
9.2
Load balancing, HAProxy et round-robin
Load balancing
Une fois le nombre de machines virtuelles adéquat atteint, il faut répartir les demandes entre ces machines. C’est le principe de load balancing à proprement
parler.
De nombreux outils existent pour répartir la charge entre plusieurs serveurs, de
même que plusieurs algorithmes de répartition.
44
On peut effectuer du load balancing à plusieurs niveaux du modèle OSI(*) :
– Couche 7 : la couche application , on peut forcer des redirections vers
d’autres adresses IP, comme par exemple avec l’utilisation du mod proxy de
apache (directive BalancerMember) ou HAProxy, détaillé plus loin.
– Couche 4 : la couche transport , en redirigeant dès l’arriver de la requête
(sans passer par la couche applicative ), avec l’utilisation de Linux Virtual
Server (LVS), solution de virtualisation pour cluster de serveurs.
Voici quelques uns des différents algorithmes :
– Redirection aléatoire : envoie des requêtes vers un des serveurs disponibles
de manière aléatoire. Ce système est simple à implémenter, mais n’est pas
efficace.
– Round-robin : effectue une rotation régulière de l’adresse IP du serveur qui
va recevoir les demandes. Cet algorithme est implémenté dans la totalité
des système de load balancing et peut facilement être amélioré par une
allocation de poids à certaines IP.
– Moins utilisé : le byrequest où le serveur qui a reçu le moins de connexions
reçoit la suivante. Déstiné à de longues sessions.
– bybusiness : redirection vers le serveur le moins utilisé.
– source : effectue un hash sur l’adresse du client pour l’assigner à une adresse
IP. Cet algorithme permet d’assurer qu’un même client se connectera toujours à un même serveur.
Round-robin
Le Round-Robin est un algorithme d’ordonnancement mais dont le principe a été
adapté à la répartition de charge. Le Round-Robin de base fournit une répartition
équitable entre plusieurs serveurs, ce qui veut dire que les serveurs doivent tous être
identiques pour une efficacité optimale. Cependant, le Round-Robin pondéré n’est
pas beaucoup plus compliqué à implémenter et présent dans la plupart des logiciels
de répartition de charge.
HAProxy
HAProxy est un logiciel libre (HAPROXY’s license) de répartition 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 d’un 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 système de load balancing en lui même est simple à mettre en place car des logiciels existent déjà pour le gérer. HAProxy semble être la solution idéale : simple
à configurer, à re-configurer, capable de gérer la répartition à plusieurs niveaux,
présentant une très bonne sécurité (pas une faille de sécurité en sept ans), et,
évidemment, libre.
Le réel problème dans le cas du cloud computing est la dynamicité du réseau et
la manière de la gérer. Il faut en effet être capable d’adapter le réseau aux demandes
des utilisateurs, c’est-à-dire ajouter des serveurs supplémentaires nécessaires à de
nombreuses requêtes ou en supprimer si la demande est faible. Le moyen le plus
simple est de gérer manuellement les capacités du réseau, et donc de faire lancer ou
arrêter les serveurs par un humain. Cependant, cette approche est coûteuse tant d’un
point de vue temps que d’un point de vue moyens, il est donc préférable de mettre
en place un service automatisé de gestion du réseau qui vérifie de manière régulière
les capacités de réponse du cloud et qui l’ajuste aux besoin des utilisateurs.
Une telle gestion du réseau présentera des incohérence et demandera des adaptations dans les premiers temps de la mise en production d’un cloud . La présence
humaine reste donc une obligation, mais seulement le temps d’ajuster ce système
aux besoins propres à un service de cloud .
46
Figure 6 – HAProxy
47
Conclusion
Le cloud computing est une mode récente où de plus en plus de clients ont
tendance à s’engouffrer, et donc de nombreux hébergeurs ont mis en place des propositions de solutions de cloud . Pourtant, ces propositions présentent toutes (ou
quasiment toutes) des aspects inadmissibles du point de vue de l’éthique du libre
(forfaits, systèmes proposés sans aucun moyen de contrôle), ou simplement trop
flous.
Pourtant, un cloud peut présenter des intérêts évidents pour une entreprise.
Grâce à un tel système, elle peut proposer un ensemble d’applications à ses employés
sans avoir à se soucier de sa maintenance ou son administration, tout en ayant l’assurance d’un système moins consommateur (la quantité des ressources doit s’adapter
à l’utilisation du cloud ) et donc plus économe (l’abonnement doit être fonction
des capacités mises en place). Certaines peuvent même utiliser le cloud pour
commercialiser un service par le biais d’applications web. L’utilisation du libre (et
surtout un total respect de son éthique) permettrait d’assurer un double objectif :
– Apporter une vision du cloud computing nouvelle par sa transparence,
ce qui améliorerait l’image d’une telle technologie dans l’esprit de la communauté libriste et qui forcerait peut-être une évolution des offres déjà existante.
– Fournir aux clients une réelle garantie sur la façon de traiter leurs données,
leur assurer un réel contrôle sur elles, et donc pouvoir enfin profiter des
possibilités techniques qu’apporte le cloud computing sans devoir faire
preuve d’une confiance aveugle en l’hébergeur.
48
Particularités
La différence principale entre un système de cloud et un hébergement classique est la gestion du réseau complexe qui le compose, gestion principalement
fondée sur deux points :
– La communication entre les serveurs : pour assurer le lancement, l’arrêt,
la communication de données entre les machines, il faut mettre en place
un système de communication complet (pour permettre, par exemple, du
passage d’objet) et automatisable (et donc définir une grammaire des ordres
que les serveurs peuvent s’envoyer).
– Le système de Load balancing : qui permet de gérer l’état du cloud en
fonction des demandes des utilisateurs, soit automatiser le lancement, l’arrêt
ou la modification de capacité des serveurs en fonction de leur temps de
réponse. C’est en ce sens qu’un cloud se distingue d’un système de
grid computing .
Pour assurer ces deux systèmes, les choix retenus sont :
– L’utilisation du protocole XMPP, hébergé par un serveur ejabberd, et une
implémentation des bots en Erlang grâce à la bibliothèque exmpp.
– L’utilisation du logiciel HAProxy pour effectuer le Load balancing, avec une
implementation complète du ou des scripts analysant le besoin du réseau et
demandant l’ajout ou la suppression de serveurs.
La gestion dynamique du réseau est le point le plus obscur à mettre en place. En
effet, cette gestion demande une analyse complexe de l’état des serveurs, qui dépend
du rôle du serveur observé, de ses capacités, de son état (utilisation des ressources,
nombre de connexions, ...) et. évidemment, des capacités disponibles chez l’hébereur
ainsi que les demandes particulières du client (demande de maximisation de la qualité
de réponse, de minimalisation des coûts, ...).
Une approche extrêmement basique de voir ce problème est de faire un appel à un
serveur, d’étudier son temps de réponse, et d’en déduire l’action à effectuer :
– Si le temps de réponse est trop court, on demande l’arrêt de serveurs.
– Si le temps de réponse est suffisant, on ne fait rien.
– Si le temps de réponse est trop long, on demande le lancement de serveurs
supplémentaires.
49
Dans le but de fournir un ensemble de scripts répondant de manière optimale à
ce problème, il faut séparer les différents serveurs suivants leurs rôles et adapter le
script basique :
– Les serveurs frontaux doivent assurer un temps de réponse correcte aux
requêtes HTTP.
– Les serveurs de bases de données doivent assurer une très grande rapidité
aux requêtes SQL.
– Les serveurs d’application doivent assurer un temps de réponse correcte aux
requêtes HTTP ainsi qu’une capacité de calcul constante.
L’avantage 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̀
être arrêté.
Vision libriste
Malgré tous les points négatifs non-réfutables formulés à l’égard du cloud computing , le fait de s’opposer aux hébergeurs fournissant un service, comme le soulève
Stallman, qui va à l’encontre des libertés du client et de l’utilisateur n’est pas
négligeable. Le pire étant que certains de ces fournisseurs privateurs le font
en basant leur publicités sur l’utilisation de logiciels Open Source, prouvant une fois
de plus la différence fondamentale entre ces deux mouvements.
De plus, après de nombreuses recherches et réflexions sur le concept, des moyens
divers peuvent être mis en place pour libérer le cloud . En effet, il est tout
à fait envisageable de fournir :
– Une architecture totalement libre (système d’exploitation, logiciels et code
mis en place par l’hébergeur).
– Un monitoring complet et permanent des serveurs qui constituent le cloud .
– Un moyen simple d’accéder à ces serveurs pour effectuer un monitoring local.
– L’ensemble des images qui sont utilisées comme images système (dans le
cadre de la virtualisation).
Le principal point à développer et à mettre en avant est l’accessibilité et le contrôle
par le client (et à un certain niveau par l’utilisateur) sur ses données, ainsi qu’un
moyen pour lui de les sécuriser vis-à-vis de l’hébergeur, et qu’il n’ait à aucun moment
de doute sur leur utilisation ou leur visibilité.
50
Inconvénients
En plus du côté buzz médiatique du cloud , cette technologie présente des
inconvénients dont il faut être conscient en tant qu’hébergeur :
– D’un point de vue éthique du libre, le cloud reste déviant d’un des objectifs du monde du libre, permettre aux utilisateurs de se réapproprier l’outil
informatique (mais n’est pas, alors, pire qu’un hébergement classique ).
– Le cloud doit se plier à des lois spécifiques variant d’un État à l’autre,
rendant difficile, par exemple, certaines migrations.
– Les facturations actuelles des services sont à la fois complexes et désavantageuses
du point de vue du client, ce qui force soit à proposer une facturation
irrespectueuse pour le client, soit à se démarquer nettement des autres
hébergeurs.
– Les systèmes de cloud actuels présentent des failles d’un point de vue
de la qualité, un nouveau type d’hébergement se doit donc de pallier ces
faiblesses pour pouvoir marquer une réelle évolution.
Ces inconvénients (au moins pour les deux derniers points) sont des contraintes pour
lesquelles les solutions n’existent pas encore (ou du moins ne sont pas majoritaires),
et sont donc les points clés pour une nouvelle offre de cloud .
Bilan
Au final, plusieurs points ammène à vouloir proposer une offre de
cloud :
– profiter du côté buzzword ;
– proposer une vision du cloud respectueuse de l’éthique du libre ;
– pouvoir adapter certains aspects de cette technologie aux services actuels
(les implémentations, scripts de lancement de serveurs, load balancing, communication XMPP, sont totalement réutilisables).
51
Glossaire
AFS
Andrew File System : système d’archivage distribué.
Bot
Programme informatique effectuant des tâches automatisées (réponses automatiques
et/ou traitement de messages par exemple).
Cookie
Fichier stocké par le navigateur sur le disque de l’internaute, permettant d’enregistrer des informations et de les communiquer au site visité.
Daemon
Processus s’exécutant en arrière plan de manière permanente.
Framework
Ensemble de bibliothèque permettant le développement d’applications.
Modèle OSI
Modèle de communication entre ordinateurs proposé par l’ISO.
Monitoring
Surveillance et mesure d’un ensemble de processus.
Objet
Définition de caractéristiques propres à un élément informatique.
Pid
Process Identifier : Code unique attribué à un processus.
SASL
Simple Authentication and Security Layer : cadre d’authentification.
SSL / TLS
Secure Sockets Layer ou Transport Layer Security : protocole de sécurisation des
échanges sur Internet.
Virtualisation
Technique permettant de faire fonctionner sur une seule machine un ensemble de
systèmes d’exploitations.
52
Table des figures
Table des figures
1
Fonctionnement du
2
Fonctionnement détaillé . . . . . . . . . . . . . . . . . . . . . . . . . 14
3
VM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4
Communication par Message Passing . . . . . . . . . . . . . . . . . . 39
5
Communication par protocole XMPP . . . . . . . . . . . . . . . . . . 40
6
HAProxy
cloud . . . . . . . . . . . . . . . . . . . . . .
7
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
53
Bibliographie
Wikipedia - Cloud Computing
URL
Wikipedia - Load Balancing
URL
Wikipedia - Load Balancing
URL
Site officiel d’Erlang
URL
Création 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 différentes 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

Etat de l`art du Cloud Computing et adaptation au

Transcription

Documents pareils

Fiche syst`eme d`assainissement 2014 St

Fiche syst`eme d`assainissement 2014 CETTE EYGUN (EYGUN

Rolls-Royce Silver Cloud III

Tél : 01 39 69 73 70 - Mairie de La Celle Saint

cloud, saas, en ligne

Fiche système dàssainissement 2014 CREON DÀRMAGNAC

Auto-organisation et chaos spatiotemporel pour un modèle proie

Fiche syst`eme d`assainissement 2014 BISCARROSSE (CAMPING