Système d administration autonome adaptable: application au Cloud

(1)

Démarche Générale Cloud et Problématique I : Administration SAA et Problématique II : Adaptabilité et Flexibilité Contributions et Validations Conclusion et Travaux futurs

Syst` eme d’administration autonome adaptable:

application au Cloud

Alain TCHANA - [email protected]

IRIT/ENSEEIHT, Equipe SEPIA

Directeur de th` ese : Daniel HAGIMONT et Laurent BROTO Rapporteurs : Jean-Marc MENAUD et No¨ el DE PALMA

Examinateurs : Michel DAYDE et Maurice TCHUENTE

29 Novembre 2011

(2)

Conclusion et Travaux futurs

D´ emarche G´ en´ erale

2 / 35 Alain TCHANA - [email protected]

(3)

Etape 1 ´

(4)

Cloud : Contexte

Cloud Computing : nouvelle approche d’h´ ebergement Avantages pour les Clients

Paiement ` a l’usage (Pay-As-You-Go) Moins d’investissement

Economie ´

Avantages pour le Fournisseur Mutualisation de ressources

Donc : gain (et moins de gaspillage)

Figure – Deux visions du cloud

(5)

Cloud Computing : D´ efis

D´ efis

Isolation (d´ efaillance, ressources, performance) : par virtualisation

Portabilit´ e et Interop´ erabilit´ e : par standardisation Administration

Administration ` a deux niveaux IaaS : administrateur du cloud

Applications clientes : administrateur entreprise

Figure – Niveaux d’administration dans le cloud

(6)

Cloud Computing : Administration

Niveau IaaS

D´ eploiement : gestion des images (OS de VM), allocation de machines (placement)

Configuration et D´ emarrage : r´ eseaux, VM

Gestion dynamique : monitoring, consolidation (migration), gestion des pannes

Niveau application cliente

D´ eploiement : images de VM et logiciels

Configuration et D´ emarrage : allocation de VM et logiciels Gestion dynamique : monitoring, r´ eparation, scalabilit´ e (r´ eplication), etc.

Solution : Syst` eme d’Administration Autonome (SAA)

(7)

Etape 2 ´

(8)

SAA

Syst`eme d’administration d’autres syst`emes informatiques Fournit les services de

D´eploiement de logiciels Configuration et D´emarrage Monitoring et Reconfiguration Exemples : Unity, Jade, TUNe, ...

Figure – Organisation g´ en´ erale d’un SAA

(9)

Cas du SAA TUNe

D´ evelopp´ e au sein de notre ´ equipe Inspir´ e de Jade, ` a composants Machine ` a langages (profils UML)

ADL : Classes UML pour la description de logiciels et nœuds WDL : XML pour les comportements des logiciels

RDL : Diagrammes d’´ etat-transition pour les programmes de reconfiguration

Plusieurs exp´ erimentations

Applications J2EE : concluantes

Applications large ´ echelle DIET : modification

Syst` emes virtualis´ es : modification

(10)

Probl´ ematique : TUNe et ses limites

Con¸cu pour des applications maˆıtre-esclave Hypoth` eses fortes sur les ´ el´ ements administr´ es (Comportements cˆ abl´ es)

Difficult´ e de personnalisation

Difficult´ e de supporter de nouveaux langages Probl` emes g´ en´ eralis´ es ` a d’autres

Machine langages (langages d´ edi´ es d’administration) : Rainbow, Accord, Unity ;

Pas de repr´ esentation de l’environnement mat´ eriel : Accord ; Syst` eme de monitoring pr´ ed´ efini : Accord ;

Types d’´ el´ ements administr´ e cˆ abl´ es : Unity ; ...

(11)

Probl´ ematique : TUNe et ses limites

Une nouvelle orientation

S´ eparer les aspects langages et le corps m´ etier du SAA

Adaptabilit´ e ` a ces deux niveaux

(12)

Etape 3 ´

(13)

Contribution et 1^reValidation : TUNeEngine, un SAA Adaptable 2^eValidation : 1) TUNeEngine pour l’administration d’IaaS (CloudEngine) 2^eValidation : 2) Utilisation de TUNeEngine et CloudEngine

TUNeEngine : Orientation g´ en´ erale

Un nouveau SAA suivant 3 directives

Uniformit´ e : pas d’hypoth` eses fortes sur les ´ el´ ements administr´ es. Les ´ el´ ements administr´ es utilisent la mˆ eme repr´ esentation interne quelque soit leur nature.

Adaptabilit´ e : les composants/services du SAA sont modifiables/rempla¸ cables sans maˆıtrise compl` ete du SAA.

Interop´ erabilit´ e et Collaboration : Capacit´ e ` a ´ echanger des informations ou des ordres d’administration avec d’autres SAA distincts.

D´ evelopp´ e suivant une architecture ` a composants Tout service est implant´ e par un composant clairement identifiable.

TUNeEngine : est un SAA d´ evelopp´ e suivant ces directives

(14)

Rappel du mod` ele d’un SAA

Figure – Rappel du mod` ele d’un SAA

(15)

TUNeEngine : Architecture g´ en´ erale

(16)

TUNeEngine : Architecture d´ etaill´ ee

Figure – Mod` ele d´ etaill´ e de TUNeEngine

(17)

TUNeEngine : Implantation bas´ ee sur Fractal

(18)

Plan de validation

1

^re

Validation : TUNeEngine pour une administration cluster Version ´ equivalent des services de TUNe

2

^e

Validation en deux phases

TUNeEngine pour l’administration d’IaaS : CloudEngine Consolidation et placement de VM

TUNeEngine pour l’administration d’applications J2EE dans le cloud

Scalabilit´ e au niveau application

Gestion simultan´ ee de ressources dans les deux niveaux

(19)

Etape 4 ´

(20)

2 ^e Validation : CloudEngine

CloudEngine est r´ ealis´ e en 3 phases :

Construction des briques logicielles fournissant les services de base d’un IaaS

Int´ egration de ces briques ` a TUNeEngine

Personnalisation des composants de TUNeEngine pour l’auto-administration de CloudEngine

(21)

2 ^e Validation : CloudEngine (Services de base)

CloudEngine : Fournit les services de base d’un IaaS Interfa¸ cage avec des hyperviseurs

Gestion des VM, images et VLAN

Optimisation de l’utilisation des ressources

(22)

2 ^e Validation : CloudEngine (Int´ egration ` a l’architecture de TUNeEngine)

(23)

2 ^e Validation : 1) CloudEngine (Personnalisation de

TUNeEngine)

(24)

2 ^e Validation : 1) CloudEngine (Finalit´ e en Fractal)

Figure – Administration dans le cloud avec TUNeEngine et CloudEngine

(25)

Contexte

IaaS : Environnement local, NFS et Syst` eme de virtualisation Xen

Application Cliente : RUBIS (site de commerce en ligne) Emulateur de clients web RUBIS ´

Benchmark pyramidale : mont´ ee, plateau, descente

(26)

Sc´ enario de validation

Figure – Sc´ enario d’´ evaluation

(27)

Contexte de la validation

Scalabilit´ e

Scalabilit´ e non ordonn´ ee Observation du tiers MySQL D´ ecision selon la charge CPU

D´ ecision bas´ ee sur des seuils min et max VM de taille fixe

Placement et Consolidation des VM Placement lors de l’allocation d’une VM Placement par regroupement

Consolidation pendant l’ex´ ecution

Consolidation selon le quota de ressources (CPU et m´ emoire)

r´ eserv´ e

(28)

Sc´ enario

R´ ecapitulatif du sc´ enario

(29)

R´ esultats

(30)

Plusieurs autres cas d’utilisation

Nous en pr´ esentons 2

(31)

Conclusion : Probl´ ematiques

Administration d’une plateforme de cloud Environnement Complexe

H´ et´ erog` ene, Virtualis´ e, ´ Evolutif

Deux niveaux d’administration (IaaS et Application) Deux types d’utilisateurs (Fournisseur et Clients) Solution par l’administration autonome

Unique SAA pour les deux niveaux

Adaptable, Flexible, Collaboratif et Interop´ erable

(32)

Validations

Une version analogue ` a TUNe pour la gestion d’applications sur cluster

Administration d’un cloud

Au niveau des applications Clientes Au niveau de l’IaaS (CloudEngine)

Validation par cas d’utilisation dans le cloud Tol´ erance aux pannes

Gestion de ressources

(33)

Travaux futurs ` a court terme

Application de TUNeEngine dans les clouds existants Extension de CloudEngine

Construction d’images via OVF

Politiques fines de consolidation (Entropy)

Coordination des boucles de contrˆ ole

Gestion des utilisateurs

(34)

Travaux futurs ` a long terme

Support de langages d’administration

yTUNe : ´ Editeur de DSL pour l’administration Construction des DSL propres au cloud Adaptabilit´ e au niveau syst` eme

Cas des hyperviseurs

(35)

Système d administration autonome adaptable: application au Cloud

Syst` eme d’administration autonome adaptable:

application au Cloud

Alain TCHANA - [email protected]

IRIT/ENSEEIHT, Equipe SEPIA

Directeur de th` ese : Daniel HAGIMONT et Laurent BROTO Rapporteurs : Jean-Marc MENAUD et No¨ el DE PALMA

Examinateurs : Michel DAYDE et Maurice TCHUENTE

29 Novembre 2011

D´ emarche G´ en´ erale

Etape 1 ´

Cloud : Contexte

Cloud Computing : nouvelle approche d’h´ ebergement Avantages pour les Clients

Paiement ` a l’usage (Pay-As-You-Go) Moins d’investissement

Economie ´

Avantages pour le Fournisseur Mutualisation de ressources

Donc : gain (et moins de gaspillage)

Figure – Deux visions du cloud

Cloud Computing : D´ efis

D´ efis

Isolation (d´ efaillance, ressources, performance) : par virtualisation

Portabilit´ e et Interop´ erabilit´ e : par standardisation Administration

Administration ` a deux niveaux IaaS : administrateur du cloud

Applications clientes : administrateur entreprise

Figure – Niveaux d’administration dans le cloud

Cloud Computing : Administration

Niveau IaaS

D´ eploiement : gestion des images (OS de VM), allocation de machines (placement)

Configuration et D´ emarrage : r´ eseaux, VM

Gestion dynamique : monitoring, consolidation (migration), gestion des pannes

Niveau application cliente

D´ eploiement : images de VM et logiciels

Configuration et D´ emarrage : allocation de VM et logiciels Gestion dynamique : monitoring, r´ eparation, scalabilit´ e (r´ eplication), etc.

Solution : Syst` eme d’Administration Autonome (SAA)

Etape 2 ´

SAA

Figure – Organisation g´ en´ erale d’un SAA

Cas du SAA TUNe

D´ evelopp´ e au sein de notre ´ equipe Inspir´ e de Jade, ` a composants Machine ` a langages (profils UML)

ADL : Classes UML pour la description de logiciels et nœuds WDL : XML pour les comportements des logiciels

RDL : Diagrammes d’´ etat-transition pour les programmes de reconfiguration

Plusieurs exp´ erimentations

Applications J2EE : concluantes

Applications large ´ echelle DIET : modification

Syst` emes virtualis´ es : modification

Probl´ ematique : TUNe et ses limites

Con¸cu pour des applications maˆıtre-esclave Hypoth` eses fortes sur les ´ el´ ements administr´ es (Comportements cˆ abl´ es)

Difficult´ e de personnalisation

Difficult´ e de supporter de nouveaux langages Probl` emes g´ en´ eralis´ es ` a d’autres

Machine langages (langages d´ edi´ es d’administration) : Rainbow, Accord, Unity ;

Pas de repr´ esentation de l’environnement mat´ eriel : Accord ; Syst` eme de monitoring pr´ ed´ efini : Accord ;

Types d’´ el´ ements administr´ e cˆ abl´ es : Unity ; ...

Probl´ ematique : TUNe et ses limites

Une nouvelle orientation

S´ eparer les aspects langages et le corps m´ etier du SAA

Adaptabilit´ e ` a ces deux niveaux

Etape 3 ´

TUNeEngine : Orientation g´ en´ erale

Un nouveau SAA suivant 3 directives

Uniformit´ e : pas d’hypoth` eses fortes sur les ´ el´ ements administr´ es. Les ´ el´ ements administr´ es utilisent la mˆ eme repr´ esentation interne quelque soit leur nature.

Adaptabilit´ e : les composants/services du SAA sont modifiables/rempla¸ cables sans maˆıtrise compl` ete du SAA.

Interop´ erabilit´ e et Collaboration : Capacit´ e ` a ´ echanger des informations ou des ordres d’administration avec d’autres SAA distincts.

D´ evelopp´ e suivant une architecture ` a composants Tout service est implant´ e par un composant clairement identifiable.

TUNeEngine : est un SAA d´ evelopp´ e suivant ces directives

Rappel du mod` ele d’un SAA

Figure – Rappel du mod` ele d’un SAA

TUNeEngine : Architecture g´ en´ erale

TUNeEngine : Architecture d´ etaill´ ee

Figure – Mod` ele d´ etaill´ e de TUNeEngine

TUNeEngine : Implantation bas´ ee sur Fractal

Plan de validation

1

Validation : TUNeEngine pour une administration cluster Version ´ equivalent des services de TUNe

2

Validation en deux phases

TUNeEngine pour l’administration d’IaaS : CloudEngine Consolidation et placement de VM

TUNeEngine pour l’administration d’applications J2EE dans le cloud

Scalabilit´ e au niveau application

Gestion simultan´ ee de ressources dans les deux niveaux

Etape 4 ´

2 e Validation : CloudEngine

2 ^e Validation : CloudEngine

2 ^e Validation : CloudEngine (Services de base)

2 ^e Validation : CloudEngine (Int´ egration ` a l’architecture de TUNeEngine)

2 ^e Validation : 1) CloudEngine (Personnalisation de

2 ^e Validation : 1) CloudEngine (Finalit´ e en Fractal)