• Aucun résultat trouvé

Présentation et analyse des solutions

Plusieurs solutions existent pour permettre la réduction globale de la consommation d'énergie dans les Clouds [62], [63], [64]. Parmi lesquelles, nous pouvons citer : la technique DVFS (Dyna- mic voltage and frequency scaling) [44], la migration [41] et les algorithmes d'ordonnancement [40]. Dans cette section, nous présentons et analysons ces solutions.

3.3.1 Technique DVFS

DVFS est une technique qui agit sur la fréquence et la tension du processeur de chaque serveur du Cloud an de réduire la consommation d'énergie au niveau de ces serveurs. Plusieurs travaux ont proposé des solutions basées sur cette technique pour minimiser la consommation énergétique dans un Cloud [65], [66]. Comme présenté à la section 2.5.3, l'exécution d'une tâche nécessite l'utilisation du CPU, de la mémoire et du disque. De manière plus précise, les expériences réalisées dans [65] montrent qu'il est avantageux de réduire la fréquence du processeur (CPU) pour exécuter une tâche qui utilise une faible proportion du CPU et une proportion élevée de la mémoire au niveau du serveur. En eet, si le taux d'utilisation du CPU pour une tâche est élevé, le temps d'exécution de cette tâche sera faible. Cependant, si on réduit la fréquence du CPU, le temps d'exécution de la tâche va augmenter, car il est inversement proportionnel à la fréquence du CPU, ce qui entraine une diminution du pourcentage de tâches traitées. Il en résulte que la performance du Cloud sera dégradée. Alors que si une tâche accède fréquemment à la mémoire, le processeur connait des délais d'attente lorsque la tâche accède à la mémoire. De ce fait, la consommation d'énergie du serveur peut être réduite en abaissant la fréquence du CPU pendant les temps d'attente du processeur. Dans ce contexte, Andreas et Frank [66] proposent une technique DVFS basée sur des statistiques d'exécution des tâches et un algorithme d'apprentissage pour sélectionner la valeur optimale du rapport tension/ fréquence (v/f ) pour l'exécution de la tâche. En eet, leur algorithme peut prédire la valeur optimale du rapport v/f à partir des statistiques d'exécution des tâches, dont le nombre d'instructions exécutées, le nombre d'instructions échouées et les cycles d'horloge.

3.3.2 La migration

Comme présenté au deuxième chapitre, la migration des machines virtuelles (VMs) se divise en deux catégories : la migration à froid (migration sans copie dans le serveur source pendant le transfert de la VM), et la migration à chaud (migration avec copie de la VM dans le serveur source pendant le transfert de la VM). De ce fait, Jyothi et Getzi [64] ont utilisé la migration à chaud pour consolider les serveurs an de diminuer le nombre de serveurs en mode veille. En eet, ils se sont basés sur la sous-utilisation du processeur pour déclencher la migration. De façon plus précise, supposons qu'on a plusieurs serveurs, chacun ayant un pourcentage donné d'utilisation du CPU. La sous-utilisation du processeur est dénie dans ce cas par le pourcentage d'utilisation le plus faible. An d'illustrer ce processus de migration,

présenté dans [64], nous considérons la conguration suivante : trois serveurs et sept machines virtuelles occupant entre 20% et 50% du taux d'utilisation des CPU des serveurs sur lesquels sont hébergés ces VMs.

Figure 3.5  Processus de migration

 À t = t0 : où t0 est l'instant initial, trois machines virtuelles sont aectées au serveur 1

avec un pourcentage d'utilisation de CPU total (la somme des pourcentages d'utilisation du CPU de chaque machine virtuelle) P1 de 95% et deux machines virtuelles sont aec-

tées au serveur 2 utilisant 70% de son CPU. Pour le serveur 3, deux machines virtuelles y sont hébergées, avec un pourcentage d'utilisation de CPU total P3 = 40%.

 Après une durée ∆t1, nous allons considérer qu'aucune nouvelle machine virtuelle n'est

apparue et que la machine virtuelle 3 a ni son exécution à t1 = t0 + ∆t1. À cet instant,

du serveur 2 et du serveur 3 sont respectivement 70% et 40%. Dans ce cas, le plus faible pourcentage d'utilisation du CPU est 40%. Donc, le serveur 3 est sous-utilisé. En se basant sur l'étude présentée précédemment [64], les machines virtuelles hébergées dans le serveur 3 sont migrées vers les autres serveurs pour éteindre le serveur 3.

 À t2 = t1 + ∆t2 , la migration des machines virtuelles est eectuée, la machine virtuelle

6 est aectée au serveur 1, puis la machine virtuelle 7 est déplacé au serveur 2. Avec cette migration, le serveur 1 est utilisé à 90% de ses capacités, en termes d'utilisation du CPU et le serveur 2 est utilisé également à 90% de ses capacités. Toutefois, le serveur 3 est éteint. Donc, cette migration permet d'utiliser deux serveurs avec le maximum de leurs capacités et d'éteindre un serveur, ce qui permet une diminution de l'énergie consommée.

3.3.3 Algorithmes d'ordonnancement

Le Cloud Computing utilise le concept d'ordonnancement des tâches pour aecter celles-ci aux machines virtuelles sous-utilisées hébergées dans les serveurs, an de partager ecace- ment les ressources (CPU, mémoire, disque). L'ordonnancement consiste à utiliser un ordon- nanceur pour l'ensemble du centre de données ainsi qu'une unique liste de tâches prêtes, et à aecter ces tâches aux serveurs appropriés. En eet, lorsque les tâches arrivent au centre de données, elles sont placées, dans un premier temps, dans une le d'attente après qu'elles soient triées (phase de priorisation). Comme mentionné à la section 2.5.2, nous considérons un Cloud sans priorité, donc les tâches seront placées dans l'ordre du  premier arrivé premier servi . Comme illustré aux gures 3.6 et 3.7, la le d'attente est gérée par un contrôleur qui implémente l'algorithme d'ordonnancement. L'ensemble constitué du contrôleur et de la le d'attente représente l'ordonnanceur qui constitue le point d'entrée d'un centre de données. L'algorithme d'ordonnancement aecte ces tâches aux machines virtuelles en passant par les commutateurs du centre de données (voir gure 2.3). Plusieurs algorithmes d'ordonnancement sont utilisés, comme Green Scheduler, Round Robin et Random [67], [68].

 Green Scheduler

Green Scheduler regroupe les tâches dans le minimum des serveurs, et les serveurs in- utilisés sont éteints. En eet, cet algorithme aecte les tâches aux machines virtuelles du premier serveur et ne passe aux machines virtuelles du serveur suivant que si le pre- mier est occupé [69]. Pour ce faire, l'algorithme analyse dynamiquement les serveurs, en vériant leur disponibilité de manière continue. À chaque fois qu'il détecte un serveur saturé, l'ordonnanceur reste à l'écart de celui-ci, même s'il répond aux exigences des tâches reçues. De manière plus précise, dans la gure 3.6, la première tâche est aectée à la première VM du premier serveur, la deuxième tâche et la troisième tâche sont aec- tées également au premier serveur. Or, après l'aectation de ces trois tâches au premier serveur, ce dernier est saturé. Dans ce cas, la quatrième tâche et la cinquième tâche sont aectées au deuxième serveur.

Figure 3.6  Algorithme d'ordonnancement Green Scheduler

 Round Robin

L'algorithme d'ordonnancement des tâches Round Robin aecte les tâches sélectionnées aux machines virtuelles disponibles à tour de rôle, comme présenté à la gure 3.7 [70]. Dans cette gure, l'algorithme envoie les tâches reçues aux machines virtuelles dispo- nibles en suivant un cercle fermé. De manière plus précise, la première tâche est aectée à la première machine virtuelle du serveur 1, la deuxième tâche est aectée à la première machine virtuelle du serveur 2, la troisième tâche est aectée à la première machine virtuelle du troisième serveur, alors que la quatrième tâche, la cinquième tâche et la sixième tâche sont aectées respectivement à la deuxième machine virtuelle du premier, du deuxième et du troisième serveur.

 Random

L'algorithme de sélection  Random  des ressources permet une assignation des tâches aux machines virtuelles de manière aléatoire [71]. Comme illustré à la gure 3.8, les tâches sont aectées aléatoirement. Dans cet exemple, la première tâche est aectée à la première VM du premier serveur, la deuxième tâche est aectée à la première VM du deuxième serveur, la tâche 3 est aectée à la deuxième VM du premier serveur, alors que la quatrième tâche et la cinquième tâche sont aectées respectivement à la deuxième VM du premier serveur et la troisième VM du deuxième serveur. Si les deux premières tâches, aectées au deuxième serveur, occupent toutes ses machines virtuelles et que l'algorithme aecte une autre tâche à ce serveur, comme illustré à la gure 3.8, cette dernière ne sera pas traitée. D'où l'inconvénient de cet algorithme.

Figure 3.8  Algorithme d'ordonnancement Random

De toutes les techniques que nous pouvons appliquer, toutes sont à utiliser avec précaution, car elles comportent des lacunes. Ainsi, une mauvaise utilisation d'une de ces techniques de réduction de la consommation d'énergie peut entrainer un eet négatif sur le service, comme la dégradation de la performance, ce qui peut se révéler très problématique. Pour la technique DVFS qui permet de réduire grandement la consommation d'énergie du processeur, l'appli- cation d'un changement de fréquence n'est pas instantanée et passer d'une fréquence à une autre prend un peu de temps. De manière plus précise, le changement de fréquence ralentira fortement l'exécution de l'application, entrainant ainsi une surconsommation d'énergie. En ce qui concerne la migration des machines virtuelles, une dégradation de performance peut survenir. En eet, les transferts des machines virtuelles nécessitent un certain temps durant lequel les machines virtuelles en migration consomment des ressources sur les serveurs source et destination. Pour les algorithmes d'ordonnancement, il y a ceux qui inuencent la perfor- mance du Cloud, comme l'algorithme Random. L'application de cet algorithme entraine plus

de tâches non traitées, comme présenté à la sous-section 3.3.3.

Documents relatifs