Le datacenter le moins efficace du monde

Ce que vous construisez

Chaque guide de ce site vous apprend à faire quelque chose correctement : les commandes dans l'ordre, à quoi ressemble un résultat correct, les modes de défaillance nommés. Ce guide est différent. Aujourd'hui, de façon entièrement hypothétique, nous allons concevoir le datacenter le moins efficace que l'argent, l'électricité et l'orgueil puissent produire.

Il nous faut une métrique, alors nous emprunterons celle du secteur : le PUE, Power Usage Effectiveness (efficacité de l'utilisation de l'énergie), la puissance totale de l'installation divisée par la puissance qui atteint réellement l'équipement informatique. Un datacenter à très grande échelle tourne autour de 1,1 : presque chaque watt fait un travail utile. Une salle serveur d'entreprise correcte atteint 1,5. Notre objectif est de 4,0 ou plus, ce qui signifie que pour chaque watt de calcul, trois watts de plus meurent pour rien. Nous ferons souvent référence à ce chiffre, comme les guides sérieux font référence aux sauvegardes.

Choix du site : la chaleur, c'est le but

Le refroidissement est le plus gros poste de dépense dans un vrai datacenter, c'est pourquoi le nôtre combattra la thermodynamique sur son propre terrain. L'emplacement idéal est un grenier. Exposé au sud. Idéalement avec une lucarne positionnée pour briller directement sur le serveur, afin que la machine reçoive à la fois sa propre chaleur perdue 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 vrais datacenters utilisent bien l'air extérieur : la technique s'appelle le free cooling (refroidissement gratuit), et elle est étudiée, filtrée et régulée en humidité. Nous l'utiliserons par accident, à travers une fenêtre qui laisse aussi entrer la pluie, le pollen et au moins un oiseau désorienté par trimestre.

Pour un vrai raffinement, installez un climatiseur, puis placez un radiateur d'appoint à soixante centimètres de son thermostat, réglé deux degrés plus chaud que la cible du climatiseur. Les deux machines vont désormais fonctionner en continu, pour toujours, en désaccord parfait. La compagnie d'électricité vous enverra une carte à Noël.

Un serveur, grand, adoré

La redondance dilue l'engagement. Notre datacenter contient exactement un serveur, et il est énorme, parce qu'une seule machine avec 512 Go de RAM ressemble à une infrastructure, alors que quatre petites ressemblent à une liste de tâches.

Le serveur a un nom. Pas un hostname, un nom. Gandalf, en général, ou Odin. Vous ne pouvez pas mettre Odin hors service. Odin est en fonctionnement depuis cinq ans :

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

Ce nombre est un sujet de fierté, c'est pourquoi vous en faites une capture d'écran et la publiez, et c'est pourquoi chaque attaquant qui voit la capture la trouve tout aussi impressionnante : 1 847 jours de fonctionnement, cela signifie 1 847 jours de vulnérabilités du noyau, corrigées par personne. Redémarrer est de toute façon hors de question : un redémarrage, c'est la façon de découvrir quels services ont été démarrés à la main en 2021 et jamais écrits dans une unité systemd. Personne ne se souvient lesquels. Le serveur est désormais porteur dans l'organigramme.

Stockage : la vitesse, et d'autres façons de perdre des données

Les disques sont configurés en RAID 0, pour la performance. Le zéro désigne le nombre de disques qui peuvent tomber en panne. Pour un effet maximal, répartissez la grappe sur du stockage d'origines diverses : deux vrais SSD, un disque à plateaux vieillissant et une clé USB récupérée à une conférence. La grappe est exactement aussi fiable que la clé de conférence, ce qui est le principe même de la conception.

Les sauvegardes sont assurées par un répertoire situé sur la même grappe, nommé backup_final_v2_REAL, qui contient une archive tar de l'ancien schéma de nommage. Les sauvegardes hors site sont représentées par un post-it indiquant « configurer les sauvegardes hors site », qui est, techniquement, stocké hors site quand vous le ramenez chez vous sur le couvercle de votre portable.

Un résultat correct ressemble à ceci : df qui indique 97 % d'utilisation, et un plan pour s'en occuper au prochain sprint.

Réseau : un seul brin de tout

Le serveur DNS tourne sur la machine elle-même, de sorte que lorsque le serveur tombe, il emporte avec lui l'enregistrement DNS que vous utiliseriez pour découvrir pourquoi. On appelle cela la consolidation.

Le pare-feu a été désactivé en 2021, temporairement, pour déboguer quelque chose. Le débogage s'est terminé ; le pare-feu, lui, n'est pas revenu. Chaque port du routeur est redirigé vers le serveur « pour gagner du temps plus tard », et le panneau d'administration du routeur est accessible depuis le côté WAN avec son mot de passe d'usine, pour une gestion à distance pratique. La vôtre, et celle des autres.

Le serveur chauffe anormalement ces derniers temps, même selon les standards d'un grenier, et top montre 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 tout seul peu après la redirection des ports, ce que nous prenons comme le signe que l'écosystème est florissant. Il supervise vingt-quatre heures sur vingt-quatre.

L'alimentation arrive par une chaîne de multiprises grand public dont la longueur cumulée dépasse la distance à parcourir jusqu'au tableau électrique, ce qui est efficace, dans un sens, parce que vous rendrez souvent visite au tableau électrique.

La redondance par la complexité

Ayant refusé la redondance là où elle compte, nous l'ajoutons maintenant là où elle ne compte pas. La page d'accueil de l'entreprise, un unique fichier HTML statique, est servie par un cluster Kubernetes de douze nœuds. On obtient ainsi ce que les ingénieurs appellent l'architecture pilotée par le CV : la page se charge en les mêmes quarante millisecondes que nginx aurait fournies, mais elle peut désormais tomber en panne de façons qui nécessitent un consultant.

Pour l'isolation, le cluster lui-même tourne 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 porteur et personne ne sait lequel.

Le chauffage en tant que service

Un serveur moderne convertit l'électricité en calcul et en chaleur, et nous comptons maximiser la seconde sortie. Un serveur multimédia sans GPU est le grand classique : le transcodage CPU d'un seul flux 4K va saturer seize cœurs et réchauffer une petite chambre, un radiateur d'appoint qui passe aussi des films. L'opérateur ambitieux passe au niveau supérieur en faisant tourner un grand modèle de langage sur CPU, un radiateur d'appoint de 70 milliards de paramètres avec une API, produisant des tokens à un rythme qu'il vaut mieux mesurer par saison.

La supervision se surveille elle-même

L'observabilité compte, alors nous déployons un moniteur de disponibilité auto-hébergé, sur le serveur même qu'il surveille. Quand Odin meurt, le moniteur meurt avec lui, et voici la partie élégante : aucune alerte ne se déclenche. Pas d'alertes signifie pas d'incidents. Pas d'incidents signifie une disponibilité parfaite, telle que mesurée. Le rapport mensuel n'a jamais été aussi beau.

Les e-mails d'alerte, pour être complet, sont relayés par un serveur de messagerie qui tourne lui aussi sur Odin. Le pipeline d'alerte est donc entièrement autonome, à la manière d'un serpent qui se mange la queue est entièrement nourri.

La partie gênante

Voici la section que je repoussais. Rien de tout cela n'est de la fiction. Le serveur adoré et irremplaçable, le RAID 0 avec les sauvegardes sur le même volume, le pare-feu désactivé « temporairement », le cluster Kubernetes qui sert une seule page, la supervision qui se surveille elle-même : j'ai vu chacune de ces choses en production. Certaines, je les ai vues cette année. Une ou deux, à mes débuts, je les ai construites.

À quoi ressemble la véritable efficacité, c'est ennuyeux, et c'est pourquoi elle perd l'argument sur l'instant et le gagne sur une décennie : un PUE auquel vous ne pensez jamais parce que quelqu'un d'autre l'a conçu. Des machines dimensionnées à leur charge de travail plutôt qu'à l'image que leur propriétaire a de lui-même. Un rayon d'impact, envisagé avant l'explosion. Des sauvegardes testées en les restaurant, selon un calendrier, avec un rappel dans l'agenda et sans héroïsme. Une redondance qui est ennuyeuse : deux exemplaires du truc bon marché valent mieux qu'un seul du truc magnifique, à chaque fois, dans chaque panne pour laquelle j'ai jamais été réveillé.

Et le datacenter le plus efficace que vous puissiez faire tourner est celui que vous ne faites pas tourner. Un VPS confie l'alimentation, le refroidissement, la redondance et les pannes matérielles de 3 h du matin à des gens qui font tout cela à grande échelle, de façon ennuyeuse, ce qui est le plus beau compliment qu'une infrastructure puisse mériter, et il vous laisse la partie réellement amusante, qui consiste à faire tourner vos propres services par-dessus, sur une machine que vous pouvez vous permettre de perdre, la seule sorte sur laquelle vous devriez jamais expérimenter.

FAQ

Dois-je réellement faire quoi que ce soit de tout cela ?

Non. Chaque section de ce guide est un anti-modèle documenté au prix de plusieurs week-ends perdus. Si votre configuration actuelle ressemble à plus de deux sections, passez directement à la dernière question de cette FAQ, dans l'ordre donné, parce que l'ordre est le tri.

C'est quoi un bon PUE, concrètement ?

Les datacenters à très grande échelle tournent autour de 1,1, une salle d'entreprise bien gérée atteint 1,4 à 1,6, et un placard non refroidi avec une querelle de radiateur d'appoint peut réellement dépasser 3. Vous ne pouvez pas rivaliser sérieusement avec 1,1 à la maison, ce qui est l'argument économique discret en faveur de la location de calcul auprès de quelqu'un qui le peut.

Chauffer un bâtiment avec des serveurs, c'est vraiment une chose ?

Oui, fait correctement. Des projets de chauffage urbain dans plusieurs pays récupèrent la chaleur perdue des datacenters au moyen d'échangeurs de chaleur et l'acheminent vers les logements, par conception, avec de l'ingénierie et des contrats. La satire ci-dessus ne porte pas sur le fait que la chaleur d'un serveur peut réchauffer une pièce ; elle porte sur le fait de le faire par accident et d'appeler cet accident une stratégie.

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

Des sauvegardes, ce soir, vers un endroit qui n'est pas le serveur, puis une restauration de test : une sauvegarde non testée n'est qu'une rumeur. Ensuite, les correctifs et le redémarrage que vous évitez, dans une fenêtre planifiée, pour apprendre ce qui casse pendant que vous regardez. Troisièmement, séparez le point unique de défaillance : déplacez le DNS et la supervision hors de la machine. Tout le reste peut attendre une semaine plus calme ; ces trois-là ne le peuvent pas.