ElaaS

ElaaS (ElasticityasaService) [90] est une solution qui vise à rendre l’élasticité autonome. Il s’agit d’un canevas issu des travaux de l’Université de Nationale Technique d’Athènes qui s’inscrit comme une contribution du projet Européen 4CaaSt [60].

ElaaS répartit le traitement de l’élasticité en différents modules. Ces modules sont au nombre de cinq :

1. L’ElaaS Core est le module en charge de coordonner l’activité globale. Pour cela, l’ElaaS Core initialise les autres modules lors de la phase d’initialisation du canevas en fixant les paramètres adéquats, de même qu’en établissant les canaux de com-munication inter-modules. Il est crée également tous les éléments de stockage de données requis pour le fonctionnement des modules. Après la phase d’initialisation, l’ElaaS Core orchestre les échanges entre les modules.

C’est le seul module qui ne soit pas extensible (au moyen du chargement de plu-gins).

2. L’Application Manager récupère la description de l’application lors de la phase d’initialisation ainsi que la description des SLAs et les KPIs à surveiller.

3. Le Monitoring Manager est en charge de la communication avec les sondes. Celui-ci est configuré pour ne consommer que les KPIs connues de l’Application Manager. Il gère un sous-module de stockage de données de sorte à créer et maintenir un historique des relevés des KPIs. Cet historique est primordial pour permettre les prises de décision d’élasticité.

4. Le Business Logic Manager est le module de prise de décision d’ElaaS. Il n’inclut pas de logique de prise de décision qui reste à la charge du développeur. Cette approche est justifiée par le fait qu’ElaaS a pour vocation d’être un canevas de prise de décision d’élasticité indépendant de l’approche retenue (i.e. pro-active ou réactive).

5. L’Action Manager est un module dont le rôle est triple. Il s’agit en premier lieu d’un passe-plats entre les décisions du Business Logic Manager et les composants applicatifs ou les éléments de la plateforme de cloud sous-jacente. L’Action Ma-nager est également une brique à même de pouvoir compléter des décisions afin d’élaborer des séquences de reconfigurations à opérer. Par exemple, si la décision de dupliquer un serveur d’application est prise, il ajoutera automatiquement un répartiteur de charge en frontal. Le Business Logic Manager est aussi en charge d’établir un graphe d’état cible de l’application (i.e. une architecture cible) appelé graphe de déploiement.

Les interactions avec ElaaS sont rendues possibles au moyen de web services. Parmi ces interactions se trouvent celles relatives à l’exposition de chaque instance du canevas ElaaS comme un service élastique auprès d’autres instances : ElaaS a cette particula-rité de viser l’élasticité offerte comme un service à disposition d’englobants eux-mêmes

élastiques. Par ailleurs, ElaaS se base sur la solution de déploiement Smartfrog [64] pour appliquer les actions de l’Action Manager.

Modèle d’application

ElaaS propose la modélisation des applications en deux modèles de niveaux différents. Le graphe d’application est un modèle dit de "haut-niveau" qui est décliné en un second appelé graphe de déploiement. Plus précisément, le graphe d’application renseigne l’en-semble des dépendances d’une application (par exemple, un fichier .war est exécuté dans un serveur d’application Glassfish et requiert une base de données MySQL). Le graphe d’application utilise une description à gros grain listant les logiciels requis et les artefacts applicatifs.

Durant le déploiement, le graphe d’application est raffiné pour obtenir le premier graphe de déploiement de l’application. Après le déploiement initial, seul le graphe de déploiement est modifié en fonction des logiques implantées dans les modules Business Logic Manager et Action Manager.

Opérations d’élasticité couvertes

Les opérations d’élasticité permises dépendent des logiques implantées dans les modules mais aussi des possibilités. ElaaS n’introduit pas de limitation quant aux possibilités d’opérations d’élasticité. Cependant celles-ci restent à la charge de l’administrateur de l’application.

Architecture applicative

ElaaS offre une vision de l’architecture applicative en deux niveaux, au travers des graphes d’application et de déploiement. Le premier graphe de déploiement est issu du graphe d’application, tandis que les suivants proviennent directement de modifications successives appliquées sur les graphes de déploiement courants. Le graphe d’application offre donc une vision à haut-niveau pour le premier déploiement, sans toutefois couvrir des notions de contraintes. Le comportement élastique de l’application est à la fois décrit par le graphe d’application en plus d’être réparti dans les implantations des modules. De son côté, le graphe de déploiement offre la vision de l’architecture durant l’exécution de l’application.

Gestion du placement

De même que pour la couverture des opérations d’élasticité, la gestion du placement est liée à l’implantation des modules d’ElaaS. Il est par exemple possible de gérer du multi-cloud mais cela implique de modifier l’implantation du module appelé Business Logic Manager.

3.3. SOLUTIONS DE GESTION COMPLÈTE DE L’ÉLASTICITÉ 69 Positionnement par rapports aux critères

ElaaS est un canevas d’élasticité à destination d’application qui peut être spécialisé au travers de plugins. Le positionnement par rapport aux critères qui suit a été réalisé en prenant en compte l’état connu de l’implantation.

• L’Indépendance applicative est Forte car ElaaS ne semble présenter aucune limite en matière de gestion de types d’applications

• L’Indépendance architecturale est évaluée à Faible car en l’état actuel d’implanta-tion de ses plugins, ElaaS n’adresse que des applicad’implanta-tions multi-tiers.

• L’évaluation de l’Indépendance vis-à-vis de l’environnement est Bonne puisque grâce à SmartFrog, ElaaS ne semble pas restreint quant aux clouds accessibles. En revanche, l’utilisation simultanée de plusieurs IaaS pour une même application ne semble pas possible.

• Gestion des applications patrimoniales : ElaaS utilisant smartFrog, les applica-tions patrimoniales sont correctement adressées sans contrainte de modification. L’évaluation pour ce critère est donc Forte.

• La Granularité des opérations est évaluée à Faible puisqu’en l’état actuel de son implantation rien n’indique qu’ElaaS raffine la granularité VM de SmartFrog.

Figure 3.9 – Evaluation d’ElaaS par rapport aux critères d’étude

• L’évaluation retenue pour la Modélisation à l’exécution est Bonne. Le Deployment Graph mentionne effectivement les liaisons entre composants mais toutefois, ce n’est pas le cas des placements.

• Pour le critère de la Modélisation de l’élasticité, l’évaluation obtenue est Moyenne. Seuls les types de composants de l’application sont mentionnés dans l’Application

Graph. Le reste du comportement élastique est décrit dans le code des plugins et cela n’est pas considéré comme une mention explicite et centralisée en un seul modèle.

• L’Expression de contraintes est évaluée à Forte. ElaaS permet l’expression de contraintes d’élasticité au travers de l’implantation de plugins pour ses modules. ElaaS permet d’étendre les contraintes gérées. Toutefois, cette évaluation est à nuancer : l’approche par implantation de plugins peut devenir une tâche complexe lorsque le nombre de contraintes à satisfaire augmente et ElaaS ne semble disposer d’aucun mécanisme permettant de gérer les conflits pouvant apparaître.

3.3. SOLUTIONS DE GESTION COMPLÈTE DE L’ÉLASTICITÉ 71