Gestionnaire d’infrastructure

L’IM est construit sur le modèle de référence MAPE-K dans le but de rendre l’infrastructure en nuage auto-administrable. En plus de la structure MAPE-K classique, l’IM se compose également d’une base de connaissance publique, qui partage certaines informations telles que les prix de loca- tion de VMs. Le reste de cette section détaille le modèle de connaissance, les interface en termes d’événements et d’actions (détecté et exécutés par les tâches de surveillance et exécution) et la tâche d’analyse qui est modélisée comme un ensemble de problèmes de satisfaction de contraintes (Constraint Satisfaction Problem - CSP).

Modèle de base de connaissance

La base de connaissance de l’IM est défini comme suit: • P = {pmi | i ∈ [1, p]} : l’ensemble de PMs. • pmi = (pmcpu_i , pmram

i ) : les capacités de CPU et RAM de pmi∈ P . • A = {ai| i ∈ [1, ψ]} : l’ensemble d’applications.

• arr

i : le taux de réduction de ressource que l’application aiaccepte. • V = {vmi | i ∈ [1, v]} : l’ensemble de VMs en train d’exécuter. • vmi= (vmcpu_i , vmram

i , vm

app

i ) : les capacités de CPU et RAM de vmi. • vmapp

i ∈ A : l’application propriétaire de la VM.

• Hpx vla matrice d’incidence, où Hij = 1 signifie pmihéberge vmj, Hij = 0 sinon. • M = {mi | i ∈ [1, q]} : l’ensemble de types/classes de VM offertes.

• mi = (mcpu_i , mram

i , mcosti ) : les capacités de CPU et RAM, et les prix de location pour la classe de VM mi ∈ M .

L’IM peut décider de promouvoir des soldes (promotions P r dans un laps de temps donné) pour les P Ms dont le taux d’occupation est inférieur à un seuil donné de manière à stimuler les demandes pour occuper une partie des ressources sous-utilisées. Comme une promotion doit être appliquée à une seule application, elle doit être traitée comme une section critique. Par conséquent, le base de connaissance publique est composé d’une section non-critique contenant le prix de location de VM M et plusieurs sections critiques, chacun correspondant à une promotion P r, comme suit:

• P r = {pri | i ∈ [1, ξ]} : l’ensemble des promotions. • pri ∈ P r = (pr_ipack, prprice_i , prtoken

i )

• prpack

i = {packij | j ∈ [1, q] : un pack de VMs pour la promotion pri. • packij ∈ N∗_{: le nombre de VMs de classe mjdans le pack.}

• prprice

i = (1 − δ) ∗ Pq

j=1mcostj ∗ packij : ∀i[1, ξ] : le prix global pri basé sur un taux fixe de réduction δ du prix normal de chaque VM du pack.

Événements et actions

VMs Requested: c’est un événement du type interloop survenant quand un gestionnaire AM effectue une action du type interloop Request VM. Cet événement comprend un ensemble de VMs demandées au prix normal et éventuellement les promotions. Pour chaque promotion demandé, le jeton correspondant est transféré (TOKEN TRANSFERT) dans le message de telle sorte qu’un accès exclusif est garanti, ce qui signifie que l’AM avait déjà demandé et acquis un jeton (TO- KEN REQUEST / TOKEN ACQUIRED) pour chaque promotion. Cet événement déclenche une tâche d’analyse qui évalue le placement des VMs demandées sur les PMs de manière à min- imiser le nombre de PMs allumées nécessaires. La tâche de planification prend le résultat de l’analyse et traduit en un ensemble d’actions Switch On PM, Create VM et Active Promotion sur l’infrastructure. Enfin, il informe en retour l’AM que les VMs demandées sont prêtes par l’exécution de l’action Notify VMs Created, du type interloop.

M E (a) A P (4) Notify VMs Created (c) (1) Swtich on PMs (2) Create VM M E (b) M A P E Energy Shortage (1) Notify Scale Down M P E (1) Create Promotion (d) VMs Requested VMs Released Low PM Utilization Destroy VM M P E Switch off PM (e) Unused PM / Timeout Expired P (3) Activate Promotion (2) Fire Event (2) Notify Renting Fees Changed

Figure A.6: Actions et événements du gestionnaire IM.

Release VMs: est aussi un événement du type interloop qui se produit lorsque un AM effectue une action Release VM, du type interloop (cf. section A.4.3). Ce événement contient la liste des VMs qui doivent être détruites. Comme il n’y a pas d’analyse particulière pour ce genre d’événement, la tâche de planification est déclenchée directement à partir de la surveillance. La tâche de planification traduit la liste des VMs à être libérées à travers d’un ensemble d’actions Destroy VMsur l’infrastructure.

Energy Shortage: c’est un événement du type endogène qui vient des données du contexte d’exécution de l’infrastructure (par exemple des sondes de consommation électrique). Cet événe- ment comprend le nombre de PMs à arrêter P#_{. Suite à cet événement, l’IM déclenche la tâche} d’analyse pour déterminer quelles PMs doivent être éteintes. La tâche de planification prend le résultat de la tâche d’analyse et le traduit en un ensemble d’actions Notify Scale Down, du type in- terloopafin d’informer les AMs concernés sur les contraintes qui pèsent sur l’infrastructure. Enfin, la tâche de planification crée une action Fire Event dont l’objectif est de déclencher l’événement endogène Timeout Expired de manière temporisée, c’est à dire après un délai donné. Cet événe- ment contient l’ensemble de PMs à arrêter (Pof f _{⊆ P ). Une fois que cet événement est détecté,}

c’est à dire après le délai expiré, la tâche de planification prend la liste des PMs à arrêter et la traduit en un ensemble de d’actions Switch Off PM sur l’infrastructure (e).

Low PM Utilization: c’est un événement endogène de l’infrastructure qui est détecté chaque fois qu’une PM pmia été sous-utilisé (lorsque le taux d’occupation est inférieur à Umin) au cours d’une certaine période de temps tl, comme il est formalisé dans l’équationA.1. Comme on peut le voir sur la figureA.6, la détection de cet événement déclenche directement la tâche de planification qui crée, pour chaque heure concernée, un ensemble d’actions Create Promotion qui crée des promotions (du type Change Public Knowledge), suivie par une action NotifyRentingFeesChanged (du type interloop, qui notifie les AMs souscrites que la base connaissance publique a été changée.

min( Pv j=1Hij∗vmramj pmram i , Pv j=1Hij∗vmcpuj pmcpu_i ) < Umin

est vrai pendant tl (A.1)

PM Unused : c’est un événement endogène de l’infrastructure qui est détecté quand une PM n’a hébergé aucune VM pendant un certain temps tu, tel qu’il est exprimé par l’équationA.2. Lors de la détection de cet événement, les PMs concernés (Pof f _{⊆ P ) sont directement arrêtées.} Comme il n’est pas nécessaire d’avoir une tâche d’analyse, la tâche de planification est directement déclenchée. Elle crée un ensemble d’actions Switch PM Off sur les infrastructures.

min( Pv j=1Hij∗vmramj pmram i , Pv j=1Hij∗vmcpu_j pmcpu_i ) = 0

est vrai pendant tu (A.2)

Analyse

Les tâches d’analyse sont constitués des CSPs et sont modélisés et résolus avec de la programma- tion par contrainte (Constraint Programming - CP)[RVBW06]. Un modèle CP est composé d’un ensemble de variables (de décision), un ensemble de domaines (valeurs possibles pour chaque variable), et des contraintes sur ces variables. Dans le cas des problèmes d’optimisation, une fonction objectif est également définie.

Lors de la détection d’un événement dans la tâche de surveillance, l’IM peut déclencher la tâche d’analyse ou directement la tâche de planification ou de l’exécution, si aucune analyse n’est requise. Comme on peut le voir sur la figureA.6, la tâche d’analyse est déclenchée soit par un événement VMs Requested ou un événement Energy Shortage. Les tâches d’analyse utilisent soit l’analyseur VM Placement Analyzer ou Energy Shortage Analyzer.

Energy Shortage Analyzer: cet analyseur est utilisé lors de la détection d’un événement Energy Shortageet vise à trouver un ensemble de PMs à arrêter pour faire face à une situation de pénurie d’énergie. La solution doit répondre aux contraintes en termes de taux de réduction des ressources (Arr

k ) déclaré par chaque application (ak) et le nombre minimum de PMs à arrêter P#, tout en minimisant l’impact de la restriction des ressources imposée aux applications.

Premièrement, nous définissons la variable de décision zi, dont le domaine D(zi) ∈ {0, 1}∀i ∈ [1, p]. Cette variable indique si une PM pmi ∈ P doit être arrêté. La deuxième partie est constituée d’un ensemble de contraintes sur les variables de décision zi. CRk et RRk sont des expressions auxiliaires correspondant respectivement à la quantité actuelle de ressources allouée à une applica- tion aket le montant des ressources à être libéré après arrêter les PMs spécifiées dans les variables z. L’équationA.3indique que pour chaque application ak ∈ A le montant des ressources à libérer (RRk) ne doit pas dépasser le montant des ressources actuellement allouées à cette application (CRk) réduit de la ressource taux de restriction (arr

k ). L’équation A.4indique qu’au moins P# PMs doivent être arrêtées afin de faire face à la pénurie d’énergie. Enfin, l’objectif est de minimiser

la restriction de ressources imposée aux applications (cf. équationA.5). CRk ∗ (1 − arrk ) ≥ RRk.∀i ∈ [1, ψ] (A.3) p X i=1 zi≥ P# (A.4) minimize( ψ X i=1 RRi) (A.5)

L’analyseur VM Placement Analyzer est déclenché suite à la détection d’un événement VMs Requested et son objectif est de placer les VMs demandées (à prix normaux ou réduits) dans les PMs de sorte que le nombre de PMs allumées nécessaires soit minimisé. Pour des raisons de place, nous ne détaillons pas le fonctionnement de cet analyseur dans ce résumé.

Planification

La tâche de planification peut être déclenchée après l’exécution de la tâche d’analyse ou directe- ment après la détection d’un événement lors de la surveillance. La planification prend en consid- ération l’état actuel de l’infrastructure et l’état désiré résultant de la surveillance ou de l’analyse pour créer actions de reconfigurations (voir la sectionA.4.2) de manière structurée.

Selon la figureA.6, il existe cinq planificateurs différents, chacun pour faire face à un événe- ment différent. Tous prennent aussi en entrée un ensemble de variables et en sortie un plan (objet de type P lan). L’objet P lan agrège un ensemble d’activités, chacune contenant un ou plusieurs autres activités ou actions autonomes. Ces activités peuvent être exécutées en séquence (objet de type Sequence) ou en parallèle (un objet de type F ork).

L’algorithme13 décrit le planificateur Energy Shortage Planner, qui est déclenché après la l’analyse effectuée par le Energy Shortage Analyzer, qui, à son tour, est déclenchée lors de la détection d’un événement Energy Shortage. Il prend en entrée l’ensemble des PMs (Pof f_{) à} arrêter, le délai au terme duquel celles-ci doivent être arrêtés (timeout), et le contexte d’exécution C. Il commence par créer les objets plan et fork (lignes 1 et 2). Il parcourt ensuite l’ensemble des applications A tout en recueillant l’ensemble des VMs impliquées appartenant à la application en question (ligne 4). Cet ensemble est utilisé par l’action NotifyScaleDown (ligne 5) afin d’informer les applications qui devront libérer des VMs. Puis l’algorithme ajoute au plan des actions de notification (ligne 6), crée une action (FireEvent) qui va déclencher l’événement TimeoutExpired contenant les PMs à arrêter après le délai donné (ligne 7) et l’ajoute au plan. Lors de la détection de cette événement, le planificateur Shutdown PM Planner est déclenché. est décrit dans l’algorithme

Algorithm 13: Energy Shortage Planner. Input: Pof f_{: les PMs à arrêter.}

Input: timeout: le temps après lequel les PMs devront être arrêtées. Input: C: le contexte d’execution de l’infrastructure.

Result: plan : le plan résultant. 1 plan ← new instance of P lan

2 notif icationF ork ← new instance of F ork 3 foreach app ∈ A do

// les VMs hébergées dans les PMs à arrêter.

4 vms ← {vmj | vmappj = app ∧ ∀i ∈ [1, p](∀j ∈ [1, v](Hij = 1 ∧ pmi ∈ Pof f))} 5 add(N otif yScaleDown(app, vms), notif icationF ork)

6 add(notif icationF ork, plan)

Virtual Machine Release Planner ce planificateur est déclenché lors de la détection d’un événe- ment VMs Released. Il prend en entrée l’ensemble de VMs qui doivent être libérées (Rvms_{) et} produit en sortie un ensemble d’actions qui vont effectivement détruire ces VMs.

Virtual Machine Placement Planner ce planificateur est utilisé pour faire face à des événements VMs Requested et déclenché après l’analyse Virtual Machine Placement Analyzer. Il prend en entrée l’ensemble de nouvelles VMs (V′_{), l’ensemble promotions demandées (R}pr_{) et la nouvelle} matrice d’incidence VMs / PMs (h). Le planificateur produit comme sortie un ensemble d’actions qui vont créer les nouvelles VMs sur les PMs respectives et notifier l’AM demandeuse.

Promotion Planner ce planificateur est déclenché directement lors de la détection d’un événe- ment Low PM Utilization. Il prend en entrée l’ensemble des PMs (Ppr_{) dans lesquelles les promo-} tions doivent être créées, les prix de location de VMs (M) et le taux de réduction des promotions (δ). Le planificateur produit en sortie un ensemble d’actions qui créent les promotions dans la base de connaissance publique.

Physical Machine Shutdown Planner ce planificateur est déclenché directement lors de la dé- tection d’un événement Unused PM ou d’un événement TimeouExpired. Cela prend en entrée le vecteur des PMs à arrêter Pof f _{et produit en sortie un ensemble d’actions sur l’infrastructure pour} éteindre les PMs en question.

Pour des raisons de simplicité, les algorithmes de ces planificateurs ne sont pas détaillés dans ce résumé.