Guide du datacenter le moins efficace au monde

Ce que vous allez construire

Chaque guide de ce site vous apprend à effectuer correctement une tâche : les commandes dans le bon ordre, l’apparence d’un résultat correct et les modes d’échec identifiés. Ce guide est différent. Aujourd’hui, dans une situation entièrement hypothétique, nous allons concevoir le datacenter le moins efficace que l’argent, l’électricité et la démesure puissent produire.

Nous avons besoin d’une métrique. Nous allons donc reprendre celle du secteur : la PUE, ou Power Usage Effectiveness, qui correspond à la puissance totale de l’installation divisée par la puissance qui parvient réellement aux équipements informatiques. Un datacenter hyperscale affiche une PUE d’environ 1.1 : presque chaque watt produit un travail utile. Une salle serveurs d’entreprise correctement conçue atteint 1.5. Notre objectif est d’atteindre 4.0 ou plus. Cela signifie que pour chaque watt utilisé par l’informatique, trois watts supplémentaires sont dépensés sans produire le moindre résultat. Nous ferons souvent référence à ce nombre, comme les guides sérieux font référence aux sauvegardes.

Choix de l’emplacement : la chaleur est l’objectif

Le refroidissement représente le principal poste de dépense d’un véritable datacenter. C’est pourquoi le nôtre combattra la thermodynamique sur son propre terrain. L’emplacement idéal est un grenier. Orienté au sud. Idéalement, avec une fenêtre de toit placée de manière à éclairer directement le serveur, afin que la machine reçoive à la fois sa propre chaleur résiduelle et celle du soleil : une collaboration entre votre facture d’électricité et une étoile.

En hiver, le refroidissement se fait en ouvrant la fenêtre. Les véritables datacenters utilisent effectivement l’air extérieur. Cette technique s’appelle le free cooling et repose sur une conception adaptée, une filtration et un contrôle de l’humidité. Nous l’utiliserons par accident, avec une fenêtre qui laisse également entrer la pluie, le pollen et au moins un oiseau désorienté par trimestre.

Pour atteindre la perfection, installez un climatiseur, puis placez un chauffage d’appoint à deux pieds de son thermostat et réglez-le deux degrés au-dessus de la température cible du climatiseur. Les deux appareils fonctionneront alors en continu, pour toujours, dans un désaccord parfait. Le fournisseur d’électricité vous enverra une carte à Noël.

Un seul serveur, imposant et irremplaçable

La redondance dilue l’engagement. Notre datacenter contient exactement un serveur, et il est immense, car une seule machine avec 512 GB de RAM ressemble à une véritable infrastructure, alors que quatre petites machines ressemblent à une liste de tâches.

Le serveur a un nom. Pas un hostname, un nom. Gandalf, généralement, ou Odin. Vous ne pouvez pas décommissionner Odin. Odin fonctionne depuis cinq ans :

$ uptime
 09:14:02 up 1847 days,  3:22,  1 user,  load average: 6.41, 6.38, 6.40

Ce nombre fait notre fierté. C’est pourquoi vous en faites une capture d’écran et la publiez. Tout attaquant qui voit cette capture le trouve également impressionnant : 1,847 jours de disponibilité représentent 1,847 jours de vulnérabilités du kernel, corrigées par personne. De toute façon, un redémarrage est exclu. C’est au redémarrage que vous découvrez quels services ont été lancés manuellement en 2021 et n’ont jamais été déclarés dans une unité systemd. Personne ne se souvient desquels. Le serveur est désormais un élément indispensable de l’organigramme.

Stockage : vitesse et autres façons de perdre des données

Les disques sont configurés en RAID 0 pour privilégier les performances. Le zéro désigne le nombre de disques susceptibles de tomber en panne. Pour maximiser l’effet, répartissez l’array sur des supports d’origines diverses : deux SSD fiables, un disque dur vieillissant et une clé USB récupérée lors d’une conférence. L’array est exactement aussi fiable que la clé de la conférence, conformément à la conception.

Les sauvegardes sont gérées par un répertoire nommé backup_final_v2_REAL sur le même array. Il contient une archive tar de l’ancien schéma de nommage. Les sauvegardes hors site sont représentées par une note autocollante indiquant « configurer les sauvegardes hors site ». Techniquement, cette note est stockée hors site lorsque vous la ramenez chez vous collée sur le capot de votre laptop.

Un résultat conforme ressemble à ceci : df indique une utilisation de 97 %, avec un plan pour traiter le problème au prochain sprint.

Réseau : un seul fil pour tout

Le serveur DNS s’exécute sur la machine elle-même. Lorsque le serveur tombe, il emporte donc l’enregistrement DNS qui permettrait de comprendre pourquoi. C’est ce qu’on appelle la consolidation.

Le pare-feu a été désactivé en 2021, temporairement, pour diagnostiquer un problème. Le diagnostic est terminé ; le pare-feu n’a pas été réactivé. Tous les ports du routeur sont redirigés vers le serveur « pour gagner du temps plus tard ». Le panneau d’administration du routeur est accessible depuis le WAN avec son mot de passe d’usine, pour faciliter l’administration à distance. Le vôtre, comme celui d’autres personnes.

Le serveur fonctionne à une température anormalement élevée ces derniers temps, même selon les critères d’un grenier, et top indique que le processus le plus actif s’appelle xmrig. Nous supposons qu’il s’agit de l’outil de supervision que nous utilisons. Nous ne l’avons pas installé. Il est apparu spontanément peu après la redirection des ports, ce que nous considérons comme le signe que l’écosystème fonctionne correctement. Il supervise le système 24 heures sur 24.

L’alimentation passe par une chaîne de multiprises grand public dont la longueur cumulée dépasse la distance à parcourir jusqu’au tableau électrique. C’est efficace, d’une certaine manière, puisque vous vous rendrez souvent au tableau électrique.

Redondance par la complexité

Après avoir refusé la redondance là où elle est importante, nous l’ajoutons là où elle ne sert à rien. La page d’accueil de l’entreprise, constituée d’un seul fichier HTML statique, est servie par un cluster Kubernetes de douze nœuds. Cela produit ce que les ingénieurs appellent une architecture guidée par le CV : la page se charge en quarante millisecondes, comme nginx l’aurait servie, mais elle peut désormais tomber en panne de façons qui nécessitent l’intervention d’un consultant.

Pour l’isolation, le cluster lui-même s’exécute dans une machine virtuelle dans une machine virtuelle dans une machine virtuelle, chaque couche ajoutant de la sécurité comme chaque couche d’un turducken ajoute un oiseau. Le formulaire de contact est composé de neuf microservices. Deux d’entre eux n’ont jamais été appelés. L’un d’eux est indispensable au fonctionnement, mais personne ne sait lequel.

Le chauffage comme service

Un serveur moderne transforme l’électricité en calcul et en chaleur, et nous voulons maximiser la seconde sortie. Un serveur multimédia sans GPU est le cas classique : transcoder un seul flux 4K avec le CPU occupe seize cœurs et réchauffe une petite chambre, comme un chauffage d’appoint qui lit aussi des films. L’opérateur ambitieux passe ensuite à l’exécution d’un grand modèle de langage sur CPU, un chauffage d’appoint de 70 milliards de paramètres avec une API, qui produit des tokens à un rythme qu’il vaut mieux mesurer par saison.

Le moniteur se surveille lui-même

L’observabilité est importante. Nous déployons donc un moniteur de disponibilité auto-hébergé sur le même serveur que celui qu’il surveille. Quand Odin tombe, le moniteur tombe avec lui. Et c’est là que réside toute l’élégance du système : aucune alerte ne se déclenche. Aucune alerte signifie aucun incident. Aucun incident signifie une disponibilité parfaite, selon les mesures effectuées. Le rapport mensuel n’a jamais été aussi bon.

Pour être exhaustifs, les e-mails d’alerte sont relayés par un mail server qui fonctionne également sur Odin. La chaîne d’alerte est donc entièrement autonome, comme un serpent qui se mord la queue et serait ainsi parfaitement nourri.

La partie inconfortable

Voici la section que je repousse depuis longtemps. Rien de tout cela n’est fictif. Le serveur irremplaçable auquel tout le monde tient, le RAID 0 avec des sauvegardes sur le même volume, le firewall désactivé « temporairement », le cluster Kubernetes qui sert une seule page, le monitoring qui se surveille lui-même : j’ai vu chacun de ces cas en production. Certains se sont produits cette année. À mes débuts, j’en ai même provoqué un ou deux.

L’efficacité réelle est ennuyeuse. C’est pour cela qu’elle perd le débat dans l’instant, puis le gagne sur une décennie : un PUE auquel vous ne pensez jamais parce qu’une autre personne l’a conçu. Des machines dimensionnées selon leur charge, et non selon l’image que leur propriétaire veut renvoyer. Un blast radius évalué avant l’explosion. Des sauvegardes testées par une restauration planifiée, avec un rappel dans le calendrier et sans héroïsme. Une redondance sans éclat : deux exemplaires d’un équipement bon marché valent toujours mieux qu’un seul exemplaire magnifique, pour toutes les pannes qui m’ont déjà valu une alerte.

Et le datacenter le plus efficace que vous puissiez exploiter est celui que vous n’exploitez pas. Un VPS confie l’alimentation électrique, le refroidissement, la redondance et les pannes matérielles à 3 a.m. à des personnes qui les gèrent à grande échelle, de manière méthodique. C’est le plus beau compliment que l’on puisse faire à une infrastructure. De votre côté, vous gardez la partie réellement intéressante : exécuter vos propres services au-dessus, sur une machine que vous pouvez vous permettre de perdre. C’est le seul type de machine sur lequel vous devriez expérimenter.

FAQ

Dois-je vraiment faire tout cela ?

Non. Chaque section de ce guide décrit un anti-pattern documenté qui vous coûtera des week-ends. Si votre configuration actuelle ressemble à plus de deux sections, passez directement à la dernière question de cette FAQ, en respectant l’ordre indiqué : c’est l’ordre de triage.

Quel est réellement un bon PUE ?

Les datacenters hyperscale tournent autour de 1.1. Une salle informatique d’entreprise bien gérée atteint 1.4 à 1.6. Un local non climatisé équipé d’un chauffage d’appoint peut réellement dépasser 3. À domicile, vous ne pouvez pas rivaliser efficacement avec 1.1. C’est l’argument économique discret en faveur de la location de ressources de calcul auprès d’un prestataire qui en est capable.

Chauffer un bâtiment avec des serveurs, est-ce une pratique réelle ?

Oui, si c’est fait correctement. Dans plusieurs pays, des projets de chauffage urbain récupèrent la chaleur fatale des datacenters au moyen d’échangeurs thermiques, puis l’acheminent vers les habitations, dans le cadre de projets planifiés, avec une ingénierie et des contrats adaptés. La satire précédente ne porte pas sur le fait que la chaleur des serveurs puisse chauffer une pièce. Elle porte sur le fait de le faire par accident et de présenter cet accident comme une stratégie.

Mon serveur ressemble déjà à cela. Que dois-je faire en premier ?

Commencez par effectuer des sauvegardes, dès ce soir, vers un emplacement qui n’est pas le serveur. Testez ensuite la restauration : une sauvegarde non testée n’est qu’une rumeur. Deuxièmement, installez les correctifs et effectuez le reboot que vous évitez depuis quelque temps, pendant une fenêtre planifiée. Vous verrez ainsi ce qui casse pendant que vous surveillez le système. Troisièmement, supprimez le point unique de défaillance : déplacez le DNS et la supervision sur une autre machine. Tout le reste peut attendre une semaine plus calme ; ces trois actions ne le peuvent pas.