Pourquoi ?

An de mieux comprendre les raisons derrière l'importance non seulement de prendre en compte la dynamicité du système, mais aussi de la modéliser de façon cohérente, reprenons l'ex- emple d'une machine qui doit s'allumer et s'éteindre. Lorsque nous étions en allocation statique, le temps entre les diérentes allocations était susamment grand pour pouvoir négliger le temps d'allumage et d'extinction des hôtes. Si l'on doit allouer et réallouer dynamiquement les tâches, il faut prendre en compte ce temps d'allumage et d'extinction, car pendant ceux-ci, les machines seront inutilisables, mais consommeront des ressources. Cette consommation de ressource est inévitable lorsque l'on éteint des machines que l'on va devoir plus tard rallumer quand la charge aura changé.

En plus d'être inutilisables pendant un certain laps de temps, il faudra changer la façon dont on approche la gestion des machines, puisque éteindre et rallumer trop souvent un hôte induira un surcoût de consommation que nous pourrions éviter. Il ne faut donc plus se limiter à éteindre

les hôtes lorsque ceux-ci sont inutilisés, mais en garder certains allumés même lorsqu'ils sont peu chargés an de pouvoir amortir un changement dans les demandes des tâches.

Le problème n'est pas seulement au niveau de l'allumage et de l'extinction des hôtes, mais il est aussi, et surtout, au niveau de la migration induite par la réallocation. On pourrait penser qu'il sut d'eectuer des allocations successives lorsque les demandes des tâches du système dévient susamment des demandes utilisées lors de l'allocation précédente. Seulement la migration d'une machine virtuelle depuis une machine physique vers une autre prend non seulement du temps, mais consomme aussi des ressources, à la fois sur la machine source que sur la machine destination, mais aussi sur l'infrastructure réseau. Rappelons-le, la migration des machines virtuelles telle que dénie dans Xen[18] ou KVM[65] par exemple fonctionne en transferant la mémoire depuis la machine physique source vers la machine physique destination. Pendant le transfert, la machine virtuelle source fonctionne toujours, ce qui amène à avoir une partie de la mémoire qui a changé pendant le transfert. Un nouveau transfert de ce qui a été changé est fait, et l'on répète ces deux opérations un certain nombre de fois ou jusqu'à avoir un noyau susamment réduit de mémoire restante. À ce moment, la machine virtuelle source est stoppée, la mémoire restante transférée, et la machine virtuelle destination démarre.

On peut déduire de ce fonctionnement que la migration de machine virtuelle met une pression importante sur l'infrastructure réseau. Ainsi, si l'on prenait la solution consistant à faire des allocations successives complètes, on aurait souvent un grand nombre de migrations, ce qui induit un goulot d'étranglement au niveau de l'infrastructure réseau, et qui va ralentir fortement la complétion de l'allocation, à tel point qu'il peut arriver des situations où l'allocation se termine dans un système où les besoins des tâches ont changé entre le début et la n de la migration, nécessitant ainsi une nouvelle allocation.

Pour prendre en compte la dynamicité du système, nous devons donc prendre en compte le fait que la migration consomme des ressources, et surtout plutôt que des allocations successives de toutes les tâches, il faudra faire des allocations successives en prenant en compte l'état courant du système. Plutôt que d'allouer des tâches, il faudra les réallouer, c'est-à-dire migrer une machine virtuelle d'une source vers une destination.

Si nous prenons enn le point de vue énergétique de la migration, la migration d'une machine virtuelle va consommer de l'énergie sur le réseau, ce qui peut-être considéré comme un surcoût constant fonction de la taille de la machine virtuelle, mais aussi des ressources sur à la fois la machine source et la machine destination. En eet, le transfert de données consomme à la fois des ressources CPU et réseau sur les machines physiques, mais aussi des ressources CPU pour initialiser la machine virtuelle destination et pour arrêter la machine virtuelle source.

Au vu de ces diérents problèmes apportés par la migration et par la dynamicité en général, il faut étendre le modèle présenté dans les chapitres précédents, pour y intégrer les eets décrits ci-dessus.

À l'instar du modèle statique, le passage à la dynamicité va demander une gestion un peu diérente de la qualité de service. Si dans le chapitre 4, nous étions concentrés sur l'augmen- tation de la performance globale des tâches pour l'allocation initiale, nous allons devoir ici, du fait de la variabilité des tâches et de la dynamicité du système, prendre en compte non plus une maximisation de performance pour les tâches, mais une minimisation du gaspillage de ressources, c'est-à-dire que nous voudrons eectuer des allocations au plus près de ce que la tâche consomme réellement. Il faudra donc eectuer des allocations permettant de toujours satisfaire les tâches, quelque soit les ressources qu'elles consomment. Nous utiliserons donc des Service Level Agree- ments (SLA) pour déterminer si une tâche est satisfaite ou non, et nous allouerons les tâches en fonction de ces SLA.

Le parallèle entre SLA et borne sur le yield a été fait dans la partie précédente, et il convient de le répéter ici. Si nous considérons que les besoins en ressource d'une tâche forment ce qui a été

5.1. PASSER DU STATIQUE AU DYNAMIQUE 99 accepté pour accord entre le client et le fournisseur de service, une allocation en dessous de cette borne constitue une violation de SLA. Dans la partie précédente, nous considérions qu'une telle violation impliquait forcément un rejet de l'allocation dans le cas du problème BoundedYield, c'est-à-dire que si nous ne pouvions trouver une allocation nous permettant d'avoir au minimum x% de satisfaction pour chacune des tâches, l'algorithme utilisé pour l'allocation n'avait pas trouvé une solution satisfaisante. Ici, puisque nous avons plusieurs allocations et réallocations successives, nous allons pouvoir changer cette valeur x, même si celle-ci n'a pas trouvé de solu- tion. Ce qui veut dire que si nous ne trouvons pas de solution satisfaisante, nous considérerons l'allocation résultante comme non satisfaisante et appliquerons les pénalités correspondantes, et nous passerons tout de même à l'allocation suivante. Une description de la dénition des SLA est donné plus tard en partie 5.3.1, ainsi qu'une explication plus détaillée des diérences du modèle de SLA en statique et dynamique en partie 5.1.2.