Embed Size (px)
Citation preview
© Fatima Ezzahra Choukairy, 2018
Optimisation de la consommation d'énergie dans un environnement Cloud
Mémoire
Fatima Ezzahra Choukairy
Maîtrise en informatique - avec mémoire
Maître ès sciences (M. Sc.)
Québec, Canada
Optimisation de la consommation d’énergie dans unenvironnement Cloud
Mémoire
Fatima Ezzahra Choukairy
Sous la direction de:
Ronald Beaubrun, directeur de recherche
Résumé
Depuis une dizaine d'années, la dématérialisation de l'information connaît un essor particu-
lier avec l'ascension du Cloud Computing. La demande sans cesse croissante et le souci de
fournir une certaine qualité de service obligent les fournisseurs à investir d'importants capi-
taux a�n de multiplier leurs o�res d'hébergement dans plusieurs zones géographiques. Avec
ce déploiement à grande échelle d'énormes centres de données, la consommation énergétique
du Cloud augmente en conséquence. De ce fait, plusieurs études portant sur la minimisation
de la consommation énergétique du Cloud ont été récemment e�ectuées, en considérant les
di�érentes techniques de réduction de l'énergie consommée.
Ce mémoire propose une méthode basée sur l'intégration d'un algorithme d'ordonnancement,
d'une technique de réduction de tension et de fréquence du processeur de chaque serveur
(appelée DVFS pour Dynamic Voltage and Frequency Scaling), ainsi que du processus de
migration des machines virtuelles (VMs). Cette méthode vise à minimiser la consommation
de l'énergie dans un environnement Cloud, tout en respectant les exigences de qualité de
service. Ce travail de recherche est réalisé en trois phases. Dans la première phase, nous
menons une étude sur les di�érentes techniques de minimisation de la consommation d'énergie.
Dans la deuxième phase, nous analysons ces techniques et proposons une méthode basée sur
la combinaison de l'algorithme d'ordonnancement Green Scheduler, de la technique DVFS
et de la migration des VMs. A�n d'évaluer l'e�cacité de cette méthode, nous e�ectuons,
dans la troisième phase, une mise en ÷uvre et une analyse des résultats issus de trois séries
de simulations. Ces résultats montrent que la méthode proposée est en mesure de réduire
l'énergie consommée par les serveurs d'une moyenne de 5% par rapport à l'utilisation d'autres
méthodes de la littérature. Cette réduction peut atteindre 7.5% dans certaines circonstances.
Les résultats de simulations montrent également que la méthode proposée permet de respecter
les exigences de qualité de services dans toutes les conditions de fonctionnement du Cloud.
iii
Abstract
The last decade has witnessed a rapid rise in Cloud Computing usage, which has led to
the dematerialization of data centers. The increased use of data centers has an impact on
the energy consumption. Therefore, several studies relating to the optimization of energy
consumption were recently carried out, hence various techniques aiming to reduce the power
consumption were adopted. In this thesis, we propose a method based on the integration of
a scheduling algorithm, the DVFS technique and the virtual machine (VM) migration. This
method aims to minimize the consumption of energy in a Cloud environment subject to the
quality of service. For this purpose, we �rstly conduct a study on di�erent techniques which
aim to minimize energy consumption. Secondly, we analyze these techniques and propose a
method based on the combination of the Green Scheduler algorithm, the DVFS technique and
the VM migration. Thirdly, we choose Green Scheduler to perform three sets of simulations.
Simulation results show that the proposed method is able to reduce the energy consumed by
the servers by an average of 5% compared to the use of other existing methods. This reduction
can reach 7.5% under certain circumstances. Such results also show that the proposed method
always meets the quality of service requirements.
iv
Table des matières
Résumé iii
Abstract iv
Table des matières v
Liste des tableaux vii
Liste des �gures viii
Liste d'abréviations x
Remerciements xii
1 Introduction 11.1 Dé�nitions et concepts de base . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Éléments de la problématique . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3 Objectifs de recherche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.4 Plan du mémoire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2 Caractérisation du Cloud Computing 62.1 Caractéristiques fonctionnelles . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2 Classi�cation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.3 Topologies des centres de données . . . . . . . . . . . . . . . . . . . . . . . . 102.4 Avantages et inconvénients . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.5 Techniques de réduction de la consommation d'énergie . . . . . . . . . . . . 162.6 Quelques dé�s de recherche . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3 Analyse du problème 243.1 Contexte du problème . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.2 Paramètres étudiés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.3 Présentation et analyse des solutions . . . . . . . . . . . . . . . . . . . . . . 313.4 Méthode proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4 Mise en ÷uvre et résultats 424.1 Plan d'expérience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.2 Mise en ÷uvre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.3 Résultats et analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
v
5 Conclusion 655.1 Synthèse des résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 655.2 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 665.3 Travaux futurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Bibliographie 68
A Modi�cation de Green Cloud 77
B Données de la simulation 1 79
C Graphe retourné par le simulateur Green Cloud 82
vi
Liste des tableaux
4.1 Comparaison entre Green Cloud et Cloud Sim . . . . . . . . . . . . . . . . . . . 444.2 Fichiers de con�guration du simulateur Green Cloud . . . . . . . . . . . . . . . 48
B.1 Énergie consommée par les trois algorithmes d'ordonnancement . . . . . . . . . 80B.2 Pourcentages de tâches traitées . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
vii
Liste des �gures
1.1 Cloud Computing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.1 Modèles de services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2 Modèles de déploiement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.3 Topologie en arbre à trois niveaux . . . . . . . . . . . . . . . . . . . . . . . . . 112.4 Topologie en arbre à deux niveaux . . . . . . . . . . . . . . . . . . . . . . . . . 122.5 Topologie Fat tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.6 Exemple de topologie DCell1 avec n=4 . . . . . . . . . . . . . . . . . . . . . . 142.7 Exemple de topologie BCube1 avec n=4 . . . . . . . . . . . . . . . . . . . . . . 142.8 Impact de la technique DVFS sur la consommation d'énergie . . . . . . . . . . 182.9 Composants d'un ordonnanceur . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.10 Processus de migration à froid . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.11 Processus de migration à chaud . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.1 Architecture générale d'un centre de données . . . . . . . . . . . . . . . . . . . 253.2 Principaux éléments de consommation d'énergie dans un serveur . . . . . . . . 273.3 Puissance d'un serveur sans le mode de veille . . . . . . . . . . . . . . . . . . . 283.4 Puissance d'un serveur avec mode de veille . . . . . . . . . . . . . . . . . . . . . 303.5 Processus de migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.6 Algorithme d'ordonnancement Green Scheduler . . . . . . . . . . . . . . . . . . 343.7 Algorithme d'ordonnancement Round Robin . . . . . . . . . . . . . . . . . . . . 343.8 Algorithme d'ordonnancement Random . . . . . . . . . . . . . . . . . . . . . . 353.9 Diagramme de �ot de la méthode proposée . . . . . . . . . . . . . . . . . . . . 39
4.1 Fichier 'main.tcl' . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.2 Topologie à deux niveaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464.3 Topologie à trois niveaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474.4 Diagramme d'héritage des classes des algorithmes d'ordonnancement . . . . . . 494.5 Choix de l'algorithme d'ordonnancement . . . . . . . . . . . . . . . . . . . . . . 494.6 Implémentation de la technique DVFS au niveau des processeurs . . . . . . . . 504.7 Comparaison des con�gurations de machines virtuelles dans Green Cloud . . . 514.8 Modi�cation du nombre de machines virtuelles par serveur dans Green Cloud . 524.9 Implémentation de la con�guration modi�ée des machines virtuelles dans Green
Cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534.10 Création des machines virtuelles dans Green Cloud . . . . . . . . . . . . . . . . 534.11 Modi�cation du processus de migration . . . . . . . . . . . . . . . . . . . . . . 544.12 Topologie du centre de données simulé . . . . . . . . . . . . . . . . . . . . . . . 55
viii
4.13 Répartition de l'énergie consommée entre les di�érents niveaux du centre dedonnées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.14 Impact des algorithmes d'ordonnancement sur la consommation de l'énergie desserveurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.15 Comparaison du pourcentage de tâches traitées entre les algorithmes d'ordon-nancement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.16 Impact de la combinaison de DVFS et de l'algorithme d'ordonnancement GSsur la consommation de l'énergie des serveurs . . . . . . . . . . . . . . . . . . . 60
4.17 Amélioration de la consommation d'énergie des serveurs par la méthode proposée 614.18 Comparaison du pourcentage de tâches traitées entre la méthode proposée et
l'algorithme d'ordonnancement GS . . . . . . . . . . . . . . . . . . . . . . . . . 62
A.1 Appel de la migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77A.2 Appel de la technique DVFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
C.1 Répartition de l'énergie consommée entre les di�érents niveaux du centre dedonnées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
ix
Liste d'abréviations
CPU : Central Processing Unit
CRAH : Computer Room Air Handling
DC : Data Center
DEWTS : DVFS-enabled E�cient Energy �ow Task Scheduling
DNS : Dynamic Network Shutdown
DVFS : Dynamic voltage and frequency scaling
EEDTSA : Energy E�cient DVFS based Task Scheduling Algorithm
GS : Green Scheduler
HEFT : Hetogeneous Earliest-Finish-Time
IaaS : Infrastructure as a Service
MIPS : Million d'instructions par seconde
NIST : National Institute of Standards and Technology
OS : Operating System
PaaS : Platform as a Service
PAC : Pompe à Chaleur
PDU : Power Delivery Unit
PSU : Power Supply Unit
QoS : Quality of Service
R : Random
RR : Round Robin
x
SaaS : Software as a Service
SDA : Système de Distribution d'Air
SLA : Service Level Agreement
TCL : Tool Command Language
TI : Technologies d'informations
UPS : Uninterrupted Power Supply
VM : Virtual Machine
xi
Remerciements
Une mission s'achève, une autre commence ! Mais avant, qu'il me soit permis de remercier les
personnes qui, de près ou de loin, ont contribué à la réussite de celle qui s'achève.
Je tiens tout d'abord à remercier vivement M. Ronald Beaubrun. Ce travail n'aurait pu voir le
jour sans son implication et son enthousiasme. Merci à lui de m'avoir initiée à toutes les facettes
de recherche, de m'avoir encadrée et d'avoir lu et relu le présent mémoire. Je le remercie aussi
pour son aide, son encouragement et son accompagnement technique et pédagogique.
Alors que ma formation de maîtrise touche à sa �n, je saisis cette occasion pour exprimer
mes sincères reconnaissances à l'Université Laval, dont les responsables, le corps enseignant
et le personnel administratif ont tout déployé pour nous donner la formation digne de cette
prestigieuse institution. Un immense merci aux personnes qui ont jalonné mon parcours, et
qui, d'une façon ou d'une autre, ont contribué à me faire arriver jusqu'ici.
J'adresse également mes vifs remerciements aux membres du jury qui se sont libérés de leurs
obligations pour juger ce travail.
Un merci tout particulier à mes parents Said Choukairy et Ghita Nadir et ma s÷ur Mariam
Choukairy, pour leur soutien depuis toujours. Un grand merci pour votre support moral et
votre amour qui n'a jamais failli, et ceci, malgré la distance qui me sépare de vous. À mon
mari Abdelali Bouyahia, j'adresse mes profonds et sincères remerciements de m'accompagner
au jour le jour dans les périodes de stress ; merci d'avoir toujours soutenu mes choix.
Mes remerciements s'étendent à ma famille à Montréal, pour avoir toujours m'encourager et
être présente à mes côtés pendant mon séjour au Canada.
Aux lecteurs, qui grâce à eux le présent mémoire prend son sens, j'adresse mes remerciements
les plus signi�ants.
xii
Chapitre 1
Introduction
Depuis quelques années, le monde des télécommunications assiste à l'émergence d'un nouveau
paradigme, appelé le Cloud Computing, qui permet aux utilisateurs d'externaliser leurs ap-
plications et d'exploiter des ressources informatiques physiques à travers Internet, sans avoir
à gérer l'infrastructure sous-jacente, souvent complexe [1]. En raison de la panoplie de res-
sources que contient l'environnement Cloud, comme les serveurs, les équipements réseau et les
systèmes de refroidissement, le Cloud consomme une grande quantité d'énergie pour fournir
des services e�caces et �ables aux utilisateurs. Dans ce mémoire, nous nous intéressons à
la minimisation de la consommation d'énergie dans le Cloud. Ce chapitre d'introduction est
divisé comme suit. Dans un premier temps, les principaux concepts et dé�nitions, permettant
de mieux cerner le cadre du travail, seront présentés. Par la suite, les éléments liés à la pro-
blématique visant à réduire la consommation d'énergie seront dé�nis et seront suivis par les
objectifs de recherche. Le plan du mémoire permettra de clore ce chapitre.
1.1 Dé�nitions et concepts de base
Au milieu de la panoplie des dé�nitions du Cloud, nous adoptons la dé�nition de l'organisme
de normalisation National Institute of Standards and Technology (NIST) que nous traduisons
comme suit : le Cloud est un concept qui consiste à déporter sur des serveurs distants une
grande quantité d'enregistrements et de traitements informatiques, traditionnellement locali-
sés sur des serveurs locaux, ou sur le poste d'un utilisateur. Un Cloud propose des services
informatiques, sous forme de services à la demande, comme illustré à la �gure 1.1 [2], [3].
Dans cette �gure, nous constatons qu'un utilisateur peut accéder aux serveurs du Cloud grâce
à un système d'identi�cation, via un équipement d'accès, tels un ordinateur ou une tablette,
et une connexion à Internet. Ces serveurs sont situés dans des salles dédiées à l'exécution des
tâches informatiques liées aux services o�erts. Ces salles, appelées centres de données, peuvent
comporter des milliers de serveurs. Elles sont aménagées de manière à installer et administrer
facilement non seulement les serveurs, mais aussi le matériel utilitaire du centre de données
1
(commutateurs, climatisation, etc.).
Figure 1.1 � Cloud Computing
Le Cloud Computing ajoute à la notion de délocalisation des services la notion d'élasticité
des ressources et de facturation à l'utilisation. Ces notions sont possibles grâce à la technique
de virtualisation des ressources [4]. En e�et, la virtualisation des ressources o�re une couche
d'abstraction qui émule le comportement des ressources matérielles (processeur, mémoire, ...)
d'un serveur [5], [6]. Elle se dé�nit aussi comme étant un ensemble de techniques permettant de
regrouper sur un seul support physique des ressources informatiques qui permettent d'e�ectuer
séparément des tâches spéci�ques, comme si elles étaient exécutées sur des supports physiques
di�érents. Quant à l'implémentation de la virtualisation des ressources, elle consiste à fournir
un environnement logique indépendant du support physique.
Avec le concept de virtualisation, émerge également la notion de machine virtuelle (VM) qui se
dé�nit comme un environnement d'exécution qui reproduit le comportement d'un serveur [7].
Une machine virtuelle est composée d'un processeur, d'une mémoire RAM (Random Access
Memory), d'un disque dur et de cartes d'interface réseau qui sont des composants virtualisés.
Il s'agit de l'unité responsable de l'exécution des tâches envoyées par les utilisateurs. En e�et,
après avoir reçu ces tâches, un gestionnaire de tâches envoie chaque tâche à la �le d'attente
de la machine virtuelle responsable de son exécution. Ce gestionnaire de tâches utilise un
algorithme d'ordonnancement qui dé�nit la manière avec laquelle les tâches sont a�ectées aux
machines virtuelles.
D'autre part, la spéci�cation des caractéristiques matérielles des machines virtuelles, souhai-
tées par l'utilisateur d'un Cloud, constitue un des dé�s des fournisseurs de services Cloud, ce
qui mène à dé�nir un contrat appelé SLA (Service Level Agreement). Un contrat SLA contient
un ensemble de clauses que le fournisseur s'engage à respecter [8]. De plus, ce contrat spéci�e
2
les exigences négociées, en termes de ressources, de qualité de service, des attentes minimales
et des obligations qui existent entre les utilisateurs et les fournisseurs du Cloud. Pour un four-
nisseur de services, appliquer de tels contrats est impératif, alors que l'absence de tels accords
peut entraîner l'éloignement des utilisateurs et compromettre la croissance de ce fournisseur.
Quant à la qualité de service (Quality of Service : QoS), elle indique le niveau de performance,
de �abilité et de disponibilité o�ert par une application, une plate-forme ou une infrastructure
supportée par un Cloud [9]. Plusieurs paramètres existent pour évaluer la qualité de service.
Parmi ces paramètres, citons : le temps de réponse et le pourcentage de tâches traitées par les
serveurs. Le temps de réponse représente le temps écoulé entre l'envoi d'une tâche au serveur
et la réception de la réponse issue du traitement de cette tâche. Quant au pourcentage de
tâches traitées par les serveurs, il représente le rapport multiplié par 100 du nombre de tâches
traitées par les serveurs sur le nombre de tâches reçues par le Cloud.
Notre recherche porte sur la réduction de la consommation d'énergie dans un Cloud. Plusieurs
techniques sont utilisées a�n de diminuer cette consommation, telle la migration qui consiste à
a�ecter des ressources d'un serveur vers un autre [10]. Elle permet aussi de regrouper plusieurs
VMs dans un seul serveur. Ce dernier objectif, appelé consolidation des serveurs, permet de
réduire la consommation du centre de données en éteignant les serveurs peu utilisés. Il existe
aussi la technique DVFS (Dynamic Voltage and Frequency Scaling) qui permet de varier la
fréquence et le voltage du processeur du serveur, in�uençant ainsi la consommation énergétique
du serveur, tout en ayant un impact sur le temps d'exécution [11].
1.2 Éléments de la problématique
Force est de constater qu'en 2014, les centres de données utilisaient près de 1.62% de l'énergie
consommée dans le monde, alors que la consommation prévue pour l'an 2020 est de l'ordre
de 140 milliards de kWh [12]. En outre, la consommation d'énergie de ces centres de données,
partout dans le monde, devrait doubler tous les cinq ans, ce qui peut générer un coût énorme
pour les entreprises et l'environnement, d'autant plus que ces centres de données sont respon-
sables de l'émission de 2% de CO2 dans l'atmosphère [13]. De ce fait, l'informatique commence
à se mettre au vert, c'est ce qu'on appelle le Green Computing. Ce concept impose le respect
de la nature au processus de traitement des données, au niveau des centres de données, en
minimisant l'émission de CO2 dans l'atmosphère et en utilisant les énergies renouvelables.
À cet e�et, les inquiétudes manifestées face à ce problème ont poussé des chercheurs [14], [15],
[16] à proposer des solutions, tout en gardant comme point de mire le respect de di�érentes
contraintes, telle la qualité de service (QoS) pour l'utilisateur et la minimisation des coûts
pour les fournisseurs. En e�et, certains chercheurs [15] ont proposé des algorithmes, en se
basant sur la technique DVFS, ainsi que sur une a�ectation optimale des machines virtuelles,
tout en tenant compte des paramètres liés au contrat SLA, alors que d'autres [16] se sont
3
concentrés sur les équipements physiques, tel le CPU des serveurs pour proposer une solution
optimale de la consommation d'énergie. D'autres chercheurs ont étudié ce problème, en �xant
une fonction-objectif pour minimiser la consommation d'énergie du Cloud [14].
De toutes les approches possibles, toutes sont à utiliser avec mesure, car elles ne sont pas
sans comporter des désavantages dans certaines conditions. À cet e�et, le problème de la
minimisation de la consommation d'énergie dans un Cloud devient compliqué. La technique
DVFS qui permet de réduire grandement la consommation du processeur des serveurs, en
manipulant la fréquence et le voltage du processeur, peut in�uencer la performance des serveurs
du Cloud. En e�et, un changement de fréquence trop fréquent ralentit l'exécution des tâches, ce
qui fait augmenter le temps d'exécution. Concernant l'ordonnancement des tâches, ce processus
est une étape nécessaire pour l'acheminement des tâches aux serveurs du centre de données.
Toutefois, ce processus est basé sur des algorithmes qui ont un impact sur la consommation
d'énergie au niveau du Cloud [17]. En e�et, la manière avec laquelle ces algorithmes a�ectent
les tâches aux VMs in�uence le nombre de serveurs utilisés. Quant à la migration des machines
virtuelles, elle nécessite une bonne connaissance de la charge de travail au niveau des serveurs,
ce qui conduit à un processus d'optimisation multi objectifs qui doit équilibrer la performance
des applications d'une part, et la consommation globale de l'énergie d'autre part. Le problème
est que les deux objectifs sont contradictoires : si nous apportons une solution pour atteindre
un objectif, l'autre objectif peut être in�uencé négativement par cette solution.
Les divers éléments de la problématique énoncés ci-dessus nous ont donc amenés à nous poser
les questions suivantes :
� Quels sont les principaux paramètres sur lesquels se basent les techniques actuelles de
minimisation de la consommation énergétique pour attaquer le problème de la consom-
mation de l'énergie dans un Cloud ?
� Comment mettre en place une méthode e�cace pour résoudre un tel problème ?
� Comment évaluer cette méthode ?
1.3 Objectifs de recherche
Dans le cadre de la présente recherche, nous visons principalement à proposer une méthode
basée sur la combinaison des techniques de minimisation d'énergie consommée dans le Cloud,
en respectant les contraintes liées à l'e�cacité des services de cet environnement. De manière
plus précise, ce travail de recherche vise à :
1. Comprendre les caractéristiques du Cloud Computing, ainsi que les di�érentes techniques
liées à la consommation d'énergie dans cet environnement ;
2. Analyser le problème de la consommation d'énergie dans le Cloud et proposer une mé-
thode qui permet de minimiser l'énergie consommée, tout en respectant la contrainte de
QoS ;
4
3. Évaluer la performance de la méthode proposée, en comparant son impact sur la consom-
mation d'énergie, ainsi que son respect des contraintes liées à la qualité de service.
1.4 Plan du mémoire
La suite du mémoire est organisée en quatre chapitres. Le deuxième chapitre consistera à situer
le cadre de notre étude, en se basant sur une revue de littérature des concepts du Cloud que
nous jugeons nécessaires pour la compréhension de ce mémoire. De ce fait, nous présenterons
dans un premier temps, les caractéristiques et les di�érents modèles du Cloud Computing.
Ensuite, nous présenterons les topologies, les avantages et inconvénients du Cloud, ainsi que
les di�érentes techniques de réduction de la consommation énergétique dans le Cloud. En�n,
nous terminerons ce chapitre par les dé�s de recherche liés à cet environnement.
Dans le troisième chapitre, l'analyse du fonctionnement du Cloud sera e�ectuée a�n de dé-
terminer les équipements qui consomment le plus d'énergie. À partir de cette analyse, nous
choisirons les paramètres de notre étude et les techniques de minimisation d'énergie consom-
mée. En nous basant sur ces techniques, nous présenterons à la �n de ce chapitre notre méthode
qui a comme point de mire la minimisation de la consommation d'énergie, en respectant la
qualité de service.
Le quatrième chapitre s'appesantira, en premier lieu, à la présentation de notre plan d'ex-
périence qui décrira les étapes nécessaires pour implémenter la méthode proposée. Ensuite,
nous allons détailler la mise en ÷uvre de la méthode, en commençant par choisir l'outil de
simulation, puis présenter les modi�cations apportées au simulateur choisi pour implémenter
la méthode proposée. Di�érentes simulations seront e�ectuées pour évaluer notre méthode. À
partir des résultats issus de ces simulations, nous allons e�ectuer une analyse de ces résultats.
Le chapitre 5 synthétisera ce mémoire par une conclusion qui résumera les contributions et les
résultats obtenus dans le cadre de cette maitrise, ainsi que les limitations de notre méthode
et les futurs travaux.
5
Chapitre 2
Caractérisation du Cloud Computing
La minimisation de la consommation d'énergie est un sujet d'actualité qui concerne plusieurs
domaines [18]. Dans ce contexte, il importe de bien présenter le cadre de notre recherche, d'où
la caractérisation du Cloud computing. Dans ce chapitre, nous allons d'abord introduire les
caractéristiques fonctionnelles du Cloud computing, suivi des di�érents modèles du Cloud et
des topologies. Puis, nous allons présenter les avantages et les inconvénients de cet environne-
ment. Par la suite, les di�érentes techniques de réduction de la consommation d'énergie seront
présentées. Nous terminons ce chapitre en présentant les dé�s de recherche liés au Cloud.
2.1 Caractéristiques fonctionnelles
Dans cette section, nous allons présenter les principales caractéristiques fonctionnelles du
Cloud qui sont : le libre-service à la demande, le partage des ressources, le service mesuré,
l'accès universel, ainsi que l'élasticité des ressources [19], [20].
2.1.1 Libre-service à la demande
Le libre-service à la demande permet à l'utilisateur d'un Cloud d'être en mesure de manipuler
des ressources distantes (serveurs, réseaux, stockage, applications...) en temps réel, en fonction
de ses besoins, et sans avoir à passer par la con�guration manuelle.
2.1.2 Partage des ressources
Les ressources matérielles du fournisseur d'un Cloud sont partagées et mutualisées entre les
di�érents utilisateurs des services o�erts. Ce partage rend l'emplacement exact des données des
utilisateurs impossible à déterminer, ce qui peut poser un véritable problème aux entreprises
qui sont soumises à de nombreuses contraintes réglementaires concernant la localisation et le
contrôle des données. En contrepartie, les économies d'échelle réalisées permettent de réduire
les coûts du fournisseur du Cloud.
6
2.1.3 Service mesuré
La consommation des services d'un Cloud est contrôlée et mesurée. Elle fait l'objet de rapports
dont les indicateurs de performances sont alignés sur ceux du client. Ce concept est dé�ni par
la mise en place d'un compteur pour facturer la consommation des services d'un client. Ces
mesures précises permettent une facturation des utilisateurs qui ne paieront que pour les
ressources qu'ils ont utilisées et pour la durée de consommation de ces ressources.
2.1.4 Accès universel
L'ensemble des ressources d'un Cloud doit être accessible et mis à la disposition de l'utilisateur
n'importe où et simplement à travers le réseau, quel que soit le client utilisé (serveur, PC, client
mobile). En e�et, les grands fournisseurs répartissent les centres de données sur la planète pour
fournir un accès à leurs systèmes en moins de 50 ms, à partir de n'importe quel endroit [19].
2.1.5 Élasticité
L'élasticité du Cloud consiste à mettre à la disposition des utilisateurs de nouvelles capacités
en cas de croissance de la demande. À l'inverse, ces capacités peuvent rapidement diminuer
lorsqu'elles ne sont plus utilisées. Cette élasticité des services Cloud crée pour l'utilisateur
�nal l'illusion d'une capacité in�nie qui peut être mise en service à tout moment. Pour les
entreprises clientes, cette élasticité permet, par exemple, de faire face aux pics d'activités que
l'infrastructure interne n'aurait pu absorber, et d'envisager de nouvelles applications.
2.2 Classi�cation
En termes de modèles, les Clouds sont caractérisés par des modèles de services et des modèles
de déploiement. Dans cette section, nous allons présenter et expliquer ces modèles.
2.2.1 Modèles de services
Ces modèles décrivent les di�érentes catégories de services qui sont accessibles aux clients
depuis une plateforme de Cloud et qu'un fournisseur est capable de proposer. Les plus connus
sont : "le logiciel-service" (Software as a Service : SaaS), "la plateforme-service" (Platform
as a Service : PaaS) et "l'infrastructure-service" (Infrastructure as a Service : IaaS) [21]. Ces
trois services sont illustrés à la �gure 2.1 qui compare le modèle classique aux trois modèles
de services du Cloud, en termes de la gestion des ressources. Comme illustré dans la �gure,
l'entreprise gère toutes ses ressources par elle-même dans le modèle classique, alors que dans
le cloud Computing, l'entreprise gère une partie des ressources et le reste est géré par un
fournisseur du Cloud.
7
Figure 2.1 � Modèles de services
De manière plus précise, le modèle "logiciel-service" ou SaaS est un modèle économique où le
client utilise les applications du fournisseur, lesquelles sont hébergées sur le Cloud. Dans ce
modèle, l'application est gérée par le client à travers une interface, généralement un navigateur.
La responsabilité du client commence et s'arrête au niveau de la gestion de ses propres données
et de l'interaction avec l'utilisateur. Tout ce qui se passe entre l'application et l'infrastructure
relève de la responsabilité du fournisseur. Parmi les vendeurs de solutions SaaS, �gurent Google
Apps, Oracle on Demand, SQL Azure [5].
Le modèle "Plateforme-service" ou PaaS fournit des environnements de création et d'exécution
pour des applications utilisant des langages et des outils supportés par le fournisseur. Ainsi,
l'utilisateur développe ses propres applications qui sont stockées sur le Cloud. Co Crid, Cloud-
Center, GoogleAppEngine ou encore Windows Azure Platform comptent parmi les fournisseurs
de solutions PaaS [22].
Le modèle "infrastructure-service" ou IaaS est utilisé pour la mutualisation des infrastructures
entre les clients et les entreprises. Dans ce modèle, le client contrôle les applications, le logiciel
serveur, les bases de données, les systèmes virtuels, alors que le fournisseur gère la virtuali-
sation, le matériel serveur, le stockage et les infrastructures réseau. Parmi les fournisseurs de
solutions IaaS, nous citons : Amazon Elastic Compute Cloud (EC2), Eucalyptus, RackSpace
Cloud et Terremark [23]. Ces fournisseurs o�rent un accès direct à leurs ressources matérielles.
Avec Amazon, considéré comme un fournisseur classique de solutions de type IaaS, un client
accède à un ordinateur sous la forme d'une image d'une machine virtuelle, sur laquelle le
système d'exploitation et les applications sont installés.
8
Tous les modèles de services cités ci-dessus partagent les mêmes caractéristiques [3] :
� Les clients louent des services au lieu de les acheter, contribuant ainsi à transformer les
dépenses de capital en dépenses opérationnelles ;
� Les fournisseurs sont responsables de toute l'infrastructure derrière le fonctionnement
des services du Cloud, en termes de maintenance, d'administration, de gestion de la
capacité et de gestion des incidents ;
� Les services sont, en théorie, disponibles beaucoup plus rapidement que ceux fournis par
les solutions traditionnelles hébergées dans les serveurs. En e�et, en adoptant le Cloud,
plus de stockage, de projets et d'applications sont garantis.
2.2.2 Modèles de déploiement
Un Cloud peut être déployé de plusieurs manières, comme l'illustre la �gure 2.2. Un utilisateur
a le choix entre se construire ou louer un Cloud privé, béné�cier des o�res d'un Cloud public
ou choisir di�érentes options d'un Cloud communautaire [24].
Figure 2.2 � Modèles de déploiement
Le Cloud privé représente une infrastructure qui est uniquement exploitée par une organisation
privée. Cependant, la gestion de ce nuage peut revenir à l'organisation elle-même, ce qu'on
9
appelle un Cloud interne, ou à un fournisseur externe, ce qui représente un Cloud privé externe.
Le Cloud privé permet aux fournisseurs et aux clients de mieux contrôler leur infrastructure.
Cela contribue au renforcement de la sécurité et de la résilience, car l'accès aux services et au
réseau est restreint. Les grandes entreprises s'appuient beaucoup sur les Clouds privés pour
faire face à des pics de consommation et de charges ponctuels.
Le Cloud public est mis à la disposition du public en général ou d'une organisation très large.
Toutefois, ce Cloud appartient à un fournisseur de services qui gère les ressources, comme les
applications et le stockage. Celles-ci sont accessibles au plus grand nombre depuis Internet. Ce
fournisseur met en place des mécanismes de sécurité pour garantir la con�dentialité des données
ainsi que les droits d'accès. Le principal avantage du Cloud public est son coût raisonnable de
mise en ÷uvre. En e�et, les coûts de déploiement du matériel, ainsi que ceux des applications
et du réseau sont pris en charge par le fournisseur qui les partage avec plusieurs clients.
Le Cloud communautaire est un modèle conçu pour le partage de ressources ou d'informations
au sein de groupes spécialisés ou d'entreprises. Ce partage permet aux utilisateurs du Cloud
communautaire de béné�cier de toutes les ressources que partagent les autres groupes utilisant
le même Cloud. Le secteur de l'aviation ou de la santé, les laboratoires de recherche et de
développement, les universités et les grandes écoles sont friands du Cloud communautaire
pour partager leurs travaux.
Le Cloud hybride est une combinaison du Cloud public et du Cloud privé, qui sont intercon-
nectés pour former un Intercloud [25]. Son avantage consiste à fédérer et agréger les données,
des politiques de sécurité ou de gestion d'identités. Un autre béné�ce consiste à utiliser les
services du Cloud public pour héberger les applications non sensibles et les services du Cloud
privé pour stocker les données critiques (con�dentielles).
2.3 Topologies des centres de données
La topologie d'un centre de données dé�nit la façon dont les équipements physiques constituant
le centre de données sont interconnectés [26]. Dans cette section, nous allons présenter les
topologies du centre de données les plus utilisées, à savoir la topologie en arbre et la topologie
récursive [27], [28].
2.3.1 Topologie en arbre
La topologie en arbre est aussi connue sous le nom de topologie hiérarchique. Dans cette to-
pologie, le réseau est composé de trois niveaux. Ces niveaux sont : le noyau, l'agrégation et
l'accès. Le noyau représente le niveau supérieur de la topologie en arbre. En e�et, il contient les
commutateurs qui sont connectés directement aux commutateurs du niveau inférieur (commu-
tateurs d'agrégation) [6]. Le noyau représente le point d'accès du Cloud. En e�et, les requêtes
10
envoyées par les utilisateurs du Cloud passent d'abord par ce niveau.
Le niveau d'agrégation contient les commutateurs connectés à la fois aux commutateurs d'accès
et aux commutateurs du noyau. Son rôle principal est d'acheminer les requêtes des utilisateurs
du Cloud aux commutateurs d'accès adéquats [6].
Le niveau d'accès fournit la connectivité pour permettre l'accès aux ressources des serveurs
disponibles. La conception de ce niveau est in�uencée par des critères de décision, comme la
virtualisation des serveurs. Parmi les commutateurs les plus couramment utilisés au niveau
d'accès, on peut citer : les commutateurs de type EoR (End-of-Row) et les commutateurs de
type ToR (Top-of-Rack) [6].
Les variantes de la topologie en arbre les plus utilisées dans les centres de données sont : le
Tree basic et le Fat Tree [27], [29]. La topologie Tree basic est constituée de deux ou de trois
niveaux de commutateurs et de routeurs, avec les serveurs comme feuilles. Dans la topologie
à trois niveaux, comme illustré à la �gure 2.3, on trouve le noyau au niveau de la racine de
l'arbre, l'agrégation au milieu de l'arbre, alors que le dernier niveau se compose des commu-
tateurs d'accès connectés aux serveurs. Pour la topologie à deux niveaux, les commutateurs
d'agrégation n'existent pas, comme illustré à �gure 2.4. Les commutateurs du noyau sont in-
terconnectés. L'inconvénient de cette topologie est que le nombre de serveurs est limité par le
nombre de ports des commutateurs du noyau.
Figure 2.3 � Topologie en arbre à trois niveaux
11
Figure 2.4 � Topologie en arbre à deux niveaux
La topologie Fat Tree est une version étendue de la topologie en arbre [30]. Dans cette topolo-
gie, l'interconnexion entre les niveaux suit certaines règles. Soit n le nombre de ports physiques
des commutateurs d'accès. Dans cette con�guration, la moitié de ces ports (n
2) sont connectés
aux ports physiques des serveurs, alors que l'autre moitié des ports des commutateurs d'accès
sont connectés aux ports des commutateurs d'agrégation. La �gure 2.5 représente la topologie
Fat Tree avec n = 4. Cette �gure illustre une topologie qui contient des commutateurs d'accès
comportant quatre ports. De ce fait, les commutateurs d'accès sont connectés d'un côté, aux
serveurs par deux liaisons (n
2), et de l'autre côté, aux commutateurs d'agrégation par deux
liaisons (n
2).
12
Figure 2.5 � Topologie Fat tree
2.3.2 Topologie récursive
Les topologies récursives sont utilisées pour les services gourmands en bande passante, en
fournissant une capacité de réseau élevée pour le tra�c du centre de données [31]. Ces topologies
se basent aussi sur la notion de niveaux. Toutefois, elles utilisent des structures de niveau
inférieur, comme des cellules, pour construire des structures de plus haut niveau. Ainsi, les
serveurs des topologies récursives peuvent être connectés à des commutateurs de di�érents
niveaux ou même à d'autres serveurs. Parmi ces topologies, on peut citer : la topologie Dcell
et la topologie Bcube.
Dans la topologie Dcell, l'élément de base est le DCell0. Cet élément est une con�guration
constituée d'un commutateur et de n serveurs [28]. Comme illustré à la �gure 2.6, le DCell0
est constitué de 4 serveurs, chaque serveur dans DCell0 est connecté à un commutateur de
la même DCell0. Pour construire une topologie DCellk de niveau k, la première étape est
la construction de DCell1 à partir de DCell0. Chaque DCell1 contient n+1 sous-groupes.
Le sous-groupe est représenté par DCell0 et chaque serveur du sous-groupe est connecté à un
serveur d'un autre sous-groupe [28]. Ainsi, la construction de la topologie DCellk est récursive.
Donc, pour construire la topologie DCellk, on se base sur la topologie DCellk−1. La �gure
2.6 présente la topologie DCell1 avec n = 4. Dans cette �gure, la DCell1 est construite de
cinq sous-groupes (DCell0). L'élément DCell0 est composé d'un commutateur et de quatre
serveurs.
13
Figure 2.6 � Exemple de topologie DCell1 avec n=4
Concernant la topologie Bcube, son élément de base est BCube0 qui est similaire à DCell0.
La principale di�érence entre BCube et DCell est au niveau de la taille du réseau. Pour
construire la topologie BCube1, on répète BCube0 n fois et on ajoute n commutateurs, chaque
commutateur étant connecté à un serveur de BCube0. De manière générale, pour construire
la topologie BCubek, on répète la topologie BCubek−1 n fois et on ajoute nk commutateurs.
La �gure 2.7 illustre BCube1 avec n = 4. En e�et, cette topologie est constituée de quatre
commutateurs et quatre BCube0. Chaque BCube0 est constituée d'un commutateur et quatre
serveurs.
Figure 2.7 � Exemple de topologie BCube1 avec n=4
14
2.4 Avantages et inconvénients
Le Cloud computing demeure entouré par plusieurs ambiguités surtout lorsqu'il s'agit de bien
identi�er les avantages ainsi que les inconvénients. Dans cette section, nous allons présenter
d'abord les avantages, puis les inconvénients liés aux di�érents aspects du Cloud computing,
comme la gestion des entreprises, la sécurité, la disponibilité des services et la consommation
énergétique.
Concernant la gestion des entreprises, le Cloud Computing o�re aux entreprises di�érents
avantages. En e�et, le Cloud permet aux entreprises de gagner en temps et en productivité
grâce à la disponibilité et l'élasticité des ressources informatiques. De plus, il o�re des systèmes
de facturation portant sur la consommation réelle de services, par opposition aux systèmes
de forfaits pour lesquels le client paie même s'il ne consomme rien [32]. A�n d'assister à
une meilleure collaboration entre les individus, l'accès aux applications et aux données de
l'entreprise peut se faire à partir d'un terminal quelconque et en temps réel. L'entreprise qui
opte pour le Cloud Computing connaît aussi un gain organisationnel. En e�et, la cohérence
du parc logiciel ne se fait plus par le biais d'installation et de la mise à jour des applications
sur les terminaux, mais revient tout simplement à utiliser la dernière version d'applications
disponibles sur le Cloud. Cette cohérence du parc logiciel facilite ainsi la modi�cation des
données et la synchronisation avec les documents en ligne.
Concernant la sécurité au niveau du Cloud, elle est assurée par la redondance au niveau de
l'enregistrement des données [33], ce qui est avantageux. En e�et, en cas de panne d'un centre
de données, l'utilisateur qui a recours au Cloud ne perdra pas ses documents, car ses derniers
y sont sauvegardés en plusieurs copies. Il est donc plus sécuritaire d'opter pour le Cloud en
matière de stockage de données au lieu d'utiliser son disque dur personnel [33].
A�n d'avoir un service de qualité, la disponibilité des services o�erts par un fournisseur du
Cloud doit se situer entre 98 et 99,99%, incluant les temps d'arrêt des serveurs pour mainte-
nance ou pour des interruptions inattendues [32]. Le Cloud intègre potentiellement des réseaux
locaux et des réseaux distants dans la liaison entre systèmes client et serveurs. La défaillance,
même transitoire, d'un réseau distant ne se traite pas de la même façon que celle d'un réseau
local. En cas de disparition ou d'indisponibilité d'une partie de l'infrastructure réseau, puisque
les données existent de base en plusieurs instances, à priori sur plusieurs sites distincts dispo-
sant de réseaux locaux di�érents, il est possible en théorie d'atteindre une instance de données
disponibles.
L'adoption du Green computing représente un autre avantage qu'o�re le Cloud. En e�et, le
Green computing ou le green IT regroupe l'ensemble des technologies permettant de limiter
la consommation énergétique et les rejets générés par l'industrie informatique [34]. Grâce à la
consolidation de serveurs et la virtualisation, le nombre de serveurs est réduit, ce qui limite la
consommation électrique des onduleurs et la consommation des climatiseurs pour refroidir les
15
onduleurs et les serveurs [35].
Le Cloud présente en contrepartie plusieurs inconvénients. En termes de gestion des entreprises,
le Cloud bouscule les habitudes de l'entreprise, ce qui peut constituer un facteur de risque.
En e�et, dans un schéma classique, toute prestation doit faire l'objet d'une approbation par
la direction �nancière. Avec le Cloud, l'utilisateur peut lui-même acheter le service et le régler
avec sa carte de crédit personnelle, ce qui représente un grand risque pour l'entreprise.
Selon certains analystes [36], le Cloud Computing représente une menace quant à la sécurité
des informations contrôlées par un tiers. En e�et, les risques encourus lorsque les données sont
consolidées sur un serveur unique sont très élevés, car lors d'une panne informatique, il peut
s'avérer di�cile de récupérer tous les renseignements en absence d'une copie déjà enregistrée.
De ce fait, la duplication des informations sur plusieurs sites distants est impérative pour
la sécurité. D'un autre côté, pour pallier au problème de con�dentialité des documents, le
cryptage informatique semble être la meilleure solution. Cependant, le Cloud Computing utilise
essentiellement des machines virtuelles, donc le principal danger provient du nombre restreint
de chi�res liés au cryptage que peuvent exploiter ces machines. Ainsi, une étude conduite
par McKinsey [36] montre également que la sécurité constitue le principal frein à l'adoption
des services du Cloud. En e�et, pour les besoins de son enquête, McKinsey a interrogé 462
décideurs informaticiens et 264 décideurs non-informaticiens sur les principales barrières à
l'adoption du Cloud computing. Le résultat est sans équivoque : la gestion de la sécurité arrive
en première position. La gestion des risques de conformité ainsi que l'exposition de l'entreprise
à ces risques arrivent en deuxième position. Il s'agit aussi du respect des obligations légales en
termes de la con�dentialité des informations concernant les clients, les employés, les paiements
électroniques, etc.
2.5 Techniques de réduction de la consommation d'énergie
Plusieurs techniques existent pour réduire la consommation énergétique au niveau des dif-
férents composants d'un centre de données [13], [37], [38]. Dans cette section, nous allons
présenter les principales techniques de réduction d'énergie, soit au niveau des équipements
physiques, telle la technique DVFS [39], ou au niveau des ressources virtuelles, comme le
processus d'ordonnancement [40] et la migration des machines virtuelles [41].
2.5.1 Technique DVFS
Un centre de données se compose principalement de serveurs et de commutateurs qui sont in-
terconnectés selon une topologie donnée. La consommation totale d'énergie dans un tel centre
de données correspond à la somme de la consommation au niveau des serveurs, et au niveau
des commutateurs. La consommation d'énergie au niveau des commutateurs est liée à l'équi-
libre de la charge de travail au niveau de ces équipements [42]. Toutefois, dans le cadre de
16
notre recherche, nous allons étudier l'équilibre de la charge de travail au niveau des serveurs.
De ce fait, l'autre alternatif pour réduire l'énergie consommée au niveau du centre de données
est la réduction d'énergie consommée au niveau des serveurs. À cet e�et, nous allons nous
concentrer sur ces équipements qui contiennent deux principaux types de composants : les
composants logiciels, comme les machines virtuelles, et les composants physiques, comme le
CPU, le disque et la mémoire. Toutefois, la technique DVFS agit sur le CPU qui consomme
la grande part d'énergie au niveau des serveurs [43]. Cette technique vise à réduire la consom-
mation d'énergie des serveurs d'un Cloud en exploitant le temps d'inactivité du processeur de
chaque serveur [39]. En e�et, un processeur exécute plusieurs tâches avec des relations inter-
tâches (par exemple, des contraintes de précédence) simultanément. Ces relations inter-tâches
entraînent généralement un temps mort (temps d'inactivité) entre les tâches. Ce temps mort
associé à une tâche est utilisé pour exécuter la tâche avec une tension et fréquence minimales.
Cela entraîne à son tour une réduction de l'énergie consommée. En e�et, la puissance utilisée
dans un processeur est dé�nie comme suit et exprimée en Watt (W ) [44] :
P = C ∗ f ∗ V 2 (2.1)
où C est la capacité électrique du processeur. Cette capacité exprimée en Farad (F ), indique
la valeur d'intensité électrique que peut supporter le processeur en appliquant une tension
de 1 V. Ce paramètre C est une constante qui caractérise chaque processeur. La fréquence f
est la fréquence de commutation du processeur exprimée en Hz. Cette fréquence représente la
vitesse avec laquelle le processeur traite les instructions. V est la tension d'alimentation du
processeur exprimée en Volt (V ). À partir de la relation (2.1), on déduit que la diminution de
l'énergie consommée par le processeur nécessite un changement au niveau du couple (f, V ),
en exploitant le temps d'inactivité du processeur.
Considérons la �gure 2.8 qui illustre le fonctionnement de la technique DVFS. Nous avons
trois représentations de la puissance utilisée par un processeur. À partir de l'équation 2.1,
cette puissance est proportionnelle à la fréquence f et au carré de la tension V 2. A�n de
véri�er l'impact de la variation de la fréquence et de la tension sur la consommation d'énergie,
nous allons d'abord présenter à la �gure 2.7.a la puissance P, calculée à partir d'une fréquence
f et d'une tension V. Ces valeurs de la fréquence et de la tension sont utilisées par le processeur
pour exécuter une tâche qui se termine à t1, un instant avant t2 qui représente l'instant de
début de la prochaine tâche. Dans ce cas, le processeur connaît un temps d'inactivité entre
t1 et t2. Pour réduire la puissance, nous allons commencer par réduire la fréquence. Dans cet
exemple, nous allons diviser la fréquence f par deux, puis nous allons présenter la puissance,
correspondante à cette fréquence, à la �gure 2.7.b. Dans cette �gure, la puissance a été divisée
par deux (P/2). Ainsi, le temps d'exécution est doublé, vu que la fréquence est l'inverse du
temps d'exécution. Toutefois, ce temps d'exécution de la tâche t2 n'a pas dépassé le délai pour
que la prochaine tâche s'exécute. Dans cette �gure, nous constatons que l'énergie consommée
est la même que celle présentée à la �gure 2.7.a. Pour réduire l'énergie consommée, nous allons
17
diminuer cette fois-ci la tension. Plus précisément, nous allons le diviser par deux. La �gure
2.7.c présente la puissance calculée à partir de la fréquence f/2 et de la tension V/2. Cette
puissance a été diminuée à P/8, et le temps d'exécution n'a pas dépassé le délai, vu que la
tension n'in�uence pas le temps d'exécution. Ainsi, l'énergie consommée a été réduite. De ce
fait, on déduit que la technique DVFS diminue la consommation d'énergie, en diminuant la
fréquence et la tension.
Figure 2.8 � Impact de la technique DVFS sur la consommation d'énergie
2.5.2 Processus d'ordonnancement
L'ordonnancement des tâches consiste à organiser dans le temps les tâches provenant des utili-
sateurs, en tenant compte des contraintes temporelles (contraintes de délai) et des contraintes
portant sur l'utilisation et la disponibilité des ressources. Avant d'aborder le problème d'ordon-
nancement, il est important de dé�nir les concepts de base du processus d'ordonnancement,
telles les tâches, les ressources et les contraintes [40], [45]. Une tâche est une entité élémentaire
localisée dans le temps, par une date de début, une date de �n, et dont la réalisation nécessite
une durée préalablement dé�nie. Elle est constituée d'un ensemble d'opérations qui requiert,
pour son exécution, certaines ressources. Ces ressources sont des moyens techniques destinés
à être utilisés pour la réalisation d'une tâche et disponibles en quantité limitée. Dans le cadre
18
d'un Cloud, plusieurs types de ressources sont à distinguer : les machines virtuelles, le CPU
et les disques. Une ressource est renouvelable si, après avoir été allouée à une ou à plusieurs
tâches, elle est à nouveau disponible. Quant aux contraintes, elles expriment des restrictions
sur les valeurs que peuvent prendre les variables de décision. Nous distinguons les contraintes
temporelles qui expriment les contraintes liées au temps alloué à la durée des tâches (temps de
début, temps d'arrêt), et les contraintes d'utilisation des ressources qui expriment la nature
et la quantité de moyens utilisés par les tâches, ainsi que leurs disponibilités.
Considérons la �gure 2.9 qui illustre un ordonnanceur constitué d'un contrôleur qui implémente
un algorithme d'ordonnancement et une �lle d'attente qui contient des tâches sur lesquelles
nous appliquons le processus d'ordonnancement. Soit m le nombre de tâches dans la �le, la
tâche i, i = 1, ..., m-1 et la tâche j, j = i+1, ..., m, représentent n'importe quelle tâche dans
la �le. Ce processus d'ordonnancement se compose des étapes suivantes :
� Phase de priorisation des tâches : cette phase établit l'ordre des tâches de départ selon
leurs priorités. De façon plus précise, les tâches de départ sont celles envoyées par l'uti-
lisateur du Cloud et qui arrivent au système d'ordonnancement comme étant le point
d'entrée du Cloud. Dans notre étude, nous considérons qu'aucune tâche n'est prioritaire,
de sorte qu'après cette phase, nous avons une liste ordonnée qui constitue la �le d'attente
dans la �gure 2.9. Dans notre cas, cette �le est ordonnée selon le principe du "premier
arrivé premier servi".
� Phase d'allocation des ressources : cette phase réserve ou alloue un ensemble de res-
sources nécessaires pour l'ordonnancement des tâches. À cette phase, le contrôleur cal-
cule le nombre de machines virtuelles hébergées dans un ou plusieurs serveurs, parmi les
trois serveurs présentés à la �gure 2.9. Ces machines virtuelles sont nécessaires pour le
traitement de chaque tâche i, j, i = 1, ..., m-1, j = i+1, ..., m.
� Phase d'ordonnancement : cette phase sélectionne les ressources (machines virtuelles,
CPU, disque, mémoire) parmi celles précédemment allouées. Cette phase fait l'ordon-
nancement de chaque tâche selon un algorithme qui dé�nit la manière avec laquelle les
tâches sont a�ectées aux machines virtuelles à travers les commutateurs du centre de
données. Dans l'exemple présenté à la �gure 2.9, chaque tâche i est a�ectée à une VM
installée sur le serveur 1.
19
Figure 2.9 � Composants d'un ordonnanceur
La manière d'a�ecter les tâches aux machines virtuelles a un impact sur la consommation
d'énergie. Autrement dit, le processus d'ordonnancement joue un rôle important dans la mi-
nimisation d'énergie consommée. En e�et, la consommation d'énergie dépend de la quantité
de ressources allouées pendant la phase d'allocation des ressources du processus d'ordonnan-
cement.
2.5.3 Migration des machines virtuelles (VMs)
La migration des VMs consiste à transférer les VMs d'un serveur vers un autre. Ce transfert
inclut le transfert de la mémoire, du CPU et du disque vers le serveur de destination. En
e�et, ce transfert est e�ectué à travers les commutateurs qui lient les serveurs. Toutefois,
le processus de migration peut être également utilisé dans un Intercloud. Autrement dit, la
migration peut être e�ectuée entre des serveurs situés dans des clouds di�érents. Dans le cadre
de notre recherche, nous étudions la migration e�ectuée dans le même Cloud, ce qui permet de
résoudre, entre autres, les problèmes de tolérance aux pannes, ou de la continuité des services,
lorsqu'un serveur particulier doit être remplacé pour des tâches de maintenance ou de mise à
niveau des services hébergés.
Les techniques de migration sont classées en migration à froid (Non-live migration) et mi-
gration à chaud (live migration) [41]. La migration à froid d'une machine virtuelle consiste
à e�ectuer le transfert de cette machine en la désactivant dans le serveur source avant le
transfert. Une fois le transfert terminé, la machine virtuelle redevient active dans le serveur
destination. Dans ce type de migration, le temps total de la migration est égal au temps d'arrêt
de la VM, ce qui représente l'intervalle entre l'instant de désactivation de la machine virtuelle
au niveau du serveur source et l'instant de réactivation de cette machine au niveau du serveur
destination. La �gure 2.10 illustre les étapes de ce type de migration. De manière plus précise,
cette �gure considère deux serveurs. Le serveur source héberge trois machines virtuelles VM1,
20
VM2, VM3, alors que et le serveur destination héberge deux machines virtuelles VM4, VM5.
Supposons que VM3 doit être migrée du serveur source vers le serveur destination selon la
migration à froid. Cette migration est e�ectuée en trois étapes :
� Étape 1 : La machine virtuelle VM3 doit s'arrêter dans le serveur source après avoir
sauvegardé son état d'exécution (éteinte, allumée, en état de veille) et ses principaux
paramètres : le CPU, la mémoire et le disque ;
� Étape 2 : Cette étape consiste à transférer l'état d'exécution et les paramètres de la
machine virtuelle 3 vers le serveur de destination. Ce transfert est e�ectué à travers les
commutateurs du centre de données ;
� Étape 3 : Après avoir été transféré vers le serveur de destination, VM3 est réactivée sur
ce dernier.
Figure 2.10 � Processus de migration à froid
L'utilisation de la migration à chaud est importante, lorsqu'on veut migrer une machine vir-
tuelle en cours d'exécution, et qu'on ne veut pas arrêter le service du Cloud qui roule au
niveau de cette machine a�n que l'utilisateur ne sent aucun changement pendant son accès
à ce service. Ce type de migration consiste à transférer une machine virtuelle en cours de
fonctionnement d'un serveur à un autre, avec maintien de l'état de la machine pendant le
processus de transfert. Ainsi, l'utilisateur des services hébergés sur la machine virtuelle n'est
pas conscient du changement de serveurs qui permet de maintenir les services des utilisateurs
pendant la durée du processus. La �gure 2.11 illustre les étapes de la migration à chaud.
De manière plus précise, cette �gure considère deux serveurs. Le serveur source héberge trois
machines virtuelles VM1, VM2, VM3, alors que le serveur destination héberge deux machines
virtuelles VM4, VM5. Supposons que VM3 doit être migrée du serveur source vers le serveur
destination selon la migration à chaud. La migration de VM3 est e�ectuée en cinq étapes :
21
� Étape 1 : Les copies des paramètres de la VM3 de la machine source sont envoyées vers
la machine destination pendant que VM3 fonctionne sur le serveur source ;
� Étape 2 : Toute modi�cation apportée à la machine virtuelle 3 pendant le transfert de
sa copie sera transférée à son tour de manière itérative au serveur de destination ;
� Étape 3 : La machine virtuelle 3 est arrêtée dans la machine source ;
� Étape 4 : Toutes les mises à jour de VM3 sont envoyées au serveur de destination ;
� Étape 5 : La machine virtuelle 3 est activée dans le serveur de destination.
Figure 2.11 � Processus de migration à chaud
2.6 Quelques dé�s de recherche
Plusieurs études se concentrent sur di�érents aspects liés au Cloud pour améliorer ce dernier
[46]. Parmi ces aspects, nous citons : la continuité des services, la sécurité des données, l'hé-
bergement des machines virtuelles et la consommation d'énergie [46], [47]. L'analyse de ces
aspects conduit à plusieurs dé�s de recherche que nous présentons dans cette section.
La continuité des services du Cloud garantit à l'utilisateur d'avoir toujours accès aux mêmes
services du Cloud et ce, de fournisseur de services. Ces exigences liées à la continuité des
services représentent un grand dé� pour le fournisseur du Cloud. En e�et, le fournisseur doit
toujours garantir et anticiper la continuité des services à ses clients en tout temps. Toutefois,
le client ne doit pas dépendre du fournisseur car cette dépendance peut présenter une menace
sur la continuité du service. Par exemple, dans le modèle Saas, où l'utilisateur utilise des
applications installées sur le Cloud, le fournisseur de service gère toute la con�guration de
l'application. De ce fait, si l'utilisateur décide de changer le fournisseur, il doit avoir tous les
accès nécessaires pour con�gurer de nouveau son application, a�n que le service soit continu.
22
Dans le cloud computing, les données doivent être transférées entre les dispositifs de l'utilisa-
teur et les centres de données des fournisseurs de services, ce qui rend ces données une cible
facile pour les pirates. La sécurité des données doit être garantie, que ce soit sur le réseau ou
encore dans les centres de données où elles sont stockées. De ce fait, nous constatons qu'il existe
deux dé�s liés à la sécurité des données : le premier dé� est lié au réseau qui est responsable
de la communication entre les équipements du centre de données et l'utilisateur du service,
et le deuxième dé� consiste à garantir la sécurité au niveau du centre de données. Le premier
dé� est traité, en proposant des solutions comme, la cryptographie, alors que le deuxième dé�
est étudié pour proposer des solutions, telle que la migration.
Avec le Cloud Computing et particulièrement avec le modèle IaaS, les o�res d'hébergement des
services se multiplient [48]. En e�et, les clients disposent d'un environnement d'hébergement
virtuel à la demande, où il est possible de choisir rapidement les machines virtuelles, d'y placer
les applications voulues et les installer dans le Cloud. Toutefois, a�n de ne pas aller à l'encontre
des performances de l'application hébergée, le processus d'assignation des machines virtuelles
aux serveurs ne peut se faire de manière aléatoire. En e�et, il importe de développer des
mécanismes e�caces a�n de s'assurer que les machines virtuelles sont adéquatement déployées
dans les serveurs.
Suite à la création des centres de données à grande échelle, la demande croissante en puissance
de calcul et en espace de stockage a mené à une consommation électrique énorme. Cette
quantité d'énergie consommée entraîne des coûts d'opération largement supérieurs aux coûts
d'investissement, en plus d'être à l'origine d'émissions élevées de CO2. En e�et, force est de
constater qu'en 2014, les centres de données ont utilisé près de 1,62% de l'énergie consommée
dans le monde [49]. Aussi, est-il que la consommation prévue pour l'année 2020 est de l'ordre
de 140 milliards de KWh [49]. À cet e�et, les inquiétudes manifestées face à ce problème ont
poussé les chercheurs à proposer des solutions, tout en gardant comme point de mire le respect
de di�érentes contraintes, telles la qualité de service (temps de réponse, pourcentage de tâches
traitées...) pour l'utilisateur et la minimisation des coûts pour les fournisseurs.
23
Chapitre 3
Analyse du problème
Nous avons vu qu'un Cloud est un système complexe, constitué de plusieurs niveaux d'équipe-
ments et caractérisé par divers modèles de services et de déploiement [21], [24], et présentant
une série de caractéristiques fonctionnelles [19]. L'évaluation de la consommation d'énergie à
travers un tel système nécessite de déterminer la consommation énergétique de chaque équi-
pement. Il en résulte que la minimisation de cette consommation d'énergie est un problème
complexe. Pour y apporter une solution, il importe de bien l'analyser. Dans ce chapitre, nous
allons d'abord présenter le contexte du problème de la consommation d'énergie, en expli-
quant le fonctionnement du Cloud et ses composants. Par la suite, les principaux paramètres
de la consommation d'énergie seront présentés, suivis des méthodes d'optimisation d'énergie
couramment utilisées. En�n, la méthode proposée viendra clore ce chapitre.
3.1 Contexte du problème
Pour présenter le contexte du problème de la consommation d'énergie dans un Cloud, nous
allons décrire le fonctionnement d'un centre de données qui est responsable du traitement des
services du Cloud et ce, pour déterminer les équipements consommant la grande part d'énergie.
Comme illustré à la �gure 3.1, un centre de données est décrit par un ensemble de composants
et de systèmes, comme le système d'alimentation électrique, le système de refroidissement, le
système de distribution d'air et les serveurs. Dans cette section, nous allons présenter chacun
de ces systèmes.
24
Figure 3.1 � Architecture générale d'un centre de données
3.1.1 L'alimentation électrique
Chaque serveur est alimenté par un équipement appelé PSU (Power Supply Unit). Cet équipe-
ment est alimenté à son tour par un réseau électrique sécurisé, provenant de l'unité d'alimenta-
tion électrique et qui se compose de deux équipements : l'onduleur UPS (Uninterrupted Power
Supply) et d'une unité appelée PDU (Power Delivery Unit). A�n d'assurer la disponibilité des
centres de données qui doit être supérieure à 99% [50], une série d'équipements est mise en
place de manière à assurer une alimentation stable et permanente. Pour alimenter les di�érents
PSU, l'énergie électrique provenant du réseau principal atteint tout d'abord l'onduleur UPS.
Ce dernier stocke une grande quantité d'énergie électrique dans des batteries, puis la restitue
en cas de panne d'alimentation principale. À la sortie de cet équipement, le courant alternatif
obtenu doit être transformé et redressé a�n d'alimenter les serveurs. C'est le rôle de l'unité
PDU qui répartit la charge vers les di�érents racks.
3.1.2 Le système de refroidissement
Dans l'optique de maintenir la �abilité des serveurs, il est important de contrôler la chaleur
dégagée par ces derniers, en maintenant des conditions de température et d'humidité appro-
priées. En e�et, l'énergie consommée par les équipements est presque entièrement transformée
en chaleur par e�et de joule. À cet e�et, un système de refroidissement se charge de maintenir
une température adéquate à l'intérieur du centre de données. Ce refroidissement peut se faire
par air, ou par eau. De manière générale, les techniques de refroidissement se réfèrent aux
solutions basées sur l'utilisation directe du milieu extérieur (air ou eau) dans ses conditions
ambiantes pour assurer, en totalité ou en partie, le refroidissement. Un système de refroidisse-
ment d'air froid est illustré à la �gure 3.1 [51]. Son rôle est de capter en permanence l'air chaud
25
produit par les équipements informatiques, de le conditionner à la température froide voulue,
puis de le sou�er vers la salle. Le système de refroidissement est généralement composé d'une
pompe à chaleur (PAC), d'une unité CRAH (Computer Room Air Handling) et des pompes de
circulation. La PAC contient un condenseur qui est refroidi par une tour de refroidissement à
eau. La CRAH dispose d'un ventilateur qui assure les débits d'air sou�é et repris. Finalement,
des pompes de circulation (repérées à la �gure 3.1 par la lettre P) font transiter l'eau dans les
circuits primaires et secondaires du système.
3.1.3 Le système de distribution d'air
Le système de distribution d'air (SDA) utilise une méthode qui vise à acheminer l'air froid
produit par l'unité CRAH vers les serveurs informatiques, tout en extrayant l'air chaud rejeté
par les serveurs, a�n de le conditionner dans l'armoire (rack) [52]. Dans la plupart des centres
de données existants, l'air s'écoule à haute vitesse en adoptant un comportement turbulent.
L'enjeu principal du système de distribution est donc de limiter les mélanges entre l'air froid
destiné au refroidissement des serveurs, et l'air chaud qui doit être évacué. Ainsi, bien qu'il ne
soit pas composé d'éléments physiques, donc qu'il n'absorbe pas d'énergie, le SDA est d'une
importance capitale pour le bon fonctionnement du centre de données. À titre d'exemple, sur
la �gure 3.1, le système de distribution est représenté par des �èches avec la lettre F pour
représenter l'air froid, et des �èches avec la lettre C pour représenter l'air chaud, a�n de
symboliser les écoulements d'air dans le centre de données. L'air froid est sou�é au niveau du
plancher proche des équipements TI (Technologie d'information), tandis que l'air chaud est
capté au niveau du plafond. Ce type de con�guration est nommé Allée chaude/Allée froide.
3.1.4 Les serveurs informatiques
Ces composants sont au c÷ur du centre de données et dé�nissent le mode de fonctionnement
de toutes les installations annexes. Sur la �gure 3.1, ils sont arrangés en racks (ou armoire
informatique) de cinq étages. Comme illustré à la �gure 3.2, les principaux éléments du serveur
qui consomment le plus d'énergie sont : le CPU, la mémoire et le disque. Parmi ces éléments,
celui qui consomme le plus d'énergie est le CPU [43]. L'ensemble de ces éléments compose la
partie TI qui représente l'unité résponsable du traitement des tâches reçues par les serveurs.
La partie TI est alimentée par l'unité électrique PSU (Power Supply Unit).
26
Figure 3.2 � Principaux éléments de consommation d'énergie dans un serveur
Ainsi, les besoins des centres de données, en termes d'énergie, se répartissent en deux grandes
catégories. Nous distinguons, d'une part, l'énergie utile nécessaire à l'alimentation des serveurs
informatiques, et d'autre part, l'énergie annexe absorbée par les équipements qui assurent le
bon fonctionnement de l'installation. Cette seconde catégorie intègre les composants chargés de
la distribution électrique et du refroidissement du système. L'énergie électrique absorbée par
les serveurs représente la part la plus importante de la consommation totale de l'installation,
vu qu'elle représente 60% d'énergie consommée par l'ensemble des composants du centre de
données [10]. Or, celle-ci est intégralement restituée sous forme de chaleur par e�et Joule dans
le centre de données. Le système de refroidissement, responsable du maintien de la température
et fonctionnant sans arrêt, représente le second plus gros poste de consommation, avec 33% de
la consommation totale. Finalement, le faible rendement de la ligne de distribution d'électricité
la rend responsable des pertes d'énergie restante. À partir de ces statistiques, et les statistiques
présentées dans l'étude e�ectuée à [43] concernant la consommation d'énergie au niveau des
di�érents composants du serveur, nous constatons que l'équipement qui consomme le plus
d'énergie au niveau du centre de données est le processeur. En e�et, cet équipement consomme
la part la plus importante au niveau du serveur, et ce dernier consomme 60% d'énergie totale
au niveau du centre de données. À cet e�et, notre méthode va cibler l'énergie consommée au
niveau du processeur.
3.2 Paramètres étudiés
Pour notre recherche, il est nécessaire de �xer les paramètres liés au problème de la consom-
mation d'énergie dans un Cloud. Deux paramètres découlent de l'objectif principal de notre
étude : l'énergie consommée et la qualité de service. Toutefois, l'élément consommant le plus
d'énergie dans un centre de données est le serveur. Dans cette section, nous allons d'abord étu-
dier la consommation d'énergie au niveau des serveurs, ensuite nous allons dé�nir le paramètre
27
in�uençant la qualité de service.
3.2.1 Consommation des serveurs
Plusieurs publications ont analysé la consommation d'énergie au niveau des serveurs dans un
Cloud [53], [54], [55], [56]. Cette analyse est e�ectuée à partir de la puissance utilisée par les
serveurs, vu que l'énergie consommée est liée à la puissance par une relation linéaire. En e�et,
l'énergie consommée par les serveurs est exprimée comme suit [57] :
E = P ∗ t (3.1)
où P : la puissance utilisée par les serveurs,
t : le temps d'utilisation des serveurs.
Les études présentées précédemment montrent qu'il existe une relation entre la puissance P
et la charge de travail (load) qui représente le nombre de tâches traitées par le centre de
données exprimé en MIPS (millions d'instructions par seconde). Cependant, les instructions
sont mesurées en bits. De ce fait, la charge de travail est exprimée en bit/s.
À partir des résultats illustrés à la �gure 3.3, la puissance des serveurs augmente lorsque la
charge du centre de données augmente. De ce fait, en se basant sur l'équation (3.1), l'énergie
consommée par les serveurs augmente également. Ces résultats sont extraits à partir des expé-
riences dans lesquelles les chercheurs augmentent le nombre de tâches envoyées aux serveurs
du Cloud [57]. Cette augmentation qui entraîne une augmentation de la charge de travail C
ne doit pas dépasser la capacité maximale du serveur.
Figure 3.3 � Puissance d'un serveur sans le mode de veille
Dans les premières études, comme dans [58], la puissance des serveurs est exprimée comme
suit :
28
P =Pmax
Cmax∗ C (3.2)
où Cmax : la charge de travail maximale que les serveurs peuvent gérer. Ce paramètre dépend
de la capacité de chaque serveur, en termes de processeur, de mémoire et de disque.
Pmax : la puissance maximale des serveurs qui se produit lorsque la charge de travail du Cloud
est au maximum.
Cependant, d'autres études [59] montrent que les serveurs consomment de l'énergie, même
quand ils ne sont pas soumis à des charges de tra�c : ils sont alors en mode de veille. La
puissance électrique en mode de veille, Pidle, peut être une grande fraction de la puissance
maximale Pmax des serveurs [59]. En e�et, Pidle peut représenter 60% à 95% de la puissance
maximale. Dans ce cas, la puissance des serveurs est exprimée comme suit [60] :
P = Pidle +Pmax − Pidle
Cmax∗ C (3.3)
où Pidle : la puissance des serveurs en mode de veille, ce qui correspond à la puissance des
serveurs lorsque la charge de travail du Cloud est nulle,
Pmax : la puissance maximale des serveurs qui se produit lorsque la charge de travail du centre
de données est au maximum,
Cmax : la charge de travail maximale que les serveurs peuvent gérer.
À partir de l'équation (3.3), nous présentons également P comme suit :
P = Pidle + Eb−inc ∗ C (3.4)
où Pidle : la puissance en mode de veille qui correspond à la puissance des serveurs lorsque la
charge de travail du Cloud est nulle,
Eb−inc : l'énergie incrémentale par bit du serveur. En e�et, cette énergie représente l'énergie
que le serveur consomme en traitant un bit de la charge de travail du centre de données. Cette
énergie est dé�nie en combinant l'équation (3.2) et l'équation (3.3). En remplaçant la puissance
exprimée dans l'équation (3.3) par celle dé�nie par (3.2), l'unité de temps sera simpli�ée, et
nous obtiendrons Eb−inc, exprimée en Joule par bit.
29
Figure 3.4 � Puissance d'un serveur avec mode de veille
3.2.2 Qualité de service
Le paramètre choisi pour évaluer la qualité de service est le pourcentage P de tâches traitées
par les serveurs. Comme il faudra faire des choix, on peut tenter de réduire la consommation
d'énergie et d'augmenter la qualité de service de manière concurrente, en tentant d'atteindre
un bon compromis. À cet e�et, le choix du pourcentage P est basé sur la relation entre le
nombre de tâche traitée et la consommation d'énergie. De ce fait, ce paramètre P nous permet
de gérer le compromis entre la minimisation de la consommation d'énergie et le respect de la
qualité de service grâce à l'équation (3.3). Comme nous avons déjà vu, ce paramètre représente
le rapport multiplié par 100 du nombre de tâches traitées par les serveurs sur le nombre de
tâches reçues par le Cloud. Le pourcentage P est exprimé comme suit :
P =Nt
Nr∗ 100 (3.5)
où Nt : le nombre de tâches traitées par les serveurs,
Nr : le nombre de tâches reçues par le Cloud.
Comme présenté à l'équation 3.3, la puissance des serveurs dépend du nombre de tâches
traitées par le Cloud. En conséquence, l'énergie consommée par ces serveurs dépend aussi de
la charge de travail qui est caractérisée par une valeur maximale. Si le Cloud reçoit une charge
de travail élevée, la consommation d'énergie des serveurs sera élevée, alors que le pourcentage P
de tâches traitées va diminuer, car ce pourcentage P est inversement proportionnel au nombre
de tâches reçues par le Cloud Nr. Ainsi, la variation de la consommation d'énergie in�uence
ce pourcentage P qui doit être supérieur à 80% pour garantir une bonne qualité de service
[61].
30
3.3 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 a�n 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 e�et, 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 e�et, 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 a�n de diminuer le nombre de serveurs en
mode veille. En e�et, 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. A�n d'illustrer ce processus de migration,
31
présenté dans [64], nous considérons la con�guration 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 a�ecté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 a�ec-
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,
le serveur 1 est caractérisé par P1 qui est égal à 70%, alors que les pourcentages P2 et P3
32
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 e�ectuée, la machine virtuelle
6 est a�ecté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 a�ecter celles-ci
aux machines virtuelles sous-utilisées hébergées dans les serveurs, a�n de partager e�cace-
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
à a�ecter ces tâches aux serveurs appropriés. En e�et, 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 a�ecte 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 e�et, cet algorithme a�ecte 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éri�ant 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 a�ectée
à la première VM du premier serveur, la deuxième tâche et la troisième tâche sont a�ec-
tées également au premier serveur. Or, après l'a�ectation 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
a�ectées au deuxième serveur.
33
Figure 3.6 � Algorithme d'ordonnancement Green Scheduler
� Round Robin
L'algorithme d'ordonnancement des tâches Round Robin a�ecte 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 a�ectée
à la première machine virtuelle du serveur 1, la deuxième tâche est a�ectée à la première
machine virtuelle du serveur 2, la troisième tâche est a�ecté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 a�ectées respectivement à la deuxième machine virtuelle du premier,
du deuxième et du troisième serveur.
Figure 3.7 � Algorithme d'ordonnancement Round Robin
34
� 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 a�ectées aléatoirement. Dans cet exemple, la première tâche est a�ectée à
la première VM du premier serveur, la deuxième tâche est a�ectée à la première VM du
deuxième serveur, la tâche 3 est a�ectée à la deuxième VM du premier serveur, alors
que la quatrième tâche et la cinquième tâche sont a�ecté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, a�ectées au deuxième serveur, occupent toutes ses machines virtuelles et que
l'algorithme a�ecte 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 e�et 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 e�et, 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 in�uencent la perfor-
mance du Cloud, comme l'algorithme Random. L'application de cet algorithme entraine plus
35
de tâches non traitées, comme présenté à la sous-section 3.3.3.
3.4 Méthode proposée
Pour combler les lacunes présentées par chaque technique prise individuellement, plusieurs
chercheurs ont proposé de combiner deux à deux ces techniques [72], [11], [73], [74], [75].
Parmi ces recherches, il y en a qui combinent la technique DVFS et l'ordonnancement [72],
[11], [73], alors que d'autres intégrent la migration avec l'ordonnancement [74], [75]. Considé-
rons d'abord les études qui proposent l'intégration de la technique DVFS et d'un algorithme
d'ordonnancement. Dans ce contexte, Tang et al. [72] proposent un algorithme d'ordonnan-
cement de tâches DEWTS (DVFS-enabled E�cient Energy �ow Task Scheduling) basé sur
la technique DVFS. Dans un délai donné, cet algorithme peut distribuer les tâches aux ma-
chines virtuelles appropriées et les traiter aux intervalles de temps nécessaires pour réduire
la consommation d'énergie des serveurs et atteindre les performances requises par le Cloud.
La technique DEWTS comporte les phases suivantes : le mappage initial des tâches et la fu-
sion des processeurs. Le mappage initial des tâches nécessite d'obtenir les priorités de toutes
les tâches dans l'ordre décroissant. Quant à la fusion des processeurs, elle permet de calculer
d'abord le nombre de tâches traitées par chaque processeur, puis trier les processeurs par ordre
décroissant, en termes de nombre de tâches traitées. Pour réduire le nombre de processeurs
utilisés, l'algorithme d'ordonnancement DEWTS permet de distribuer les tâches aux machines
virtuelles hébergées dans des serveurs appropriés. Ces serveurs contiennent les processeurs qui
traitent le plus grand nombre de tâches reçues par le Cloud. En e�et, ces processeurs sont pla-
cés au début de la liste des processeurs, obtenue dans la phase de fusion des processeurs. Les
résultats de cette étude montrent que l'algorithme DEWTS permet d'augmenter l'utilisation
des processeurs et de réduire la quantité de la consommation d'énergie des serveurs.
D'autre part, Wu et al. [11] ont intégré un algorithme d'ordonnancement écologique et la mé-
thode DVFS pour minimiser la consommation énergétique des serveurs. Cet algorithme d'or-
donnancement utilise l'ordonnancement prioritaire des tâches pour sélectionner les machines
virtuelles en fonction d'un poids calculé, selon les exigences des utilisateurs pour exécuter les
tâches. Ce poids est calculé en multipliant le coût énergétique de chaque machine virtuelle
par le nombre de machines virtuelles utilisées. La technique DVFS permet alors de réduire la
consommation d'énergie d'un serveur, quand il est en mode de veille, ou durant une charge de
travail faible. Dans cette étude, deux paramètres sont considérés : la consommation d'éner-
gie des serveurs et le temps d'évaluation de la qualité de service de l'approche proposée. Les
résultats de cette recherche présentent ces deux paramètres en fonction du nombre de tâches
reçues par le Cloud. Ces résultats sont comparés à ceux présentés dans [76], utilisant un algo-
rithme d'ordonnancement basé sur le choix de la machine virtuelle la plus performante pour
exécuter les tâches reçues. En e�et, la méthode proposée dans [11] peut réduire de 23% la
consommation d'énergie de la méthode présentée dans [76]. Toutefois, les délais d'exécution
36
des tâches reçues par le Cloud sont très proches de ceux présentés dans [76].
Par ailleurs, Mishra et al. [73] ont proposé un algorithme d'ordonnancement EEDTSA (Energy
E�cient DVFS based Task Scheduling Algorithm) basé sur la technique DVFS pour réduire
au minimum la consommation d'énergie des serveurs, en changeant di�érentes paires tension-
fréquence du CPU pour chaque tâche. Par la suite, l'algorithme d'ordonnancement Hetero-
geneous Earliest-Finish-Time (HEFT) [77] est appliqué pour a�ecter toutes les tâches aux
machines virtuelles appropriées. Ces machines virtuelles utilisent une partie du processeur des
serveurs sur lesquels elles sont hébergées. Cet algorithme d'ordonnancement comporte deux
phases principales : une phase pour calculer les priorités de toutes les tâches, et une phase pour
sélectionner les meilleurs processeurs, en termes de performance pour les tâches prioritaires.
La consommation d'énergie de cet algorithme a été comparée avec celle de l'algorithme Ran-
dom utilisé sans la technique DVFS. Cette comparaison a montré que l'algorithme EEDTSA
permet de consommer moins d'énergie que l'algorithme Random.
Considérons maintenant la deuxième catégorie de recherches qui proposent l'intégration de
la migration et d'un algorithme d'ordonnancement [74], [75]. Dans ce contexte, Farahnakiam
et al. [74] ont proposé une méthode de consolidation dynamique des serveurs appelée RL-
DC (Reinforcement Learning-based Dynamic Consolidation). Cette méthode est basée sur la
migration et utilise l'algorithme d'ordonnancement Random pour réduire le coût d'énergie
des serveurs et éviter la violation du contrat SLA (Service Level Agreement), c'est à dire
l'ensemble des clauses que le fournisseur du Cloud s'engage à respecter. En e�et, la violation
du contrat SLA est calculée par la di�érence entre le nombre de tâches reçues par le Cloud et le
nombre de tâches traitées dans les serveurs. La migration, utilisée dans la méthode RL-DC, se
base sur l'apprentissage par renforcement. En e�et, l'apprentissage par renforcement permet
d'apprendre à détecter un serveur sous-utilisé par l'intermédiaire d'un agent d'apprentissage.
Ensuite, la méthode RL-DC permet d'a�ecter toutes les machines virtuelles de ce serveur sous-
utilisé à d'autres serveurs, pour que le serveur sous-utilisé passe à l'état de veille. De plus,
les machines virtuelles sont hébergées dans les serveurs qui consomment le moins d'énergie.
Les auteurs ont comparé l'énergie consommée par les serveurs en appliquant la méthode RL-
DC, avec l'énergie consommée par les serveurs en utilisant les trois algorithmes de migration
présentés dans [78]. La fonctionnalité principale de ces algorithmes est de dé�nir les seuils
d'utilisation du CPU des serveurs pour appliquer la migration des machines virtuelles. Grâce
à la capacité d'apprentissage de la méthode RL-DC, une réduction d'énergie des serveurs de
15% à 40% est atteinte par rapport aux trois autres algorithmes. De plus, une amélioration
au niveau du SLA est constatée, en termes de nombre de tâches traitées dans les serveurs.
D'autre part, l'approche présentée dans [75] a également mis l'accent sur l'intégration d'un
algorithme d'ordonnancement et de la migration des machines virtuelles a�n d'obtenir un
système écoénergétique. Dans cette recherche, Chribi et al. [75] ont proposé une combinaison de
deux algorithmes : un algorithme d'ordonnancement basé sur le tri des machines virtuelles selon
37
un ordre décroissant, en termes de consommation d'énergie, et un algorithme de migration qui
tient compte d'un nombre minimal de migrations et d'une consommation d'énergie minimale.
Des économies signi�catives d'énergie peuvent être obtenues en fonction de la charge de travail
au niveau des serveurs. À faible charge, les gains obtenus à partir de la minimisation d'énergie
consommée des serveurs peuvent être assez importants. Toutefois, ces gains sont plus faibles
à des charges élevées, en termes de consommation d'énergie des serveurs.
À partir de l'analyse précédente, nous déduisons que l'intégration de deux techniques de mini-
misation de la consommation d'énergie apporte une amélioration au niveau de la consomma-
tion d'énergie des serveurs par rapport à l'utilisation d'une technique prise individuellement.
Toutefois, la combinaison de deux techniques comporte toujours des lacunes au niveau de
la performance du Cloud et au niveau de la minimisation de la consommation d'énergie des
serveurs, surtout lorsque la charge de travail au niveau des serveurs est élevée [11], [75]. Étant
donné ces limites, nous proposons une méthode basée sur l'intégration des trois techniques de
minimisation de la consommation d'énergie a�n de combler les lacunes de ces méthodes. Pour
ce faire, nous allons d'abord �xer une durée de session ts durant laquelle nous appliquons la
méthode proposée. En e�et, le Cloud va recevoir durant la période ts les tâches envoyées par
les utilisateurs. Ces tâches représentent les demandes de services qu'o�re le Cloud sollicité, et
elles sont reçues par l'ordonnanceur une à la fois, jusqu'à la �n de la durée ts. Après avoir reçu
toutes les tâches, trois phases seront appliquées, comme présenté à la �gure 3.9. La première
phase consiste à choisir l'algorithme d'ordonnancement qui o�re la meilleure consommation
d'énergie. La deuxième phase sert à intégrer la technique DVFS à l'algorithme d'ordonnan-
cement choisi pour améliorer la consommation d'énergie. Quant à la troisième phase, elle
consiste à intégrer le processus de migration aux deux techniques précédentes, suite à l'éva-
luation du pourcentage d'utilisation du CPU. Cette évaluation exprime la surutilisation ou la
sous-utilisation du serveur. A�n d'évaluer l'e�cacité de notre méthode, en termes de consom-
mation d'énergie et du respect des exigences de qualité de service, nous évaluons l'énergie
consommée E pendant ts, puis, nous calculons le pourcentage de tâches traitées P.
� Phase 1 : Choix de l'algorithme d'ordonnancement
A�n d'a�ecter les tâches reçues aux machines virtuelles hébergées par les serveurs, un
système d'ordonnancement est mis en place pour e�ectuer ce travail, comme illustré
aux �gures 3.6, 3.7 et 3.8. Le choix de l'algorithme d'ordonnancement in�uence l'énergie
consommée et la performance de service, vu que certains algorithmes peuvent engen-
drer des tâches non traitées, comme l'algorithme Random (voir �gure 3.8). De ce fait,
cette étape consiste à choisir parmi les algorithmes d'ordonnancement suivants : Green
Scheduler, Random et Round Robin, celui qui o�re la consommation d'énergie la plus
faible. Pour ce faire, nous e�ectuons trois tests, en considérant à chaque fois un al-
gorithme d'ordonnancement parmi les trois. Pour chaque test, nous calculons l'énergie
consommée par les serveurs du Cloud. En�n, nous choisissons l'algorithme qui o�re la
38
Figure 3.9 � Diagramme de �ot de la méthode proposée
39
consommation d'énergie la plus faible.
� Phase 2 : Intégration de la technique DVFS
Après avoir choisi l'algorithme d'ordonnancement adéquat, nous le combinons avec la
technique DVFS. Cette technique est appliquée sur tous les serveurs actifs du centre de
données, c'est-à-dire les serveurs utilisés pour traiter les tâches envoyées par les utilisa-
teurs. Une variation au niveau de la fréquence et du voltage du CPU en est résultée,
d'où une variation au niveau de la charge du processeur (CPU) de chaque serveur actif.
� Phase 3 : Intégration de la migration
Nous appliquons le processus de migration à la combinaison de l'algorithme d'ordonnan-
cement choisi et la technique DVFS. L'application de la migration sur un serveur est liée
au pourcentage d'utilisation du CPU. En e�et, le calcul de ce paramètre est basé sur le
nombre d'instructions, mesuré en MIPS, utilisé pour représenter la capacité du serveur et
la capacité de la VM hébergée dans le serveur actif, en termes de traitement des tâches.
Les tâches reçues seront distribuées aux machines virtuelles sur di�érents serveurs. Soit
n le nombre de serveurs et mi le nombre de machines virtuelles hébergées dans chaque
serveur i, i = 0, ....., n-1 . Nous supposons que chaque serveur i a son propre nombre mi
de machines virtuelles. Pour calculer le pourcentage d'utilisation Pi du CPU de chaque
serveur, nous commençons par calculer le nombre de tâches traitées par chaque serveur
i. Ce nombre Ui, exprimé en MIPS, est calculé à partir du nombre de tâches Vj traitées
par chaque machine virtuelle hébergée j. Ui est exprimé comme suit :
Ui =
mi−1∑j=0
Vj , i = 0, 1, ..., n− 1 (3.6)
où Vj : le nombre de tâches traitées par chaque machine virtuelle j, hébergée dans le
serveur i,
mi : le nombre de machines virtuelles hébergées dans le serveur i.
Le pourcentage d'utilisation Pi du CPU est dé�ni à partir du nombre Ui de tâches
traitées par le serveur i et le nombre maximal Si de tâches que peut traiter le processeur
du serveur i. De ce fait, Pi est exprimé comme suit [79], [80] :
Pi =Ui
Si∗ 100, i = 0, 1, ..., n− 1 (3.7)
où Si : le nombre maximal de tâches que peut traiter le processeur du serveur i,
Ui : le nombre de tâches traitées par chaque serveur i.
La migration est appliquée sur un serveur i comme étant le serveur source, s'il est dans
un état de surcharge ou un état de sous-charge. Dans [81], l'état de surcharge est dé�ni
lorsque Pi > 70% et l'état de sous-charge est représenté par Pi < 30%. De ce fait,
l'intégration de la migration est réalisée comme suit :
40
Si 30% ≤ Pi ≤ 70% : La migration n'est pas appliquée au niveau de ce serveur, car sa
charge est équilibrée.
Si Pi > 70% : une migration est e�ectuée au niveau de ce serveur.
Si Pi < 30% : toutes les VM seront migrées vers d'autres serveurs et ce serveur i sera
en mode veille.
Après avoir appliqué les trois phases de notre méthode, il sera question d'évaluer l'e�cacité
de celle-ci, en termes de consommation d'énergie et de qualité de service. Pour ce faire, nous
évaluons d'abord la quantité d'énergie E consommée par les serveurs. Puis, nous calculons
le pourcentage de tâches traitées P, après l'application des trois phases de la méthode, a�n
d'évaluer l'impact de cette méthode sur la qualité de service.
41
Chapitre 4
Mise en ÷uvre et résultats
Après la présentation de notre méthode, il est important d'en présenter la mise en ÷uvre a�n
d'évaluer son e�cacité, en termes de consommation d'énergie et de qualité de service à partir
des résultats obtenus. Ce chapitre détaille la phase de la mise en ÷uvre de notre méthode,
ainsi que celle d'obtention et d'analyse des résultats. De façon plus précise, il sera question de
présenter d'abord le plan d'expérience. Par la suite, une étude détaillée des di�érentes étapes
de ce plan sera élaborée. En�n, il sera nécessaire d'e�ectuer une analyse des résultats issus de
la mise en ÷uvre.
4.1 Plan d'expérience
Ce plan d'expérience décrit les étapes nécessaires à la mise en ÷uvre de la méthode proposée et
à l'obtention des résultats de cette méthode. Cette mise en ÷uvre nécessite le choix d'un outil
de simulation qui servira à l'implémentation de la méthode proposée. En e�et, la réalisation
des scénarios de manière répétitive est parfois impossible dans un Cloud réel, car les données
varient instantanément. À cet e�et, pour choisir un simulateur adéquat, nous allons commencer
par une analyse des outils existants, les catégoriser à partir de leurs fonctionnalités, puis les
comparer, en termes d'énergie consommée dans le but d'opter pour l'outil le plus adapté à la
méthode proposée.
Pour implémenter notre méthode, il convient d'abord de véri�er si l'outil choisi implémente les
trois caractéristiques de la méthode : les algorithmes d'ordonnancement, DVFS et la migration.
Dans le cas où l'outil choisi n'implémente pas toutes ces caractéristiques, il sera nécessaire d'y
implémenter les caractéristiques manquantes. Puisque la méthode proposée est basée sur une
contrainte liée au pourcentage d'utilisation du CPU pour intégrer le processus de migration,
il sera question d'implémenter cette contrainte dans l'outil de simulation. En�n, il s'avère
nécessaire d'y implémenter l'intégration des trois caractéristiques de la méthode proposée, vu
que celle-ci est dé�nie par la combinaison de ces trois caractéristiques.
42
L'obtention des résultats quant à elle, sera déduite à partir de trois séries de simulations ef-
fectuées dans l'outil choisi. La première série de simulations vise à tester l'impact de chaque
algorithme d'ordonnancement sur la consommation d'énergie, et d'en déduire celui qui o�re
la plus faible consommation d'énergie, puis sélectionner cet algorithme pour le reste des si-
mulations. La deuxième série de simulations consiste à intégrer à l'algorithme sélectionné la
technique DVFS, puis à comparer le comportement résultant de cette combinaison avec celui
de la première série de simulations. Pour la troisième série de simulations, nous allons intégrer
le processus de migration à la combinaison précédente.
Ces simulations permettront d'évaluer l'impact de l'intégration des trois caractéristiques de la
méthode proposée sur la consommation d'énergie, ainsi que sur la qualité de service. Pour ce
faire, nous allons comparer les résultats de ces simulations avec ceux des deux séries de simu-
lations précédentes. A�n de quanti�er la consommation énergétique et la qualité de service,
deux paramètres seront utilisés : la quantité d'énergie consommée au niveau des serveurs et le
pourcentage de tâches traitées. En vue de simuler le Cloud dans ses di�érents états de charge,
il sera plus convenable d'exprimer les di�érents résultats de simulations en fonction du taux
d'utilisation des ressources. Ce paramètre représente le nombre de ressources informatiques
attribuées (CPU, mémoire, disque) pour traiter les tâches reçues par le Cloud, par rapport au
nombre de ressources disponibles dans le Cloud.
4.2 Mise en ÷uvre
Pour la mise en ÷uvre de la méthode proposée, nous allons d'abord justi�er 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 modi�cations 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 e�et,
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 e�et nous contenter de la première catégorie de simulateurs qui contient Green Cloud,
Cloud Sim.
Ensuite, nous allons e�ectuer 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
43
Pramètres Green Cloud Cloud SimModèles d'applications Calcul, transfert de données Calcul, transfert de donnéesModèles d'énergie Appliqué pour tous les compo-
sants du centre de donnéesAucun
Mode d'économie d'énergie DVFS, DNS, DVFS+DNS AucunSupport du résultat HTML Console
Table 4.1 � Comparaison entre Green Cloud et Cloud Sim
qui implémentent les types d'applications qu'o�re le Cloud sont les mêmes pour les deux
simulateurs. En e�et, 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 e�ectuer 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 o�rant 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 o�re 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 e�et, 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 o�re 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, a�n de simuler et étudier les performances des protocoles réseau [88]. Il
o�re 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
44
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'a�ecter une
valeur à une variable, alors que d'autres commencent par la fonction put qui sert à l'a�chage.
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 e�et, 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 e�et, 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 tra�c du Cloud qui représente l'ensemble des requêtes envoyées par les utilisateurs du
service Cloud. Ce tra�c 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 tra�c 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
45
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.2 � Topologie à deux niveaux
46
Figure 4.3 � Topologie à trois niveaux
4.2.2 Implémentation
Pour implémenter la méthode proposée, nous allons e�ectuer des modi�cations 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 e�et, toute simulation
dans Green Cloud est basée sur sept �chiers en format tcl, contenant toute la con�guration 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.
47
Fichier Rôle
Main.tcl détermine la topologie du centre de données et le tempsde la simulation. Il fait appel aux autres �chiers de lacon�guration.
Setup_ params.tcl contient la con�guration générale des serveurs, des tâches etdes 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 machinesvirtuelles.
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ésultatsd'exécution.
Finish.tcl calcule et présente les statistiques de la simulation.
Table 4.2 � Fichiers de con�guration 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à e�ectuée dans le simulateur. En e�et, 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 e�et, la classe ScoreScheduler implémente les caractéristiques
des algorithmes qui a�ectent 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.
48
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 e�et, 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
e�et, le simulateur utilise la fonction void setDVFS (int eDVFS_enabled_) pour activer
49
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 e�et, 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'e�ectuer deux modi�cations. La première consiste à modi�er
le nombre de machines virtuelles par serveur. En e�et, nous augmentons d'abord ce nombre
pour rendre le Cloud simulé plus réel. Alors que la con�guration de base de Green Cloud ne
supporte qu'une machine virtuelle par serveur, un Cloud réel o�re 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 modi�ons le
�chier `dc.tcl' dans l'optique de supporter plusieurs machines virtuelles par serveur. Un indice
est ajouté à chaque machine virtuelle pour l'identi�er dans le serveur qui l'héberge. Soit n le
50
nombre de serveurs, comme présenté à la �gure 4.7, dans la con�guration 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 con�guration 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 identi�e la machine virtuelle parmi les mi
machines virtuelles hébergées dans Si.
Figure 4.7 � Comparaison des con�gurations de machines virtuelles dans Green Cloud
Pour implémenter cette con�guration, 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 a�n 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 e�et,
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.
51
Figure 4.8 � Modi�cation 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 . A�n de simpli�er cette implémentation
et utiliser un tableau à une dimension, nous utilisons un seul indice l, l = 0, ....,∑n−1
i=0 mi
pour identi�er 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 identi�ant les machines virtuelles dans chaque serveur i, i = 0, ...., n-1 ,
à un seul indice l, l = 0, ....,∑n−1
i=0 mi, identi�ant 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 identi�er 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∑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.
52
Figure 4.9 � Implémentation de la con�guration modi�ée des machines virtuelles dans GreenCloud
Figure 4.10 � Création des machines virtuelles dans Green Cloud
53
La deuxième modi�cation à e�ectuer 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 e�et, nous modi�ons 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 � Modi�cation du processus de migration
4.3 Résultats et analyse
A�n d'évaluer l'e�cacité et les performances de la méthode proposée, nous allons e�ectuer
trois séries de simulations. Dans cette section, nous allons d'abord �xer les paramètres de
simulations. Ensuite, nous allons présenter et analyser les résultats de ces simulations.
4.3.1 Paramètres de con�guration
Pour obtenir les résultats de simulations, il est important de con�gurer les paramètres sui-
vants : la topologie du centre de données, le nombre de serveurs, les paramètres des tâches
reçues, le mode d'énergie. Comme présenté à la sous-section 4.2.2, le �chier de con�guration
d'un Cloud dans Green Cloud est `setup_params.tcl'. Pour la topologie du centre de données,
54
nous optons pour la topologie par défaut du simulateur Green Cloud qui est la topologie à
trois niveaux illustrée à la �gure 4.3. La �gure 4.12 illustre la topologie implémentée dans le
simulateur Green Cloud qui représente une instance de la topologie à trois niveaux illustrée à
la �gure 4.3. Cette instance comporte 144 serveurs, distribués en trois racks (48 serveurs par
rack), reliés entre eux par un commutateur de coeur, deux commutateurs d'agrégation et trois
commutateurs d'accès. Comme mentionné au plan d'expérience, nos résultats sont présentés
en fonction du taux d'utilisation des ressources qui est �xé indépendamment du nombre de
serveurs de la topologie. De ce fait, le choix de la topologie du centre de données n'in�uence
pas notre recherche, ce qui justi�e le choix de la topologie par défaut du centre de données.
Figure 4.12 � Topologie du centre de données simulé
Nous con�gurons maintenant les paramètres des tâches suivants : le nombre d'instructions
traitées par tâche, la taille d'une tâche, ainsi que le type d'une tâche. Pour ces paramètres, nous
adoptons ceux par défaut dans le simulateur Green Cloud. À cet e�et, le nombre d'instructions
d'une tâche est �xé à 300 000 MIPS et la taille d'une tâche à 100 000 octets. Quant au type
d'une tâche, il est �xé à `HPC'(High Performance Computing). Ce type de tâche est le plus
utilisé, vu que le type `HPC' se caractérise par une vitesse de traitement plus élevée [93].
Après avoir con�guré les paramètres des tâches, nous �xons le mode d'énergie dans le si-
mulateur Green Cloud. Pour activer le mode DVFS dans ce simulateur, nous attribuons au
paramètre Serv(eDVFS_enabled) qui se trouve dans le �chier `setup_params.tcl' la valeur 1.
Cette valeur signi�e que dans notre simulation, les serveurs supportent la technique DVFS.
55
L'activation de cette technique dans Green Cloud est présentée à l'annexe A.
Après avoir con�guré le Cloud, il est important de �xer le temps nécessaire pour simuler son
fonctionnement. Ce temps de simulation indique le temps réel de fonctionnement du centre
de données. Nous �xons ce temps de simulation à 60 s pour éviter trop d'attente pendant
les simulations. Pour con�gurer ce temps dans Green Cloud, nous attribuons au paramètre
sim(end_time) qui se trouve dans le �chier 'main.tcl' la valeur 60. Pour 60 s de temps de
simulation, nous avons besoin de 90 s de temps d'exécution. Ce dernier représente le temps
nécessaire pour exécuter le code de la simulation et avoir les résultats.
4.3.2 Résultats des simulations
Comme mentionné au plan d'expérience, les résultats seront présentés en fonction du taux
d'utilisation des ressources. Ce taux prend les valeurs suivantes : 0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7,
0.8, 0.9 pour exprimer les états de charges possibles d'un Cloud. Cette section porte sur la
présentation de ces résultats obtenus à partir de trois séries de simulations. La première série de
simulations consiste à comparer les trois algorithmes d'ordonnancement pour en choisir le plus
e�cace, en termes de consommation d'énergie. La deuxième série sert à intégrer la technique
DVFS à l'algorithme d'ordonnancement choisi. La dernière série simule notre méthode, en
intégrant ses trois caractéristiques.
Série 1 : Simulations avec les algorithmes d'ordonnancement
Nous commençons par une première série de simulations dans laquelle, pour chaque algorithme
d'ordonnancement (Green Scheduler (GS), Round Robin (RR) et Random (R)), nous varions
le taux d'utilisation des ressources. La première simulation consiste à �xer le taux d'utilisation
des ressources à la valeur 0.1, choisir l'algorithme Green Scheduler comme algorithme d'or-
donnancement, puis noter la consommation d'énergie des serveurs, mesurée par le simulateur.
Ensuite, nous changeons l'algorithme d'ordonnancement pour la même valeur du taux d'utili-
sation des ressources, ce qui conduit à trois simulations pour cette valeur du taux d'utilisation
des ressources. Il en résulte que nous avons besoin de neuf simulations pour chaque algorithme
d'ordonnancement, a�n d'analyser la consommation d'énergie pour les di�érentes valeurs du
taux d'utilisation des ressources. Les paramètres de ces simulations sont mis à l'annexe B. La
�gure 4.13 présente le graphe retourné par le simulateur Green Cloud, concernant la réparti-
tion de la consommation d'énergie pour l'algorithme d'ordonnancement GS, en �xant le taux
d'utilisation des ressources à la valeur 0.9. Cette �gure illustre l'énergie consommée par tous
les composants du Cloud qui est de 1056.89 Wh, ainsi que l'énergie consommée par chaque
niveau de la topologie à trois niveaux illustrée à la �gure 4.12. En e�et, les commutateurs d'ac-
cès consomment 4% de l'énergie totale, les commutateurs d'agrégation en consomment 26%,
alors que le commutateur du Coeur en consomme 12%. Quant aux serveurs, ils consomment
58% de l'énergie totale.
56
Figure 4.13 � Répartition de l'énergie consommée entre les di�érents niveaux du centre dedonnées
À partir des valeurs extraites des 27 simulations, nous présentons, à la �gure 4.14, la consom-
mation d'énergie des serveurs en fonction du taux d'utilisation des ressources. Nous remarquons
que cette consommation d'énergie augmente lorsque la charge de travail du centre de données
augmente. Considérons la �gure 4.14. Nous constatons que l'algorithme d'ordonnancement
Green Scheduler o�re la meilleure consommation d'énergie pour les di�érentes charges de tra-
vail du centre de données. Cet algorithme o�re une réduction moyenne de 4% de l'énergie
consommée par rapport à l'algorithme Round Robin et une réduction moyenne de 3.5% de
l'énergie consommée par rapport à l'algorithme Random.
57
Figure 4.14 � Impact des algorithmes d'ordonnancement sur la consommation de l'énergiedes serveurs
A�n de véri�er le respect des exigences de qualité de service par chaque algorithme d'or-
donnancement, il est nécessaire d'analyser le pourcentage P de tâches traitées pour chaque
algorithme, en fonction du taux d'utilisation des ressources. Il en résulte que nous avons besoin
de neuf simulations pour chaque algorithme d'ordonnancement. Le pourcentage P de tâches
traitées est exprimé par l'équation (3.5) en fonction du nombre Nt de tâches traitées au niveau
des serveurs et du nombre Nr de tâches reçues par le Cloud. Or, le simulateur Green Cloud
considère le nombre de tâches échouées Ne au niveau du Cloud. À cet e�et, Nt est calculé à
partir de Ne par l'équation suivante :
Nt = Nr −Ne (4.3)
où Nr : le nombre de tâches reçues par le Cloud,
Ne : le nombre de tâches échouées au niveau du Cloud.
Les simulations du pourcentage P de tâches traitées consistent à extraire depuis le simulateur
Green Cloud, le nombre de tâches échouées Ne et le nombre Nr de tâches reçues par le Cloud,
pour chaque valeur du taux d'utilisation des ressources. Ensuite, nous utilisons l'équation (4.3)
pour déduire le pourcentage P de tâches traitées. Les valeurs des 27 simulations concernant
le pourcentage P sont mises à l'annexe B. Ce pourcentage P est présenté à la �gure 4.15 en
fonction du taux d'utilisation des ressources. Nous remarquons que le pourcentage P diminue
lorsque le taux d'utilisation des ressources augmente. Cette diminution est liée à la quantité
58
de plus en plus élevée de tâches qui sont gérées par l'algorithme d'ordonnancement, ce qui
peut causer l'échec de certaines tâches. Nous constatons aussi que le pourcentage P, présenté
par les trois algorithmes, commence à diminuer à partir de la valeur 0.3 du taux d'utilisation
des ressources pour l'algorithme d'ordonnancement Random, et à partir de la valeur 0.4 pour
les autres algorithmes.
Figure 4.15 � Comparaison du pourcentage de tâches traitées entre les algorithmes d'ordon-nancement
Série 2 : Intégration de la technique DVFS à l'algorithme d'ordonnancement
La deuxième série de simulations consiste à combiner la technique DVFS et l'algorithme d'or-
donnancement Green Scheduler (GS) qui a fait preuve d'une e�cacité, en termes de minimi-
sation d'énergie consommée, dans la première série de simulations. De ce fait, nous choisissons
la technique DVFS comme mode d'énergie du simulateur Green Cloud, puis nous varions le
taux d'utilisation des ressources de 0.1 à 0.9 comme précédemment. Dans la �gure 4.16, nous
présentons l'énergie consommée par les serveurs pour la combinaison de la technique DVFS et
de l'algorithme d'ordonnancement GS, ainsi que l'énergie consommée en utilisant l'algorithme
d'ordonnancement GS, pris individuellement. Dans cette �gure, nous constatons que l'intégra-
tion de la technique DVFS et de l'algorithme GS permet une réduction moyenne de 1,5% de
l'énergie consommée par rapport à l'utilisation de l'algorithme GS pour les di�érentes valeurs
du taux d'utilisation des ressources.
59
Figure 4.16 � Impact de la combinaison de DVFS et de l'algorithme d'ordonnancement GSsur la consommation de l'énergie des serveurs
Série 3 : implémentation de la méthode proposée
Pour implémenter la méthode proposée, nous intégrons la migration à la combinaison de la
technique DVFS et de l'algorithme d'ordonnancement GS. De ce fait, nous appelons la fonction
de migration que nous avons implémenté. Puis, nous varions à nouveau le taux d'utilisation des
ressources de 0.1 à 0.9 comme précédemment. Ensuite, nous extrayons l'énergie consommée
par les serveurs et le nombre de tâches échouées dans le Cloud. La �gure 4.17 présente une
comparaison entre l'énergie consommée en appliquant notre méthode et l'énergie consommée
en utilisant l'algorithme d'ordonnancement Green Scheduler. En considérant cette �gure, nous
constatons que notre méthode permet une réduction moyenne de 5% de l'énergie consommée
par rapport à l'utilisation de l'algorithme GS.
60
Figure 4.17 � Amélioration de la consommation d'énergie des serveurs par la méthodeproposée
A�n d'évaluer le respect des exigences de qualité de service par la méthode proposée, nous
présentons le pourcentage P de tâches traitées au niveau des serveurs. La �gure 4.18 illustre
ce pourcentage P, en utilisant la méthode proposée, ainsi que le pourcentage P de tâches
traitées par les serveurs en appliquant l'algorithme d'ordonnancement Green Scheduler. Nous
constatons que notre méthode fournit un pourcentage P de tâches traitées plus élevé que celui
o�ert par l'algorithme Green Scheduler. De plus, ce pourcentage P o�ert par notre méthode
est toujours supérieur au seuil qui est de 80% pour toutes les charges de travail.
61
Figure 4.18 � Comparaison du pourcentage de tâches traitées entre la méthode proposée etl'algorithme d'ordonnancement GS
4.3.3 Analyse des résultats
Cette analyse vise à véri�er ce qu'apporte la méthode proposée au niveau de la consommation
d'énergie des serveurs et de la qualité de service d'un Cloud. Pour ce faire, nous montrons
d'abord les liens entre les résultats obtenus et l'aspect théorique de notre recherche. Ensuite,
nous expliquons comment un fournisseur du Cloud peut adopter notre méthode. Nous avons
déjà vu que la proportion de l'énergie consommée par les serveurs est de 58% de l'énergie totale
consommée dans le Cloud pour un taux d'utilisation des ressources de 0.9. Ainsi, comment
ce pourcentage va évoluer si le taux d'utilisation des ressources change ? Intuitivement, on
s'attend à ce que la proportion d'énergie consommée des serveurs diminue lorsque le taux
d'utilisation des ressources est faible. Pour véri�er cette intuition, nous avons e�ectué une
simulation avec un taux d'utilisation des ressources de 0.1, en choisissant l'algorithme Green
Scheduler comme algorithme d'ordonnancement (voir l'annexe C). À partir de cette simulation,
la proportion de l'énergie consommée devient 29%, ce qui est conforme avec notre intuition.
Nous justi�ons cette diminution de la proportion de l'énergie consommée des serveurs par la
variation du taux d'utilisation des ressources. En e�et, si le taux d'utilisation des ressources
est élevé, le Cloud reçoit une grande quantité de tâches. Par conséquent, chaque serveur utilise
une proportion élevée du CPU et de la mémoire pour traiter et stocker ces tâches. Ces deux
équipements (CPU et mémoire) sont considérés parmi les éléments qui consomment le plus
d'énergie au niveau du serveur.
Considérons la première et la deuxième série de simulations. Nous avons déjà vu que l'algo-
rithme Green Scheduler o�re une réduction de l'énergie consommée par rapport aux autres
62
algorithmes d'ordonnancement, quelle que soit la charge de travail appliquée sur le Cloud.
Cette réduction peut se justi�er par le principe de cet algorithme qui distribue les tâches de
telle sorte que peu de serveurs sont utilisés et que les serveurs non utilisés sont éteints. De
plus, nous constatons dans la �gure 4.14 que l'énergie consommée par les serveurs n'est pas
nulle, même si la charge de travail prend une valeur proche de 0, ce qui est justi�é par l'éner-
gie consommée lorsque le serveur est en mode de veille. Cette énergie est consommée lorsque
le serveur utilise la puissance Pidle de l'équation (3.3). Quant à l'impact de la combinaison
de l'algorithme Green Scheduler et de la technique DVFS, il est présenté à la �gure 4.16.
Cette �gure illustre une réduction moyenne de 1.5% de l'énergie consommée pour la combi-
naison de la technique DVFS et de l'algorithme Green Scheduler par rapport à l'utilisation de
l'algorithme Green Scheduler. Toutefois, cette amélioration de l'énergie consommée n'est pas
uniforme pour toutes les valeurs du taux d'utilisation des ressources. En e�et, la combinaison
de la technique DVFS et de l'algorithme Green Scheduler n'apporte aucune amélioration de
l'énergie consommée pour des taux d'utilisation des ressources de 0.1 et de 0.9. Ces résultats
sont conformes avec ce que nous avons présenté dans la section 3.4, concernant l'améliora-
tion de l'énergie consommée par l'intégration de deux techniques. En e�et, cette amélioration
dépend du taux d'utilisation des ressources.
Quant à l'e�cacité de la méthode proposée sur la consommation d'énergie, nous déduisons,
à partir de la �gure 4.17, que notre méthode o�re une réduction moyenne de 5% de l'énergie
consommée au niveau des serveurs par rapport à l'utilisation de l'algorithme Green Scheduler.
De plus, notre méthode o�re une réduction de 3% pour un taux d'utilisation des ressources
de 0.1 et une réduction de 3.5% pour un taux de 0.5, alors que pour un taux de 0.9 la
méthode proposée o�re une réduction de 7.5%. À partir de ces résultats, nous déduisons que
la méthode proposée o�re une réduction de l'énergie consommée pour toutes les valeurs du
taux d'utilisation de ressources. Ainsi, l'amélioration de l'énergie consommée o�erte par notre
méthode est plus importante pour les charges de travail les plus élevées.
Quant à la contrainte de qualité de service, elle est toujours respectée par notre méthode.
En e�et, pour garantir un service Cloud avec une bonne qualité de service, le pourcentage
P de tâches traitées par les serveurs doit être supérieur à 80% [61]. En considérant la �gure
4.18, le pourcentage P de tâches traitées par les serveurs est égal à 100% lorsque le taux
d'utilisation des ressources est inférieur à 0.5, ce qui signi�e que toutes les tâches reçues par le
centre de données sont traitées. À partir de la valeur 0.6 du taux d'utilisation des ressources,
le pourcentage P de tâches traitées commence à diminuer jusqu'à la valeur 80% pour un taux
d'utilisation des ressources de 0.9.
Les résultats obtenus sont très encourageants pour les fournisseurs de services Cloud, car ils
disposeront d'une méthode leur permettant de réduire la consommation d'énergie, en respec-
tant le contrat SLA, en termes de qualité de service. Pour intégrer la méthode dans son Cloud,
le fournisseur doit adopter comme algorithme d'ordonnancement l'algorithme Green Scheduler
63
qui permet d'activer le minimum de serveurs possibles. De plus, le fournisseur doit utiliser des
serveurs composés de processeurs qui permettent l'implémentation de la technique DVFS, en
plus d'implémenter le processus de migration dans son Cloud.
64
Chapitre 5
Conclusion
Après avoir présenté et analysé les résultats de simulations, il nous revient maintenant de
conclure ce mémoire. Dans ce chapitre, nous allons récapituler le travail de recherche e�ectué
dans le cadre de ce mémoire. Il sera question de présenter d'abord une synthèse des résul-
tats obtenus. Par la suite, les limitations de nos travaux seront présentées et �nalement, des
recommandations pouvant faire l'objet de recherches futures seront proposées.
5.1 Synthèse des résultats
Ce mémoire s'intéresse particulièrement à la minimisation de la consommation d'énergie dans
un Cloud, en respectant les exigences de qualité de service. Pour ce faire, nous avons d'abord
présenté le cadre de notre recherche en caractérisant le Cloud Computing. Cette caractéri-
sation consistait en premier lieu, à dé�nir les caractéristiques fonctionnelles du Cloud, suivi
des di�érents modèles et topologies du centre de données. Ensuite, nous avons présenté les
avantages et les inconvénients du Cloud. Pour étudier la minimisation de la consommation
d'énergie dans le Cloud, nous avons présenté les di�érentes techniques de réduction d'énergie
consommée. En�n, nous avons présenté les dé�s de recherche a�n d'explorer les di�érentes
pistes de recherche liées au Cloud.
En raison de la complexité du Cloud, l'évaluation de la consommation d'énergie à travers
un tel système nécessitait de déterminer la consommation énergétique de chaque équipement.
Nous avons déduit que la minimisation de cette consommation d'énergie est un problème
complexe qui nécessite une analyse, a�n d'y apporter une solution. Pour analyser le problème
de la consommation d'énergie, nous avons d'abord présenté le contexte de ce problème, en
décrivant le fonctionnement d'un centre de données. Ensuite, nous avons �xé les deux para-
mètres liés au problème de la consommation d'énergie. Avant de proposer notre méthode, nous
avons présenté les di�érentes techniques de réduction de la consommation d'énergie couram-
ment utilisées. Puis, nous avons proposé une méthode basée sur l'intégration de l'algorithme
d'ordonnancement Green Scheduler, de la technique DVFS et de la migration.
65
Après la présentation de notre méthode, nous avons présenté les étapes de son implémentation
dans le simulateur Green Cloud. À partir de trois séries de simulations, nous avons obtenu
des résultats liés à la consommation énergétique et à la qualité de service. Concernant la
consommation énergétique, notre méthode o�re une réduction moyenne de 5% de l'énergie
consommée au niveau des serveurs par rapport à l'utilisation de l'algorithme Green Scheduler.
Quant à la contrainte de qualité de service, elle est toujours respectée par notre méthode. En
e�et, notre méthode o�re un pourcentage de tâches traitées qui est toujours supérieur à 80%.
Ce mémoire a su donner lieu à plusieurs contributions dans le domaine de la consommation
d'énergie dans un Cloud. Nous avons d'abord modi�é le simulateur Green Cloud pour bien
modéliser un Cloud réel dans lequel chaque serveur héberge plusieurs machines virtuelles. Nous
y avons intégré aussi le processus de migration qui prend en compte les contraintes que nous
avons posées dans notre méthode, en termes de pourcentage d'utilisation du CPU. De plus,
nous avons proposé l'intégration de l'algorithme Green Scheduler, de la technique DVFS et
de la migration, ce qui a fait preuve d'une e�cacité, en termes de consommation d'énergie.
Cette méthode proposée respecte également l'exigence de qualité de service, représentée par
le pourcentage de tâches traitées qui doit être supérieur à 80%.
5.2 Limitations
En dépit des résultats présentés, les travaux réalisés dans le cadre de ce mémoire présentent
certaines limitations. La première limitation réside dans le fait que l'environnement choisi pour
notre recherche est un seul Cloud, alors qu' en réalité, un Cloud n'est pas isolé. Par conséquent,
la méthode proposée et les résultats obtenus sont seulement valides pour un Cloud isolé.
Au niveau des paramètres de qualité de service, seul le pourcentage de tâches traitées au niveau
des serveurs a été considéré. Un tel choix a été e�ectué vu que ce paramètre est lié directement
aux algorithmes d'ordonnancement. Cependant, ces algorithmes sont utilisés également dans
notre méthode pour la minimisation de la consommation d'énergie. À cet e�et, dans le but
d'exploiter les algorithmes d'ordonnancement, tout en respectant la qualité de service, le choix
judicieux est le nombre de tâches traitées au niveau des serveurs.
Une autre limitation associée à la méthode proposée est liée au fait d'avoir négligé d'autres
techniques liées au système de refroidissement et se concentrer sur les serveurs. Cette considé-
ration est en général possible lorsqu'en raison des proportions d'énergie consommée, le pour-
centage le plus important est celui des serveurs qui peut aller à 60% de l'énergie consommée
d'un centre de données.
66
5.3 Travaux futurs
Nous ne saurions conclure ce mémoire sans faire état des pistes intéressantes pouvant faire
l'objet de recherches futures. À ce stade, plusieurs voies de recherche découlant des limitations
énoncées à la section précédente seront présentées. Une première piste à explorer serait de
considérer des interactions entre plusieurs centres de données et d'étendre les résultats au
niveau d'un InterCloud qui constitue une interconnexion de plusieurs Clouds.
Du côté des paramètres de qualité de service, une voie importante à analyser est l'ajout d'autres
paramètres, comme le temps de traitement des tâches, a�n d'améliorer la performance du
Cloud. En e�et, le respect des contraintes liées aux di�érents paramètres de qualité de service
est un indice important d'e�cacité de la méthode proposée.
Dans le cadre du choix des techniques de minimisation d'énergie consommée, la méthode
proposée considère les techniques liées à la consommation de l'énergie au niveau des serveurs.
Cependant, dans le contexte où un centre de données est situé dans une région où les ressources
naturelles ne facilitent pas la tâche de refroidissement, une grande consommation d'énergie
survient au niveau du Cloud. Une avenue de recherche consisterait à combiner les techniques
de refroidissement aux techniques utilisées par notre méthode.
67
Bibliographie
[1] Eric Mounier Mattin Grao Txaparteg. New technologies and architectures for e�cient
data center. Technical report, YOLE DEVELOPPEMENT, 2015.
[2] Yong Pan and Ning Hu. Research on dependability of cloud computing systems. In 2014
International Conference on Reliability, Maintainability and Safety (ICRMS), pages 435�
439. IEEE, 2014.
[3] Peter Mell, Tim Grance, et al. The nist de�nition of cloud computing. Future Generation
Computer Systems, 2011.
[4] Alessio Botta, Walter De Donato, Valerio Persico, and Antonio Pescapé. Integration of
cloud computing and internet of things : A survey. Future Generation Computer Systems,
56 :684�700, 2016.
[5] Guilherme Da Cunha Rodrigues, Rodrigo N Calheiros, Vinicius Tavares Guimaraes, Gle-
derson Lessa dos Santos, Marcio Barbosa De Carvalho, Lisandro Zambenedetti Granville,
Liane Margarida Rockenbach Tarouco, and Rajkumar Buyya. Monitoring of cloud com-
puting environments : Concepts, solutions, trends, and future directions. In Proceedings
of the 31st Annual ACM Symposium on Applied Computing, pages 378�383. ACM, 2016.
[6] Borivoje Furht and Armando Escalante. Handbook of cloud computing, volume 3. Sprin-
ger, 2010.
[7] Qiao Yan, F Richard Yu, Qingxiang Gong, and Jianqiang Li. Software-de�ned networking
(sdn) and distributed denial of service (ddos) attacks in cloud computing environments : A
survey, some research issues, and challenges. IEEE Communications Surveys & Tutorials,
18(1) :602�622, 2016.
[8] Paul Manuel. A trust model of cloud computing based on quality of service. Annals of
Operations Research, 233(1) :281�292, 2015.
[9] Danilo Ardagna, Giuliano Casale, Michele Ciavotta, Juan F Pérez, and Weikun Wang.
Quality-of-service in cloud computing : Modeling techniques and their applications. Jour-
nal of Internet Services and Applications, 5(1) :11, 2014.
68
[10] Raja Wasim Ahmad, Abdullah Gani, Siti Ha�zah Ab Hamid, Muhammad Shiraz, Abdul-
lah Yousafzai, and Feng Xia. A survey on virtual machine migration and server consolida-
tion frameworks for cloud data centers. Journal of Network and Computer Applications,
52 :11�25, 2015.
[11] Chia-Ming Wu, Ruay-Shiung Chang, and Hsin-Yu Chan. A green energy-e�cient sche-
duling algorithm using the dvfs technique for cloud datacenters. Future Generation Com-
puter Systems, 37 :141�147, 2014.
[12] Jean-Marc Pierson and Helmut Hlavacs. Introduction to energy e�ciency in large-scale
distributed systems. Large-Scale Distributed Systems and Energy E�ciency : A Holistic
View, pages 1�16, 2015.
[13] Iván Tomás Cotes-Ruiz, Rocío P Prado, Sebastián García-Galán, José Enrique Muñoz-
Expósito, and Nicolás Ruiz-Reyes. Dynamic voltage frequency scaling simulator
for real work�ows energy-aware management in green cloud computing. PloS one,
12(1) :e0169803, 2017.
[14] Yacine Kessaci, Nouredine Melab, and El-Ghazali Talbi. Optimisation multi-critère pour
l'allocation de ressources sur clouds distribués avec prise en compte de l'energie. In
Rencontres Scienti�ques France Grilles 2011, 2011.
[15] Anton Beloglazov, Jemal Abawajy, and Rajkumar Buyya. Energy-aware resource allo-
cation heuristics for e�cient management of data centers for cloud computing. Future
generation computer systems, 28(5) :755�768, 2012.
[16] Anton Beloglazov and Rajkumar Buyya. Adaptive threshold-based approach for energy-
e�cient consolidation of virtual machines in cloud data centers. In MGC@ Middleware,
page 4, 2010.
[17] Huangke Chen, Xiaomin Zhu, Hui Guo, Jianghan Zhu, Xiao Qin, and Jianhong Wu.
Towards energy-e�cient scheduling for real-time tasks under uncertain cloud computing
environment. Journal of Systems and Software, 99 :20�35, 2015.
[18] Toni Mastelic, Ariel Oleksiak, Holger Claussen, Ivona Brandic, Jean-Marc Pierson, and
Athanasios V Vasilakos. Cloud computing : Survey on energy e�ciency. Acm computing
surveys (csur), 47(2) :33, 2015.
[19] Ning Zhong, Jianhua Ma, Runhe Huang, Jiming Liu, Yiyu Yao, Yaoxue Zhang, and
Jianhui Chen. Research challenges and perspectives on wisdom web of things (w2t). In
Wisdom Web of Things, pages 3�26. Springer, 2016.
[20] Deepak Puthal, BPS Sahoo, Sambit Mishra, and Satyabrata Swain. Cloud computing
features, issues, and challenges : A big picture. In 2015 International Conference on
Computational Intelligence and Networks (CINE), pages 116�123. IEEE, 2015.
69
[21] Abhinivesh Jain and Niraj Mahajan. Introduction to cloud computing. In The Cloud
DBA-Oracle, pages 3�10. Springer, 2017.
[22] AR Manu, Jitendra Kumar Patel, Shakil Akhtar, VK Agrawal, and KN Bala Subramanya
Murthy. A study, analysis and deep dive on cloud paas security in terms of docker
container security. In 2016 International Conference on Circuit, Power and Computing
Technologies (ICCPCT), pages 1�13. IEEE, 2016.
[23] Mauro Hinz, Charles C Miers, Mauricio A Pillon, and Guilherme P Koslovski. A cost
model for iaas clouds based on virtual machine energy consumption. In Proceedings of
the XII Brazilian Symposium on Information Systems on Brazilian Symposium on Infor-
mation Systems : Information Systems in the Cloud Computing Era-Volume 1, page 19.
Brazilian Computer Society, 2016.
[24] Tariqul Islam, D Manivannan, and Sherali Zeadally. A classi�cation and characterization
of security threats in cloud computing. Int. J. Next-Gener. Comput, 7(1), 2016.
[25] Jin Li, Yan Kit Li, Xiaofeng Chen, Patrick PC Lee, and Wenjing Lou. A hybrid cloud
approach for secure authorized deduplication. IEEE Transactions on Parallel and Dis-
tributed Systems, 26(5) :1206�1216, 2015.
[26] Dejene Boru, Dzmitry Kliazovich, Fabrizio Granelli, Pascal Bouvry, and Albert Y Zomaya.
Energy-e�cient data replication in cloud computing datacenters. Cluster computing,
18(1) :385�402, 2015.
[27] Amin Vahdat, Mohammad Al-Fares, and Alexander Loukissas. Scalable commodity data
center network architecture, July 9 2013. US Patent 8,483,096.
[28] Shahram Jamali, Fatemeh Alizadeh, and Soheila Sadeqi. Task scheduling in cloud com-
puting using particle swarm optimization. The Book of Extended Abstracts, 192, 2016.
[29] Mohammad Al-Fares, Sivasankar Radhakrishnan, Barath Raghavan, Nelson Huang, and
Amin Vahdat. Hedera : Dynamic �ow scheduling for data center networks. In NSDI,
volume 10, pages 19�19, 2010.
[30] Abhijit Biswas, Md Anwar Hussain, and Alakesh Kalita. An improved congestion free
modi�ed fat tree network�on�chip topology. In 2016 International Conference onv
Signal Processing, Communication, Power and Embedded System (SCOPES), pages 759�
763. IEEE, 2016.
[31] Chuanxiong Guo, Guohan Lu, Dan Li, Haitao Wu, Xuan Zhang, Yunfeng Shi, Chen Tian,
Yongguang Zhang, and Songwu Lu. Bcube : a high performance, server-centric network
architecture for modular data centers. ACM SIGCOMM Computer Communication Re-
view, 39(4) :63�74, 2009.
70
[32] Dimitar Grozev, Grisha Spasov, Mitko Shopov, Nikolay Kakanakov, and Galidiya Petrova.
Experimental study of cloud computing based scada in electrical power systems. In
Scienti�c Conference Electronics (ET), International, pages 1�4. IEEE, 2016.
[33] Pierangela Samarati, S De Capitani di Vimercati, S Murugesan, and I Bojanova. Cloud
security : Issues and concerns. Encyclopedia on Cloud Computing, pages 1�14, 2016.
[34] Ishfaq Ahmad and Sanjay Ranka. Handbook of Energy-Aware and Green Computing-Two
Volume Set. CRC Press, 2016.
[35] Ranjan Kumar, G Sahoo, Vikram Yadav, and Pooja Malik. Minimizing the energy
consumption of cloud computing data centers using queueing theory. In Advances in
Computational Intelligence : Proceedings of International Conference on Computational
Intelligence 2015, pages 201�210. Springer, 2017.
[36] Joe Peppard and John Ward. The Strategic Management of Information Systems : Buil-
ding a Digital Strategy. John Wiley & Sons, 2016.
[37] Abdul Hameed, Alireza Khoshkbarforoushha, Rajiv Ranjan, Prem Prakash Jayaraman,
Joanna Kolodziej, Pavan Balaji, Sherali Zeadally, Qutaibah Marwan Malluhi, Nikos Tziri-
tas, Abhinav Vishnu, et al. A survey and taxonomy on energy e�cient resource allocation
techniques for cloud computing systems. Computing, 98(7) :751�774, 2016.
[38] Tarandeep Kaur and Inderveer Chana. Energy e�ciency techniques in cloud computing :
A survey and taxonomy. ACM Computing Surveys (CSUR), 48(2) :22, 2015.
[39] Fábio D Rossi, Miguel G Xavier, César AF De Rose, Rodrigo N Calheiros, and Rajku-
mar Buyya. E-eco : Performance-aware energy-e�cient cloud data center orchestration.
Journal of Network and Computer Applications, 78 :83�96, 2017.
[40] Joel JPC Rodrigues, Liang Zhou, Lucas DP Mendes, Kai Lin, and Jaime Lloret. Distri-
buted media-aware �ow scheduling in cloud computing environment. Computer Commu-
nications, 35(15) :1819�1827, 2012.
[41] Lalithabhinaya Mallu and R Ezhilarasie. Live migration of virtual machines in cloud
environment : A survey. Indian Journal of Science and Technology, 8(S9) :326�332, 2015.
[42] FeiFei Chen, Jean-Guy Schneider, Yun Yang, John Grundy, and Qiang He. An energy
consumption model and analysis tool for cloud computing environments. In Proceedings
of the First International Workshop on Green and Sustainable Software, pages 45�50.
IEEE Press, 2012.
[43] Dad Djouhra. Optimisation des Performances des Data Centers des Clouds sous
Contrainte d'Optimisation d'Energie. PhD thesis, Université d'Oran, 2016.
71
[44] Jouhra Dad and Ghalem Belalem. Energy optimisation in cloud computing. International
Journal of Information Technology, Communications and Convergence, 3(1) :1�12, 2014.
[45] Chun-Wei Tsai and Joel JPC Rodrigues. Metaheuristic scheduling for cloud : A survey.
IEEE Systems Journal, 8(1) :279�291, 2014.
[46] Juee U Daryapurkar and Karuna G Bagde. Cloud computing : Issues and challenges. no.
April, pages 770�773, 2014.
[47] Rafael Moreno-Vozmediano, Rubén S Montero, and Ignacio M Llorente. Key challenges
in cloud computing : Enabling the future internet of services. IEEE Internet Computing,
17(4) :18�25, 2013.
[48] Franck Leon. La construction des Business Models des fournisseurs de services d'infra-
structure Cloud Computing (IaaS). PhD thesis, Université Nice Sophia Antipolis, 2015.
[49] Huigui Rong, Haomin Zhang, Sheng Xiao, Canbing Li, and Chunhua Hu. Optimizing
energy consumption for data centers. Renewable and Sustainable Energy Reviews, 58 :674�
691, 2016.
[50] Théodore Jean Richard Relaza. Sécurité et Disponibilité des Données Stockées dans les
Nuages. PhD thesis, Université Paul Sabatier-Toulouse III, 2016.
[51] Anton Beloglazov, Rajkumar Buyya, Young Choon Lee, and Albert Zomaya. A taxonomy
and survey of energy-e�cient data centers and cloud computing systems. In Advances in
computers, volume 82, pages 47�111. Elsevier, 2011.
[52] Hamza Salih Erden, Mehmet Turgay Yildirim, Mustafa Koz, and H Ezzat Khalifa. Energy
assessment of crah bypass for enclosed aisle data centers. In Intersociety Conference on
Thermal and Thermomechanical Phenomena in Electronic Systems (ITherm), pages 433�
439. IEEE, 2016.
[53] Violaine Villebonnet, Georges Da Costa, Laurent Lefevre, Jean-Marc Pierson, and Pa-
tricia Stolf. Dynamically building energy proportional data centers with heterogeneous
computing resources. In International Conference on Cluster Computing (CLUSTER),
pages 217�220. IEEE, 2016.
[54] Ricardo Lent. Analysis of an energy proportional data center. Ad Hoc Networks, 25 :554�
564, 2015.
[55] Arun Vishwanath, Jiazhen Zhu, Kerry Hinton, Robert Ayre, and Rod Tucker. Estimating
the energy consumption for packet processing, storage and switching in optical-ip routers.
In Optical Fiber Communication Conference, pages OM3A�6. Optical Society of America,
2013.
72
[56] Rathijit Sen and David A Wood. Energy-proportional computing : A new de�nition.
Computer, 50 :26�33, 2017.
[57] Xing Luo, Jihong Wang, Mark Dooner, and Jonathan Clarke. Overview of current deve-
lopment in electrical energy storage technologies and the application potential in power
system operation. Applied Energy, 137 :511�536, 2015.
[58] Jayant Baliga, Robert WA Ayre, Kerry Hinton, and Rodney S Tucker. Green cloud
computing : Balancing energy in processing, storage, and transport. Proceedings of the
IEEE, 99(1) :149�167, 2011.
[59] Arun Vishwanath, Fatemeh Jalali, Robert Ayre, Tansu Alpcan, Kerry Hinton, and Rod-
ney S Tucker. Energy consumption of interactive cloud-based document processing appli-
cations. In International Conference on Communications (ICC), pages 4212�4216. IEEE,
2013.
[60] Valérie Danielle Justafort. Optimisation de l'Empreinte Carbone dans un Environnement
Intercloud : Modèles et Méthodes. PhD thesis, École Polytechnique de Montréal, 2015.
[61] Rodrigo da Rosa Righi, Vinicius Facco Rodrigues, Cristiano André da Costa, Guilherme
Galante, Luis Carlos Erpen De Bona, and Tiago Ferreto. Autoelastic : Automatic resource
elasticity for high performance applications in the cloud. IEEE Transactions on Cloud
Computing, 4(1) :6�19, 2016.
[62] Shaoxiong Hua and Gang Qu. Approaching the maximum energy saving on embedded
systems with multiple voltages. In Proceedings of the 2003 IEEE/ACM international
conference on Computer-aided design, page 26. IEEE Computer Society, 2003.
[63] Linwei Niu and Wei Li. Energy-e�cient �xed-priority scheduling for real-time systems
based on threshold work-demand analysis. In Proceedings of the seventh IEEE/ACM/IFIP
international conference on Hardware/software codesign and system synthesis, pages 159�
168. ACM, 2011.
[64] Jyothi Sekhar and Getzi Jeba. Energy e�cient vm live migration in cloud data centers
1. 2013.
[65] Gaurav Dhiman and Tajana Simunic Rosing. Dynamic voltage frequency scaling for mlti-
tasking systems using online learning. In Low Power Electronics and Design (ISLPED),
2007 ACM/IEEE International Symposium on, pages 207�212. IEEE, 2007.
[66] Andreas Weissel and Frank Bellosa. Process cruise control : Event-driven clock scaling
for dynamic power management. In Proceedings of the 2002 international conference on
Compilers, architecture, and synthesis for embedded systems, pages 238�246. ACM, 2002.
73
[67] Josep Ll Berral, Íñigo Goiri, Ramón Nou, Ferran Julià, Jordi Guitart, Ricard Gavaldà, and
Jordi Torres. Towards energy-aware scheduling in data centers using machine learning.
In Proceedings of the 1st International Conference on energy-E�cient Computing and
Networking, pages 215�224. ACM, 2010.
[68] Saleh Atiewi, Salman Yussof, and Mohd Ezanee. A comparative analysis of task schedu-
ling algorithms of virtual machines in cloud environment. Journal of Computer Science,
11(6) :804, 2015.
[69] Truong Vinh Truong Duy, Yukinori Sato, and Yasushi Inoguchi. Performance evaluation
of a green scheduling algorithm for energy savings in cloud computing. In Parallel &
Distributed Processing, Workshops and Phd Forum (IPDPSW), 2010 IEEE International
Symposium on, pages 1�8. IEEE, 2010.
[70] D Chitra Devi and V Rhymend Uthariaraj. Load balancing in cloud computing envi-
ronment using improved weighted round robin algorithm for nonpreemptive dependent
tasks. The Scienti�c World Journal, 2016, 2016.
[71] M Thangadurai and K Baskar. Secure outsourced data stream under multiple keys using
random algorithm in cloud computing. International Journal of Science, Engineering and
Computer Technology, 6(9) :331, 2016.
[72] Zhuo Tang, Ling Qi, Zhenzhen Cheng, Kenli Li, Samee Ullah Khan, and Keqin Li. An
energy-e�cient task scheduling algorithm in dvfs-enabled cloud environment. J. Grid
Comput., 14(1) :55�74, 2016.
[73] Sambit Kumar Mishra, Priti Paramita Parida, Sampa Sahoo, Bibhudatta Sahoo, and
Sanjay Kumar Jena. Improving energy usage in cloud computing using dvfs. In Progress
in Advanced Computing and Intelligent Engineering, pages 623�632. Springer, 2018.
[74] Fahimeh Farahnakian, Pasi Liljeberg, and Juha Plosila. Energy-e�cient virtual machines
consolidation in cloud data centers using reinforcement learning. In 2014 22nd Euromicro
International Conference on Parallel, Distributed and Network-Based Processing (PDP),
pages 500�507. IEEE, 2014.
[75] Chaima Ghribi, Makhlouf Hadji, and Djamal Zeghlache. Energy e�cient vm scheduling
for cloud data centers : Exact allocation and migration algorithms. In Cluster, Cloud and
Grid Computing (CCGrid), 2013 13th IEEE/ACM International Symposium on, pages
671�678. IEEE, 2013.
[76] Young Choon Lee and Albert Y Zomaya. Minimizing energy cconsumption for precedence-
constrained applications using dynamic voltage scaling. In Cluster Computing and the
Grid, 2009. CCGRID'09. 9th IEEE/ACM International Symposium on, pages 92�99.
IEEE, 2009.
74
[77] Haluk Topcuoglu, Salim Hariri, and Min-you Wu. Performance-e�ective and low-
complexity task scheduling for heterogeneous computing. IEEE transactions on parallel
and distributed systems, 13(3) :260�274, 2002.
[78] Anton Beloglazov and Rajkumar Buyya. Optimal online deterministic algorithms and
adaptive heuristics for energy and performance e�cient dynamic consolidation of virtual
machines in cloud data centers. Concurrency and Computation : Practice and Experience,
24(13) :1397�1420, 2012.
[79] Liang-Teh Lee, Kang-Yuan Liu, Hui-Yang Huang, and Chia-Ying Tseng. A dynamic
resource management with energy saving mechanism for supporting cloud computing.
International Journal of Grid and Distributed Computing, 6(1) :67�76, 2013.
[80] Vrunda J Patel and PHA Bheda. Reducing energy consumption with dvfs for real-time
services in cloud computing. IOSR J (IOSR J Comput Eng), 16(3) :53�57, 2014.
[81] Nidhi Jain Kansal and Inderveer Chana. Energy-aware virtual machine migration for
cloud computing-a �re�y optimization approach. Journal of Grid Computing, 14(2) :327�
345, 2016.
[82] Utkal Sinha and Mayank Shekhar. Comparison of various cloud simulation tools avai-
lable in cloud computing. International Journal of Advanced Research in Computer and
Communication Engineering, 4(3), 2015.
[83] Mehdi Ahmed-Nacer, Kunal Suri, Mohamed Sellami, and Walid Gaaloul. Simulation
of con�gurable resource allocation for cloud-based business processes. In 2017 IEEE
International Conference on Services Computing (SCC), pages 305�313. IEEE, 2017.
[84] Kiran Gupta, Rydhm Beri, Veerawali Behal, Kiran Gupta, Rydhm Beri, and Veerawali
Behal. Cloud computing : A survey on cloud simulation tools. International Journal for
Innovative Research in Science & Technology (IJIRST), 2(11), 2016.
[85] Anurag Jain and Rajneesh Kumar. A comparative analysis of task scheduling approaches
for cloud environment. In 2016 3rd International Conference on Computing for Sustai-
nable Global Development (INDIACom), pages 1787�1792. IEEE, 2016.
[86] Sareh Fotuhi Piraghaj, Amir Vahid Dastjerdi, Rodrigo N Calheiros, and Rajkumar Buyya.
Containercloudsim : An environment for modeling and simulation of containers in cloud
data centers. Software : Practice and Experience, 47(4) :505�521, 2017.
[87] Saleh Atiewi, Salman Yussof, Mohd Ezanee, and Muder Almiani. A review energy-e�cient
task scheduling algorithms in cloud computing. In Long Island Systems, Applications and
Technology Conference (LISAT), 2016 IEEE, pages 1�6. IEEE, 2016.
75
[88] Neha Aggarwal, Teglovy Singh Chohan, Karamveer Singh, Rajan Vohra, and Shalini Ba-
hel. Relative analysis of aodv & dsdv routing protocols for manet based on ns2. In Inter-
national Conference on Electrical, Electronics, and Optimization Techniques (ICEEOT),
pages 3500�3503. IEEE, 2016.
[89] James C Phillips, John E Stone, Kirby L Vandivort, Timothy G Armstrong, Justin M
Wozniak, Michael Wilde, and Klaus Schulten. Petascale tcl with namd, vmd, and swift/t.
In Proceedings of the 1st First Workshop for High Performance Technical Computing in
Dynamic Languages, pages 6�17. IEEE Press, 2014.
[90] Anup Singh Kushwaha, Bashir Alam, and Gaganjot Kaur. Observation of energy e�ciency
in green cloud simulator. In Cloud System and Big Data Engineering (Con�uence), 2016
6th International Conference, pages 135�140. IEEE, 2016.
[91] Nikola VasiljeviÊ, Guillaume Lea, Per Hansen, and Henrik M Jensen. Mobile network
architecture. 2016.
[92] Natnael Argaw. Distributed Score Based Job Scheduling Algorithm for Cloud Computing
Environment. PhD thesis, ADDIS ABABA UNIVERSITY, 2016.
[93] Aeshah Alsughayyir and Thomas Erlebach. Energy aware scheduling of hpc tasks in de-
centralised cloud systems. In 2016 24th Euromicro International Conference on Parallel,
Distributed, and Network-Based Processing (PDP), pages 617�621. IEEE, 2016.
76
Annexe A
Modi�cation de Green Cloud
Cette annexe illustre les modi�cations apportées au simulateur pour implémenter la méthode
proposée. En e�et, la �gure B.1 et la �gure B.2 illustrent le processus d'appel de la migration
et de la technique DVFS respectivement.
Figure A.1 � Appel de la migration
77
Figure A.2 � Appel de la technique DVFS
78
Annexe B
Données de la simulation 1
Dans cette annexe, nous présentons les valeurs des paramètres que nous avons variés pour ef-
fectuer les simulations de la première expérience. En e�et, le tableau A.1 montre les valeurs des
paramètres nécessaires pour les 27 simulations e�ectuées pour analyser l'énergie consommée
en fonction du taux d'utilisation des ressources (taux). Par exemple, pour un taux d'utilisation
des ressources de 0.1 et en utilisant Green Scheduler comme algorithme d'ordonnancement,
nous obtenons à partir du simulateur une consommation d'énergie de 228.9 Wh. Concernant
l'analyse du pourcentage de taches traitées pour cette première expérience, nous présentons
au tableau A.2 les valeurs des paramètres concernant cette analyse à savoir le taux d'utilisa-
tion des ressources, l'algorithme d'ordonnancement le nombre de tâches reçues Nr ainsi que
le nombre de tâches échouées Ne. Tous ces paramètres sont extraits du simulateur. Puis, nous
calculons le pourcentage de taches traitées P à partir de l'équation 3.5.
79
Taux Algorithme d'ordonnace-ment
Energie consommée en Wh
0.1GC 228.9RR 322.9R 319
0.2GC 292.5RR 447R 428
0.3GC 367RR 508.1R 491
0.4GC 420RR 541R 534
0.5GC 485RR 574R 567
0.6GC 537RR 604R 592
0.7GC 565RR 619R 592
0.8GC 590RR 634R 624
0.2GC 613RR 642R 634
Table B.1 � Énergie consommée par les trois algorithmes d'ordonnancement
80
Taux Nt Algorithme d'ordon-nancement
Ne Tâches traitées en %
0.1 5467GC 0 100RR 0 100R 0 100
0.2 9135GC 0 100RR 0 100R 0 100
0.3 13702GC 0 100RR 0 100R 5 99.96350898
0.4 18270GC 0 100RR 0 100R 100 99.45265463
0.5 22838GC 0 100RR 0 100R 674 97.04877835
0.6 27405GC 799 97.08447364RR 357 98.69731801R 2011 92.66192301
0.7 31973GC 3338 89.5599412RR 2845 91.1018672R 4041 87.36121102
0.8 36541GC 6110 83.2790564RR 5641 84.56254618R 6710 81.63706521
0.9 41108GC 9035 78.02130972RR 8716 78.79731439R 9798 76.16522331
Table B.2 � Pourcentages de tâches traitées
81
Annexe C
Graphe retourné par le simulateur
Green Cloud
Cette annexe présente le graphe retourné par le simulateur Green Cloud, concernant la ré-
partition de la consommation d'énergie pour l'algorithme d'ordonnancement Green Scheduler,
en �xant le taux d'utilisation des ressources à la valeur 0.1. La �gure C.1 illustre l'énergie
consommée par tous les composants du Cloud qui est de 228.4Wh, ainsi que l'énergie consom-
mée par chaque niveau de la topologie à trois niveaux illustrée à la �gure 4.12. En e�et, les
commutateurs d'accès consomment 4% de l'énergie totale, les commutateurs d'agrégation en
consomment 45%, alors que le commutateur du Coeur en consomme 23%. Quant aux serveurs,
ils consomment 29% de l'énergie totale.
82
Figure C.1 � Répartition de l'énergie consommée entre les di�érents niveaux du centre dedonnées
83
