Cloud

Les exp´erimentations r´ealis´ees avec TUNe dans les domaines pr´ec´edents nous ont conduit vers un domaine beaucoup plus complet et complexe qu’est le cloud. Comme nous l’avons pr´esent´e dans la section 3, le cloud dans son ensemble (IaaS et appli- cations entreprise) repr´esente un cas d’administration dans lequel l’utilisation d’un SAA apparaˆıt ´evidente. Ainsi, nous pr´esentons dans cette section une tentative d’uti- lisation du syst`eme TUNe pour l’administration du cloud dans son ensemble. Sans reprendre la pr´esentation de l’administration dans le cloud r´ealis´ee dans la section3, nous nous appuyons sur cette derni`ere pour effectuer notre ´etude. Plus pr´ecis´ement, cette ´etude pr´esente les limitations du syst`eme TUNe pour l’administration dans le cloud.

Probl`eme 3.1

Administrer le cloud dans son ensemble avec TUNe revient `a ex´ecuter plusieurs instances de TUNe par niveau d’utilisation : une instance pour l’administration de l’IaaS et plusieurs instances (`a raison d’une instance par entreprise) pour l’admi- nistration des applications entreprise. Reposant sur la collaboration entre les deux niveaux, l’administration du cloud implique ´egalement la collaboration/interop´e- rabilit´e entre les instances de TUNe de niveau entreprise et l’instance de TUNe de niveau IaaS.

Probl`eme 3.2

Comme les environnements de grille, l’IaaS peut ˆetre constitu´e d’un grand nombre de ressources. Ces derni`eres peuvent ˆetre r´eparties dans plusieurs localit´es (cas d’Amazon EC2 avec X localit´es). Dans ce contexte, l’utilisation de TUNe est pro- bl´ematique et rejoint la situation d´ecrite dans le Probl`eme 1.3 de la section 5.4.2.

Probl`eme 3.3

L’instance TUNe de niveau IaaS administre des ´el´ements de diverses natures : des serveurs assurant les services de base de l’IaaS (facturation, stockage de don- n´ees, r´eseaux, etc.), des VM qui servent de support d’ex´ecution pour les applications entreprise, et des ´equipements mat´eriels. Dans le processus d’administration, le d´e- ploiement des serveurs et celui des VM n’est pas r´ealisable de la mˆeme mani`ere. On retrouve le mˆeme probl`eme que nous avons ´evoqu´e dans la section 5.4.2(Probl`eme 1.2).

5.4. EXP ´ERIMENTATIONS ET PROBL ´EMATIQUES 51 Probl`eme 3.4

Comme toute plateforme informatique, les op´erations de maintenance font partie du cycle de vie du cloud. Ces op´erations peuvent entraˆıner la mise en indisponibilit´e partielle ou totale d’un ensemble de machines. La prise en compte de cette activit´e par TUNe se traduit par le retrait des machines concern´ees du SR. Cependant, cette op´eration n’est pas possible dans TUNe. Si le retrait concerne un cluster tout entier, uniquement la modification des langages de TUNe permettra de prendre en compte cette op´eration. Dans le cas o`u le retrait concerne des ressources individuelles, la modification des langages et du coeur de TUNe sont n´ecessaires. Ceci s’explique par le fait que le syst`eme TUNe ne repr´esente pas de fa¸con individuelle les ressources mat´erielles dans le SR. Il est donc impossible de les manipuler individuellement. De fa¸con analogue, l’extension du cloud par ajout de nouvelles machines ne peut ˆetre pris en compte par TUNe. Ces deux situations s’observent ´egalement au niveau entreprise. Pour illustrer cela, prenons l’ex´ecution dans le cloud d’une application de type maˆıtre-esclave par une entreprise. La scalabilit´e telle que nous l’avons pr´esent´ee dans la section5.4.1) entraˆınera des ajout/retrait de VM (vues comme des ressources mat´erielles par les entreprises).

Probl`eme 3.5

Comme nous l’avons pr´esent´e dans la section 3, la plupart des op´erations d’ad- ministration dans le cloud sont d´eclench´ees par celles du niveau entreprise. C’est ainsi que l’ajout/retrait de VM au niveau de l’IaaS survient apr`es l’extension/r´educ- tion des ressources au niveau entreprise (les op´erations d´ecrites dans le paragraphe pr´ec´edent). Cette op´eration n’est pas possible dans le syst`eme TUNe. En effet, il le permet uniquement pour des logiciels dont la description est connue avant son (TUNe) d´emarrage. De plus, les entreprises ou le fournisseur de l’IaaS peuvent sou- haiter int´egrer de nouveaux types de logiciels dans l’environnement apr`es le d´emar- rage de TUNe (ce qu’il ne permet pas). En guise d’exemple, prenons une entreprise ex´ecutant dans le cloud une application J2EE constitu´ee des serveurs Apache, Tom- cat, MySQL-Proxy et MySQL. Initialement, l’application est constitu´ee d’une seule instance d’Apache et aucun distributeur de charges devant Apache n’existe. Apr`es saturation du serveur Apache, l’entreprise peut souhaiter de joindre un distributeur de charges (HA-Proxy) tout en gardant l’ex´ecution de l’ensemble de l’application et du SAA.

Probl`eme 3.6

Le changement ou la d´efinition d’une strat´egie commerciale (d´efinition d’un nou- veau type de contrat, d’une nouvelle m´ethode de tol´erance aux pannes des VM, etc.) par le fournisseur du cloud se traduit par l’ajout ou le retrait de politiques de reconfiguration dans l’instance TUNe de niveau IaaS. Cette situation est simi- laire aux deux pr´ec´edentes. Elle peut ´egalement concerner le niveau entreprise. De la mˆeme fa¸con que l’administrateur de l’IaaS ajoute/retire des logiciels/mat´eriels, il peut effectuer la mˆeme op´eration pour les politiques de reconfiguration.

Probl`eme 3.7

5.5. SYNTH `ESE ET NOUVELLE ORIENTATION 52