Upload
minerva-stephens
View
28
Download
0
Tags:
Embed Size (px)
DESCRIPTION
L'Efficience Energétique des Services dans les Systèmes Répartis Hétérogènes et Dynamiques Application à la Maison Numérique. Soutenance de thèse pour l’obtention du Doctorat de l'Université Lille 1 Sciences et Technologies (Ecole Doctorale SPI). Président : Jean-Louis PAZAT, INSA Rennes - PowerPoint PPT Presentation
Citation preview
Rémi Druilhe
L'Efficience Energétique des Services dans les Systèmes Répartis Hétérogènes et Dynamiques
Application à la Maison Numérique
Président : Jean-Louis PAZAT, INSA RennesRapporteur : Noel DE PALMA, Université Joseph Fourier, GrenobleRapporteur : Jean-Marc MENAUD, Ecole des Mines de NantesExaminateur : Laurent LEFEVRE, INRIA
Directrice : Laurence DUCHIEN, Université Lille 1Co-Directeur : Lionel SEINTURIER, Université Lille 1Encadrant : Matthieu ANNE, Orange
Soutenance de thèse pour l’obtention du Doctorat de l'Université Lille 1 Sciences et Technologies
(Ecole Doctorale SPI)
2
Introduction
Le Numérique et l’Energie
Source : Impact Environnemental de la Filière TIC en France, 2010
13,1
4,6
11,9
14,0
6,7
14,6
11,4
8,5
14,4
11,8
8,2
14,0
12,7
7,6
13,6
2005 2008 2012 2015 2020
Electronique Grand Public
Télécommunication
Système d’Information
7,3 % de la consommation totale d’électricité en France en 2008
35,329,6
TWh/an
34,3 34,0 33,9
3
Introduction
Chauffage31%
Autres46%
Cuisine8%
Eau Chaude15%
Eclairage12,8%
Audiovisuel20%
Froid23,3%
Lavage14,9%
Informatique14,5%
4700kWh/an
2162kWh/an
Divers14,4%
Source : EDF, 2009Source : Projet Remodece, 2008Source : ADEME, Equipements électriques, 2008Source : Overview of ICT energy consumption, 2013
Consommation d’électricité (tout
électrique)
Consommation des autres équipements
électriques
Consommation électrique moyenne de la maison numérique
4
Introduction
Ouverture au tiers
La Maison Numérique
Hétérogénéité
Volatilité
Répartition
Qualité de service
5
Introduction
Challenges
Comment augmenter l’efficience énergétique de la maison numérique en prenant en compte
L’hétérogénéité
La volatilité
La qualité de service
Application
6
Introduction
Approche
Trouver la répartition des applications qui minimise la consommation d’énergie
Mettre dans un état de basse consommation les équipements inutilisés
Application
7
Introduction
Plan
Etat de l’Art
Définitions et Hypothèses de Travail
Modélisation de la Maison Numérique
Architecture de HomeNap
Validation de HomeNap
Conclusion
9
Etat de l’art - Hypothèses - Modélisation - Architecture - Validation - Conclusion
Efficience énergétique
Usage
Application
Contrôle
Matériel Etats énergétiquesAdaptation matérielle
Couche de contrôleRéveil
ConceptionMandatement / Répartition
Rétroaction
Couches Exemples
10
Etat de l’art - Hypothèses - Modélisation - Architecture - Validation - Conclusion
Migrer les applications pour minimiser les serveurs actifs – Exemple : Entropy [HLM+09]
Consolidation
H1 : Environnement homogène
H2 : Considère seulement l’apparition/disparition d’applications
Application
Application Applicati
on
Application
11
Etat de l’art - Hypothèses - Modélisation - Architecture - Validation - Conclusion
Répartition
Distribuer les composants d’une application pour l’adapter à l’environnement
– Exemple : PARM [MV03]
Composant 1
Composant 2
Composant 3
H1 : Ne considère pas les ressources locales, e.g., autres équipements
12
Etat de l’art - Hypothèses - Modélisation - Architecture - Validation - Conclusion
Un équipement agit comment un mandataire afin de représenter un service fournit par un autre équipement
– Exemple : UPnP Low Power [UPnPLP07]
Mandatement de service
ClientApplicati
on
H1 : Un service est lié à un équipement
13
Etat de l’art - Hypothèses - Modélisation - Architecture - Validation - Conclusion
Mandatement d’application
Un équipement agit comme un mandataire afin d’exécuter une application issue d’un autre équipement
– Exemple : Parasite [Zhong11]
Application
H1 : Nécessite un équipement dédié
H2 : Conçu pour un seul service
14
Etat de l’art - Hypothèses - Modélisation - Architecture - Validation - Conclusion
Classification des systèmes
Degré d’autonomieCœur Contrôle Autonome
Politique de décision
Fonction d’utilité
Fonction d’action
Mobile Service OverlayEntropyPARM
TranshumanceHOPEUPnP LPParasite
HomeNap
Source : A survey of autonomic computing - degrees, models, and applications, 2008.Source : An artificial intelligence perspective on autonomic computing policies. 2004.
16
Etat de l’art - Hypothèses - Modélisation - Architecture - Validation - Conclusion
Définition de l’Efficience Energétique
Efficience Energétique = Travail utile du processus
Apport d’énergie dans le processus
Source : What is energy efficiency?: Concepts, indicators and methodological issues, 1996
Energie Travail utile(Aller de A à B)
17
Etat de l’art - Hypothèses - Modélisation - Architecture - Validation - Conclusion
Application
Définition d’un Processus
Un processus est l’association d’un équipement et d’une application
EquipementEnergie Service
Processus
18
Etat de l’art - Hypothèses - Modélisation - Architecture - Validation - Conclusion
Un service est rendu par une seule et unique application
Application
Equipement
Hypothèse d’un modèle unifié de service
Energie Service
19
Etat de l’art - Hypothèses - Modélisation - Architecture - Validation - Conclusion
Equipement 1Equipement 2
Hypothèse d’une couche d’abstraction
Une application est exécutable sur un ensemble d’équipements hétérogènes dès lors qu’ils possèdent les ressources suffisantes
Application
Energie 1 Service
Couche Abstraction
Energie 2
20
Etat de l’art - Hypothèses - Modélisation - Architecture - Validation - Conclusion
Un équipement peut fournir plusieurs services dès lors qu’il possède les ressources matérielles nécessaires et suffisantes pour le déploiement des applications
Appli BAppli A
Hypothèse de parallélisme
Energie Service AService B
Equipement
21
Etat de l’art - Hypothèses - Modélisation - Architecture - Validation - Conclusion
Hypothèse de répartition des applications
Le service est fourni par un ensemble de processus associés. La taille de cet ensemble est de 1 ou supérieur
Composant B
Equipement 2
Composant A
Equipement 1
Service Service
22
Etat de l’art - Hypothèses - Modélisation - Architecture - Validation - Conclusion
Hypothèse du périmètre d’efficience énergétique
La maison numérique est un environnement informatique limité en équipements et auto-suffisant en ressources
Fournisseur Transporteur Consommateur
23
Etat de l’art - Hypothèses - Modélisation - Architecture - Validation - Conclusion
Les définitions et les hypothèses
Définition de l’efficience énergétique
Définition d’un processus
Hypothèse d’unicité de l’implémentation d’un service
Hypothèse d’une couche d’abstraction
Hypothèse de parallélisme
Hypothèse de répartition des applications
Hypothèse du périmètre d’efficience énergétique
25
Etat de l’art - Hypothèses - Modélisation - Architecture - Validation - Conclusion
Problèmes et approche
Challenges liés à cet environnement– Hétérogénéité– Volatilité– Qualité de service
Développer un modèle pour gérer les propriétés de l’environnement
– Utiliser des contraintes de déploiement– Modéliser les états, les événements et les actions
disponibles dans l’environnement– Définir une fonction d’utilité pour parvenir à une
solution quel que soit l’état du système
26
Etat de l’art - Hypothèses - Modélisation - Architecture - Validation - Conclusion
Modélisation de l’état
A un instant t, un ensemble d’applications est déployé sur un ensemble d’équipements : le plan de répartition
0
1
0
0
0
110001
00
1
0
00
00
0
0001
27
Etat de l’art - Hypothèses - Modélisation - Architecture - Validation - Conclusion
tE
tead
Le plan de répartition
Matrice
tead
1 si teAa
0 sinon
teA: ensemble des applications hébergées par l’équipement e à l’instant t
tt AaEe
tea
t dD
1,1
)(tE: ensemble des équipements à l’instant ttA: ensemble des applications à l’instant t
tA
0
1
0
0
0
11
01
00
1
0
00
00
0
0001
00
28
Etat de l’art - Hypothèses - Modélisation - Architecture - Validation - Conclusion
Modélisation de la volatilité
Apparition ou disparition d’équipements ou d’applications
Les événements significatifs changent l’ensemble des équipements ou l’ensemble des applications
0 101 0000
0001
1
00
001
10
0000
29
Etat de l’art - Hypothèses - Modélisation - Architecture - Validation - Conclusion
Elément Equipement Application
Apparition d’un élément
Disparition d’un élément
Les événements significatifs
eEE tt 1
eEE tt \1
aAA tt 1
aAA tt \1
30
Etat de l’art - Hypothèses - Modélisation - Architecture - Validation - Conclusion
Modélisation du plan de répartition
Migration des applications d’un équipement à un autre
Calcul du plan de déploiement
0 101 0000
0001
1
00
001
10
0000
31
Etat de l’art - Hypothèses - Modélisation - Architecture - Validation - Conclusion
Le plan de déploiement
Permet le passage d’un plan de répartition à un autre
Définit les actions de migration d’une application
tea
teaea dd 1
1 si a doit être déployée sur e
0 si a ne bouge pas ou n’est pas présente sur e
-1 si a doit être retirée de e
32
Etat de l’art - Hypothèses - Modélisation - Architecture - Validation - Conclusion
Modélisation de l’hétérogénéité
Description des ressources requises par une application
Description des ressources disponibles sur un équipement
Processeur : 500 MIPS
Ecran : 1
Processeur : 2000 MIPS
Ecran : 1
PrésenceUtilisateur : Vrai
PrésenceUtilisateur : Vrai
33
Etat de l’art - Hypothèses - Modélisation - Architecture - Validation - Conclusion
Deux types de contraintes de déploiement
Contraintes à valeurs quantitatives– e.g., quantité de ressources matérielles
Contraintes à valeurs énumérées– e.g., présence utilisateur, localisation
34
Etat de l’art - Hypothèses - Modélisation - Architecture - Validation - Conclusion
Exemples de contraintes de déploiement
Ressources matérielles
Présence de l’utilisateur
e
e
SCR
CAM
RAM
CPU
R
2
1
200
2000
a
a
SCR
CAM
RAM
CPU
R
1
0
20
500
PrésenceUtilisateur = Vrai
35
Etat de l’art - Hypothèses - Modélisation - Architecture - Validation - Conclusion
Ecran : 1Camera :
1
PrésUti : Vrai
CPU : 500 MIPS
La mobilité des applications
CPU : 500 MIPS
PresUti : Vrai
Camera : 1 Ecran : 1
Application
36
Etat de l’art - Hypothèses - Modélisation - Architecture - Validation - Conclusion
Deux ensembles dans une application
Ensemble de composants
Ensemble de contraintes
Décomposition
PrésenceUtilisateur : Vrai
GPS : 1 RAM : 20 MB
Ecran : 1Localisation : cuisine
20
15
1
11
1
1
1
1 1
15
37
Etat de l’art - Hypothèses - Modélisation - Architecture - Validation - Conclusion
Groupement en grappe de composants
Dépend du type de contrainte
1
1
1
15
5
5
15
20
38
Etat de l’art - Hypothèses - Modélisation - Architecture - Validation - Conclusion
Modélisation de la consommation
La puissance consommée par les équipements
Fonction d’utilité
Fonction objectif
)( te
one QP
lpeP
ePsi e en état de basse consommation
si e actif
))1()((P tslpe
te
te
one
te
EePQP
t
)))1()((min()min(P tslpe
te
te
one
te
EePQP
t
)1(1 tea
Aa
te d
t
avec
39
Etat de l’art - Hypothèses - Modélisation - Architecture - Validation - Conclusion
Synthèse de la modélisation
Fonction d’utilité décrivant les états du système
Prise en compte de la volatilité au travers de la modélisation des états, des événements et des actions
Prise en compte de l’hétérogénéité au travers de la spécification des contraintes de déploiement
Prise en compte de la qualité de service au travers de la satisfaction des contraintes de déploiement
41
Etat de l’art - Hypothèses - Modélisation - Architecture - Validation - Conclusion
Approche
Concevoir un système autonome, transparent, efficient énergétiquement et intégrant la fonction d’utilité
– Prendre en compte la dette énergétique– Utiliser les composants orientés service pour créer des
applications plus mobiles– Utiliser une boucle de contrôle fermée pour gérer les
événements et agir sur la répartition des composants
42
Etat de l’art - Hypothèses - Modélisation - Architecture - Validation - Conclusion
Architecture de HomeNap
Contrôleur
Gestionnaire
Adaptation du placement
des composants
Contrôle des états énergétiques des
équipements
Coordinateur
Collecteur
43
Etat de l’art - Hypothèses - Modélisation - Architecture - Validation - Conclusion
La dette énergétique
Différence de consommation d’énergie de l’environnement qui exécute un système par rapport à ce même environnement ne l’exécutant pas
HomeNap
Environnement
Avec le déploiement de HomeNap
Sans le déploiement de HomeNap
44
Etat de l’art - Hypothèses - Modélisation - Architecture - Validation - Conclusion
Gain énergétique
Un gain énergétique est réalisé dès lors que la dette énergétique est remboursée
RemboursementGain énergétique
HomeNap
Environnement
45
Etat de l’art - Hypothèses - Modélisation - Architecture - Validation - Conclusion
Un système réactif
Une boucle de contrôle fermée afin d’améliorer l’efficience énergétique en continu
Événement significatif
Plan de Répartition Optimisé
Plan de Répartition Mis à Jour
Contraintes
FonctionOptimisatio
n
FonctionMaJ
46
Etat de l’art - Hypothèses - Modélisation - Architecture - Validation - Conclusion
Adaptation à l’environnement
Boucle de contrôle MAPE-K [IBM03]
Gestionnaires
Coordinateur
Equipements et composants
AnalyseOptimisationet Planification
Observation Exécution
ActionneursCapteurs
Connaissance
47
Etat de l’art - Hypothèses - Modélisation - Architecture - Validation - Conclusion
Un système autonome
Le système se considère dans l’optimisation de la consommation d’énergie
– Sauvegarde de l’état des composants migrés– Transfert du code binaire
Coordinateur
Gestionnaire
Gestionnaire
Gestionnaire
Gestionnaire
48
Etat de l’art - Hypothèses - Modélisation - Architecture - Validation - Conclusion
Coordinateur
Les pannes
Disparition du coordinateur– Détection lors d’une communication avec le
coordinateur– Election du nouvel hôte du coordinateur– Restauration du coordinateur à partir du dernier état
connu Coordinateur
Gestionnaire
Gestionnaire
Gestionnaire
Gestionnaire
49
Etat de l’art - Hypothèses - Modélisation - Architecture - Validation - Conclusion
Synthèse de l’architecture
Mécanisme de limitation de la dette énergétique grâce à un système réactif
Système autonome qui se considère dans la recherche d’une solution
Système transparent pour l’utilisateur pour atteindre l’objectif
51
Etat de l’art - Hypothèses - Modélisation - Architecture - Validation - Conclusion
Mise en œuvre
Extension du modèle de consommation d’un équipement
Mise sous forme d’un problème de satisfaction de contraintes
Canevas Logiciels– OSGi / iPOJO [Escoffier07]– UPnP [UPnP08]– Solveur de contraintes Choco [Choco12]
minminmax)()( eCPU
e
CPUe
eeCPUe
one P
totaleR
utiliséeRPPutiliséeRP
52
Etat de l’art - Hypothèses - Modélisation - Architecture - Validation - Conclusion
Paramètres des évaluations
Equipements Consommation (W)
Architecture
Ordinateur Fixe 80 – 122 x86
Ordinateur Portable 1 25 – 48 x86
Ordinateur Portable 2 23 – 33 x86
BeagleBoard 8 – 10 ARM
nn3Nombre de grappes
considéréesNombre d’équipements
considérés
Nombre de combinaisonsconsidérées
53
Etat de l’art - Hypothèses - Modélisation - Architecture - Validation - Conclusion
Dette énergétique du coordinateur
Valeur de n
Dett
e é
nerg
éti
que (
Wh)
0,0001
0,001
0,01
0,1
1
10
2 3 4 5
Ordinateur Fixe (80-122 W)Ordinateur Portable 1 (25-48 W)
Ordinateur Portable 2 (23-33 W)BeagleBoard (8-10 W)
54
Etat de l’art - Hypothèses - Modélisation - Architecture - Validation - Conclusion
Temps de calcul de l’algorithme
Valeur de n
Tem
ps
de c
alc
ul (s
ec)
0,01
0,1
1
10
100
10000
2 3 4 5
Ordinateur Fixe (80-122 W)Ordinateur Portable 1 (25-48 W)
Ordinateur Portable 2 (23-33 W)BeagleBoard (8-10 W)
1000
100000
55
Etat de l’art - Hypothèses - Modélisation - Architecture - Validation - Conclusion
Temps de calcul versus dette énergétique
Temps (sec)
Dett
e é
nerg
éti
que (
Wh)
0,0001
0,001
0,01
0,1
1
10
10 100 1000 10000 10000010,10,01
n=2n=3
n=4
n=5
Ordinateur fixe Ordinateur portable 2BeagleBoardOrdinateur portable 1
56
Etat de l’art - Hypothèses - Modélisation - Architecture - Validation - Conclusion
Cas d’utilisation pratique
AlarmeTraitementd’images
Acquisitiond’images
PrésenceUtilisateur : vraiEcran : 1
Processeur : 500 MIPS Camera : vraiLocalisation : cuisine
PrésenceUtilisateur : vrai
GUI
Equipement actif
Equipement basse consommation
Equipement hors système
57
Etat de l’art - Hypothèses - Modélisation - Architecture - Validation - Conclusion
ScenarioAvec
Hom
eN
ap
San
s H
om
eN
ap
AcqTra
C
Ala
Ala
Tra
Acq
Evénement 1 : Apparition de l’ordinateur fixe
58
Etat de l’art - Hypothèses - Modélisation - Architecture - Validation - Conclusion
Evénement 2 : Apparition de l’interface utilisateur
Scenario
GUI
Tra Acq
C
Ala
GUI Ala
Tra
Acq
Avec
Hom
eN
ap
San
s H
om
eN
ap
59
Etat de l’art - Hypothèses - Modélisation - Architecture - Validation - Conclusion
Evénement 3 : Disparition de l’interface utilisateur
Scenario
GUI
Tra Acq
C
Ala
GUI Ala
Tra
Acq
Avec
Hom
eN
ap
San
s H
om
eN
ap
60
Etat de l’art - Hypothèses - Modélisation - Architecture - Validation - Conclusion
Evaluation pratique
Optimisation Réduction de l’énergie
Dette énergétique
Remboursement etGain énergétique
62
Etat de l’art - Hypothèses - Modélisation - Architecture - Validation - Conclusion
Conclusion
Comment augmenter l’efficience énergétique de la maison numérique en prenant en compte ses propriétés ?
La modélisation tient compte des propriétés considérées
– Hétérogénéité aux travers des contraintes de déploiement
– Volatilité aux travers de la modélisation des événements
– Qualité de service aux travers de la satisfaction des contraintes de déploiement
L’architecture est conçue pour réduire son impact énergétique
– Autonome par la prise en compte du système– Efficient énergétiquement par un système réactif– Transparent par la non intervention de l’utilisateur
63
Etat de l’art - Hypothèses - Modélisation - Architecture - Validation - Conclusion
Perspectives
Court terme– Enrichir le modèle– Construire de nouvelles grappes de composants– Développer une architecture plus extensible– Améliorer la gestion de la volatilité– Améliorer l’algorithme d’optimisation
Long terme– Apprendre des habitudes des utilisateurs– Migrer les services temporellement– Estimer le coût énergétique minimal d’un service– Prendre en compte l’environnement extérieur (e.g.,
cloud)– Transférer vers les organismes de normalisation
Rémi Druilhe
L'Efficience Energétique des Services dans les Systèmes Répartis Hétérogènes et Dynamiques
Application à la Maison Numérique
Président : Jean-Louis PAZAT, INSA Rennes, France
Rapporteur : Noel DE PALMA, Université Joseph Fourier de Grenoble, FranceRapporteur : Jean-Marc MENAUD, Ecole des Mines de Nantes, FranceExaminateur : Laurent LEFEVRE, Université de Lyon, France
Directrice : Laurence DUCHIEN, Université Lille 1, FranceCo-Directeur : Lionel SEINTURIER, Université Lille 1, FranceEncadrant : Matthieu ANNE, Orange, France
Soutenance de thèse pour l’obtention du Doctorat de l'Université des Sciences et Technologies de Lille
(spécialité Informatique)
65
Annexes
Publications
[ARTICLE] Rémi Druilhe, Matthieu Anne, Jacques Pulou, Laurence Duchien and Lionel Seinturier, Components Mobility for Energy Efficiency of Digital Home, CBSE, 2013
[ARTICLE] Rémi Druilhe, Matthieu Anne, Jacques Pulou, Laurence Duchien and Lionel Seinturier, Energy-driven Consolidation in Digital Home, SAC track SEAGC, 2013
[POSTER] Rémi Druilhe, Matthieu Anne, Romain Rouvoy and Laurence Duchien, La réduction de la consommation d'énergie dans les environnements domestiques répartis, CFSE, 2011
66
Annexes
References
[Choco12] Ecole des Mines de Nantes, Choco, http://www.emn.fr/z-info/choco-solver, 2012.
[Escoffier07] C. Escoffier. and R.S. Hall and P.Lalanda, iPOJO: An extensible service-oriented component. In Services Computing, pages 474-481. IEEE, 2007.
[HLM+09] Fabien Hermenier, Xavier Lorca, Jean-Marc Menaud, Gilles Muller, and Julia Lawall. Entropy: a consolidation manager for clusters. In Proceedings of the 2009 ACMSIGPLAN/SIGOPS international conference onVirtual execution environments, pages 41–50. ACM, 2009
[IBM03] A. Computing. An architectural blueprint for autonomic computing. IBM White Paper, 2003.
[Kephart04] J.O. Kephart and W.E. Walsh. An artificial intelligence perspective on autonomic computing policies. In Policies for Distributed Systems and Networks, 2004. POLICY 2004. Proceedings. Fifth IEEE International Workshop on, pages 3–12. IEEE, 2004.
[Khanna06] G. Khanna, K. Beaty, G. Kar, and A. Kochut. Application performance management in virtualized server environments. In Network Operations and Management Symposium. IEEE, 2006.
[MV03] S. Mohapatra and N. Venkatasubramanian. Parm: Power aware reconfigurable middleware. In Distributed Computing Systems, 2003. Proceedings. 23rd International Conference on, pages 312–319. IEEE, 2003.
[UPnP08] UPnP Forum. UPnP Device Architecture 1.1, Octobre 2008.
[UPnPLP07] UPnP Forum. UPnP Low Power Architecture, Août 2007.
[Zhong11] W. Zhong, G. Shi, Z. Zhao, and F. Xia. Parasite: A system for energy saving with performance improvement in networked desktops. In Green Computing and Communications (GreenCom), 2011 IEEE/ACM International Conference on, pages 79–84. IEEE, 2011.
67
Annexes
Temps de calcul de l’algorithme
Valeur de n
Tem
ps
(sec)
2 3 4 50,01
0,1
1
10
100
1000
10000
100000
Problème A : problème sous-contraint
Problème B : problème quasiment sur-contraint