Mise en ÷uvre

Pour la mise en ÷uvre de la méthode proposée, nous allons d'abord justier le choix du simulateur qui sera utilisé dans le cadre de cette recherche, et le présenter par la suite. Puis, nous décrirons les modications apportées au simulateur pour implémenter notre méthode.

4.2.1 Choix de l'outil

Le choix du simulateur est basé sur la présence ou non de la fonction de la consommation d'énergie dans ce simulateur. De ce fait, nous allons d'abord catégoriser les outils présentés dans [82] à partir de l'implémentation du modèle d'énergie dans ces derniers. À cet eet, ces simulateurs sont regroupés en deux catégories : des simulateurs intégrant la modélisation d'énergie consommée, comme Cloud Sim [83], Green Cloud [84], et des simulateurs conçus pour analyser le temps de réponse d'un service Cloud, comme Cloud Analyst [85] et DC Sim [86]. Cette dernière catégorie sera écartée, vu que Cloud Analyst et DC Sim traitent de temps de réponse. Or, ce paramètre n'a aucun lien avec la consommation énergétique. Nous allons à cet eet nous contenter de la première catégorie de simulateurs qui contient Green Cloud, Cloud Sim.

Ensuite, nous allons eectuer une comparaison entre les deux simulateurs : Green Cloud et Cloud Sim. Cette comparaison est présentée au Tableau 4.1, où les modèles d'applications

Pramètres Green Cloud Cloud Sim

Modèles d'applications Calcul, transfert de données Calcul, transfert de données Modèles d'énergie Appliqué pour tous les compo-

sants du centre de données Aucun

Mode d'économie d'énergie DVFS, DNS, DVFS+DNS Aucun

Support du résultat HTML Console

Table 4.1  Comparaison entre Green Cloud et Cloud Sim

qui implémentent les types d'applications qu'ore le Cloud sont les mêmes pour les deux simulateurs. En eet, Cloud Sim et Green Cloud implémentent tous les deux des applications de calcul et de transfert de données. Par exemple, si un utilisateur se connecte à un Cloud pour y enregistrer une photo, les deux simulateurs simulent cette tâche, en calculant l'espace nécessaire pour stocker cette image et eectuer son transfert dans le Cloud. Pour le mode d'économie d'énergie, ce paramètre dénissant la technique de gestion de la consommation d'énergie est implémenté dans Green Cloud, en orant DVFS et DNS (Dynamic Network Shutdown). Concernant la technique DVFS, nous l'avons déjà présentée et expliquée dans les sections 2.5.2 et 3.3.1, alors que DNS est une technique qui consiste à éteindre les commutateurs du centre de données qui sont inutilisés. Or, dans le cadre de notre recherche, nous nous contentons de la consommation d'énergie au niveau des serveurs. De ce fait, la technique DNS ne sera pas utilisée. Nous utiliserons plutôt la technique DVFS dans ce simulateur. En outre, le simulateur Green Cloud ore un meilleur processus d'analyse des résultats de simulation, en fournissant un support HTML avec les graphiques, alors que le simulateur Cloud Sim retourne ses résultats dans une console.

La comparaison entre ces deux simulateurs montre que Green Cloud a un certain nombre d'avantages par rapport à Cloud Sim. En eet, Green Cloud met en ÷uvre trois algorithmes d'économie d'énergie (DNS, DVFS et DNS + DVFS) [87], alors que Cloud Sim n'en im- plémente aucun. Or, notre méthode est dénie par trois caractéristiques, dont la technique DVFS. D'où la force de Green Cloud, en termes de mode d'économie d'énergie. Ce simula- teur calcule également avec précision la consommation d'énergie par chaque requête reçue, alors que le simulateur Cloud Sim ne fournit aucun modèle d'énergie au niveau des requêtes. Nous en concluons que le simulateur Green Cloud ore une analyse plus précise concernant la consommation d'énergie dans un environnement Cloud.

Green Cloud est une extension open source de NS-2. Ce dernier est un outil de simulation de réseaux informatiques. L'outil NS-2 est parmi les simulateurs les plus utilisés dans les labora- toires de recherche, an de simuler et étudier les performances des protocoles réseau [88]. Il ore aussi une plateforme de développement de nouveaux protocoles et permet de les tester. Green Cloud est basé sur les packages du simulateur NS-2 pour la création des topologies du centre de données. De plus, ce simulateur est programmé en C++, ainsi qu'en Tool Command

Language (TCL). TCL est un langage de script initialement conçu en 1988 [89]. La gure 4.1 présente une partie du chier 'main.tcl' qui est utilisé dans le simulateur Green Gloud. Un chier en format tcl est un chier avec une extension tcl, écrit en langage tcl. Comme illustré à la gure 4.1, le chier est composé de lignes de commandes. Chaque ligne est constituée de mots. Le premier mot est toujours le nom d'une fonction. Par exemple, dans la gure 4.1, nous constatons que quelques lignes commencent par la fonction set, ce qui permet d'aecter une valeur à une variable, alors que d'autres commencent par la fonction put qui sert à l'achage.

Figure 4.1  Fichier 'main.tcl'

Le simulateur Green Cloud implémente les composants suivants :

 Les serveurs qui représentent les unités d'exécution des tâches. En eet, Green Cloud implémente ces composants, en intégrant leurs caractéristiques, comme la vitesse du processeur, la taille de la mémoire et le nombre de machines virtuelles hébergées ;  Les commutateurs qui sont dénis par leur type, ainsi que leur rôle dans la topologie

du centre de données. En eet, un commutateur peut se présenter dans une topologie comme un "commutateur de c÷ur", alors que d'autres jouent le rôle de "commutateurs d'agrégation" ou de "commutateurs d'accès" dans la même topologie ;

 Le trac du Cloud qui représente l'ensemble des requêtes envoyées par les utilisateurs du service Cloud. Ce trac est mesuré en MIPS (millions d'instructions par seconde). Par exemple, si un utilisateur accède à son Cloud pour récupérer un document, l'ensemble des requêtes envoyées par cet utilisateur pour récupérer ses données représente une partie du trac du Cloud.

Comme présenté au deuxième chapitre, il existe diérentes topologies de centre de données. Parmi ces topologies, citons : la topologie en arbre à plusieurs niveaux. Green Cloud implé- mente trois instances de cette topologie : la topologie à deux niveaux, la topologie à trois niveaux, la topologie à haut débit à trois niveaux [90]. La topologie à deux niveaux contient

les racks des serveurs qui forment le premier niveau du réseau, comme illustré à la gure 4.2. Les commutateurs, représentés à cette gure par Layer-3 (L3), assurent la circulation du tra- c. Ces commutateurs facilitent également la connectivité complète, en utilisant des liaisons de 10 Gigabits Ethernet (GE) [91]. Les centres de données à deux niveaux dans Green Cloud peuvent prendre en charge jusqu'à 5500 n÷uds. Un noeud représente alors un serveur ou un commutateur. La topologie à trois niveaux, comme présenté à la gure 4.3, comporte trois niveaux : le niveau d'accès qui contient les racks dans lesquels les serveurs sont regroupés, le niveau d'agrégation et le niveau noyau. Les deux derniers niveaux comportent les commuta- teurs du centre de données. Cette topologie permet une augmentation du nombre de serveurs pris en charge à 10000. La topologie à haut débit à trois niveaux ajoute des liaisons de 10 GE entre les commutateurs d'agrégation et les commutateurs d'accès dans la topologie à trois niveaux, présentée à la gure 4.3. Cela entraîne une réduction du nombre des commutateurs d'accès, ainsi que la réduction du câblage du centre de données.

Figure 4.3  Topologie à trois niveaux

4.2.2 Implémentation

Pour implémenter la méthode proposée, nous allons eectuer des modications au simulateur pour l'adapter à notre méthode. Avant d'apporter tout changement au simulateur, il est pri- mordial d'étudier les diérents chiers et classes qu'il implémente. En eet, toute simulation dans Green Cloud est basée sur sept chiers en format tcl, contenant toute la conguration de cette simulation. Ainsi, ces chiers font appel à toutes les classes développées en C++ dans ce simulateur. Le tableau 4.2 présente ces chiers, en décrivant leurs rôles.

Fichier Rôle

Main.tcl détermine la topologie du centre de données et le temps de la simulation. Il fait appel aux autres chiers de la conguration.

Setup_ params.tcl contient la conguration générale des serveurs, des tâches et des données liées à la migration.

Topology.tcl crée la topologie du centre de données.

Dc.tcl responsable de la création des serveurs et des machines virtuelles.

User.tcl attribue une valeur à chaque paramètre dénissant les re- quêtes envoyées par les utilisateurs.

Record.tcl dénit les procédures du rapport sur les résultats d'exécution.

Finish.tcl calcule et présente les statistiques de la simulation.

Table 4.2  Fichiers de conguration du simulateur Green Cloud

Il s'avère nécessaire que le simulateur implémente les trois caractéristiques de notre méthode : les algorithmes d'ordonnancement, la technique DVFS et la migration. Concernant la première caractéristique, l'implémentation des trois algorithmes d'ordonnancement, à savoir Green Sche- duler, Random et Round Robin est déjà eectuée dans le simulateur. En eet, les trois algo- rithmes sont implémentés dans le simulateur par des classes qui héritent de la classe principale DcScheduler. Considérons la gure 4.4 qui présente les liaisons d'héritage entre les diérentes classes qui implémentent les algorithmes d'ordonnancement. Nous constatons que la classe Round Robin et la classe Green Scheduler héritent directement de la classe DcScheduler, alors que la classe Random hérite de la classe DcScheduler à travers la classe ProbabilisticSchedu- ler qui hérite à son tour de la classe ScoreScheduler. Cette dernière hérite aussi directement de la classe DCScheduler. En eet, la classe ScoreScheduler implémente les caractéristiques des algorithmes qui aectent la tâche à la ressource convenable (le processeur, la mémoire, la bande passante du réseau) [92], selon les caractéristiques de chaque ressource. Quant à la classe ProbabilisticScheduler, elle met en ÷uvre les caractéristiques des algorithmes probabilistes, en les ajoutant aux caractéristiques héritées de la classe ScoreScheduler. En ce qui concerne la classe principale DcScheduler, elle implémente toutes les liaisons entre les classes qui créent les instances des serveurs, des machines virtuelles, et les classes qui implémentent les tâches envoyées par les utilisateurs.

Figure 4.4  Diagramme d'héritage des classes des algorithmes d'ordonnancement

Toutefois, dans un centre de données, nous devons avoir un seul algorithme d'ordonnancement. À cet eet, une variable est utilisée dans le simulateur pour xer l'algorithme d'ordonnance- ment qu'on veut simuler. Comme illustré à la gure 4.5 qui présente la choix d'algorithme d'ordonnancement à simuler, scheduler_name est utilisé pour xer cet algorithme. Considé- rons par exemple, la ligne 116 de la gure 4.5, nous constatons que si scheduler_name contient la valeur GreenScheduler, l'algorithme instancié est Green Scheduler.

Figure 4.5  Choix de l'algorithme d'ordonnancement

De même pour la deuxième caractéristique, Green Cloud implémente également DVFS. En eet, le simulateur utilise la fonction void setDVFS (int eDVFS_enabled_) pour activer

cette technique au niveau des processeurs. Cette fonction prend en paramètre un entier eDVFS_enabled_ qui prend la valeur 1 si on veut activer DVFS et la valeur 0 dans le cas de désactivation du DVFS. En outre, le CPU implémente DVFS par la fonction void CPU : :setDVFS ( int eDVFS_enabled_ ) qui est présentée à la gure 4.6. En eet, comme illustré à la ligne 106 de cette gure, pour chaque valeur du pointeur iter qui pointe vers un c÷ur du CPU, on active la technique pour chaque c÷ur.

Figure 4.6  Implémentation de la technique DVFS au niveau des processeurs

Green Cloud n'implémente pas tout le processus de migration. De ce fait, il reste à l'adapter pour implémenter la migration selon les contraintes posées, en termes de pourcentage d'utilisa- tion du CPU. Il est important d'eectuer deux modications. La première consiste à modier le nombre de machines virtuelles par serveur. En eet, nous augmentons d'abord ce nombre pour rendre le Cloud simulé plus réel. Alors que la conguration de base de Green Cloud ne supporte qu'une machine virtuelle par serveur, un Cloud réel ore la possibilité d'avoir plu- sieurs machines virtuelles sur un serveur, au lieu d'avoir plusieurs serveurs hébergeant chacun une machine virtuelle.

Comme présenté au tableau 4.2, le chier responsable de la création des machines virtuelles est le chier `dc.tcl'. Dans ce chier, les serveurs sont créés en premier, en xant leurs caractéris- tiques. Concernant les machines virtuelles, elles sont hébergées dans chaque serveur. L'implé- mentation de ces machines virtuelles est basée sur l'implémentation des fonctions nécessaires pour le traitement des tâches au niveau de ces machines virtuelles. Ainsi, nous modions le chier `dc.tcl' dans l'optique de supporter plusieurs machines virtuelles par serveur. Un indice est ajouté à chaque machine virtuelle pour l'identier dans le serveur qui l'héberge. Soit n le

nombre de serveurs, comme présenté à la gure 4.7, dans la conguration de base de Green Cloud, chaque machine virtuelle VM(i), i = 0, ...., n-1 , est caractérisée par un indice iden- tique à celui du serveur Si qui l'héberge. Or, dans la conguration modiée, chaque serveur

peut héberger mi machines virtuelles. Donc, les machines virtuelles VM(i)(j ), i = 0, ...., n-1 ,

j = 0, ...., mi-1 , sont caractérisées par deux indices : l'indice i qui fait référence au serveur

hébergeant cette machine virtuelle et l'indice j qui identie la machine virtuelle parmi les mi

machines virtuelles hébergées dans Si.

Figure 4.7  Comparaison des congurations de machines virtuelles dans Green Cloud

Pour implémenter cette conguration, nous supposons que le Cloud simulé contient n serveurs. Nous calculons d'abord le nombre mi de machines virtuelles hébergées dans chaque serveur i,

i = 0, ...., n-1 . Ce nombre mi est calculé par une fonction aléatoire an de simuler un Cloud

réaliste. Comme illustré à la gure 4.8 qui représente l'implémentation de cette première étape dans le simulateur Green Cloud, le nombre de serveurs n est représenté par Nservers, alors que l'indice i et le nombre mi sont représentés respectivement par k et nbrvm(k). En eet,

suite à l'utilisation de certains paramètres dans d'autres parties du code dans le simulateur, nous changeons les paramètres utilisés par de nouveaux paramètres pour éviter des confusions dans le code. Dans la gure 4.8, nbrvm(k) est calculé par la fonction aléatoire rand(). Nous xons le seuil de cette fonction rand() à 10 pour limiter le temps d'exécution du code.

Figure 4.8  Modication du nombre de machines virtuelles par serveur dans Green Cloud

Après avoir calculé le nombre mi pour chaque serveur i, nous implémentons les machines

virtuelles VM(i)(j ), i = 0, ...., n-1 , j = 0, ...., mi-1 . An de simplier cette implémentation

et utiliser un tableau à une dimension, nous utilisons un seul indice l, l = 0, ...., Pn−1 i=0 mi

pour identier les machines virtuelles dans une liste vms_() qui contient toutes les machines virtuelles du centre de données. La gure 4.9 illustre cette implémentation, en présentant le passage de deux indices identiant les machines virtuelles dans chaque serveur i, i = 0, ...., n-1 , à un seul indice l, l = 0, ...., Pn−1

i=0 mi, identiant ces machines virtuelles dans la liste vms_().

Considérons la gure 4.9 pour calculer l'indice l d'une machine virtuelle dans le Cloud. Nous supposons que cette machine virtuelle est hébergée dans un serveur k, k = 0, ..., n-1 , et sa position dans ce serveur est j, j = 0, ..., mk-1 . L'indice l pour identier VM(k)(j ) dans la

liste vms_() est calculé comme suit :

l = vk+ j (4.1)

où j : la position de VM(k)(j ) dans le serveur k,

vk : le nombre de machines virtuelles des serveurs d'indice 0 à k-1. Elle est exprimée comme

suit : vk= k−1 X i=0 mi (4.2)

où mi : le nombre de machines virtuelles hébergées dans chaque serveur i.

La gure 4.10 illustre le calcul de l'indice l et l'implémentation de la liste des machines virtuelles vms_(). Dans cette gure, nous utilisons également Nservers pour représenter le nombre de serveurs n.

Figure 4.9  Implémentation de la conguration modiée des machines virtuelles dans Green Cloud

La deuxième modication à eectuer au niveau du simulateur Green Cloud est l'implémenta- tion de la migration. Pour ce faire, nous utilisons la classe `vmmigration.cc' qui implémente la migration, en y ajoutant les contraintes exigées par notre méthode pour déclencher ce proces- sus. En eet, nous modions la fonction startmigration( ) de cette classe qui sert à déclencher le processus de migration. Pour ce faire, nous calculons au début le pourcentage d'utilisation du CPU, en appelant la fonction getTotalCap() qui calcule ce pourcentage au niveau de chaque serveur. Comme illustré à la gure 4.11, nous comparons le pourcentage d'utilisation du CPU avec les contraintes posées. De manière plus précise, si ce pourcentage est inférieur à 30% ou supérieur à 70%, le processus de migration est déclenché. Ainsi, l'énergie consommée par le serveur source et le serveur de destination est mise à jour par la fonction UpdateEnergyAnd- Consumption(), comme présenté à la gure 4.11. Si ces contraintes ne sont pas validées, un message d'erreur est retourné, en indiquant qu'il n'y a pas de migration.

Figure 4.11  Modication du processus de migration