Boucle de contrôle MAPE-K

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.

Figure6.1 – Méta-modèle MAPE-K

i) Surveillance - Monitor

Le monitor permet de collecter les informations sur le système (workload, performance, application et ressources) via des sondes. Nous proposons deux modes de collecte :Pull etPush(voir Figure6.2).

a)Pull

Le mode Pull consiste à fournir des mesures en se basant sur des sondes. Nous dis-tinguons plusieurs types de sondes dédiées au Workload (quantité de charge, temps

d’attente), SLA (temps de réponse, disponibilité), Application (mode de chaque ser-vice) et Infrastructure (nombre de réplicas pas tier, MPL associé).

Les sondes collectent des mesures selon le modePullà des intervalles réguliers (par exemple 5 secondes). Ces informations peuvent être agrégées pour fournir une seule valeur (moyenne, minimum, maximum ou f()) sur une fenêtre de temps (par exemple, la moyenne de temps des réponses sur une fenêtre d’une minute). Ces données seront en-voyées par leMonitorà l’Analyzerd’une manière régulière via le gestionnaire autonome.

Les valeurs des intervalles et fenêtres dépendent du type d’application (e-commerce, calcul scientifique) et la nature de son workload (aléatoire, cyclique, événementiel).

b)Push

Le modePushpermet de notifier les événements suivants : Le cycle de vie d’une instance :

• instance-activated informe de la mise en fonctionnement d’une instance. Cette notification permet le retour en mode normal.

• instance-fullTime annonce la fin de la période-instance pour chaque instance du système (stratégie de terminaisonUaP). Elle est envoyée avant la fin de la période pour prendre une décision.

Le cycle de vie de dimensionnement

• scaling-calmStartedmentionne le début d’une période de calme.

• scaling-calmEndedavertit la fin d’une période de calme.

Le cycle de vie d’une application

• application-degradationPeriodEndedindique la fin de l’utilisation du mode dégradé.

Cette notification permet le retour en mode normal.

Le cycle de vie de SLA

• sla-thresholdExceededcapture un dépassement de seuil d’un SLO. Cette notification déclenche le mode dégradé.

Dans le prototype actuel, pour des raisons de coordination entre événements notifiés et cycle de vie de la boucle autonomique, les notifications seront enregistrées dans une base de données nommée base de notifications et lues de façon synchrone par le gestionnaire autonome.

ii) Analyse - Analyze

La Figure6.3illustre le méta modèleAnalyzer. Les informations collectées par leMonitor sont envoyées à l’Analyzerrégulièrement. Ce dernier traite les informations via la mé-thodeRightCapacityde diverses manières : proactive et/ou réactive selon les politiques

Figure6.2 – Méta-modèle Monitoring

de gestion de l’élasticité. L’originalité de notreAnalyzerest d’adresser le multi-couches (cross-layer). Il prend en compte deux niveaux à savoir : l’application (SaaS) et l’infra-structure (IaaS).

a) Réactive, proactive, hybride

Réactive: L’analyse réactive consiste à prendre des décisions en fonction de la demande courante. La dégradation de fonctionnalité est utilisée conformément à la politique Ap-plication Elasticitypour absorber les petits pics des charges ainsi que le démarrage des instances.

Proactive: L’analyse proactive consiste à ajuster la capacité en se basant sur la future demande. Notre solution de prédiction, développée précédemment dans le chapitre5, estime la future charge. En cas d’une erreur de prédiction, il n’y a pas de réaction particulière à faire. La terminaison des instances est dirigée par le contexte courant en corrélation avec la base des notifications (instance-fullTime).

Hybride : Cette analyse mélange une réaction proactive et une réaction réactive.

Par défaut, l’analyse proactive permet d’anticiper une augmentation possible de ca-pacité d’une manière régulière. L’analyse réactive permet de corriger les erreurs de prédiction et/ou terminer des instances en se basant sur le contexte courant. Elle est activée si l’Analyzerlit une notification dans la base des notifications. L’analyse réactive est exécutée avant l’analyse proactive. Cette dernière considère le résultat de l’analyse réactive comme contexte courant.

b) Capacité optimale, architecture appropriée

Capacité optimale : Les politiques (BestPolicies) encadre le processus d’analyse. La capacité optimale est le résultat de l’application des politiques de gestion d’élasticité sur la capacité demandée.

Architecture appropriée : L’architecture appropriée est calculée en fonction des événements liés à la performance ou aux actions de dimensionnement. En cas de dépassement d’un seuil d’un objectif ou une action d’ajout des ressources, l’architecture appropriée passe en mode dégradé.

Figure6.3 – Méta-modèle Analyze iii) Planification - Plan

Après avoir étudier l’état (courant et/ou futur) du système via l’Analyzer, le Planner prépare le plan d’actions. Nous distinguons entre deux types d’actions immédiates et différées. Le plan est le résultat de zéro ou plusieurs actions (ajustements ou notifica-tions) immédiates et/ou différées (voir Figure6.4).

Figure6.4 – Méta-modèle Plan a) Actions

Immédiates: Les actions immédiates sont calculées en fonction de la différence entre la capacité courante et la capacité optimale. Ces actions sont exécutées directement :

• ajout de capacité (scale upet/ouscale out),

• calibrage du mode de l’application (scale app),

• ajustement du contrôle d’admission (scale mpl).

Différées : La stratégie de terminaison UaP gouverne la réduction de capacité. Une instance sera supprimée si elle a consommé plus de 95% de son temps-instance. Si la capacité demandée est inférieure à la capacité optimale, une action (scale down et/ou scale in) est différée. Lors des prochains cycles, l’Analyzerpermet de forcer la réduction ou d’annuler l’action en se basant sur le contexte courant et sur la base de notifications

(instance-fullTime).

b) Notifications

La politiqueInfrastructure Elasticitycontrôle l’augmentation de capacité. Nous propo-sons d’envoyer une notification (email) au fournisseur de service (SaaS) si la capacité demandée est supérieure à la capacité définie par la politique Infrastructure Elasticity.

Cette notification peut être immédiate ou différée (fin de la journée, fin de la semaine).

iv) Exécution - Execute

L’Executorconsiste à exécuter le plan défini par lePlanner(voir Figure6.5).

Figure6.5 – Méta-modèle Execute

a) Actions

Nous énumérons trois actionneurs possibles : infraEffector, appEffector et mplEff ec-tor :

Infrastructure: infraEffector exécute un ensemble des actions sur les ressources à savoir principalement :scale in,scale out,scale upetscale down.

Application : appEffector permet d’interagir avec l’application comme une boîte blanche. Il accomplit l’actionscale appqui ajuste le mode de fonctionnement de l’appli-cation.

Contrôle d’admission : mplEffector permet de piloter le contrôle d’admission. Il consiste à ajuster le MPL de chaque instance via l’actionscale mpl.

b) Notifications

En plus des actions, l’Executor permet d’envoyer des notifications au fournisseur de service afin d’être alerté lorsque la capacité demandée est supérieure à la capacité maximum définie par la politiqueInfrastructure Elasticity.

v) Connaissances - Knowledge

Dans ce travail, les connaissances consistent à partager l’ensemble des politiques (Best-Policies), leurs paramètres associés, variables publiques comme la durée de cycle MAPE-K ainsi que la base des notifications.