Le PUE (Power Usage Effectiveness), un indicateur valable de mesure « Green IT » pour le Cloud ?

 

Image : Pixabay 

Qu’est-ce que le PUE ?

L’acronyme n’est pas de plus connu dans le monde de l’IT. Il doit commencer à l’être par les experts datacenters. Mais par les temps qui courent, il risque d'être mis sur le devant de la scène.  

L’IT pèse de plus en plus lourd sur le front des émissions de gaz à effet de serre (GES), et le stockage de l’information en a une part non négligeable. La Commission Européenne a chiffré à 76,8 TW/H la consommation des datacenters en Europe, soit 2,7% de la demande électrique de l’UE, avec une projection à 100 MW/H en 2030, soit une progression de 28%. 

En ce temps de basculement massif des infras vers le cloud, il était important de définir les éventuels bénéfices de ce mode de stockage également selon une approche « Green IT ».

Le PUE est défini en divisant la quantité d’énergie nécessaire à faire tourner un datacenter, et l’énergie nécessaire pour faire fonctionner l’ « équipement » qu’il contient : 



L’énergie nécessaire au fonctionnement des serveurs étant relativement intangible lorsque l’équipement est récent, les gestionnaires de datacenters auront intérêt à se concentrer sur l’efficacité énergétique de l’infrastructure. C’est une indicateur clé, pas le seul évidemment, pour permettre aux gestionnaires de datacenters de monitorer l’efficacité de l’infrastructure.

Dans la puissance totale de l’installation, on trouvera :

  • Le matériel du datacenter,
  • Les composants d'alimentation électrique,
  • Les systèmes de refroidissement,
  • Les systèmes d'éclairage,

 Dans l’énergie nécessaire aux équipements informatiques, on trouvera :

  • L'énergie utilisée pour alimenter les équipements de stockage,
  • L'équipement de mise en réseau,
  • Les équipements de contrôle, 
  • ….

La conduite la plus évidente à adopter sera de tenter de faire baisser le numérateur, et donc l’énergie nécessaire à faire fonctionner l’installation :

  • En améliorant les systèmes de refroidissement,
  • En recourant à un éclairage économe,
  • En remplaçant le matériel obsolète,
  • ….

 Mais à notre sens, c’est surtout la marche vers la Cloud qu’il faut promouvoir, et surtout vers certains Clouds. 

Le Cloud et son "bon" PUE, quoique variable. 

Les hyperscalers (dont les datacenters excèdent souvent les 5000 servers : Azur, Google Cloud, AWS essentiellement), ont des scores de PUE qui avoisinent les 1. D'autres Cloud providers sont nettement moins vertueux, et la plupart des data centers sont entre 1,6 et 1,8 (cf « Vertiv. »).  

C'est extrêmement difficile à calculer, mais le PUE d'une infrastructure "on prem", compte tenu de la taille de l'installation et du socle de moyens qu'il faut nécessairement mettre en oeuvre, est mécaniquement infiniment supérieure.

Il en ressort que l’énergie nécessaire pour une infra on prem' à iso niveau de service a été calculée à X 100 par un collectif (ASHRAE technical Commitee 9.9). 




L’essence de l‘engouement pour le Cloud dans les entreprises, c’est à la fois l’immense plasticité d’une infra Cloud,  sa mise en œuvre ne nécessitant (presque) aucun effort, et
 donc une efficacité energétique infiniment supérieure, surtout s'il s'agit d'hyperscalers !  

Alors pourquoi certains tardent encore à migrer ?

Les entreprises des plus anciennes ont des legacy system on prem’ des plus compliqués. Elles ont parfois des héritages mainframe avec du cobol, du DB2, des bases de données Oracle avec du PL/SQL qui a foisonné…. Ces architectures sont inextricablement liées à l’ERP, au CRM, ou au core system de l’entreprise. Et de l’autre côté du scope, il y a des myriades d’outils dont on sait plus très bien s’ils servent ou pas.   

Pour aller de façon efficace vers le Cloud, l’enjeu pour ces entreprises sera double :

  • Avoir une vision de ce qui sert ou pas, afin de procéder à des décommissionnements massifs, une des pierres angulaires de la préparation d’une migration, 
  • Avoir une vision granulaire des processus de transport / transformation de la donnée dans les legacy systems. 

1- En effet, la compréhension fine des chaînes de traitement de données associée à l’analyse de logs permettra de détecter les branches mortes pour simplifier les architectures sources. Ainsi il n’y aura plus qu’à « déménager » vers le Cloud ce qui doit l’être vraiment. En tous les cas, c'est une bonne première étape.  

2- Par ailleurs, la compréhension fine des chaînes de traitement de données permettra aussi de reconstruire très simplement des flux à l’identique dans le Cloud. La difficulté sera donc d’opérer un parsing (=scan) technique qui permettra de déconstruire la complexité (= « reverse engineering »), puis de reconstruire les flux dans le Cloud (Big Query pour Google, Redshift pour Amazon, Azure SQL pour Azure…).  Ce peut être fait de façon quasi automatisée en « traduisant » le code sources en SQL  générique, et en y associant des scripts spécifiques pour reproduire les subtilités du code source.

Il restera beaucoup de choses à faire, mais notre propos est de dire que les techniques actuelles d'introspection des systèmes en place permettent  de mettre en oeuvre des projets de cet ordre là, même si a priori ils paraissent excessivement complexes. Le jeu en vaut sûrement la chandelle.  

 Conclusion

Nous pensons que le Cloud est accessible à tous les types d’entreprises, même celles qui sont lestées par un legacy system a priori inexpugnable. Il faudra préalablement analyser simplifier son legacy avec des outils, et pas avec la méthode "papier / crayon".  Ce sera un véritable vecteur de modernisation du système d’information, mais aussi un step vers une amélioration du « Power User Effectiveness » réel de l'entreprise. Les PUEs sont également variables d'un Cloud provider à l'autre, et l'ambition écologique doit peser dans votre choix, car ce sera une contribution factuelle à la baisse des GES de chacun. 

 #greenIT #itdebt 

ellipsys@ellipsys-bi.com 

www.ellipsys-bi.com 


Commentaires

Posts les plus consultés de ce blog

La Data Observabilité, Buzzword ou nécessité ?

BCBS 239 : L'enjeu de la fréquence et de l'exactitude du reporting de risque

Le data lineage, l’arme idéale pour la Data Loss Prevention ?