soCloud

soCloud [115, 116, 117, 118] est une solution issue des travaux au de l’Université Lille 1. Cette solution vise à adresser plusieurs problématiques du cloud.

La première de ces préoccupations concerne la résistance aux pannes des services fournis dans le cloud. Face aux problèmes rencontrés chez différents fournisseurs, so-Cloud propose une gestion de la haute-disponibilité basée sur la mise en place automa-tique de répliquas pour chaque application. Ces répliquas sont répartis dans plusieurs clouds de sorte à palier les problèmes de panne pouvant se produire chez un ou plusieurs fournisseurs.

Une deuxième problématique est la résilience. Celle-ci augmente la première : soCloud propose un mécanisme permettant la résilience en se basant à la fois sur son mécanisme de réplication, mais également par la détection des pannes et le retour vers un état fonctionnel.

Une troisième problématique que soCloud adresse est l’enfermement propriétaire. soCloud opère au sein de différentes offres de cloud de façon uniforme : les applications ne sont ainsi pas liées à un ou plusieurs services spécifiques à une offre. Par ailleurs, cette uniformité permet aux utilisateurs de soCloud de ne pas devoir gérer eux-mêmes différentes APIs et plateformes d’administration.

Enfin, une problématique importante du cloud actuellement, remise en lumière par les récentes actualités relatives à la confidentialité des données est la maîtrise des em-placements d’exécution. Il s’agit pour un utilisateur d’avoir un contrôle total sur la destination géographique lors du déploiement de son application.

SoCloud propose une boucle complète d’élasticité qui s’appuie sur une plateforme multi-cloud. Une originalité de soCloud réside dans sa mise en place transparente de la haute-disponibilité et de la résilience. Afin de mener à bien sa tâche, soCloud utilise les composants principaux suivants :

• Le Monitoring est un composant réparti sous la forme d’agents au sein des dif-férentes VMs que compte une application. Il remonte par défaut un ensemble de métriques telles que l’occupation CPU, l’occupation mémoire ou l’utilisation CPU et mémoire par processus. Par ailleurs, ce composant est essentiel afin de repérer les pannes au sein des VMs applicatives.

• Le Workload Manager se situe en aval du monitoring. Il a la charge de récupérer et stocker les données du monitoring. Il a également pour rôle d’agréger les données de sorte à pouvoir fournir des indicateurs de dérive. Par exemple, le workload manager peut signaler une occupation CPU trop importante sur les cinq dernières minutes. Ce type d’alerte est ensuite remonté au Controller,

• Le Controller est le composant de soCloud chargé de la décision. A partir des indications de dérives remontées depuis le workload manager, le controller décide des actions correctrices à mener. Ces actions sont répercutées sur l’application au niveau applicatif et au niveau des clouds par le biais d’actionneurs adaptés.

Le controller offre par ailleurs différents services qui facilitent l’utilisation de so-Cloud ainsi que l’administration des applications déployées comme un service de géo-localisation qui réalise une répartition géographique des accès. Un autre service est l’éclatement de bases de données relationnelles de sorte à ce qu’elle soit répartie et passe bien à l’échelle. Le controller gère également les problèmes de crédences ou de création de graphiques montrant les métriques du monitoring et les données agréges du workload manager.

• Le Load Balancer est le composant qui permet la mise en œuvre pratique de la haute-disponibilité, de la résilience et de l’élasticité. Ce composant gère la répar-tition de charge et fait office de proxy pour des flux TCP et HTTP. Sa gestion des flux TCP en plus des flux HTTP est clairement à l’avantage de soCloud.

Modèle d’application

Le modèle d’application de soCloud repose sur SCA (Service Component Architecture), le standard du consortium international OASIS relatif aux architectures SOA (Service Oriented Architecture). De façon plus précise, soCloud utilise FraSCAti [135, 136], une implantation des spécifications SCA basée sur le modèle de composants Fractal. FraS-CAti offre des capacités de réflexivité à SCA ce qui est un atout important pour son utilisation dans soCloud. FraSCAti adresse la composition de services à destination de composants marqués par une forte hétérogénéité de langages et de canevas. Cette com-position est décrite au travers d’un fichier renseignant l’architecture de l’application ainsi que les différentes règles et contraintes d’élasticité.

Le recours à FraSCAti souligne deux limites de la solution. Tout d’abord, la liste des langages et canevas couverts est importante puisque FraSCAti permet à soCloud de supporter les interfaces écrites en WSLD et Java. Les langages et canevas supportés sont Java, Groovy, BPEL, EJB, OSGI, Spring, Xquery, Jython, Jruby, Fscript, Beanshell et Velocity. Cependant, à notre connaissance, il n’est pas possible de gérer des applications écrites par exemple en PHP, Ruby On Rails, ou même Node.js. Une seconde limite est a priori plus gênante : elle concerne la nécessité d’avoir une application ayant une architecture SCA. Il s’agit d’une limite identifiée pour laquelle le recours à des wrappers permettrait de conserver les atouts de SCA et FraSCAti au niveau de la gestion des composants et services tout en repoussant cette limite. De fait, cette même limite peut être rédhibitoire à l’égard d’applications ne pouvant pas être modifiées.

Opérations d’élasticité couvertes

soCloud gère une gamme très complète d’opérations d’élasticité qui incluent à la fois les opérations de croissance et décroissance horizontale, mais également les opérations de croissances et décroissances verticales. Il s’agit là d’un point fort de la solution claire-ment différenciateur par rapport à d’autres solutions existantes. soCloud gère ainsi des opérations de scale out sur un type de composant. L’opération inverse consiste en un scale in sur ce même type de composant. Il est à noter que la seconde opération est

3.3. SOLUTIONS DE GESTION COMPLÈTE DE L’ÉLASTICITÉ 65 exactement l’inverse de la première : elle permet de faire revenir l’application dans l’état exact d’avant le scale out. Il en est de même pour les opérations d’élasticité verticales. Architecture applicative

Nous n’avons pas identifié de point d’accès ou d’API offrant une vision de l’architec-ture de l’application durant son exécution. Cette limite peut, par exemple, être gênante pour un administrateur ou un développeur voulant aller consulter les journaux système présents sur les VMs de l’application à des fins de debug. En revanche, un point fort de soCloud réside dans la modélisation de l’élasticité d’une application. La solution in-troduit effectivement une description permettant de mentionner des règles d’élasticité et les modalités d’exécution des opérations élastiques. Les règles d’élasticité permettent de spécifier les décisions prises par soCloud à partir de l’expression des actions à entre-prendre en cas de dépassement de seuils. Ces règles ont l’avantage d’être extensibles et peu verbeuses. Par ailleurs, le modèle proposé dans soCloud permet à l’utilisateur de spécifier sous la forme d’annotations, les modalités de réalisation des décisions au travers d’un Domain Specific Language (DSL) non-extensible.

Gestion du placement

Les annotations proposés dans soCloud permettent une gestion très fine des placements : il est possible de spécifier le profil matériel des VMs à utiliser, des cardinalités maxi-males, le nombre de répliquas ou encore des emplacements géographiques précis pour le déploiement des composants de l’application. Là encore, il s’agit d’un point fort pour soCloud.

Positionnement par rapports aux critères

L’évaluation de soCloud montre qu’il s’agit d’une solution très complète par rapport aux critères considérés.

• L’Indépendance applicative est Forte. soCloud ne souffre d’aucune limite en matière de gestion de types d’applications. Il faut toutefois modérer cette évaluation face à l’absence de gestion de certains langages et canevas populaires. Un point intéressant de soCloud réside dans son load balancer : alors que ce type de composant introduit des limites sur ce critère pour d’autres solutions étudiées dans ce manuscrit, ce n’est pas le cas ici.

• L’Indépendance architecturale est évaluée à Faible. L’évaluation de ce critère pro-vient de la spécificité de soCloud au type d’architecture SCA et face à la faible utilisation de ce standard. Une couche de wrappers permettrait de faire remonter l’évaluation de ce critère à Forte.

• L’Indépendance vis-à-vis de l’environnement est Forte. Il s’agit évidemment d’un des gros points forts de la solution puisqu’aucune limite n’est notée en matière de

capacité d’accès à quelque cloud que ce soit. Par ailleurs, soCloud gère le déploie-ment d’une même application au sein de plusieurs clouds en même temps.

• Gestion des applications patrimoniales : la gestion des seules applications ayant une architecture SOA est une limite identifiée. Une application ne pouvant être modifiée ne peut être gérée par soCloud, ce critère est évalué à Faible. Ici encore, l’introduction de wrappers offrirait potentiellement une évaluation à Forte. • La Granularité des opérations est évaluée à Bonne puisque soCloud permet des

opérations d’élasticité verticale sans toutefois offrir une finesse au niveau du com-posant.

• L’évaluation retenue pour la Modélisation à l’exécution est Faible car il ne semble pas possible pour un utilisateur de la solution d’avoir connaissance de l’architecture de son application en cours d’exécution.

• Concernant l’évaluation de la Modélisation de l’élasticité,celle-ci est Forte grâce à une expression explicite complète.

• L’Expression de contraintes est évaluée à Bonne en raison de la possibilité d’ex-primer des contraintes complexes telles que le placement, le nombre de répliquas ou le profil matériel des VMs. Il faut toutefois noter que les contraintes d’élasticité exprimées sous la forme d’annotations ne sont apparemment pas extensibles. De même les notions de cardinalités sur les liaisons semblent restreintes.

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