Puissance électrique dans les protocoles de tolérance aux pannes

Télécharger le fichier original (Mémoire de fin d’études)

Services applicatifs considérés

Dans cette thèse, nous nous intéressons spécifiquement à deux services applica-tifs : la tolérance aux pannes et la diﬀusion de données. D’une part, le choix de ces deux services applicatifs est motivé par le fait qu’ils font partie des services incon-tournables pour relever les principaux défis auxquels il est nécessaire de faire face à une échelle post-pétaflopique. D’autre part, il se justifie par une volonté d’étudier deux services dont le positionnement dans l’application est assez diﬀérent. En ef-fet, la tolérance aux pannes est un composant logiciel qui s’exécute en arrière plan, parallèlement à l’application pendant toute la durée de son exécution. Quant à la diﬀusion de données, il s’agit d’un service ayant lieu à un moment donné de l’appli-cation et pouvant être assimilé à une partie de cette application. Il existe diverses façons d’implémenter chacun de ces deux services applicatifs.

Le service de tolérance aux pannes

Il existe trois grandes familles de protocoles de tolérance aux pannes reposant sur la sauvegarde de points de reprise : les protocoles coordonnés, les protocoles non coordonnés, et les protocoles hiérarchiques. Le principe général commun à ces trois grandes familles est de sauvegarder régulièrement (intervalle de points de reprise) l’état global de l’application afin de redémarrer cette dernière en cas de panne au dernier point de sauvegarde plutôt que de tout ré-exécuter. Le problème lorsqu’on sauvegarde les points de reprise c’est de garantir la cohérence globale du système. Un état global est dit cohérent s’il ne comporte pas de messages reçus mais non envoyés.
Les protocoles coordonnés sont actuellement les protocoles de tolérance aux pannes les plus utilisés dans les applications de calcul haute performance. Afin de garantir la cohérence globale du système, le protocole coordonné repose sur la coor-dination qui consiste essentiellement à synchroniser tous les processus avant chaque sauvegarde de point de reprise [Netzer and Xu, 1995]. La coordination peut avoir un impact important sur les performances car pour synchroniser tous les processus, il faut d’abord attendre que tous les messages en cours de transmission soient reçus. De plus, en cas de panne avec le protocole coordonné, tous les processus doivent re-démarrer au dernier point de reprise même si un seul processus est tombé en panne. Cela conduit à un gaspillage d’énergie important car tous les processus, même ceux qui ne sont pas tombés en panne, doivent rejouer tous leurs calculs et communi-cations déjà réalisés depuis le dernier point de reprise. La figure 1.3 schématise le fonctionnement du protocole coordonné avant et après une panne.
Le protocole non coordonné avec enregistrement de messages aborde ce pro-blème en ne redémarrant que les processus défaillants. Dans ce cas, la consommation d’énergie de la récupération est censée être beaucoup plus faible que celle du pro-tocole coordonné. En contrepartie, afin de garantir la cohérence globale des points de reprises sauvegardés de façon non coordonnée, les protocoles à enregistrement de messages doivent sauvegarder tous les messages envoyés par tous les processus lors de l’exécution entière, ce qui est également coûteux en performances [Bouteiller et al., 2010]. Ainsi, en cas de panne, les processus non défaillants ré-émettent aux processus défaillants les messages qu’ils ont sauvegardés. La figure 1.4 schématise le fonctionnement du protocole non coordonné avant et après une panne.
Une troisième famille de protocoles de tolérance aux pannes a été proposée ré-cemment afin de remédier aux limitations des protocoles coordonnés et des proto-coles à enregistrement de messages : les protocoles hiérarchiques [Guermouche et al., pear,Meneses et al., 2010,Bouteiller et al., 2011]. Ces protocoles combinent les avan-tages d’un enregistrement réduit de messages pendant l’exécution sans défaillance et d’un redémarrage limité en cas de récupération. Ces protocoles structurent les processus de l’exécution en grappes et enregistrent uniquement les messages échan-gés entre grappes. Les messages échangés au sein d’une même grappe ne sont pas sauvegardés. Ces protocoles ne mettent pas en jeu une sauvegarde coordonnée de point de reprise globale mais les processus issus d’une même grappe se coordonnent avant chaque sauvegarde de point de reprise.
Dans cette thèse, nous nous focalisons sur les deux premières familles de proto-coles étant donné que la troisième famille est une combinaison de la première et de la deuxième.

Le service de diﬀusion de données

MPI (Message Passing Interface) est une bibliothèque de fonctions utilisables avec les langages C, C++ et Fortran permettant de faire communiquer plusieurs ordinateurs distants par passage de messages. Il s’agit d’un standard de communi-cation incontournable pour l’exécution d’applications parallèles sur des infrastruc-tures distribuées à très large échelle. En eﬀet, la majorité des plates-formes péta-flopiques l’utilisent actuellement et la communauté de recherche sur le calcul très haute performance continue d’aﬃrmer que l’on ne pourra pas s’en passer à l’échelle post-pétaflopique.
En ce qui concerne les algorithmes de diﬀusion de données, deux principales implémentations MPI existent : MPICH2 8 et OpenMPI 9. Les algorithmes utilisés diﬀèrent d’une implémentation à l’autre. En eﬀet, pour diﬀuser un volume de don-nées assez grand (plus de 128 Ko) à un nombre de processus assez grand (plus de 8 processus), OpenMPI utilise l’algorithme de Pipeline avec une taille de paquet (chunk) paramétrable alors que MPICH2 utilise une distribution des données par-tielles (Scatter) suivie d’une collecte généralisée des données partielles (AllGather). L’algorithme de distribution de données partielles de MPICH2 est implémenté en utilisant un arbre bi-nomial avec une taille de paquet égale au volume total des don-nées divisé par le nombre total des processus. Chacune des deux implémentations (MPICH2 et OpenMPI) utilise d’autres algorithmes mais qui ne sont utilisés que pour les messages relativement petits diﬀusés à un nombre de processus relativement faible.
Une autre approche prometteuse pour diﬀuser les données est d’utiliser la pro-grammation hybride en combinant MPI pour les communications inter-noeuds avec OpenMP pour les communications intra-noeuds [Rabenseifner et al., 2009]. En eﬀet, MPI est optimisé pour des architectures à mémoire distribuée alors que OpenMP est plus performant pour programmer sur des mémoires partagées. Dans un algorithme hybride de diﬀusion de données, le processus initiateur utilise MPI pour diﬀuser la donnée à un seul processus MPI désigné sur chaque noeud. Ensuite, chaque pro-cessus MPI utilise OpenMP pour partager la donnée diﬀusée avec tous les autres processus qui se trouvent dans le même noeud.
Dans cette thèse, nous nous intéressons aux deux algorithmes de diﬀusion de données MPI (Scatter & AllGather d’une part et Pipeline d’autre part) ainsi qu’aux deux algorithmes de diﬀusion hybrides combinant OpenMP à chacun des deux al-gorithmes MPI.

Enjeux et problématiques

L’objectif principal de cette thèse est de réduire la consommation énergétique des infrastructures de calcul très haute performance. Com-ment exécuter des applications sur ces infrastructures dans l’optique de consommer moins d’énergie ? Comme expliqué précédemment, nous nous préoccupons essen-tiellement d’économiser l’énergie consommée par les services applicatifs (plutôt que celle des applications) dans la mesure où ils sont connus actuellement et qu’ils sont incontournables à très large échelle. Or nous venons de voir qu’il existe diverses façons d’implémenter un même service applicatif (diﬀérents protocoles de tolérance aux pannes et divers algorithmes de diﬀusion de données). Dans la mesure où il existe plusieurs versions (algorithmes, protocoles) pour chacun des services applica-tifs, la deuxième question que l’on est amené à se poser est de savoir quelle version choisir pour consommer moins d’énergie. Ce choix dépend-il des paramètres d’exécution de l’application ou/et des spécificités de la plate-forme de calcul très haute performance ?
Le cas échéant, nous devons être capables de prédire la consommation énergé-tique des diﬀérentes versions de ces composants logiciels en fonction des paramètres d’exécution et des spécificités de la plate-forme de calcul intensif. En connaissant la consommation énergétique des diﬀérentes versions d’un service applicatif avant l’exécution de l’application, nous serons capables de choisir celui qui consomme le moins d’énergie. Comment estimer de façon précise avant l’exécution de l’application, la consommation énergétique des diﬀérentes versions d’un même service applicatif ? Pour répondre à cette question, il est d’une part essen-tiel de savoir comment tenir compte des paramètres d’exécution. D’autre part, il est important de mettre en place une méthodologie afin d’adapter les modèles théoriques d’estimation énergétique aux caractéristiques architecturales (processeurs, coeurs de calcul, mémoires, réseaux, etc.), matérielles (types de supports de stockage, techno-logie réseau, etc), logicielles (système d’exploitation) et environnementales (tem-pérature de la salle d’expérimentation) de la plate-forme expérimentale. Les mo-dèles théoriques d’estimation énergétique sont les équations permettant de calculer l’énergie consommée à partir de tous les paramètres faisant varier la consommation énergétique. Pour adapter les estimations énergétiques au matériel d’exécution, nous avons besoin de procéder à un ensemble de mesures de puissance électrique et de temps d’exécution permettant de calibrer les modèles d’estimation en fonction de l’infra-structure de calcul intensif. Nous appelons calibration le processus qui consiste à or-chestrer la prise de ces mesures de puissance électrique et de temps d’exécution. Afin de calibrer les modèles d’estimation sur une plate-forme donnée, il faut être capable de mesurer la consommation électrique pendant l’exécution des services applicatifs. Comment mesurer la consommation électrique des services applicatifs ? Comment s’assurer de la précision de la valeur relevée à l’aide d’un dispositif de mesure de la consommation électrique ? Quelle fréquence de mesure est nécessaire pour tenir compte des éventuelles variations électriques ? Par ailleurs, une infrastruc-ture de calcul intensif comporte une ou plusieurs grappes de calcul constituées de noeuds identiques d’un point de vue matériel et logiciel. Comment se comportent ces noeuds identiques vis à vis de la consommation électrique ? Ont-ils tous la même consommation s’ils exécutent les mêmes applications ?
En plus d’être très importante, la consommation électrique des supercalculateurs est dynamique. En eﬀet, la dynamique de consommation électrique est une consé-quence d’une utilisation irrégulière des ressources de calcul et d’un plafonnement variable de la puissance électrique totale que peut délivrer le fournisseur d’électri-cité. Par conséquent, nous pensons qu’il est indispensable de mettre en place un dialogue avec les diﬀérents acteurs qui interagissent avec l’infrastructure de calcul intensif. En plus de l’utilisateur qui souhaite exécuter ses applications et l’admi-nistrateur qui configure et supervise la plate-forme expérimentale, le fournisseur d’énergie joue également un rôle très important dans la mesure où il permet l’ali-mentation électrique de l’infrastructure. Selon son approvisionnement en énergie et des tendances de consommation de la société, l’électricité qu’il fournit peut être pro-posée à des tarifs financiers fluctuants et est à l’origine d’une pollution variable de l’environnement quantifiée en grammes de CO2 émis.
À cet eﬀet, l’usage d’une grille électrique intelligente permet de gérer le dialogue entre le fournisseur d’énergie et le consommateur qui, dans notre cas est l’infrastruc-ture de calcul très haute performance. Un autre objectif de cette thèse est de « consommer mieux » en s’appuyant sur cette grille électrique intelligente mais éga-lement sur la calibration électrique de la plate-forme de calcul intensif. « Consommer mieux » signifie que nous consommons la même quantité d’énergie mais à moindres coûts financiers tout en générant moins de pollution de l’environnement. Comment tenir compte des contraintes des diﬀérents acteurs afin de « consommer mieux » se-lon plusieurs critères (consommation d’énergie, coûts financier et environnemental) ? Pour cela, il faut veiller à planifier les réservations des ressources de calcul de sorte que l’on puisse consommer « moins » et « mieux ».

Contributions et annonce du plan

Dans la suite du présent manuscrit, nous allons chercher à répondre aux ques-tions précédemment énoncées. Pour cela, nous nous appuyons essentiellement sur des expérimentations pour valider nos réponses.
Le chapitre 2 présente un état de l’art des diﬀérentes solutions pour mesurer, estimer et réduire la consommation énergétique des serveurs de calcul. Il présente également les diﬀérentes solutions pour planifier des réservations de ressources de calcul dans une plate-forme distribuée tout en optimisant la consommation énergé-tique.
Dans le chapitre 3, nous évaluons et analysons la consommation électrique de noeuds de calcul haute performance à partir de mesures réelles issues de diﬀérents scénarii. Le premier objectif de ce chapitre est de souligner les diﬃcultés pour mesurer avec précision l’énergie consommée par un service applicatif donné. Ces diﬃ-cultés sont mises en avant grâce à l’étude des divergences entre les mesures issues de diﬀérents appareils de mesures (externes/internes, avec une fréquence de mesure faible/élevée). Le deuxième objectif de ce chapitre est d’étudier le comportement de la consommation électrique de noeuds identiques.
Dans le chapitre 4, nous présentons notre approche d’estimation de la consom-mation d’énergie pour les protocoles de tolérance aux pannes et les algorithmes de diﬀusion de données. Nous présentons les modèles selon lesquels nous évaluons l’énergie consommée par les diﬀérents services étudiés. Bien que génériques, ces mo-dèles ne suﬃsent pas pour estimer de façon précise la consommation énergétique des diﬀérentes versions d’un service donné. En eﬀet, la consommation énergétique d’un service applicatif est très dépendante du matériel utilisé dans la plate-forme d’exécution. Afin d’adapter nos modèles à une plate-forme donnée, notre approche d’estimation repose donc sur une calibration de la plate-forme basée sur des mesures énergétiques réelles des diﬀérentes opérations de base identifiées.
Le chapitre 5 présente les diﬀérentes solutions pour réduire la consommation d’énergie dans une plate-forme de calcul très haute performance. Dans un premier temps, nous étudions la possibilité de réduire la consommation énergétique en nous basant sur les résultats de calibration électrique des noeuds de calcul qui constituent l’infrastructure de calcul très haute performance. Dans un deuxième temps, nous mettons en évidence comment il est possible de réduire la consommation énergétique des applications en nous appuyant sur les estimations énergétiques des diﬀérentes versions de services applicatifs.
Le chapitre 6 présente SESAMES, un environnement logiciel qui intègre des ca-librations et estimations énergétiques que nous sommes capables de fournir. Dans ce chapitre sont présentées les diﬀérentes fonctionnalités de SESAMES. Nous dé-crivons les diﬀérents composants ainsi que les interactions de SESAMES avec les multiples acteurs de la plate-forme de calcul très haute performance. Nous décrivons en particulier les échanges SESAMES/utilisateurs et les échanges SESAMES/four-nisseur d’énergie qui ont lieu dans le cadre d’une grille électrique intelligente. En nous appuyant sur SESAMES, nous présentons notre approche eﬃcace en énergie et multi-objectifs (moins d’énergie, moins de coûts financiers et environnementaux) pour planifier les réservations de ressources qu’expriment les diﬀérents utilisateurs de la plate-forme de calcul très haute performance.
Le chapitre 7 présente les conclusions de cette thèse et ouvre de nouvelles pers-pectives et voies de recherche.

Évaluation de la consommation énergétique lors de l’exécution d’applications

Pour évaluer la consommation énergétique d’applications, la première approche consiste à utiliser des dispositifs qui mesurent la puissance électrique alimentant les diﬀérentes machines sur lesquelles est exécutée une application. La deuxième approche consiste à estimer la consommation énergétique en s’appuyant sur des modèles théoriques, généralement liés aux performances. La première méthode est souvent utilisée pour évaluer la précision des approches d’estimation.

Mesure de la puissance électrique

Pour mesurer la consommation énergétique des systèmes informatiques, deux méthodes sont principalement utilisées : soit on utilise des équipements matériels que l’on connecte à l’intérieur ou à l’extérieur de chaque machine, soit on utilise des capteurs d’énergie qui sont intégrés à certaines architectures matérielles.

Quel est le bon équipement de mesure électrique ?

Plusieurs travaux de recherche se sont intéressés à la mesure de la puissance électrique des serveurs ou des systèmes distribués à large échelle. Pour cela, diﬀérents dispositifs ont été utilisés.
Dans l’article [Carpentier et al., 2012], les auteurs supervisent la consomma-tion énergétique de serveurs à l’aide de quatre diﬀérents dispositifs de mesure de la puissance électrique :
– le PDU 1 Eaton 2 ;
– le PDU Schleifenbauer 3 ;
– le wattmètre OmegaWatt 4 ;
– une carte de supervision proposée par plusieurs constructeurs (Dell, Intel, HP et Nec) : l’interface de gestion intelligente de matériel [Intel et al., 2009] (IPMI 5) est un ensemble de spécifications d’interfaces permettant de supervi-ser la consommation énergétique et la température à l’intérieur des machines.
Pour mesurer la consommation énergétique, d’autres dispositifs assez similaires sont également utilisés :
– le wattmètre WattsUp utilisé dans [Castillo et al., 2011] ;
– la carte de supervision PowerExecutive proposée dans les serveurs IBM Bla-deCenter 6 ;
Ces dispositifs de mesure se diﬀérencient notamment par quatre critères : la na-ture, la localité, la précision et la fréquence de mesure. OmegaWatt et WattsUp mesurent la puissance active, c’est-à-dire la puissance électrique moyenne calculée à partir de l’énergie mesurée pendant une seconde alors que les autres dispositifs me-surent une puissance électrique instantanée qui est obtenue en mesurant le courant et la tension aux bornes de la machine. IPMI (utilisé aussi dans [Giri and Vanchi, 2010]) et PowerExecutive permettent de mesurer la puissance électrique à l’intérieur de la machine (à la sortie du bloc d’alimentation) contrairement aux autres dispo-sitifs qui la mesurent en externe (à l’entrée du bloc d’alimentation). Cela signifie que la mesure électrique fournie par IPMI est en courant continu et ne tient pas compte de la puissance électrique dissipée par le bloc d’alimentation du serveur. À l’opposé, les trois autres dispositifs mesurent en courant alternatif la puissance élec-trique globale alimentant la machine et tient donc compte du bloc d’alimentation et de tous les composants matériels de la machine. Ainsi, un inconvénient de IPMI et PowerExecutive est que ces dispositifs ne tiennent pas compte de la puissance électrique dissipée par le bloc d’alimentation du serveur qui peut représenter une proportion importante de la consommation totale du serveur (environ 20 %).
Bien que IPMI et PowerExecutive présentent l’avantage de superviser la puis-sance électrique sans avoir à installer un équipement supplémentaire, cette solution s’avère être peu précise et ne permet pas d’avoir une granularité de mesure assez fine (puissance instantanée à une fréquence relativement faible). En eﬀet, en ce qui concerne IPMI, une incertitude de mesure de 7W est trop grande pour mesurer des fluctuations électriques de quelques watts alors que les wattmètres OmegaWatt, WattsUp et le PDU Schleifenbauer aﬃchent une précision de l’ordre de 0:1W . Le PDU Eaton a une précision intermédiaire de 1W . De plus, les deux cartes de supervision (IPMI et PowerExecutive) présentent une fréquence de mesure assez faible (1 mesure toutes les 5 secondes pour IPMI). Bien que leurs précisions de me-sure soient relativement élevées, les autres dispositifs ne fournissent qu’une mesure par seconde au meilleur des cas. En fournissant des puissances électriques chaque 3 secondes, les PDUs Schleifenbauer et Eaton ne sont donc pas adaptés pour mesu-rer la consommation énergétique des applications ou des tâches qui ne durent que quelques secondes. À l’opposé, OmegaWatt et WattsUp fournissent une mesure qui tient donc compte des fluctuations électriques pendant une seconde étant donné qu’ils mesurent une puissance moyenne chaque seconde.
Pour illustrer cela, la figure 2.1 compare la puissance électrique totale d’une grappe de six noeuds mesurée simultanément par IPMI et le PDU Eaton. L’axe des abscisses aﬃche l’horaire de la mesure tandis que l’axe des ordonnées présente la puissance électrique totale en watts. La courbe représente l’évolution de puissance électrique totale mesurée avec IPMI alors que les histogrammes représentent celle du PDU Eaton. Même si la puissance électrique mesurée par IPMI est censée être plus basse (car ne tient pas compte des blocs d’alimentation) que celle qui est relevée par le PDU Eaton, nous observons un scénario diﬀérent entre 15h55 et 16h15 et ce à cause de la précision des mesures qui est beaucoup plus faible avec IPMI ( 7W vs 1W ) sur chaque noeud. Par ailleurs, nous observons qu’il y a un décalage temporel entre les variations électriques mesurées par IPMI et celles qui sont relevées par le PDU Eaton. Les mesures prises par IPMI sont en retard par rapport à celles mesurées avec le PDU Eaton (voir 15h52). Ce décalage temporel est lié à la fréquence de mesure de IPMI qui est relativement plus basse que celle du PDU Eaton (1 mesure toutes les 5 secondes vs 1 mesure chaque 3 secondes).
Il existe d’autres équipements mesurant à des fréquences plus élevées (supérieures à 1 Hz). En eﬀet, des équipements de mesure interne comme PowerMon2 [Bedard et al., 2010] permettent de mesurer à des fréquences très élevées la puissance élec-trique interne instantanée des diﬀérentes lignes électriques ATX (3.3 V, 5 V et 12 V) qui sortent du bloc d’alimentation de la machine et qui alimentent la carte mère et les diﬀérents périphériques. Pour mesurer la puissance électrique instantanée d’une ligne électrique, PowerMon2 mesure la valeur du courant et la multiplie par la tension qui est constante (3 V, 5 V ou 12 V). Lorsque PowerMon2 est utilisé pour mesurer la puissance électrique d’une seule ligne électrique, sa fréquence de mesure peut atteindre 3072 Hz.
Les auteurs de l’article [Barrachina et al., 2013] ont utilisé trois autres équipements de mesure interne très similaires à PowerMon2. Parmi eux, ils ont utilisé NI qui peut atteindre 7000 Hz s’il mesure la puissance électrique d’une seule ligne électrique. Les deux autres équipements de mesure interne DCM et DC2M ont été fabriqués par leurs soins et permettent de mesurer la puissance électrique instan-tanée à des fréquences respectivement égales à 25 Hz et 100 Hz. Contrairement à PowerMon2, ces trois équipements (NI, DCM et DC2M) ne permettent de me-surer que les lignes électriques de 12V qui permettent d’alimenter les processeurs, les ventilateurs et une partie de la carte mère. Par exemple, ils ne permettent pas de mesurer la puissance électrique alimentant certains périphériques tel que le disque dur.
L’inconvénient de ces équipements de mesure interne est qu’ils ne sont pas faciles à brancher et qu’ils ne conviennent que pour des blocs d’alimentation standards, c’est-à-dire avec des câbles électriques respectant la norme ATX. Leur déploiement est donc inapplicable à très large échelle. Les auteurs des articles [Hähnel et al., 2012,Rotem et al., 2012] utilisent les comp-teurs d’énergie RAPL 7 disponibles uniquement dans les processeurs Intel Sandy et Ivy Bridge. D’autres compteurs d’énergie équivalents existent sur les processeurs AMD qui sont par exemple utilisés dans le supercalculateur BlueWaters 8. Les comp-teurs d’énergie RAPL permettent de mesurer la puissance électrique instantanée de ces processeurs Intel à une fréquence égale à 1000 Hz et avec une précision assez éle-vée (inférieure à 1 W). Ils sont intéressants pour superviser la puissance électrique d’applications s’exécutant sur des systèmes distribués à très large échelle dans la mesure où ils ne nécessitent aucun branchement et mesurent la puissance instanta-née avec une précision et une fréquence élevées. Cependant, ils ne mesurent que la puissance électrique des processeurs (et non pas de toute la machine). D’autre part, ils ne sont disponibles que dans les familles de processeurs Intel Sandy et Ivy Bridge. De plus, il s’agit d’une solution de mesure intrusive dans la mesure où il faut ac-céder souvent aux compteurs d’énergie pour lire les valeurs de puissance électrique. Pour cela, il est nécessaire d’exécuter un programme qui collecte les mesures. Il faut donc s’assurer que l’utilisateur a les droits suﬃsants pour exécuter ce programme. L’exécution d’un tel programme peut fausser la mesure de la puissance électrique.
Ainsi, nous pouvons classer tous ces dispositifs de mesure en cinq catégories présentées dans le tableau 2.1.

Table des matières

1 Introduction
1.1 Services applicatifs considérés
1.1.1 Le service de tolérance aux pannes
1.1.2 Le service de diffusion de données
1.2 Enjeux et problématiques
1.3 Contributions et annonce du plan
2 Etat de l’art
2.1 Évaluation de la consommation énergétique lors de l’exécution d’applications
2.1.1 Mesure de la puissance électrique
2.1.2 Estimation de la consommation énergétique
2.2 Solutions pour une consommation efficace de l’énergie
2.2.1 Solutions pour réduire la consommation énergétique
2.2.2 Solutions pour mieux consommer l’énergie
2.3 Conclusions du chapitre
3 Mesure de la puissance électrique de services applicatifs
3.1 Mesure de la puissance électrique dans les protocoles de tolérance aux pannes et dans les algorithmes de diffusion de données
3.1.1 Dispositif expérimental et méthodologie
3.1.2 Puissance électrique dans les protocoles de tolérance aux pannes
3.1.3 Puissance électrique dans les algorithmes de diffusion de données
3.1.4 Analyse des mesures électriques
3.2 Quel équipement choisir pour mesurer la puissance électrique ?
3.2.1 Dispositif expérimental
3.2.2 Analyse de la consommation énergétique
3.2.3 Analyse de la puissance électrique
3.2.4 Analyse des profils temporels de puissance électrique
3.2.5 Discussion
3.3 A-t-on besoin de mesurer la puissance électrique pour tous les noeuds d’une même grappe ?
3.3.1 Les machines d’une même grappe ont-elles une puissance électrique identique ?
3.3.2 Quelle est l’origine des différences de puissance électrique au repos ?
3.4 Conclusions du chapitre
4 Estimation de la consommation énergétique des services applicatifs
4.1 Identification des opérations
4.1.1 Cas de la tolérance aux pannes
4.1.2 Cas de la diffusion de données
4.2 Méthodologie de calibration énergétique
4.2.1 Calibration de la puissance électrique op
4.2.2 Calibration du temps d’exécution top
4.3 Méthodologie d’estimation énergétique
4.3.1 Cas de la tolérance aux pannes
4.3.2 Cas de la diffusion de données
4.4 Validation des estimations
4.4.1 Résultats de calibration de la plate-forme
4.4.2 Précision des estimations
4.5 Conclusions du chapitre
5 Consommer moins d’énergie dans les infrastructures de calcul très haute performance
5.1 Choix du service applicatif en exploitant les estimations énergétiques
5.1.1 Tolérance aux pannes
5.1.2 Diffusion des données
5.2 Choix des noeuds de calcul en exploitant leur hétérogénéité électrique
5.2.1 Méthodologie
5.2.2 Évaluation du gain énergétique lors des exécutions d’applications de calcul haute performance
5.2.3 Évaluation du gain en puissance électrique lors de l’extinction
des noeuds inutilisés
5.3 Conclusions du chapitre
6 Consommer mieux dans les infrastructures de calcul très haute performance
6.1 SESAMES : un environnement logiciel pour consommer moins et mieux
6.1.1 Architecture conceptuelle de SESAMES
6.1.2 Services pris en compte dans SESAMES
6.1.3 Composants de SESAMES
6.1.4 Grille électrique intelligente
6.2 Ordonnancement efficace en énergie des réservations des ressources
6.3 Evaluation de l’ordonnanceur de réservations multi-critères
6.3.1 Environnement de simulation
6.3.2 Résultats d’évaluation
6.4 Conclusions du chapitre
7 Conclusions et perspectives
7.1 Conclusions
7.2 Discussion et Perspectives
7.2.1 Compromis entre la consommation énergétique et le temps d’exécution des services applicatifs
7.2.2 Inclusion des mécanismes de récupération des points de reprise
7.2.3 Appliquer des leviers énergétiques visant à réduire la consommation énergétique
7.2.4 Vers un ordonnancement des réservations de ressources multiobjectifs optimisé qui accepte plus de requêtes
Publications
References