Mon blog

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 RFC 7326 (et le cahier des charges dans le RFC 6988). 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 (RFC 7326) 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 RFC 7460 sur la MIB générale, RFC 7461 et le RFC 7577 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. RFC 6632).

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. RFC 3621), 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 RFC 3805, 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 RFC 7460, dans sa section 10, détaille ce risque.