Test n˚3 : Elasticité verticale de l’application Springoo

10.4 Test n˚3 : Elasticité verticale de l’application Springoo

Relatif au scénario n˚3, ce test vise à montrer les capacités de Vulcan à gérer l’élasticité verticale. De façon plus précise, cela implique de :

1. Placer chaque composant dans une VM. 2. Placer chaque VM dans un IaaS.

3. Choisir le profil de VM adapté en fonction d’un profil matériel minimal et des profils proposés par le IaaS choisi.

4. Mettre à jour le profil de VM lorsque cela est requis comme c’est le cas lors d’une opération de (dé)croissance verticale.

Dans ce test, Vulcan doit donc résoudre plusieurs contraintes de placements et de confi-gurations (pour le profil des VMs, en plus de celles déjà existantes pour les liaisons applicatives. La figure 10.6 montre les différentes étapes du test pour le modèle par intention exposé dans le listing 10.2.

Figure 10.6 – Succession des différentes étapes du test n˚3

Dans la figure 10.6, les IaaS sont représentés par des rectangles violets avec des coins arrondis. Dans ce test, deux Iaas sont utilisés afin d’illustrer un cas de choix de placement pour les VMs. Ces IaaS correspondent pour l’un au IaaS OpenStack précédemment utilisé pour l’intégration VAMP-Vulcan, et pour l’autre à un datacentre dernière génération d’Orange.

Listing 10.2 – Modèle par Intention du test n˚3

1

2 <!−− l e s b a l i s e s d e l i m i t a n t l e s r e q u e t e s s o n t a b s e n t e s pour f a c i l i t e r l a l e c t u r e −−>

3 <components>

4 <component name=" Apache " i n i t=" 0 " />

5 <component name=" J o n a s " i n i t=" 0 " /> 6 <component name="MySQL" i n i t=" 0 " /> 7 </components> 8 <containers> 9 <container name="vm" i n i t=" 0 " /> 10 <container name=" i a a s " i n i t=" 0 " /> 11 </ containers> 12 13 <bindings> 14 <!−− l i a i s o n Apache [ 1 ]−[ 1 . . ∗ ] J o n a s −−> 15 l o c a l : b i n d E x a c t l y O n e A l l ( " Apache " , " J o n a s " ) 16 <!−− l i a i s o n J o n a s [ 1 . . ∗ ]−[ 1 ]MySQL −−> 17 l o c a l : b i n d A l l E x a c t l y O n e ( " J o n a s " , "MySQL" ) 18 </bindings> 19 20 <placements>

21 <!−− p l a c e r chaque composant dans s a p r o p r e VM −−>

22 l o c a l : placeOneOne ( )

23 <!−− aucune VM v i d e a u t o r i s e e −−>

24 l o c a l : p u r g e E m p t y C o n t a i n e r s ( "vm" )

25 <!−− p l a c e r chaque VM c o n t e n a n t un composant Apache , J o n a s ou MySQL

26 dans un I a a S p r e c i s ( r e c o n n u p a r s o n i d e n t i f i a n t l o g i q u e ) −−> 27 l o c a l : p l a c e A l l C o n t a i n e r s C o n t a i n i n g T y p e s O f I n s t a n c e s ( "vm" , " i a a s " , 28 " i d " , " i a a s _ v a l−de− r e u i l " , 29 ( " Apache " , " J o n a s " , "MySQL" ) ) 30 </placements> 31 <c o n f i g u r a t i o n s> 32 <!−− p r o f i l minimal pour l e s VMs −−> 33 l o c a l : s e t C o n t a i n e r s P r o f i l e s B y I n s t a n c e s C o n t a i n e d ( "vm" , 34 ( " Apache " , " J o n a s " , "MySQL" ) ,

35 )

36 <!−− m i s e a j o u r d e s p r o f i l s de VMs : E l a s t i c i t e V e r t i c a l e −−> 37 l o c a l : a p p l y V e r t i c a l E l a s t i c i t y ( "vm" , " i a a s " ) 38 <!−− a d r e s s e i p p u b l i q u e s u r t o u t composant Apache −−> 39 l o c a l : s e t P u b l i c I p O n ( ( " Apache " ) , "vm" ) 40 </ c o n f i g u r a t i o n s> 41

Le lecteur pourra noter qu’aucun IaaS n’est stocké directement dans le modèle par intention : les IaaS peuvent ainsi être connus lors de l’exécution, de même que les profils matériels qu’ils proposent à leur clients. La prise en compte des IaaS est dynamique mais comme le montre cet exemple, il est possible de maîtriser le IaaS de destination, puisque la contrainte - écrite de la ligne 25 à la ligne 27 - renseigne un identifiant précis de IaaS

10.4. TEST N˚3 : ELASTICITÉ VERTICALE DE L’APPLICATION SPRINGOO 161 à utiliser : cela est lié à cette contrainte et résulte donc d’un choix utilisateur.

Le non-renseignement des IaaS dans le modèle par intention permet non seulement une connaissance dynamique des IaaS mais aussi de garantir une certaine facilité d’uti-lisation. La connaissance des IaaS disponibles est réalisée dans l’étape n˚1 au travers d’une simple addition de conteneur de type IaaS par la même API que celle fournie à la brique d’Analyse. Pour chaque IaaS, les propriétés renseignées spécifient l’identifiant et les profils matériels disponibles. Le modèle par extension obtenu est visible dans le listing 10.3. Il mentionne les deux IaaS cités ci-avant.

Listing 10.3 – Modèle par Extension de l’étape n˚1 du test n˚3

1 <e x t e n s i o n a l M o d e l>

2 <container t y p e=" i a a s " name=" 2 ">

3 

4 <v a l u e>

5 

6 

7 

8 </ v a l u e>

9 

10 

11 <v a l u e>o p e n s t a c k−dev</ v a l u e>

12 

13 </container>

14 <container t y p e=" i a a s " name=" 1 ">

15 

16 <v a l u e>

17

18

19

20

21

22

23 </ v a l u e>

24 

25 

26 <v a l u e>i a a s _ v a l−de− r e u i l</ v a l u e>

27 

28 </container>

29</ e x t e n s i o n a l M o d e l>

Durant le test n˚3, les profils des VMs sont donc choisis parmi ceux des IaaS rensei-gnés. Le choix du IaaS est spécifié par contrainte dans le modèle par intention de même que la détermination du profil adapté pour les VMs. Au cours des tests, ce profil est modifié pour un serveur Jonas et le serveur MySQL comme illustré aux étapes n˚3, 4 et 6 par le schéma 10.6. Les performances obtenues sont quant à elles visibles dans le diagramme 10.7. Celui-ci montre que les opérations d’élasticité se répartissent en trois ensembles :

1. Les étapes n˚3, 4 et 6 ont des mesures et des répartitions très similaires. Celles-ci correspondent à des opérations de (dé)croissance verticale portant sur une VM. Les durées de la planification durant ces étapes se situent ici entre 133 et 153 millisecondes ce qui est rapide. L’étape n˚1 est également similaire, mais son cas est un peu à part en raison de la nature de l’opération traitée.

2. Les étapes n˚2 et 5 correspondent à des opérations d’élasticité horizontale avec pour la première l’ajout d’un composant Apache dans un modèle ne comprenant que des conteneurs de type iaas (ce qui entraine l’ajout d’un composant Jonas et d’un MySQL), et pour la seconde, l’ajout d’un composant Jonas au tiers métier. Ces deux étapes requièrent des révisions pour des ajouts de VMs et leurs durées mesurées sont respectivement de 199 et 230ms ce qui est également rapide. 3. L’étape n˚1 qui est un peu à part en raison de sa nature.

Les relevés pour ce test n˚3 montrent la rapidité d’exécution de Vulcan pour l’élasticité verticale. Il est à noter qu’un scénario non-montré dans ce test est adressé par Vulcan : il s’agit d’une gestion concomitante de l’élasticité verticale ET horizontale. Vulcan permet effectivement de réaliser concomitamment les deux types d’élasticité ce qui est un différenciateur supplémentaire.

Figure 10.7 – Performances de Vulcan sur le Scénario n˚3 pour l’application Springoo : le temps de calcul est donné en millisecondes, en fonction des étapes

Au cours du test n˚3, Vulcan a démontré ses capacités de gestion de l’élasticité verticale. Plus que cela, il a démontré sa capacité à offrir une connaissance dynamique du cloud par une liste de IaaS fournie durant l’exécution. Grâce à cette connaissance à chaud Vulcan se définit comme une solution à la fois simple d’usage, dynamique et réaliste. Enfin, sa gestion concomitante des deux types d’élasticité est un avantage par rapport aux solutions existantes. Par ailleurs, il est à noter que des scénarios d’élasticité

10.4. TEST N˚3 : ELASTICITÉ VERTICALE DE L’APPLICATION SPRINGOO 163 à la granularité composant ont également concernés Springoo : à partir d’un déploiement initial sur deux VMs où un serveur Apache et un serveur Jonas étaient colocalisés sur la même VM, l’application était élastifiée en répartissant chacun des composants dans sa propre VM avant de revenir à l’état initial. Ce scénario a été mené à bien sur une instance réelle de Springoo grâce au Vulcan Deployer et sur un cluster d’hyperviseurs Virtualbox. Le test qui suit aborde une autre capacité différenciatrice de Vulcan : l’élasticité profilée.

Dans le document Planification pour la gestion autonomique de l'élasticité d'applications dans le cloud (Page 180-185)