en violation. En n, margin représente à quel point une tâche peut être en violation. Prenons un exemple avec des valeurs de Yt
SLA= 70%, avec margin = 20%. Nous aurons donc une valeur
de Yt
bound = 50%, ce qui veut dire que nous ne pourrons allouer une tâche en dessous de 50%
de ce qu'elle avait requis, mais qu'une allocation entre 50% et 70% sera considérée comme une violation de SLA.
Soit une nouvelle variable binaire vt
j qui représente une violation de la tâche j à l'instant t.
∀t∀j YSLAt − Yt
j < vj (5.23)
La contrainte 5.23 dé nit la violation de SLA, c'est-a-dire que lorsque le yield de la tâche j Yt j
est inférieur à Yt
SLA, la tâche j est en violation de SLA.
Nous pouvons donc ajouter une contrainte sur le nombre maximum de violations MAX_V IO- LAT ION Sde SLA que l'on peut avoir dans une allocation à chaque timestep avec la contrainte 5.24.
∀t X
j
vj<= M AX_V IOLAT IONS (5.24)
Pour conclure, il faut noter que, du fait du fonctionnement des solveurs vis-à-vis des con- traintes, une solution optimale calculée à partir de cet ensemble de contraintes ne sera optimale que par rapport à cet ensemble de contrainte. Il est donc di cile de comparer les solutions optimales et approchées calculées par les diérents algorithmes. En eet, si l'on prend un exem- ple avec MAX_V IOLAT IONS = 100, la solution optimale en énergie sera avec exactement un nombre de violations égal à 100, qui sera en fait une solution optimale avec exactement ce nombre de violations, et non pas une solution optimale en énergie, ce qui pourra diérer des algorithmes approximés qui auront eux par exemple moins de violations mais une énergie consommée plus grande. De la même manière, si l'on avait changé l'objectif à minimiser le nombre de violations, la solution optimale n'aurait pas tenu compte de l'énergie et aurait donné une solution non énergétiquement e cace, mais sans violation. Notons au passage que nous observerons un eet similaire avec la contrainte 5.20 sur le nombre de migrations.
Le calcul de l'optimal n'est donc pas cohérent avec la manière dont va s'utiliser l'infrastructure de simulation dé nie en 5.3, qui correspond au cas où Ybound= Yt
SLA et margin = 0.
C'est pourquoi nous n'allons pas utiliser de calcul de résultats optimaux dans les diérentes expériences. Ce modèle restera cependant une modélisation de la réalité, et nous pourrons de plus nous en servir comme validation des allocations, c'est-à-dire à savoir si une allocation sera valide car elle se conforme à chacune des contraintes, et ainsi détecter rapidement l'éventualité d'une allocation défectueuse.
5.3 Simulations
Maintenant que le modèle est dé ni, nous pouvons à présent utiliser ce modèle pour en étudier les impacts. Pour ce faire, nous allons dé nir l'environnement de simulation. Les travaux, présentés dans [25] et que nous présentons ici ont été eectués conjointement avec Michael Maurer et Ivona Brandi¢ de la Vienna University of Technology, dans le cadre de l'action COST IC0804 [4].
5.3.1 Environnement de simulation
Pour dé nir l'environnement de simulation, il faut commencer par dé nir où nous nous plaçons dans la boucle autonomique MAPE-K dé nie précédemment. Puisque nous nous concentrons sur
Service Level Agreement (SLA) CPU ≥ 1024 MIPS MEM ≥ 512 MB Storage ≥ 2 GB TX ≥ 5 MBps RX ≥ 10 MBps
Table 5.1 Dé nition d'un SLA
la partie allocation et réallocation de ressources, notre approche se situera dans les parties analyse et plani cation. Nous supposerons donc que la partie exécution et monitoring seront gérées dans le simulateur, mais ne seront pas étudiées.
Nous devons donc dans les parties analyse et plani cation dé nir quelles seront les actions à prendre pour être e caces à la fois du côté de la qualité de service, ici modélisée par des SLA qui seront décrits ci-après, et à la fois le côté consommation d'énergie de l'infrastructure.
Concrètement, nous allons dé nir des actions réactives et proactives pour atteindre ces buts. Recon guration de machines virtuelles
La première action sera la recon guration des machines virtuelles. Elle tentera de provisionner au plus proche des besoins des tâches pour réduire autant que possible le gaspillage de ressources dû à une surprovision. Les provisions ainsi dé nies seront utilisées ensuite par l'algorithme de réallocation comme les bornes sur la performance dé nies précédemment : Yt
bound.
Cette recon guration devra aussi s'acquitter d'autres objectifs qui seront de minimiser les violations de SLA. Si nous cherchons à réduire l'intervalle entre ce qui est attribué à une tâche et ce qu'elle avait demandé, il apparait que des variations brusques dans les demandes entraineront une violation de SLA. Nous avons donc deux objectifs antagonistes : réduire le gaspillage dans les ressources attribuées, et avoir de la marge de manoeuvre pour éviter les violations de SLA. Un autre objectif lié à la réduction ou non des ressources allouées à une tâche sera de minimiser le nombre de réallocation de machines virtuelles. En eet, si le système est relativement stable, c'est-à-dire si nous ne recon gurons pas souvent les machines virtuelles, nous n'aurons pas besoin de bouger les machines virtuelles.
Il faut alors se poser la question de comment est dé nie une violation de SLA. Comme introduit dans [79], la distinction est faite entre ce qui est demandé par la tâche, ce qui est fourni au service par le système, et ce que le service consomme réellement. Ce qui est demandé par la tâche, le SLA lui même est comme le montre le tableau 5.1 un ensemble de contraintes sur les diérentes ressources proposées dans la dé nition des ressources d'une machine virtuelle. Ce qui est attribué à la tâche correspond à ce qui sera eectivement alloué la tâche par l'algorithme de décision du gestionnaire de tâches, soit αt
jh. Cette valeur sera bien sûr supérieure ou égale à ce
que le service va eectivement consommer. En n, ce que la tâche consomme réellement est une portion de ce qu'elle avait demandé. Une tâche peut demander par exemple 1000MIPS mais n'en consommer la majorité du temps que la moitié. Cette valeur devra donc toujours être inférieure ou égale à ce que la tâche avait demandé (Yt
SLA).
Nous pouvons à présent dé nir ce que nous appelons une violation de SLA. Une violation de SLA aura lieu lorsque la tâche tentera de consommer plus de ressources que ce qui lui a été attribué. Cela veut dire que si l'on alloue à la tâche moins que ce qu'il avait demandé, celui-ci ne sera en violation de SLA seulement si il tente de consommer plus que son allocation. Prenons un exemple. Nous avons une tâche qui demande 1000 MIPS de CPU. À un instant donné, est alloué à celle-ci 1200 MIPS. Ici, nous ne pourrons pas avoir de violation de SLA, puisque même si la VM
5.3. SIMULATIONS 109 consomme son maximum, c'est-à-dire 1000 MIPS, ce sera toujours moins que les 1200 alloués. Si par contre à un autre moment, la VM se voit alloué 800 MIPS mais tente d'en consommer 900, il y aura à ce moment là une violation de SLA. En n, si nous allouons 600 MIPS à cette même machine virtuelle, mais qu'elle n'a besoin que de 500, nous n'aurons pas de violation de SLA.
0% TT_low=60% TT_high=80% 100%
Region -1
Region 0
Region +1
tv t1 t2 t3 t4 t5 t6Figure 5.6 Principe des seuils pour l'approche par règles
A n de gérer proactivement le provisionnement des machines virtuelles sur les machines physiques, nous utiliserons une approche basée sur des règles et des seuils de menace (ou threat thresholds, TT ). Nous dé nirons pour chaque SLA deux TTs, un TT haut et un TT bas. Ceux-ci serviront à dé nir l'orientation que doit prendre le provisionning des machines virtuelles. Comme l'illustre la gure 5.6, si nous avons une utilisation des ressources supérieure au TT haut, la ressource en question est sous-provisionnée, et donc peut tendre à manquer. Si au contraire, nous avons une ressource utilisée en dessous du TT bas, c'est l'eet inverse, c'est-à-dire que trop de ressources ont été allouées par rapport à ce qu'elle consomme. Entre les deux seuils, la ressource est considérée comme bien provisionnée.
Pour chacune des deux régions +1 et −1 sont dé nies des règles de transformation : une pour augmenter l'allocation de ressource dans le cas +1, et une pour la diminuer dans l'autre cas. Ces règles sont dé nies comme suit :
1 IF
2 utilisationr> T Thighr AND utilisationrprdite> T T r high
3 THEN
4 Aecter provisionr à utilisér
valeur_cible(ressource) pour les politiques avec beaucoup de ressources
disponibles.
5 Aecter provisionrà min( utilisér
valeurcible(r), SLO
r∗(1+/100))pour les politiques avec peu de ressources
disponibles.
1 IF
2 utilisationr< T Tr
low AND utilisationrprdite< T Tlowr
3 THEN
4 Aecter provisionr à max( utilisér
valeur_cible(r), provision_minimaler).
Figure 5.8 Schéma de la règle pour diminuer la provision d'une ressource r
Gestion des machines physiques
La seconde action proactive et réactive que le gestionnaire de tâches va entreprendre est celle de la gestion des machines physiques, c'est-à-dire la gestion de l'allumage et de l'extinction des hôtes. Pour ce faire, il faut tenter de répondre à la question : combien pouvons nous éteindre de machines physiques sans pour autant impacter les SLA des tâches. Ainsi, nous avons implé- menté une stratégie d'extinction des hôtes permettant itérativement d'éteindre un certain nombre d'hôtes parmi les machines physiques que l'on peut éteindre, c'est-à-dire celles qui peuvent être vides (i.e : qui n'ont pas de machines virtuelles allouées).
À un instant donné, nous déciderons d'éteindre une portion de ces hôtes vides telle que : Nombre de machines physique à éteindre = Nombre de machines physique vide
a
Ainsi, lorsque le nombre de machine physique à éteindre restera constant, cette formule per- mettra d'éteindre toutes les machines physiques sauf une, qui restera pour faire tampon en cas de pic de charge. Cette technique permettra d'arrêter toutes ces machines sauf une en t = dloga
1 ne
timesteps. Cela permettra d'éteindre des machines en peu de temps, mais de manière à en garder certaines en cas de variation brusque des demandes du système.
Pour l'allumage des machines, nous fonctionnerons de manière similaire à la gestion de la recon guration avec des règles et des seuils. Nous surveillons ainsi les valeurs moyennes d'util- isations de chaque ressources. Si au moins une dépasse un seuil (T Tressource
P M ), nous allumerons
des machines autant de machines qu'il faudra pour faire redescendre la moyenne en dessous du seuil correspondant. Par exemple, si l'utilisation moyenne de CPU dépasse notre seuil de 80% pour arriver jusqu'à 90% il faudra allumer autant d'hôtes que nécessaire pour que la nouvelle moyenne redescende en dessous de 80%. Nous choisirons bien évidemment les hôtes à allumer les plus e caces énergétiquement parlant.
Réallocation des machines virtuelles
La dernière action que nous pouvons prendre est celle de la réallocation des machines virtuelles. Si nous faisons une allocation initiale et que les besoins des tâches changent, il faut réallouer les machines potentiellement diéremment. Nous avons donc implémenté diérents algorithmes de réallocation de machines virtuelles. Ces algorithmes calculent un ensemble de migration pour passer d'un état donné vers un autre en tentant d'économiser de l'énergie.
FirstFit Le premier algorithme que nous avons développé est un algorithme basé sur le principe du FirstFit. À la diérence du FirstFit classique, cet algorithme doit tenter de faire une réallocation de machines virtuelles, et ainsi ne peut pas simplement faire une allocation des tâches sur les premiers hôtes. Il faut donc l'adapter de manière à conserver un comportement similaire au FirstFit, mais dans ce nouveau contexte.
La première allocation se fera comme décrit dans le chapitre 4. Pour les réallocations qui suivront, l'allocation se fera en deux étapes. La première sera de trouver l'hôte le plus chargé
5.3. SIMULATIONS 111 parmi les hôtes non vides, pour ensuite distribuer une certaine portion de sa charge à la manière d'un algorithme FirstFit, c'est-à-dire pour chaque tâches sur le premier hôte sur lequel il rentre. La seconde étape consistera à prendre l'hôte le moins chargé qui n'est pas destination d'une migration de tâche, et de distribuer la charge de cet hôte tâche de manière FirstFit. RoundRobin Le second algorithme développé est basé sur le comportement de l'algorithme RoundRobin décrit précédemment. La première allocation se fera de la même manière. Pour les réallocations, de la même manière que pour le rst t, nous prenons l'hôte le plus chargé pour en distribuer la charge à la manière d'un RoundRobin. Ensuite, une machine virtuelle sera choisie sur chaque hôtes pour migrer vers une machine physique vide. Le but étant ici d'avoir à la fois une composante de consolidation et d'équilibrage de charge. Cet algorithme n'aura pas de bonnes performances en terme de consommation d'énergie, mais il nous servira de comparaison pour les autres algorithmes, puisqu'il aura un comportement facilement prédictible.
C'est nalement l'avantage des deux algorithmes FirstFit et RoundRobin, qui sont des algorithmes bien connus, de pouvoir conserver un comportement que l'on connait, prédictible et simple, a n de pouvoir avoir une base de comparaison sur un comportement spéci que, la consolidation pour le FirstFit et l'équilibrage pour le RoundRobin.
MonteCarlo Nous avons ensuite développé un algorithme basé sur le fonctionnement de la méthode de Monte Carlo, qui est une technique probabiliste utilisée pour calculer des valeurs numériques. Dans notre cas, nous eectuerons une première allocation en RoundRobin, a n d'avoir un système équilibré, ce qui permettra de converger plus vite vers une bonne solution. Pour les réallocations, l'algorithme calcule la valeur de l'allocation courante, c'est-à-dire une valeur basée sur un certain nombre de paramètres qui en augmentent ou diminuent la valeur. Ces paramètres visent à eectuer les modi cations de valeur suivantes :
Augmenter le coût pour chaque tâche qui migre.
Augmenter le coût pour chaque hôte considéré comme surchargé.
Diminuer le coût pour chaque hôte qui est vide, ou qui sera vide au timestep suivant. Le poids de chaque paramètre peut être modi é pour changer son impact. Dans nos expériences, nous avons choisi des valeurs de 1 pour les tâches qui migrent, 4 pour les hôtes surchargés, -10 pour les machines physiques qui sont ou seront vides, et en n 90% pour une machine considérée comme étant surchargée.
Cela veut dire que par exemple, si nous avons une instance de 3 hôtes, avec une machine virtuelle consommant 50% de CPU migrant depuis l'hôte 1 vers l'hôte 2, la valeur de l'instance sera de 1 × 1 + 4 × 0 + (−10 × 2) = −19. L'algorithme calcule ensuite diérentes réallocations choisies aléatoirement par un ensemble de migrations. Si la valeur d'une allocation est inférieure à celle précédente, nous gardons cette nouvelle allocation. Cette étape est répétée un nombre dé ni de fois, 100 fois dans notre cas, a n de faire émerger le meilleur ensemble de migration à eectuer pour la prochaine itération.
Nous avons choisi d'implémenter un algorithme suivant une méthode de Monte Carlo, car cela nous permettait de pouvoir donner des poids diérents à certaines actions comme la migration ou l'allumage d'un hôte. Ainsi, nous pouvons modi er facilement l'algorithme pour pouvoir converger vers un certain type de solutions, comme une solution avec peu de migration si les migrations ont un fort poids.
VectorPacking En n, le dernier algorithme dé ni est l'algorithme basé sur le VectorPack- ing comme décrit précédemment en section 4.3. Pour la première allocation, nous eectuons une allocation en utilisons l'algorithme VectorPacking décrit en 4.3. Pour les réallocations ensuite, l'algorithme va tenter de consolider autant que possible en utilisant la même heuristique que pour
l'allocation initiale. Pour cela, on va eectuer un ensemble de migrations en partant des tâches les plus volumineuses, séparées en deux listes de manière à contrebalancer le déséquilibre sur les hôtes destination. Ensuite, il y aura une étape d'équilibrage depuis les machines physiques les plus chargées vers celles qui le sont le moins et qui ne seront pas vides dans l'itération suivante. Ainsi, l'algorithme tente de consolider les VM dans le plus petit sous ensemble de machines physiques, pour ensuite équilibrer la charge parmi les machines choisies. Cet algorithme a montré dans les expériences précédentes sur l'allocation statique (cf : section 4.4.2) sec ses bons résultats et son e cacité en terme de consommation d'énergie, c'est pourquoi nous avons conservé un algorithme au comportement similaire.