Le but du projet EMAN
(Energy MANagement) à l'IETF
est de développer un ensemble de normes techniques sur la gestion de
l'énergie par les équipements informatiques en réseau. Ce
RFC explique le projet et décrit des scénarios
d'utilisation. C'est un pas de plus (très modeste encore) vers un
Internet plus « vert ».
Le cadre général pour la gestion de l'énergie des équipements
Internet figure dans le (et le cahier
des charges dans le ). L'idée est de
d'abord de pouvoir superviser à distance tout engin connecté à l'Internet, et de
connaitre par ce moyen sa consommation d'énergie (le préalable à toute
action). Puis, le cadre EMAN
(défini par le groupe de
travail du même nom) doit permettre l'action sur ces engins,
par exemple ralentir le processeur pour
diminuer la consommation, ou carrément arrêter certaines machines pour
économiser l'énergie. Il existe bien sûr déjà des méthodes pour cela
mais elles ne sont pas encore normalisées ou bien utilisent des
protocoles pré-Internet. EMAN doit permettre la
supervision et l'action sur des engins très différents, et ne sortant
pas de chez le même fournisseur. Le but n'est pas seulement
d'économiser l'argent (l'électricité coûte cher) mais aussi de tenir
compte de la finitude des ressources de la planète (c'est, à ma
connaissance, la première fois que ce point est mentionné dans un
RFC : bien des acteurs de l'Internet vivaient jusqu'à présent dans
l'illusion qu'on trouverait toujours « une autre ressource
énergétique »).
Bref, deux tâches pour EMAN, la supervision
(mesurer la consommation) et l'action (éteindre si nécessaire).
Pour permettre cette supervision et cette action, EMAN () a défini un modèle de données, et utilisera le protocole
SNMP, et des MIB dont
certaines sont déjà développées (voir par exemple les sur la MIB générale, et le sur la MIB
de gestion des batteries). EMAN n'est donc pas une nouvelle pile
protocolaire complète (cf. section 5), il s'appuie sur
TCP/IP et sur les protocoles de gestion de
réseaux standard (cf. ).
Et les scénarios d'usage promis ? Ils figurent en section 2 de
notre RFC. Je ne vais pas tous les reprendre
ici mais certains sont rigolos. On trouve des routeurs dont on veut mesurer la
consommation, des commutateurs qui sont
eux-même distributeurs d'énergie (PSE Power Sourcing
Equipment, par exemple via PoE,
cf. ), etc. Dans ce dernier cas, celui où des
machines sont alimentées via un équipement réseau, il y a deux
sous-cas : soit la machine est elle-même capable de faire du EMAN,
donc d'informer sur sa consommation électrique elle-même (elle est un
« Energy Object »), soit elle ne
l'est pas et le PSE va alors devoir le faire pour elle. Et si la
machine tire du courant d'une prise au mur ? Là encore, deux sous-cas,
l'alimentation électrique peut être un PDU (Power
Distribution Unit) « intelligent », capable de transmettre
les informations lui-même, soit ce n'est pas le cas et il faudra
alors que la machine alimentée soit capable de transmettre les informations à la gestion de
réseau (un PC n'aura pas de mal, un objet plus
simple si). Voir aussi la section 2.5 sur cette notion d'intermédiaire
de mesure, le Mid-level Manager.
Il y a déjà partout des compteurs
électriques, soit intégrés aux PDU, soit autonomes, et qui mesurent la consommation. Un des enjeux
d'EMAN est de les rendre interrogeables à distance (section 2.4).
Prenons maintenant le cas d'un immeuble de bureaux ou d'une usine,
doté d'une grosse alimentation électrique, gérée par des
professionnels. De tels systèmes (BMS, Building Management
System) sont évidemment gérés centralement
depuis longtemps, bien avant EMAN, mais en général par des mécanismes
non-standards. La liaison physique avec les équipements se fait
souvent en RS-232 ou
RS-485, les protocoles sont
BACnet, Modbus ou
ZigBee.
Plus modeste, la supervision de la consommation électrique à la
maison. On peut vouloir savoir combien son
frigo consomme (le fameux frigo connecté, de
préférence en IPv6, un grand classique du
discours marketing sur l'Internet des
Objets). Beaucoup des équipements à superviser seront sans
doute bon marché, et n'ayant donc pas toutes les capacités EMAN, et
devront donc être interrogés via un relais (le mid-level
manager dont j'ai parlé plus haut).
Au contraire, dans un centre de données, on
a à la fois un enjeu bien plus important (la facture d'électricité de
ces centres est énorme) et davantage de moyens (plein de machines
connectés qui ne demandent pas mieux que d'être gérées à distance
depuis un gestionnaire central). On veut en général une granularité de
mesure très fine (pas juste « ce que consomme cette
armoire » mais « ce que consomme ce serveur »)
donc on va gérer d'importantes quantités de données.
Il ne faut pas oublier les équipements de stockage de l'énergie
eux-mêmes, de la batterie traditionnelle à la
pile à hydrogène. Ces équipements sont
souvent distants (une batterie dans une tour de
télécommunications ou en haut
d'un château d'eau).
Et pour terminer cette liste très variée, n'oublions pas les
humbles imprimantes. En raison de leur
consommation électrique élevée, les imprimantes ont souvent des
dispositifs d'économie d'énergie (mode « veille »). La consommation
varie donc énormément (pensez au chauffage des éléments
thermo-mécaniques comme le cylindre lorsque l'imprimante démarre) et des interrogations
périodiques risquent donc de rater les moments de haute consommation. Les imprimantes haut
de gamme connaissent déjà la gestion à distance et ont souvent SNMP.
Je l'ai indiqué plus haut, EMAN n'arrive pas dans un vide
complet. Il y a de nombreuses années que la consommation électrique
des équipements informatiques
est mesurée et que les machines sont éteintes à distance pour
économiser des joules. La section 4 de notre
RFC couvre les normes et spécifications techniques existantes (je ne
les reprends pas toutes ici, il y en a beaucoup). Ainsi,
la CEI a toute une série de normes sur la
gestion de l'électricité, avec notamment un modèle décrit dans
IEC 61850. C'est un modèle qui embrasse
largement, avec une centaine de
classes. La norme IEC 62053 est
également importante et ces normes ont déjà été utilisées dans
EMAN. Proche de IEC 62053,
l'ANSI a sa norme C12
sur les compteurs électriques.
DMTF a aussi son modèle, DMTF DSP1027.
Il existe aussi des normes plus spécifiques, par exemple le
PWG a des normes pour les imprimantes. À noter que la
MIB « imprimante », dans le ,
ne couvre pas la gestion d'énergie. Il y a onze ans, c'était jugé
moins important et peu de travail avait été fait en ce sens à
l'IETF.
Parmi les autres spécifications existantes, on peut aussi citer
ZigBee, élaboré par une organisation privée et
pas une SDO ouverte.
Et, bien sûr, il y a Smart grid (section
4.3.3), le projet coordonné par le NIST. Smart
grid est plus vaste qu'EMAN (il inclut la distribution de l'énergie)
mais moins normatif car c'est plus un projet de coordination que de normalisation.
Un projet important car souvent vu par le consommateur final est
Energy Star,
lancé par le gouvernement états-unien. Il ne
s'agit pas d'une norme technique ou d'un protocole de communication
mais d'un ensemble de bonnes pratiques que devraient suivre les
équipements électriques, notamment en terme d'efficacité
énergétique. Aujourd'hui, EMAN et EnergyStar sont deux efforts séparés
mais, dans le futur, EnergyStar pourrait référencer EMAN pour inciter
les fabricants à doter leurs systèmes de capacité de mesure.
La section 5 de notre RFC rappelle quelques limites
volontaires d'EMAN : EMAN ne cherche pas à résoudre tous les problèmes
de l'électricité. Par exemple, EMAN ne couvre pas la production et le
transport de l'électricité, seulement sa consommation chez les
utilisateurs finaux.
Enfin, pour terminer ce RFC, n'oublions évidemment pas la sécurité, avec la section 6,
qui rappelle notamment que la mesure de la consommation électrique
peut poser de sérieux problèmes de protection de la vie
privée. (On pourra déterminer à distance vos habitudes à
la maison, par exemple. La NSA saura quand vous
avez des insomnies et allumez la lumière en pleine nuit.) Le , dans sa section 10, détaille ce risque.