• Aucun résultat trouvé

B.2 Règles à base des seuils niveau SaaS

5.14 Méthode de planification de capacité

de fournisseur SaaS (minimiser le coût de service et minimiser les violations SLA).

La valeur de workload dépend de la nature de l’analyse : valeur courante observée (analyse réactive) et valeur future suite à un appel au composant Forecaster (analyse proactive). La méthode de planification de capacité (voir Figure 5.14) se compose de trois algorithmes principaux : i)getUpperBound, iii)getDemandedCapacityet getOptimal-Capacity.

coût faible. Pour cette fin, nous introduisons deux algorithmesgetUpperBoundet getDe-mandeCapacity.

La méthode de planification de la capacité vérifie d’abord si la capacité courante garantit les objectifs de niveau de services pour la demande. Si les objectifs sont ga-rantis, nous considérons que les valeurs actuelles de Km (m = 1, ...,M) comme borne supérieure et l’algorithme getDemandedCapacity sera invoqué. Sinon, en cas de viola-tion, nous augmentons le nombre des instances affectées à tous les tiers de l’application Cloud jusqu’à trouver une valeur de Km qui réponde aux objectifs de niveau de ser-vices. Nous utilisons notre modèle analytique à chaque incrémentation pour calculer les performances (voir Algorithme5).

Algorithme 5:getUpperBound

Input: M,Km,MPLm,SLAc,Nc,Zc,Scm,Vcm(m=1, ..M,c=1...C) Output: Km,MPLm(m=1, ..M)

1 c,αc,ω)=per f ormance(...);

2 whileρC!=1do

3 for m=1toMdo

4 Km++;

5 if m==1then

6 MPLm=

PC c=1NcVc,m

Km ;

7 else

8 MPLm= MPLmK−1Km−1

m ;

9 c,αc,ω)=per f ormance(...);

10 return Km, MPLm(m=1, ..M)

De la borne supérieure trouvée deKm, l’algorithmegetDemandedCapacityestime la capacité demandée. Nous définissons la capacité demandée comme la valeur minimum deKm. Pour estimer efficacement la valeur minimale deKm, une recherche dichotomique sur l’intervalle [1..Km] est effectuée comme mentionné dans l’algorithme6.

La ligne 4 modifie la valeur deKm. LeMPLm est ajusté en conséquence (lignes 5-8) pour répartir la demande sur lesKminstances par tier. Nous distinguons deux cas après l’invocation de notre algorithme de performance : i) les objectifs (SLOs) sont garantis donc nous diminuons la borne Kmax (ligne 11), ou ii) les objectifs (SLOs) ne sont pas garantis. Dans ce cas, nous différencions entre le dépassement de seuil de disponibilité (lignes 13-14) et le dépassement de seuil de temps de réponse (lignes 15-29).

Le dépassement de seuil de disponibilité reflète soit des priorités mal ajustées ou une capacité insuffisante. Nous traitons en particulier la deuxième cause en augmen-tant la borneKmin(ligne 14).

Le dépassement de seuil de temps de réponse signifie que le contrôle d’admission est mal paramétré. Nous utilisons une recherche dichotomique pour calculer les valeurs deMPLm pour chaque tier. Le raisonnement est le même. Nous modifions la valeur de MPLm(ligne 20). L’invocation de notre algorithme de performance permet d’ajuster les bornesMPLmax(ligne 23) etMPLmin(ligne 25).

Après l’ajustement deMPLm, si les objectifs sont garantis, nous réduisons la borne Kmax (ligne 27) sinon nous augmentons Kmin (ligne 29). L’algorithme poursuit la re-cherche dans le nouvel intervalle.

Algorithme 6:getDemandedCapacity

Input: M,Km,MPLm,SLAc,Nc,Zc,Scm,Vcm(m=1, ..M,c=1...C) Output: Km,MPLm(m=1, ..M)

1 for m=1toMdo

2 Kmin=1;Kmax=Km;

3 while Kmin!=Kmaxdo

4 Km =Kmin+Kmax2Kmin;

5 ifm==1then

6 MPLm=

PC c=1NcVc,m

Km ;

7 else

8 MPLm= MPLmK−1Km−1

m ;

9 c,αc,ω)=per f ormance(...);

10 ifρC==1then

11 Kmax=Km;

12 else

13 ifone o f(αc > αmax,c)then

14 Kmin=Km+1;

15 else

16 for mm=1toMdo

17 MPLmin=1;

18 MPLmax=MPLmm;

19 while MPLmin!=MPLmaxdo

20 MPLmm=MPLmin+MPLmax2MPLmin;

21 c,αc,ω)=per f ormance(...);

22 ifρC==1then

23 MPLmax=MPLmm;

24 else

25 MPLmin=MPLmm+1;

26 ifρC==1then

27 Kmax=Km;

28 else

29 Kmin=Km+1;

30 return Km, MPLm(m=1, ..M)

ii) Capacité optimale

La capacité optimale est le résultat de l’application des politiques de gestion de l’élas-ticité sur la capacité demandée (voir Algorithme 7). Dans un premier temps, nous calculons la différence entre la capacité (configuration) courante et la capacité deman-dée afin d’identifier les ajustements nécessaires. La capacité optimale est le résultat de zéro ou plusieurs ajustements : ajustement de contrôle d’admission ou ajustement des ressources.

Algorithme 7:getOptimalCapacity

Input:currentCapacity,demandedCapacity,Min,Max,instanceTime Output:Km,MPLm(m=1, ..M)

1 for m=1toMdo

2 MPLm=demandeCapacity.getMPL(m);

3 Km=demandeCapacity.getK(m);

4 delta=di f f(currentCapacity,demandedCapacity);

5 if addthen

6 if demandedCapacity>Maxthen

7 Noti f ication;

8 Km=min(demandeCapacity,Max);

9 if removethen

10 if demandedCapacity<Minthen

11 Noti f ication;

12 if currentCapacity==Minthen

13 Noti f ication;

14 else

15 for m=1toMdo

16 Km=currentCapacity.getK(m);

17 if delta.getK(m)!=0then

18 for k=1tocurrentCapacity.getK(m)do

19 if (durationi%instanceTime)>(0,95.instanceTime)then

20 toTerminatem.add(i);

21 toTerminatem.sort();

22 Km=Kmmin(toTerminatem.sort(),delta.getK(m));

23 if one o f(Km!=demandeCapacity.getK(m))then

24 for m=1toMdo

25 if m==1then

26 MPLm=

PC c=1NcVc,m

Km ;

27 else

28 MPLm= MPLm−1Km−1

Km ;

29 returnKm, MPLm(m=1, ..M)

Nous distinguons 3 cas possibles d’ajustement des ressources :

Ajout des ressources (scale up, scale out) : La capacité optimale est limitée par la politiqueInfrastructure Elasticity (la capacité maximum pré-definie). Dans le cas où la capacité demandée est supérieure à la capacité maximum autorisée, une notification sera déclenchée.

Suppression des ressources (scale down, scale in) : La capacité optimale est diri-gée par la stratégie "UaP" (si elle est activée). Une instance sera supprimée si elle a consommé plus de 95% de son temps-instance. Nous vérifions, également, la capacité minimale.

Ajout et suppression: Nous distinguons deux possibilités :i) ressources homogènes entre tiers, ii) ressources hétérogènes entre tiers. Si les ressources sont homogènes, une migration des instances entre tiers est possible. Dans ce travail, nous utilisons des res-sources hétérogènes entre tiers.

A la fin de l’algorithme, si la capacité optimale est différente de la capacité demandée, nous adaptons les valeurs de MPL avec la capacité optimale pour ajuster le contrôle d’admission.

Algorithme 8:getDemandedArchitecture

Input: mode,modei,j(i=1, ..I,j=1...J) Output: modei,j(i=1, ..I,j=1...J)

1 for i=1toIdo

2 for j=1toJdo

3 if Li,j>1then

4 modei,j=mode;

5 return modei,j(i=1, ..I,j=1...J)

Algorithme 9:getAppropriateArchitecture

Input: event,context

Output: modei,j(i=1, ..I,j=1...J)

1 if event==thresholdExceedingthen

2 mode=degraded;

3 else if event==endDegradationDurationthen

4 per f ormance(mode=normal,context);

5 ifρC==1then

6 mode=normal;

7 else ifevent==activateInstancesthen

8 mode=normal;

9 getDemandedArchitecture(mode, ...);

10 return modei,j(i=1, ..I,j=1...J)

5.5 Synthèse

Ce chapitre détaille les éléments de base de la solutionHybridScalequi fournissent des réponses aux limitations soulevées au niveau des travaux de l’état de l’art à savoir prin-cipalement : la non-considération du modèle économique en particulier la facturation et la non-prise en compte du temps d’initialisation des ressources.

HybridScaleest basé sur une boucle autonomique pour automatiser et optimiser en continue la gestion de capacité des ressources. D’abord, nous avons présenté BestPo-licies : des politiques de gestion de l’élasticité. Ces politiques permettent de contrôler l’analyse. L’originalité de BestPolicies repose principalement sur trois types de poli-tiques : i) les polipoli-tiques de prix, ii) les polipoli-tiques de réaction et iii) les polipoli-tiques de dimensionnement. En particulier, nous proposons la stratégie de terminaison pour harmoniser le dimensionnement automatique avec le modèle économique (facturation à l’heure).

Nous avons proposé dans le chapitre précédent deux solutions à savoir la dégrada-tion de QdS et la dégradadégrada-tion de foncdégrada-tionnalité pour absorber le temps d’initialisadégrada-tion des ressources. Dans ce chapitre, nous consolidons notre solution avec la prédiction de la charge du travail. Nous proposons une technique de prédiction basée sur les séries chronologiques. Notre technique de prédiction permet de générer les futures charges en paramétrant aisément les intervalles/fenêtres de prédiction.

Enfin, nous avons proposéRightCapacity: une méthode de planification de capacité de ressources dirigée par SLA. L’originalité de RightCapacity réside dans la

planifica-tion multi-couches (cross-layer). Il prend compte deux niveaux à savoir : l’applicaplanifica-tion (SaaS) et l’infrastructure (IaaS). Au niveau infrastructure, notre méthode de planifica-tion est basée sur la théorie des files d’attente. Elle calcule la capacité des ressources optimale. Notre méthode est suffisamment générale pour modéliser n’importe quelle application Web déployée sur le Cloud. Au niveau application, notre méthode de pla-nification, calcule l’architecture logicielle appropriée.

6

Prototype HybridScale et expérimentations

Dans le chapitre précédent, nous avons présenté les éléments de base pour mettre en œuvre un auto-dimensionnement dirigé par SLA. Nous nous intéressons dans ce chapitre à présenter et à expérimenter notre prototype de recherche pour valider nos contributions autour d’HybridScale.

Nous commençons par détailler notre prototype HybridScale : un framework de dimensionnement automatique. La réutilisabilité des élements d’HybridScale comme l’intégration des politiques de gestion de l’élasticité (BestPolicies) dans une solution de dimensionnement existante comme Amazon Auto-Scaling est détaillée en annexe B. Ensuite, nous proposons un certain nombre d’expérimentations pour valider notre contribution dans l’environnement IaaS Amazon EC2.

Sommaire

6.1 PrototypeHybridScale . . . 130 6.1.1 Boucle de contrôle MAPE-K. . . 130 6.1.2 Cycle de vie du gestionnaire autonome . . . 135 6.1.3 Implémentation . . . 136 6.2 Expérimentations . . . 139 6.2.1 Protocole d’expérimentation . . . 139 6.2.2 Résultats . . . 141 6.3 Synthèse . . . 148

129

La Figure6.1illustre le méta-modèle de boucle de contrôle MAPE-K. Le gestionnaire au-tonome exécute une séquence de tâches auau-tonomes (AutonomicTask) [Hor01], qui sont déclenchées lors d’un événement donné et en tenant compte de sa base de connais-sances (Knowledge).

Le gestionnaire autonome observe les informations remontées via des capteurs (Mo-nitor). Il utilise ses données et sa connaissance interne pour analyser (Analyzer), planifier (Planner) et exécuter (Executor) des actions pour atteindre un objectif déterminé. Les actions sont exécutées via des actionneurs.