9.2 Scénarios d’élasticité
9.2.1 Scénario n˚1 : Elasticité multi-tiers élémentaire
9.2.3 Scénario n˚3 : Elasticité verticale . . . 144 9.2.4 Scénario n˚4 : Elasticité profilée . . . 145
9.3 Positionnement par rapport à l’état de l’art . . . 148
U
n objectif des travaux de thèse est de valider l’approche par des cas d’usages permet-tant de montrer l’apport de la solution proposée. Ce chapitre présente donc des cas d’usages significatifs et va montrer comment Vulcan se différencie par rapport à d’autres solutions de gestion de l’élasticité. Pour cela, une première section présente les applica-tions recensées et explique leur intérêt pour l’élasticité. Cela a pour but d’identifier des scénarios d’élasticité représentatifs et pourtant loin d’être tous adressés par les solutions actuelles de gestion de l’élasticité des applications dans le cloud.9.1 Applications retenues pour la validation
Cette section présente la liste des applications retenues afin de valider l’approche propo-sée. Chacune de ces applications diffère des autres par ses besoins en termes de scénarios d’élasticité. Cette différence s’explique aussi bien par les dissimilitudes d’architectures
que par des logiques métiers hétéroclites. La première de ces applications est Springoo, un exemple déjà exposé au cours des explications de ce document.
9.1.1 Springoo
Springoo est une application web trois tiers JavaEE. Elle se compose de serveurs Apache, Jonas et MySQL. Cette application présente les caractéristiques suivantes :
• Springoo est une application représentative de 80% du Système d’information d’Orange.
• Par ses concepts elle est similaire à d’autres applications dans des domaines variés comme par exemple l’Auto-Configuration Server (ACS) de la société Motorola, une application permettant l’authentification et la configuration de matériels tels que des Livebox, des actionneurs de vannes, des capteurs de température ou d’autres périphériques. Un autre exemple est CoopNet, une application permettant de créer des ponts téléphoniques, de partager des documents et le bureau des utilisateurs en cours de conférence. Cette application est proposée par Orange Business Services. • Springoo fait également partie des cas d’usages du projet FSN OpenCloudWare
dans lequel s’inscrit cette thèse.
• Le champ des similitudes de Springoo peut même être étendu aux applications PHP reposant sur la stack LAMP en raison de leur architecture très similaire : seuls les serveurs du tiers métier changent.
• L’élasticité des applications multi-tiers est largement adressée par les solutions actuelles.
Toutes ces caractéristiques démontrent l’intérêt de Springoo : il s’agit d’une applica-tion très représentative et dont l’élasticité est déjà adressée par les soluapplica-tions actuelles de gestion de l’élasticité. Springoo présente donc l’avantage d’être non seulement un cas d’usage pertinent mais également différenciateur dans la mesure où au final beau-coup de scénarios d’élasticité ne sont aujourd’hui pas adressés. C’est cette application qui a été mise en œuvre lors de l’intégration avec VAMP, une solution de déploiement d’applications dans le cloud qui implante l’Exécution dans la boucle MAPE-K.
9.1.2 Clif
Clif [51] est un canevas d’injection de charge permettant de stresser une application et d’en observer le comportement induit. Clif est une application Open Source écrite en Java. Elle fait partie intégrante des contributions du projet OpenCloudWare. Cette application est par ailleurs très utilisée pour tester des applications en cours de dévelop-pement ainsi que pour effectuer des calibrages. Clif diffère totalement de Springoo par son architecture qui comprend les éléments suivants :
9.1. APPLICATIONS RETENUES POUR LA VALIDATION 141 • Le Superviseur est l’unité centrale de Clif. Il orchestre les tests en modulant
l’in-jection de charge puis rassemble les données produites par les sondes.
• Les Sondes sont des capteurs présents au niveau du Système Sous Test (SUT). Elles permettent aussi bien de stocker des métriques généralistes (charge CPU, occupation mémoire) que des métriques plus spécifiques aux applications (nombre de requêtes par seconde, temps de réponse). Il s’agit donc d’un élément embarqué dans les machines de l’application soumises à la charge.
• Les Blades sont des éléments d’injection de charge qui simulent le comportement d’utilisateurs humains. Chaque blade peut moduler son injection. Le placement des blades par rapport au système sous test est primordial pour garantir la bonne tenue des tests. Il est effectivement nécessaire qu’elles soient placées dans le même réseau que le SUT afin que les flux réseaux ne constituent pas un goulet d’étranglement. Les blades sont pilotées par le superviseur. Chacune d’elles présente donc une liaison en direction de celui-ci et les sondes suivent le même schéma. La figure 9.1 donne un exemple d’architecture de Clif.
Dans ce schéma, les rectangles de couleurs représentent des composants. Les VMs sont représentées par des rectangles oranges avec des bords arrondis. Ce type de représentation est utilisé dans l’ensemble des schémas d’architectures du reste du chapitre.
Figure 9.1 – Architecture de l’application Clif
Clif a été retenu en raison de l’importance du calibrage d’une application avant sa mise en production. Cela permet effectivement à une brique d’Analyse de savoir comment une application doit être mise à l’échelle. Son utilisation dans les milieux industriel et académique [148] en fait un cas d’usage intéressant puisque répandu.
9.1.3 Ganglia
Ganglia [75, 102, 104, 161] permet la surveillance de machines et d’applications. Il s’agit d’un canevas Open Source écrit en partie en C, en Perl et en PHP. Il est également capable de gérer des éléments en Python. A l’instar de Nagios [80] ou Zabbix, d’autres canevas de surveilance, Ganglia est très utilisé, que ce soit au niveau industriel ou aca-démique (Grid5000). Il se compose de deux éléments principaux :
• Le Ganglia Monitor Deamon (Gmond) est un élément collecteur. Il permet de remonter les métriques de la machine sur laquelle il s’exécute. Il surveille
égale-ment les autres Gmonds du cluster. Les données des Gmonds sont envoyées au GmetadUI.
• Le GmetadUI comprend un Ganglia Meta Deamon (Gmetad), un élément en charge de remonter et stocker dans une base de données locale les informations des Gmonds. Le GmetadUI comprend également une interface graphique PHP qui doit être colocalisée avec la base de données stockant les métriques.
L’architecture de Ganglia est en étoile : chaque Gmond a un liaison en direction du GmetadUI comme illustré par la figure 9.2.
Figure 9.2 – Architecture applicative de ganglia
Ganglia a été retenu comme cas d’usage en raison de son utilisation répandue à des fins de supervision. Il s’agit d’un canevas pouvant par exemple être proposé comme un service de collecte de métriques par une plateforme de cloud. Ganglia peut également être vu comme une brique de Monitoring au sein d’une boucle autonomique MAPE-K visant à créer une élasticité automatique.
9.1.4 USB over IP
L’application USB over IP est un cas d’usage d’origine interne à Orange. Cette applica-tion permet de connecter des périphériques USB sur une Livebox sans avoir à charger des pilotes sur celle-ci. Les Livebox ont en effet des capacités matérielles limitées. D’autre part, inclure des pilotes à la volée pose d’importants problèmes de sécurité et de sta-bilité. L’idée est donc de déporter dans le cloud le traitement des périphériques USB. L’application se compose de deux types d’éléments :
• Les Nœuds sont des contrôleurs USB. De par une limitation du bus USB, ils ne peuvent gérer que 128 périphériques de façon concomitante bien que ces contrôleurs ne soient pas exigeants en termes de ressources matérielles. Une VM n’est donc jamais surchargée par un seul Node.
• Le Répartiteur est une unité en charge d’orienter les périphériques USB nouvelle-ment connectés vers un nœud de traitenouvelle-ment. Il s’agit d’une sorte de répartiteur de charge. Après cette première connexion, plus aucun flux ne passe par lui.
L’architecture d’USB over IP (USBoIP) comporte donc des nœuds tous liés en direction du répartiteur. La figure 9.3 en illustre un exemple.
9.2. SCÉNARIOS D’ÉLASTICITÉ 143
Figure 9.3 – Architecture de l’application USBoIP
L’intérêt d’USBoIP réside dans le fait que les scénarios optimaux d’élasticité pour cette application impliquent d’avoir une granularité plus fine que celle de la VM.
Cette section a présenté les cas d’usages retenus pour la validation des travaux de thèse. Ceux-ci comprennent des applications ayant des logiques métiers très différentes et des architectures tout aussi dissemblables. La section suivante présente des scénarios d’élas-ticité identifiés pour ces applications.
9.2 Scénarios d’élasticité
Un scénario d’élasticité est une succession d’architectures pour une application. Plus concrètement, durant son élasticité, une application va voir son architecture être modifiée en fonction de contraintes généralement en lien avec ses caractéristiques. Cette section présente un ensemble de scénarios d’élasticité pour les applications retenues comme cas d’usage et présentées ci-avant. Ces scénarios décrivent des évolutions architecturales pour chacune de ces applications. Ils visent à montrer des aptitudes de gestion de l’élasticité permettant de clairement différencier Vulcan par rapport à l’état de l’art actuel.
9.2.1 Scénario n˚1 : Elasticité multi-tiers élémentaire
Ce scénario est basique mais indispensable puisqu’il correspond à l’élasticité adressée par les solutions actuelles. Il s’agit d’une opération de croissance horizontale résultant en l’ajout d’un serveur sur le tiers métier. Appliqué à Springoo, ce scénario est réalisé au travers de l’ajout d’un nouveau serveur Jonas comme illustré par la figure 9.4. Cela per-met pour l’application de pouvoir améliorer l’expérience utilisateur lorsque les serveurs existants commencent à être surchargés.
Ce scénario se justifie par sa représentativité tant au niveau des applications visant à être élastifiées, qu’au niveau de l’état de l’art actuel en matière de gestion de l’élasticité. Il s’agit d’un point de repère pour l’évaluation de Vulcan. Les scénarios qui suivent sont plus poussés.
Dans ce schéma, les rectangles de couleurs représentent des composants applicatifs, tandis que les rectangles oranges avec des bords arrondis correspondent aux VMs. Cette représen-tation est utilisée dans le reste des schémas de ce chapitre.
Figure 9.4 – Scénario d’élasticité n˚1 : représentation de deux modèles par extension successifs.