Je confirme qu'il est possible de doubler l'alimentation venant du plafond, pour les serveurs qui consomment beaucoup (notamment les serveurs avec de nombreux GPU intégrés), si 32 A est insuffisant.

On rajoute sur la gaine à barre un second boitier de ce type :

À l’intérieur, on retrouve un disjoncteur de 32 ampères, de quoi superviser ce disjoncteur et deux fusibles pour protéger le dispositif de supervision :

On optimise à mort tout ce qui concerne le refroidissement et la consommation électrique liée, mais ne faudrait il pas se poser les bonnes questions sur les fondamentaux ? On récupère un bâtiment existant surement pour économiser 3 ronds (et peut être aussi pour ne pas artificialiser une nouvelle surface). Mais y'a t'il eu un vrai travail d'isolation thermique ?

On se moque pas mal de l'isolation thermique pour un datacenter. Imagine, les équipements informatique produisent plus de 1000W au m². Des calories qu'il faut évacuer. Quand il fait froid dehors, on se moque bien de l'isolation. Quand il fait chaud dehors, c'est effectivement judicieux d'avoir une bonne isolation, mais ça n'est pas prioritaire dans la conception du datacenter.

Et aussi s'interroger sur la localisation de ces datacenter. Ca me semblerait plus logique que les nouvelles installations se fassent dans des pays très au nord. Ou bien si on veut absolument les conserver sur notre territoire, ne vaudrait il pas mieux privilégier des sites en altitude afin de bénéficier d'une température extérieure plus clémente qu'en plaine ?

En altitude, en France, tu vas avoir du mal à installer un tel site industriel à mon avis. Il faut un réseau électrique fiable, redondant, et une bonne densité de fibre autour.
Beaucoup de datacenters s'implantent dans des pays "froid", Suède, Norvège, Canada, oui, c'est déjà le cas. Mais certains usages ont besoin d'une latence faible vers les utilisateurs finaux ou vers d'autres serveurs déjà implantés en France.

Après à un moment donné, va falloir se pencher sur les services que ces datacenter hébergent. Et légiférer pour classer ces services selon leur niveau d'importance. Le 24/7 ne devrait être réservé qu'à des services stratégiques. Si par exemple Twitter ou Facebook ou je ne sais quelle merde de RS tombe pendant 4h, ca va vraiment poser un problème a part aux influenceurs débiles ?

Ces datacenters hébergent beaucoup plus que des "réseaux sociaux". Énormément d'entreprises vivent grâce au "numérique", directement  (c'est leur business premier) ou indirectement.

Sinon, je suis tout aussi partagé que toi entre admiration et "critique" sur cette débauche d'énergie dans les datacenter.
Ce qui m'a toujours dérangé avec les datacenters "green" (greenwashing), c'est qu'ils communiquent sur l'efficacité de tout ce qui est autour des "équipements IT" (serveurs/routeurs). Mais une fois qu'on est arrivé à un rendement correct de toute cette partie "autour des équipements IT" (PUE 1.2 ou en dessous), on se rend compte que ça n'est pas ça le plus important. Le plus important c'est d'arrêter cette débauche de serveurs qui se tournent les pouces avec une charge CPU faible. Le plus important, c'est de coder des architectures de "système d'information" qui soient efficaces. De coder en pensant toujours aux ressources consommée, en les optimisant (CPU, RAM, bande passante). C'est de choisir les composants les plus efficaces énergétiquement (processeur ARM, accélération matérielle).

Leon.

Fansat, la facon de travailler que tu décris n'est pas morte, regarde du côté de l'embarqué (microcontroleurs hein, pas des cortex A-12)

Je pense que la facon de développer en assemblant des briques dont tu parles ne date pas d'hier. Quand j'ai commencé à coder il y a ~15 ans, c'était déjà le cas avec Java et Maven, et maintenant c'est surtout dans le dev Web qu'on voit ce genre de choses, à tel point que le quidam lambda revient aux applications natives car "l'internet, c'est lent".

C'est selon moi surtout une question de management qui a mené à ce genre de pratiques : les project managers ont une pression de vélocité et de coût importante, et sortent pour la grande majorité d'écoles de management dans lesquelles on apprend beaucoup de choses, certes, mais pas la technique (ni même les bases de la culture scientifique, dans mon expérience).
Donc il faut SCRUM, Jira et que les développeurs fassent des petits tickets. Si le Kanban ne montre pas un indicateur de vélocité pour l'équipe au plus haut, on ne cherche pas à comprendre quel problème était dur à résoudre, on va assigner "le ticket" à "une ressource" d'une autre équipe pour que ca aille plus vite.
On sépare les équipes responsables de la sécurité applicative et de la protection des données des équipes de dev, car elles ont des objectifs fixés par leurs hiérarchies diamétralement opposées (l'une doit aller vite pour qu'on puisse vendre, l'autre est une assurance sur le long terme).

J'ai vu des mecs satellisés d'équipes de WebDev (un métier avec ses nombreux problèmes, certes, mais dans lequel je ne suis qu'amateur) pour tenter de faire de l'embarqué car il fallait "une ressource en plus".
Je bossais avec l'un d'entre eux, j'ai passé plus d'un mois à tenter de lui faire comprendre que pour piloter des groupes froids de plusieurs centaines de kW, on avait besoin que le code soit robuste, et qu'on pouvait pas dire à l'utilisateur (quel utilisateur?) qu'il fallait "vider le cache et recharger la page".

Ce n'est que peu étonnant de voir le même management dire "si il faut 2-5x plus de serveurs pour contourner le bug, c'est pas grave, ca sera moins cher que de développer un fix".
Bref, pour moi, le souci dans "DSI" a toujours été le "D". Fin du HS

Pour en revenir au sujet (plus intéressant!), quand je bossais dans le datacenter il y a une bonne dizaine d'années, on estimait qu'environ 10% des serveurs allumés dans nos parcs étaient "oubliés" par nos clients. En creusant un peu chez un client, j'ai compris que ca fonctionnait comme cela :
- un sysadmin a besoin d'un (ou de plusieurs) serveurs, il en fait la demande.
- 6 mois plus tard, les achats se saisissent de la demandent et approuvent (note qu'ils n'ont souvent même pas à procurer le serveur eux-même, le sysadmin peut l'avoir de lui-même en deux clicks si on l'y autorise)
- l'OS pré-installé n'est pas le bon (trop récent), la boite impose soit RHEL 4 (!) soit une version exotique de windows 2000 (la "souche logicielle" approuvée). Il faut faire une demande spécifique à l'infrastructure provider car cet OS n'existe plus dans les images proposées, et d'ailleurs, fournir une licence pour ledit OS.
- retour aux achats, obtention d'une licence, envoi de la licence au fournisseur d'infrastructure, etc. etc.
- 8 à 10 mois après, le gars dispose de son serveur et peut  commencer à y installer ses applis.

Bien évidemment, le sysadmin avait la pression pour rajouter un serveur de base de données ASAP et se fait taper dessus car il est 10 mois en retard.
Il commande donc un nombre de serveurs en avance pour en avoir sous le coude le vendredi soir à 7pm quand les alertes "server low on disk space" arrivent sur son téléphone, si il n'est pas parti de désespoir entre temps.

Le serveur reste dans le rack, touours allumé (quand j'éteignais les machines dont je n'avais pas besoin, les techs du datacenter les rallumaient lors de leur ronde de maintenance), à dissiper une centaine de watts à se tourner les pouces.

Un jour, le sysadmin part. Personne n'ose toucher à ces serveurs car "ils pourraient servir à quelque chose, mais je ne sais pas quoi". Trop risqué de l'éteindre.

Le fournisseur d'infrastructure n'a rien à gagner à inciter ses clients à les rendre : il réduirait son CA. De toute facon, même avec un paquet de serveurs qui se tournent les pouces, le client paye touours moitié moins (parfois 10x moins) que s'il était sur AWS, donc pas de risque de le perdre.

Ce post est déjà bien assez long pour que j'aborde le côté applicatif...

T'as 15 ans d'avance, je me couche.

Il y aurait même des enfoiros qui prétendraient que le Saint Patron du Dev moderne serait un certain Hermann... Peut-être pour la daube? Ok, je sors! 

on commence a voir dans les marchés publics des contraintes d'efficience sur les datacenters, mais aussi sur l'optimisations du code... mais vu qu'entre la partie IT qui est sensibilisé, les achats, la comm', les politiques, il n'y a pas les mêmes enjeux, volonté, échelle temporelle, ca va mettre du temps avant de vraiment aboutir à des choses intéressantes et contraignantes xD