applica-tion. Les données agrégées sont ensuite exposées à l’étape suivante appelée Analyse. 2. L’Analyse est une étape de prise de décision : en fonction de l’état de l’application et de sa charge, l’Analyse décide d’une opération d’élasticité. Cette décision décrit une modification de l’architecture de l’application qui ne suffit pas à elle seule à déterminer une nouvelle architecture. La décision consiste effectivement en une méta-modification de l’application qui implique d’être raffinée afin d’obtenir une nouvelle architecture-cible. C’est le rôle de la Planification
3. La Planification est l’étape durant laquelle un plan de reconfiguration de l’architec-ture de l’application va être établi. La Planification permet d’obtenir une nouvelle architecture-cible à partir de l’architecture courante en appliquant la décision de l’Analyse. Cette étape est au cœur des travaux exposés dans ce manuscrit. Fina-lement, la nouvelle architecture est fournie à la quatrième et dernière étape de la boucle MAPE-K.
4. L’Exécution est l’étape durant laquelle la nouvelle architecture de l’application est effectivement mise en place au niveau des éléments de l’application.
Tout au long de la boucle, les étapes lisent et enrichissent la Connaissance du système. Des approches antérieures ont déjà visé à utiliser la boucle autonomique MAPE-K pour permettre la modification d’architectures applicatives. Ce fut le cas de Rainbow [46, 45]. Cependant, cette solution n’est pas adaptée au cloud. Nous pensons qu’une solution permettant la modification d’architectures applicatives à des fins d’élasticité dans le cloud est primordiale. Plus particulièrement, nous pensons que des avancées peuvent être apportées grâce à une planification innovante.
La suite de ce manuscrit se focalise sur la troisième étape de la boucle MAPE-K , la Planification. Comme l’a montré l’état de l’art, il s’agit d’une problématique qui est actuellement très peu adressée. La section suivante détaille le rôle de la planification afin de comprendre en quoi cette étape est primordiale.
4.3 Rôle de la Planification
La planification a pour principal objectif d’appliquer la méta-modification correspon-dant à la décision de l’analyse sur l’architecture courante de l’application, pour au final établir un plan de reconfiguration. Le rôle de planification est de contextualiser la décision de l’analyse à l’architecture courante de l’application tout comme la décision de faire aller tout droit le chat dans le programme Acoustic Kitty aurait dû l’être pour traverser la route.
L’établissement d’un tel plan de reconfiguration est un processus complexe puisqu’il faut adresser l’ensemble des problématiques de l’architecture de l’application. Comme le montre la figure 4.2, ces problématiques sont nombreuses. Elles ne se résument pas à de simples arrêts ou démarrages de VM. Afin de comprendre la complexité du rôle de la planification, la suite de cette section s’appuie sur l’exemple illustré par la figure 4.2, qui
correspond à un scénario de croissance horizontale sur le tiers métier de l’application web trois tiers Springoo.
Apache VM1 Jonas VM2 MySQL VM5 Apache VM1 Jonas VM2 Décision: +1 Jonas
Ajout d’une nouvelle VM configurer l’image virtuelle
configurer le dépôt de l’image virtuelle déterminer le cloud de destination renseigner les crédences d’accès au cloud de destination
configurer le profil matériel en fonction de ceux proposés par le cloud de destination et des besoins de Jonas
…
Configurer la nouvelle VM configurer le firewall
déterminer s’il faut ajouter des logiciels à chaud
configurer les logiciels autres que les applicatifs (VPN, pilotes, sondes…) Reconfigurer les éléments de l’application déjà présents et du nouveau Jonas
configuration de l’Apache connaître l’adresse ip du MySQL connaître le port du MySQL connaître les crédences de la base … Apache VM1 Jonas VM2 MySQL VM5 Jonas VM3 Plan de reconfiguration Jonas VM3 MySQL VM5 Jonas VM6 Jonas VM3 Jonas
Analyse
Planification
Figure 4.2 – Explicitation du rôle de la planification au travers d’une croissance hori-zontale de l’application Springoo
Dans cet exemple, la décision a été prise par l’analyse d’ajouter un serveur Jonas, c’est-à-dire d’ajouter une instance au tiers métier. Cette décision n’est pas suffisante pour que l’architecture de l’application soit correcte. En effet, la nouvelle instance de serveur Jonas n’est non seulement pas placée au sein d’une VM, mais elle reste en outre non-connectée au reste de l’application. La décision de l’analyse est une méta-modification qui nécessite des calculs supplémentaires pour obtenir une nou-velle architecture-cible complète. Dans cet exemple, la planification va donc consis-ter à établir un plan de reconfiguration mentionnant l’ajout d’une VM pour y exécuconsis-ter la nouvelle instance de serveur Jonas ainsi que la façon d’inclure cette nouvelle instance dans l’application. Pour cela, la planification va :
• Spécifier l’ajout d’une nouvelle VM. La planification va établir dans quel cloud la nouvelle VM doit être démarrée. Ce choix n’est pas immédiat puisqu’en
fonc-4.3. RÔLE DE LA PLANIFICATION 83 tion des exigences de l’utilisateur, la planification doit - par exemple - pouvoir gérer des notions de haute-disponibilité ou de tarification. Outre le choix du cloud d’hébergement de la nouvelle VM, la planification doit également en déterminer le profil matériel adéquat. Pour cela, la planification peut être amenée à résoudre, par exemple, des exigences de l’utilisateur portant sur les besoins des logiciels em-barqués (ex : un serveur Jonas doit avoir 1Go de ram au minimum), sur le prix maximum que l’utilisateur veut respecter pour chaque VM , voire les deux conco-mittamment. En plus du choix du cloud d’hébergement, de la détermination du profil matériel, la planification peut être amenée à gérer d’autres aspects tels que le choix de l’image virtuelle à utiliser, la gestion des serveurs de noms DNS, la détermination de la nécessité d’obtenir une adresse IP publique pour la nouvelle VM...
• Configurer la nouvelle instance pour qu’elle intègre l’application. Suivant la solu-tion d’exécusolu-tion utilisée, cette préoccupasolu-tion peut nécessiter différentes reconfigu-rations. Si la solution utilisée est VAMP par exemple, cette configuration passe par la mention des interfaces du composant Fractal représentatif de la nouvelle instance de serveur Jonas. Pour d’autres, il s’agira de renseigner des paramètres possiblement connus uniquement lors de l’exécution de l’application (ex : adresse ip du serveur MySQL, nom du serveur Jonas, port du serveur MySQL, crédences du serveur MySQL,..).
• Configurer le reste de l’application pour intégrer la nouvelle instance de serveur Jonas. Là encore, cette préoccupation est liée à la solution d’exécution utilisée. Il peut aussi bien s’agir de la spécification d’interfaces Fractal, que du renseignement de paramètres possiblement dynamiques (ex : ip de la nouvelle VM, nom de la nouvelle instance de serveur Jonas à renseigner auprès du module mod_jk du serveur Apache,..)
Le rôle de la planification est donc de compléter la décision de l’analyse pour établir un plan de reconfiguration à même d’être interprété par la solution d’exécution. Ce plan dépend donc de la solution d’exécution et doit être adapté en conséquence. Le plan de reconfiguration constitue une description des modifications de l’architecture courante de l’application établie en appliquant la décision de l’analyse. Sa détermination doit également obéir à des exigences de l’utilisateur que celui-ci peut fixer au travers de l’expression de contraintes. L’état de l’art a montré que les solutions actuelles ne permettent pas d’adresser toutes les problématiques de l’établissement d’un tel plan de reconfiguration, or nous pensons qu’une planification complète et complètement descriptible est nécessaire. Cependant, les approches actuelles fonctionnent en mode "boîte noire" : nous pensons qu’en conséquence, une brique séparée permettant d’exprimer l’ensemble des exigences de l’architecture de l’application doit être réalisée.
Ce manuscrit décrit dans sa suite une proposition de solution à même de lever les verrous des solutions actuelles. La section suivante décrit les caractéristiques requises
pour que cette solution puisse à la fois permettre d’atteindre les objectifs généraux de la thèse mais aussi d’élargir le champ des possibles en matière de gestion de l’élasticité.