La solution présentée dans ce manuscrit est appelée Vulcan en référence à la vulcanisa-tion, une réaction chimique permettant de rendre un élastomère élastique. Le fonction-nement global de Vulcan est illustré par le schéma 4.3.
La planification réalisée par Vulcan s’appuie sur deux modèles.
1. Le premier des deux modèles est appelé Modèle par Extension [77]. Il permet la représentation de l’architecture courante d’une application ainsi que la représenta-tion de l’architecture-cible. Si l’architecture courante est issue de la Connaissance
4.5. VULCAN, UNE SOLUTION DE PLANIFICATION POUR UNE ÉLASTICITÉ AUTOMATISÉE85
Limite identifiée Risque possible Caractéristique requise
Spécificité à une application La solution est limitée dans sa gestion des applications
Agnosticité vis-à-vis de l’appli-cation, tout en permettant de spécialiser l’élasticité à une ap-plication
Spécificité à un type d’archi-tecture applicative (ex : ap-plications n-tiers)
La solution est limitée dans sa gestion des architectures applicatives
Agnosticité vis-à-vis de l’archi-tecture applicative
Spécificité à des IaaS ou des solutions d’exécution
Risque d’enfermement pro-priétaire
Agnosticité vis-à-vis de l’envi-ronnement d’exécution
Mauvaise gestion des ap-plications patrimoniales vir-tualisables
Non-utilisation de la solu-tion par manque d’adapta-tion
Ne pas nécessiter de modifica-tions de l’application
Granularité limitée à la VM Limitation quant à la ges-tion du placement (ex : choix du profil matériel im-possible)
Offrir une granularité plus fine que la VM au niveau du com-posant applicatif et des para-mètres de configurations Non-exposition à
l’utilisa-teur de l’architecture de l’application
Non-connaissance de l’état de l’application par l’utilisa-teur
Offrir une représentation de l’architecture de l’application durant son exécution
Comportement élastique non descriptible(ou partiel-lement)
La solution est limitée dans les scénarios possibles d’élasticité
L’élasticité doit pouvoir être décrite totalement
Absence d’expression de contraintes
Le comportement élastique est compliqué à spécifier pour l’utilisateur et donc po-tentiellement incompréhen-sible
Permettre l’expression de contraintes relatives à l’élasti-cité
Expression du comporte-ment élastique suivant dif-férentes approches (ex : contraintes et programma-tion)
Difficulté d’apprentissage de la solution par l’utilisateur
Recours à une approche unique pour la spécification du com-portement élastique
Les contraintes ne peuvent être étendues
La solution ne peut gérer de nouvelles contraintes
Le formalisme du modèle d’élasticité doit permettre d’étendre les contraintes gérées par la solution
Table 4.1 – Caractéristiques requises pour une solution innovante de planification
de la boucle MAPE-K, l’architecture-cible provient du moteur de calculs de Vulcan. Vulcan réalise ses calculs directement sur le modèle par extension. La réalisation de ces calculs dépend d’un algorithme de planification innovant. Une des particu-larités de cet algorithme est de réaliser les calculs en tenant compte des différentes contraintes de l’application. Ces contraintes sont en fait connues grâce au second
Figure 4.3 – Fonctionnement global de Vulcan, un gestionnaire de planification de l’élasticité
modèle sur lequel s’appuie Vulcan : le Modèle par Intention.
2. Le Modèle par Intention [77] permet à l’algorithme de connaître comment modifier l’architecture de l’application. Il est fourni par l’administrateur de l’application à rendre élastique. Il s’agit d’un gabarit pour l’ensemble des modèles par extension possibles. Pour cela, le modèle par intention centralise l’ensemble des contraintes d’une application et permet d’adresser l’ensemble des calculs nécessaires à l’éta-blissement d’un plan de reconfiguration. Le modèle par intention de Vulcan fait usage d’un formalisme novateur permettant de décrire des contraintes suivant un mode d’expression unique. L’utilisation de ce formalisme conjointement avec celle de l’algorithme de Vulcan offre l’avantage de faciliter la réutilisation des contraintes exprimées pour une application par d’autres applications. Cela permet un appren-tissage aisé de la solution.
La suite de ce document approfondit les concepts énoncés dans cette section tout en faisant le lien avec les caractéristiques requises identifiées dans la section précédente.
Chapitre 5
Modèle par extension
d’applications élastiques
Sommaire
5.1 Description du modèle par extension . . . 88 5.2 Modèle par extension d’une application de distribution de
contenu . . . 91 5.3 Opérations élémentaires de modification d’un modèle par
extension . . . 93
L
’émergence du cloud computing a vu des travaux proposer des ontologies afin d’adres-ser la diversité des offres de cloud et l’absence de standards de description. Ces travaux visent principalement à homogénéiser des offres de cloud ayant des descriptions très hétérogènes. Une ontologie se définit par l’ensemble structuré des termes et concepts caractéristiques d’un domaine. Les ontologies permettent de décrire des éléments en les liant par des relations avec une sémantique précisée par l’ontologie [169]. Certaines ap-proches visent à offrir une connaissance homogène la plus complète possible, accessible par l’utilisateur pour des services offerts par les fournisseurs de cloud [147, 111]. D’autres ont pour objectif d’offrir des services spécifiques comme du stockage répartis et fiable dans le cloud [22, 85] ou du déploiement automatisé sur plusieurs IaaS en prenant en compte les niveaux de services demandés par l’utilisateur [110].Ces travaux montrent un enjeu actuel de recherche qui est d’offrir une description homogène de services hétérogènes. Il s’agit plus précisément de permettre une connais-sance simple des plateformes sous-jacentes mais aussi de l’application comme le montre [169].
Le modèle par extension va dans ce sens et offre une connaissance de l’état courant de l’application. Il permet en outre à Vulcan de planifier les reconfigurations à opérer sur l’application lorsqu’une décision d’élasticité est prise par l’analyse. Ce chapitre a pour
objectif de décrire de façon détaillée ce qu’est le modèle par extension.
5.1 Description du modèle par extension
Le modèle par extension est une représentation de l’état de l’application. Il ne s’agit aucunement d’un modèle de programmation comme OSGI [48], ou Fractal [39, 129] par exemple. Le modèle par extension est une abstraction des ressources de l’application servant à leur administration. De ce fait, Vulcan n’impose pas de changement au niveau du code applicatif. En revanche, le modèle par extension permet une réelle connaissance de l’application durant la mise en œuvre de l’élasticité.
S’il n’est pas un modèle de programmation comme Fractal, le modèle par extension en utilise toutefois les concepts architecturaux. Ces concepts permettent de décrire l’in-tégralité des préoccupations à adresser pour permettre l’élasticité d’une application dans le cloud. Les préoccupations à adresser se répartissent en deux niveaux d’administration de l’élasticité [24, 59, 157] : le niveau infrastructure et le niveau applicatif.
• Le niveau infrastructure de l’administration de l’élasticité des applications dans le cloud concerne principalement les VMs, les IaaS, le réseau, leurs configurations et leurs liens. Une illustration d’un tel lien est l’hébergement d’une VM dans un IaaS : de l’existence, la disponibilité et la capacité d’accueil du IaaS dépend l’exécution de la VM.
• Le niveau applicatif concerne les logiciels qui par leur exécution assurent la mise en œuvre des fonctionnalités de l’application. Ce niveau concerne également les configurations de ces logiciels. D’autre part, le niveau applicatif inclut également les liens entre les briques logicielles. Les briques logicielles peuvent effectivement dépendre d’autres briques logicielles pour leur exécution. Cette notion de dépen-dance reflète la nécessité d’une brique logicielle de communiquer avec la brique logicielle dont elle dépend, afin de pouvoir elle-même être fonctionnelle. C’est par exemple le cas dans une application web comme Springoo où le serveur frontal Apache dépend d’un serveur Jonas qui lui même dépend d’un serveur de base de données MySQL.
La gestion de l’élasticité d’une application requiert donc d’administrer ces deux ni-veaux. Pour cela, il est nécessaire d’en permettre la représentation dans le modèle par extension. En outre, ces deux niveaux de préoccupations doivent être gérés de façon concomitante de sorte à également adresser les liens existants entre les deux niveaux. A titre d’exemple, les briques logicielles d’une application s’exécutent au sein de VMs qui elles-mêmes sont hébergées dans des clouds. Une réponse à cette problématique est en partie fournie par les travaux autour des solutions Jade, TUNe et TUNeEngine évoquées dans la suite de ce manuscrit en sous-sous-section 6.2.3. Ces travaux ont effec-tivement permis de démontrer la pertinence du recours aux architectures à composants pour rendre homogène la gestion automatisée et simplifiée d’éléments hétérogènes [68].
5.1. DESCRIPTION DU MODÈLE PAR EXTENSION 89 Afin de permettre la modélisation de l’ensemble des préoccupations décrites ci-avant, le modèle par extension utilise des concepts issus des architectures à base de composants et plus particulièrement du modèle Fractal. Le choix de retenir les architectures à base de composant pour le modèle par extension se justifie également par l’expressivité de cette approche ainsi que par sa capacité à permettre des calculs et des raisonnements. Si le premier point a été démontré par des solutions comme Fractal ou OSGi, le se-cond l’a été par exemple par SystemCAS, une solution de simulation de circuits et de programmes [91, 122].
Le schéma 5.1 illustre les concepts retenus pour le modèle par extension. Une
ap-Légende A B A est placé dans le conteneur B A B Le composant B dépend du composant A Composant de l'application ex: serveur Apache, serveur Jonas
Conteneurs
Figure 5.1 – Vue globale des concepts manipulés dans le modèle par extension plication est constituée de composants primitifs qui sont exécutés dans des composants composites. Un composant primitif ne peut contenir d’autres composants, tandis qu’un composant composite peut contenir des composants primitifs et/ou des composants com-posites. La suite du manuscrit désigne les composants primitifs par le terme de compo-sants, et les composants composites par celui de conteneurs. L’exécution d’un composant au sein d’un conteneur est décrite par le placement de ce composant dans son conte-neur d’exécution. Par exemple, dans la figure 5.1, le composant C.1 est placé dans le conteneur VM.1. La notion de placement désigne également l’exécution d’un conteneur au sein d’un autre : le conteneur VM.1 est ainsi placé dans le conteneur Cloud.2. Cet exemple met en évidence une notion additionnelle qui est la hiérarchie de conteneurs : les conteneurs de plus bas niveau sont placés dans des conteneurs de plus haut niveau.
Outre la notion de placement, le modèle par extension utilise celle de liaison. Une liaison relie deux composants et traduit une dépendance de l’un par rapport à l’autre. Plus précisément, il s’agit d’une relation orientée qui indique la dépendance du compo-sant d’origine envers le compocompo-sant de destination. Dans le cas de la figure 5.1, il existe une liaison depuis le composant C.3 vers le composant C.2 : cela traduit une dépendance de C.3 envers C.2.
La configuration de chaque composant et de chaque conteneur est portée par chaque élément grâce à des paramètres de configuration. Les paramètres permettent de men-tionner l’ensemble des attributs de chacun des éléments. Par exemple, les paramètres d’un conteneur de type VM mentionnent - notamment - le profil matériel de la machine représentée.
L’ensemble des notions du modèle par extension est issu du méta-modèle illustré par la figure 5.2 et la section suivante donne un exemple de modèle par extension pour une application très largement utilisée. De plus, des exemples issus de l’implantation de Vulcan sont donnés dans le chapitre 8.