Mon blog

L'augmentation considérable des coûts de l'énergie, et la montée plus que justifiée des préoccupations écologiques, fait que la question de la consommation énergétique des équipements informatiques devient de plus en plus cruciale (certaines études estiment que la consommation d'énergie de l'Internet dépasse celle d'un pays comme la Russie). Les gros centres de données du nuage, usines à consommer du mégawatt, sont particulièrement visés. Cela a amené l'IETF à se lancer dans un domaine nouveau pour elle, et à créer un groupe de travail consacré à la gestion de l'énergie, EMAN, dont voici le premier vrai RFC, le cahier des charges du problème.

Le modèle envisagé est celui d'engins qui consomment ou fournissent de l'énergie, typiquement sous forme électrique, et qu'on veut pouvoir à la fois surveiller (monitoring function) et piloter (control function). Ces engins ont parfois une adresse IP, permettant de leur parler directement, et parfois pas, et il faut alors passer par un relais, qui va être la face visible de l'engin. Ce premier RFC du groupe EMAN définit les services indispensables dans les futures normes de gestion de l'énergie, suivant le modèle décrit dans le RFC 7326 (attention, ce RFC est un cahier des charges pour les normes, les futurs RFC d'EMAN, pas forcément pour les mises en œuvres qui suivront).

La gestion d'engins connectés au réseau n'est évidemment pas un problème nouveau et il existe déjà solutions et normes. Mais la gestion de l'énergie a trois particularités :

• L'information intéressante n'est pas forcément obtenable auprès de l'engin géré. Ainsi, une machine peut être incapable d'indiquer sa consommation électrique, alors qu'on peut l'obtenir en interrogeant le dispositif qui l'alimente en électricité (par exemple un commutateur PoE) Ce genre de demandes indirectes sera fréquent dans le cadre de la gestion de l'énergie.
• Même chose pour le contrôle (allumer ou éteindre l'engin), qui doit parfois se faire indirectement.
• Et rappelez-vous qu'il sera fréquent que les engins connectés ne soient pas directement accessibles en IP et qu'il faille passer par un relais, ce qui est un cas bien plus rare en gestion de réseaux traditionnelle.

Avant d'aborder le cahier des charges proprement dit, la section 2 de notre RFC expose la terminologie, car tous les participants à l'IETF, bien versés dans le vocabulaire TCP/IP, ne connaissent pas forcément celui du monde de l'énergie (l'IEEE a un « Authoritative Dictionary of IEEE Standards Terms » d'où le RFC extrait plusieurs termes, mais je ne trouve pas ce dictionnaire en ligne). Donc, révisons un peu physique et ingéniérie :

• Énergie (Energy) : dans le cadre de l'informatique et des réseaux, c'est typiquement de l'énergie électrique, mesurée en kWh (ne surtout pas écrire kW/h comme on le voit trop souvent).
• Puissance (Power) : le taux d'usage, de production ou de transmission de l'énergie. En kW, parfois en joules par seconde.
• Attributs (Power attributes) : les caractéristiques du courant électrique comme la tension, la phase ou la fréquence. Voir le « International Electrotechnical Vocabulary » de l'IEC.
• Gestion de l'énergie (Energy management) : les fonctions qui permettent de mesurer, modéliser, planifier, optimiser, etc l'énergie.
• Système de gestion de l'énergie (Energy management system) : le matériel et le logiciel qui assurent les fonctions ci-dessus.
• Supervision de l'énergie (Energy monitoring) : le sous-ensemble de la gestion de l'énergie qui s'occupe de mesurer passivement.
• Contrôle de l'énergie (Energy Control) : le sous-ensemble de la gestion de l'énergie qui s'occupe d'agir activement, par exemple en éteignant des machines inutiles.

La section 3 complète cette section 2 de terminologie en exposant quelques problématiques générales, qu'il faut avoir en tête lorsqu'on veut gérer l'énergie. D'abord, la notion d'état (Power state) : un engin peut être en état normal (il fonctionne, il répond et il consomme du courant), endormi (il consomme moins de courant, il ne répond pas aux requêtes normales mais il peut revenir en état normal rapidement) ou éteint (il ne consomme plus rien mais peut prendre un certain temps à se rallumer et à redevenir opérationnel). Les engins les plus simples n'ont que deux états, allumé et éteint. Les plus perfectionnés en ont plus que trois : par exemple, ils peuvent avoir des modes de basse consommation où l'engin reste complètement opérationnel mais avec des performances réduites. Sur des engins composés de plusieurs parties relativement indépendantes, il est parfois possible de couper le courant dans une partie de ces sous-ensembles et pas seulement dans l'engin entier.

Le but ultime de la gestion de l'énergie est d'économiser du courant. Comme rien n'est parfait en ce bas monde, cela se fera souvent au prix d'un service moins bon. Il sera donc en général nécessaire de faire des compromis.

La gestion de l'énergie peut être entièrement locale (à l'intérieur de l'engin lui-même) ou bien globale au réseau. Un exemple de gestion locale est une machine qui se met en sommeil automatiquement lorsqu'elle n'a pas eu d'activité depuis N minutes. Cela peut se faire sans réseau, sans collecter l'information et sans système central. Un exemple de gestion globale est un système qui voit que la consommation électrique du réseau devient trop importante (en coût ou, tout simplement, par rapport aux capacités du fournisseur d'énergie) et qui éteint alors autoritairement certains engins. Le système de gestion ayant plus d'informations que les machines locales, il peut prendre des décisions plus appropriées, et tenir compte de politiques globales (on éteint les machines dans le bureau la nuit). Les deux méthodes ont leurs avantages et leurs inconvénients et, en général, on combine les deux.

À noter (section 3.4) que la supervision de la consommation d'énergie, à elle seule, ne diminue pas la consommation. Elle va même l'augmenter, puisque le système de supervision consomme lui-même du courant. Pour que ce système mène à une diminution de la consommation, il faut aussi qu'il soit utilisé pour chercher les économies possibles, évaluer les mesures de réduction de consommation, assurer la comptabilité de chaque entité, etc.

Pour assurer une bonne supervision, avec une granularité permettant cette comptabilité, il va falloir des identificateurs pour désigner les différentes entités (section 4). Une entité peut être une machine ou bien seulement une partie d'une machine (un disque dur, par exemple, ou bien une line card). En effet, certaines mesures d'économie d'énergie peuvent être à ce niveau de détail (éteindre une seule line card). Il existe déjà de tels identificateurs, par exemple dans les MIB des RFC 4133 et RFC 3621. Il faudra donc lier les informations de gestion de l'énergie à ces identificateurs, traitant des problèmes comme la persistence en cas de redémarrage.

Ensuite, il faut connaître, pour chaque entité supervisée et/ou contrôlée, un certain nombre d'informations (section 5). Par exemple, il est préférable de connaître l'importance d'une entité, pour éviter d'éteindre une machine importante alors qu'on voulait économiser quelques watts. Une autre propriété utile est l'ensemble des caractéristiques statiques de son alimentation électrique : utilise-t-elle du courant continu ou alternatif, quelle est la tension normale, la fréquence normale (par exemple, 230 V à 50 Hz), etc. Il faut aussi connaître la liste des interfaces utilisées pour l'énergie, et s'il s'agit de production (power outlet, par où on envoie de l'énergie) ou de consommation (power inlet, par où on reçoit de l'énergie).

Et il y a des caractéristiques dynamiques :

• Est-ce que le courant est disponible sur la prise ? Est-il utilisé ? Si oui, quelle est la puissance consommée ou produite en ce moment ? Attention, ce dernier point peut nécessiter des équipement de mesure coûteux. Certaines machines ne vont pas être capables de mesurer précisement leur propre consommation.
• Et la consommation ou production d'énergie (rappel : l'énergie est la puissance multipliée par le temps) ? Que vaut-elle sur un intervalle de temps donné ?
• Pour faciliter les alarmes, le RFC suggère aussi que la machine soit capable de signaler que la puissance tombe en dessous d'une certaine valeur, ou grimpe au-dessus d'un maximum.
• Quelles sont la tension et l'intensité actuelles ?
• Quel est l'état de la machine supervisée, allumée, éteinte, en basse consommation, en veille ? Et quels sont les états possibles (ils ne sont pas les mêmes pour toutes les machines) ? Là encore, pour les alarmes, un mécanisme de notification non sollicitée, permettant d'être informé des changements d'état, est demandé.
• Il y a bien d'autres choses à superviser comme l'état des batteries (en train de se charger ? de se décharger ?), leur charge (pleine ? vide ? à moitié vide ?), mesurée en mAh avec évidemment des alarmes en dessous d'un certain seuil ou comme leur température.

Après la supervision, le contrôle (section 6). Contrairement à la supervision, il est actif. Il s'agit d'agir. Agir sur quoi ?

• Couper ou allumer le courant (le RFC avertit que certains engins peuvent ne pas aimer une coupure brutale et que cette fonction doit donc se faire dans le cadre d'un système de gestion plus général, qui ne prend pas en compte que la consommation d'énergie).
• Faire passer l'engin d'un état (basse consommation, veille, hibernation, etc) à un autre.

Une section 9 détaillée couvre les problèmes de sécurité. On a beaucoup parlé des risques de sécurité des SCADA, souvent connectés à l'Internet sans réflechir. Ces systèmes de contrôle, souvent anciens et n'ayant pas fait l'objet d'une analyse de sécurité sérieuse, sont parfois reliés à ce réseau mondial sans précautions. Contrôler l'état des machines et leur fourniture d'électricité est clairement une fonction très sensible. La sécurité doit donc être soigneusement pesée. Tout doit être authentifié et autorisé. Et les engins qui mettent en œuvre les services décrits dans ce RFC ne devraient pas être connectés à l'Internet public sans une très bonne raison (section 9.2).

Il n'y a pas que le contrôle qui pose des problèmes de sécurité. Par exemple, la supervision soulève des problèmes de vie privée, comme cela a été plusieurs fois évoqué dans le débat sur les compteurs intelligents.

Depuis ce cahier des charges, plusieurs RFC sur le sujet ont été publiés comme les RFC 7326 et le RFC 7603.