Rémi Druilhe

Post on 24-Feb-2016

37 views 0 download

Tags:

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

Transcript of Rémi Druilhe

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/an34,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

8

ETAT DE L’ART

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èneH2 : 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

Client Application

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.

15

DÉFINITIONS ET HYPOTHÈSESde Travail

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 processusSource : 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 ServiceCouche 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

24

de la Maison NumériqueMODÉLISATION

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 AaEetea

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 ApplicationApparition d’un élémentDisparition 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

SCRCAMRAMCPU

R

212002000

a

a

SCRCAMRAMCPU

R

1020500

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

55

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

40

ARCHITECTUREde HomeNap

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

équipementsCoordinate

urCollecteu

r

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

nFonction

MaJ

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

Analyse Optimisationet 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

CoordinateurGestionnair

eGestionnair

eGestionnair

eGestionnair

e

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 CoordinateurGestionnair

eGestionnair

eGestionnair

eGestionnair

e

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

50

de HomeNapVALIDATION

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

totaleRutilisé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 x86Ordinateur Portable 1 25 – 48 x86Ordinateur Portable 2 23 – 33 x86BeagleBoard 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

Dette

éne

rgét

ique

(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 d

e ca

lcul (

sec)

0,010,1

110

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)

Dette

éne

rgét

ique

(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

Alarme Traitementd’images

Acquisitiond’images

PrésenceUtilisateur : vraiEcran : 1

Processeur : 500 MIPS Camera : vraiLocalisation : cuisine

PrésenceUtilisateur : vrai

GUI

Equipement actifEquipement basse consommationEquipement hors système

57

Etat de l’art - Hypothèses - Modélisation - Architecture - Validation - Conclusion

ScenarioAv

ec H

omeN

apSa

ns H

omeN

ap

AcqTra

CAla

AlaTra

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

CAla

GUI AlaTra

Acq

Avec

Hom

eNap

Sans

Hom

eNap

59

Etat de l’art - Hypothèses - Modélisation - Architecture - Validation - Conclusion

Evénement 3 : Disparition de l’interface utilisateur

Scenario

GUI

Tra Acq

CAla

GUI AlaTra

Acq

Avec

Hom

eNap

Sans

Hom

eNap

60

Etat de l’art - Hypothèses - Modélisation - Architecture - Validation - Conclusion

Evaluation pratique

Optimisation Réduction de l’énergie

Dette énergétiqueRemboursement etGain énergétique

61

CONCLUSION

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 (s

ec)

2 3 4 50,010,1

110

1001000

10000100000

Problème A : problème sous-contraintProblème B : problème quasiment sur-contraint

68

Annexes

Evaluation Théorique

69

Merci à tous

et

Place au pot d’après thèse dans la cafétéria du Bâtiment A