Prise en compte des caract´eristiques

Apr`es la pr´esentation du mod`ele architectural devra suivre la conception et le d´eveloppement d’un SAA g´en´erique, montrons `a pr´esent comment ce mod`ele r´epond aux caract´eristiques que nous avons identifi´ees dans la section6.1.

L’uniformit´e des ´el´ements administr´es dans le SAA est assur´ee dans ce mod`ele par le composant SR Manager. En effet, c’est dans son implantation que les constructeurs du SAA d´ecideront de figer ou non les diff´erences entre les ´el´ements administr´es.

L’adaptabilit´e du SAA est ´evidente dans ce mod`ele dans la mesure o`u il r´epond enti`erement sur une architecture `a composants dans lequel tous les services sont identifiables par un composant.

Pour finir, la collaboration/interop´erabilit´e est une fonctionnalit´e mise en avant et remplie par le composantExternal Communicator dans le mod`ele. Ce composant permet l’´emission et la r´eception d’ordres d’administration entre plusieurs SAA de natures distinctes.

6.3 Synth` ese

Dans ce chapitre, nous avons propos´e des directives devant guider la concep-tion et le d´eveloppement d’un SAA hautement adaptable et flexible. Ces directives concernent `a la fois les besoins que doit remplir ce SAA, l’approche g´en´erale de son implantation et pour finir le mod`ele architectural qu’il devra suivre. De plus, nous avons montr´e comment ces directives permettront au SAA de prendre en compte l’administration d’une plateforme de cloud ainsi que des applications qu’il h´eberge.

Dans le chapitre suivant, nous ´etudions les travaux de recherche existants qui s’int´eressent aux mˆemes probl´ematiques que celles que nous adressons dans cette th`ese. Il s’agit globalement de la construction des SAA flexibles et de l’administra-tion autonome dans le cloud.

Syst`eme d’administration autonome adaptable : application au Cloud

Chapitre 7 Etat de l’art

Contents

7.1 SAA . . . 66 7.1.1 Rainbow . . . 67 7.1.2 Accord . . . 69 7.1.3 Unity . . . 71 7.1.4 Synth`ese . . . 73 7.2 SAA pour le cloud . . . 73 7.2.1 OpenNebula . . . 74 7.2.2 Eucalyptus . . . 77 7.2.3 OpenStack . . . 78 7.2.4 Microsoft Azure . . . 80 7.2.5 Autres plateformes de cloud . . . 83 7.3 Synth`ese . . . 83

Dans cette th`ese, notre principale probl´ematique est l’administration des plate-formes de cloud et des applications qu’elles h´ebergent. Exer¸cant dans le domaine de l’administration autonome depuis ces derni`eres ann´ees, nous avons ´etabli le rappro-chement entre la probl´ematique d’administration dans le cloud et celle des grilles de calculs que nous traitions dans nos recherches. C’est ainsi que nous avons entre-pris d’´etudier l’utilisation de notre syst`eme d’administration autonome TUNe, con¸cu pour l’administration des applications dans les clusters et les grilles, pour l’admi-nistration du cloud dans son ensemble (IaaS et applications des entreprises). Con¸cu pour ˆetre g´en´erique et utilisable dans plusieurs domaines, le syst`eme TUNe a montr´e cependant quelques difficult´es `a prendre en compte des besoins d’administration de certains domaines applicatifs parmi lesquels le Cloud (voir le chapitre5).

L’´etude des difficult´es de TUNe nous a conduit `a proposer plus g´en´eralement un canevas de d´eveloppement d’un v´eritable syst`eme g´en´erique et adaptable `a tous les domaines applicatifs dont le cloud. Ce canevas pr´econise trois recommandations `a suivre dans le processus de d´eveloppement d’un SAA `a vocation g´en´erique :

7.1. SAA 66 (1) S´eparer le d´eveloppement du cœur du SAA (fonctionnalit´es de base) de celui des langages d’administration qu’utiliseront ses futurs administrateurs.

(2) Le SAA devra remplir les crit`eres suivants :

– l’uniformit´e : il ne dispose d’aucun comportement pr´e-cˆabl´e li´e `a un type d’´el´ement (les machines par exemple).

– l’adaptabilit´e: la modification de ses services ne doit pas n´ecessiter la connais-sance enti`ere de son processus de d´eveloppement.

– l’interop´erabilit´e : sa facult´e `a initier la communication avec d’autres SAA d’une part et `a exporter ses interfaces d’acc`es distant d’autre part.

(3) Pour finir, nous recommandons l’utilisation d’une approche de d´eveloppement `a composants pour son implantation.

En somme, nous nous int´eressons `a deux probl´ematiques : la construction de SAA g´en´eriques et l’administration du cloud dans son ensemble (niveau IaaS et en-treprise). Dans ce chapitre, nous ´etudions les travaux de recherche qui s’int´eressent

`a ces probl´ematiques. Nous l’organisons de la mani`ere suivante. Dans un premier temps, nous ´etudions les SAA `a vocation g´en´erique existants. Dans cette premi`ere

´etude, nous pr´esentons le positionnement de ces SAA par rapport aux recomman-dations que nous avons ´enum´er´ees ci-dessus. Dans un second temps, nous ´etudions les syst`emes d’administration sp´ecifiques aux environnements de cloud. Comme nous l’avions pr´ecis´e dans la section3.3, ces syst`emes doivent remplir les crit`eres suivants : – Interop´erable : capacit´e `a dialoguer avec d’autres syst`emes de gestion de cloud et ´egalement avec des syst`emes d’administration des applications d’en-treprises.

– Auto-r´eparable: capacit´e `a prendre en compte automatiquement les pannes dans l’environnement qu’il administre (machines, VM et logiciels).

– Extensible : capacit´e `a prendre en compte de nouveaux ´el´ements dans l’en-vironnement (nouvelles machines r´eelles et virtuelles, nouveaux logiciels).

– Programmable: capacit´e `a prendre en compte de nouvelles politiques d’ad-ministration (nouvelles m´ethodes de consolidation, de scalabilit´e, etc.).

– Adaptable : capacit´e `a permettre le remplacement ou la modification de ses modules afin de prendre en compte des particularit´es de certaines plateformes de cloud.

– Langages d´edi´es : dispose des langages de facilitation de son utilisation.

Compte tenu de sa sp´ecialisation dans le cloud, il n’est pas absurde que ce syst`eme propose des langages facilitant son utilisation.

Remarquons que ces crit`eres sont inclus dans ceux que nous avons identifi´es pour les SAA g´en´eriques.

7.1 SAA

Parmi les travaux de d´eveloppement de SAA, peu d’entre eux ont la vocation de prendre en compte plusieurs domaines d’applications `a la fois. En effet, ils s’int´e-ressent chacun pour la plupart `a un domaine pr´ecis. Ainsi, le crit`ere d’adaptabilit´e Syst`eme d’administration autonome adaptable : application au Cloud

7.1. SAA 67 que nous consid´erons comme le crit`ere principal de notre mod`ele est tr`es peu pris en compte dans les autres syst`emes. Pour cette raison, notre revue de l’existant ´etudiera principalement l’extensibilit´e des SAA qui est l’un des crit`ere d´ecoulant de l’adapta-bilit´e et pris en compte par certains SAA. En rappel, l’extensil’adapta-bilit´e d’un SAA d´esigne la capacit´e du SAA `a prendre en compte pendant son ex´ecution, l’ajout/retrait de nouveaux ´el´ements logiciels ou des instances de logiciels dont la description existait au d´emarrage du SAA.

Dans cette section, nous ´etudions les SAA : Rainbow [?], Accord [?] et Unity [?

]. Le premier se d´efinit comme SAA adaptable (au sens que nous avons d´efini dans le chapitre pr´ec´edent) `a des domaines quelconques tandis que les deux derniers sont sp´ecifiques `a des domaines particuliers.