Comment Railway a construit son propre datacenter
(blog.railway.com)- Railway a estimé que son compute basé sur GCP limitait les prix, le support et le développement de fonctionnalités, et a lancé Railway Metal, une infrastructure physique qu’elle peut contrôler plus directement
- Après un démarrage en janvier 2024, il a fallu 5 mois jusqu’au raccordement du premier serveur, puis 3 mois supplémentaires avant d’y placer des workloads utilisateurs, et le premier site en Californie a été mis en service 9 mois plus tard
- Plus que la location d’espace, les principales contraintes étaient l’alimentation électrique et le refroidissement ; Railway a donc choisi la cage colocation plutôt qu’un greenfield ou une location au rack
- Le réseau repose sur au moins 2 ISP par région, la table de routage complète d’Internet, la sélection de route par préfixe IP et une conception multi-zone pour se prémunir contre la panne d’un datacenter unique
- Il faut gérer directement l’agencement des racks, la documentation du câblage, les PDU, les switchs à airflow inversé, les API Redfish, PXE, FRR et SONiC ; construire son propre cloud ressemble davantage à construire une maison qu’à déployer avec Terraform
Pourquoi passer de GCP à Railway Metal
- Le compute de Railway était construit dès le départ sur Google Cloud Platform
- GCP a aidé pendant la phase de croissance initiale, mais à mesure que l’exploitation a grandi, des limites sont apparues pour fournir aux clients la plateforme souhaitée
- Une exploitation sur un hyperscaler limitait directement les prix, le niveau de service et l’étendue des fonctionnalités que Railway pouvait développer
- les egress fees ont un impact sur les prix
- même lorsqu’un problème vient de l’infrastructure supérieure, il est rare d’en comprendre la cause
- l’entreprise estime que même en dépensant plusieurs millions de dollars par an, le niveau de support ne diffère pas beaucoup de celui d’un client qui dépense 100 dollars
- En réponse, Railway a lancé en 2024 le projet Railway Metal
- 9 mois plus tard, le premier site californien était mis en service
- de la fibre optique dans la cage jusqu’aux contrats ISP, Railway a elle-même conçu, spécifié et installé l’ensemble
- l’entreprise est aussi en train d’ouvrir 3 régions de datacenter supplémentaires
Premier choix d’espace : une cage dans un datacenter
- Le projet Railway Metal a démarré en janvier 2024, et il a fallu 5 mois pour connecter le premier serveur
- 3 mois supplémentaires ont été nécessaires avant d’estimer qu’il était possible d’y exécuter des workloads utilisateurs
- Une infrastructure en propre nécessite un espace pour les serveurs, une alimentation stable et un refroidissement suffisant
- Trois grandes options existaient
- Greenfield buildout : acheter ou louer un datacenter
- Cage Colocation : obtenir un espace dédié entouré de parois grillagées à l’intérieur du datacenter d’un opérateur
- Rack colocation : louer un rack individuel ou une partie de rack dans un datacenter de colocation
- Railway a choisi la cage colocation afin d’obtenir un espace vide avec quatre parois, une porte sécurisée et la liberté de concevoir le reste elle-même
- Le coût de l’espace en lui-même n’est pas énorme, mais les plus gros postes sont l’électricité et le refroidissement qui en découle
- selon la région, le coût par kW varie fortement
- dans l’ouest des États-Unis, il peut être inférieur de plus de moitié à celui de Singapour
- l’électricité est payée sous forme d’engagement mensuel garantissant une disponibilité à la demande, indépendamment de la consommation réelle
Conception de l’alimentation et PDU
- Railway a d’abord défini le nombre cible de vCPU, les Go de RAM et les To de NVMe nécessaires pour correspondre à la capacité utilisée sur GCP
- À partir de là, l’entreprise a choisi les serveurs et les CPU
- La variable clé était la densité de puissance, c’est-à-dire faire tenir la densité de compute souhaitée dans une enveloppe de consommation donnée
- Le calcul électrique ne se limite pas à additionner des watts, et devient plus complexe en triphasé
- l’article de Cloudflare sur l’alimentation triphasée et les PDU couvre ce sujet
- Dans un datacenter, l’électricité est la ressource la plus critique, et une panne de courant peut impliquer un temps de rétablissement très long
- Chaque rack doit disposer de 2 arrivées électriques totalement indépendantes
- en fonctionnement normal, les deux arrivées se partagent la charge
- le rack doit continuer à fonctionner si l’une des deux tombe
- Pour alimenter les serveurs, il faut une Power Distribution Unit
- un PDU de base ressemble essentiellement à une multiprise extensible
- les PDU déployés par Railway permettent le contrôle et la mesure prise par prise
- chaque PDU est accessible via le réseau, avec mesure et contrôle à distance de chaque prise
Réseau : ISP, routage et chemins par région
- Une machine cloud n’existe pas seule ; le réseau joue donc un rôle central
- Railway a recherché des installations de datacenter solidement connectées au monde extérieur afin de réduire la latence
- Les critères privilégiés étaient les suivants
- être on-network avec des ISP Tier 1
- être présent sur un Internet Exchange
- disposer de fibre permettant de rejoindre d’autres datacenters proches
- Les applications déployées sur Railway communiquent avec des endpoints très variés
- un utilisateur résidentiel à Sydney
- une API hébergée sur des serveurs AWS aux États-Unis
- Pour réduire la latence et les coûts de bande passante, Railway contractualise avec plusieurs fournisseurs d’accès Internet optimisés selon les usages
- Les ISP sont choisis en fonction de la maturité du réseau dans la région cible
- travailler avec le mauvais ISP peut ajouter des network hops jusqu’à certains marchés cibles et augmenter la latence
- dans le pire des cas, cela peut produire des chemins réseau inutilement complexes
- dans chaque région, Railway choisit au moins 2 réseaux distincts selon leur footprint local
- Une fois connectée, l’entreprise récupère auprès de chaque ISP la table de routage complète d’Internet, l’agrège sur ses switchs réseau et détermine le meilleur chemin selon chaque préfixe IP
- si un utilisateur australien accède à une application déployée à Singapour, les paquets passeront probablement par Telstra
- si cette même application envoie des paquets vers des utilisateurs ou serveurs au Japon, ils passeront probablement par PCCW
- Les informations de peering sont publiques, et bgp.tools permet de visualiser les interconnexions réseau
- Pour la redondance, Railway construit plusieurs zones au sein de chaque région, et l’interconnexion entre sites est aussi importante pour la montée en charge
- des options comme la dark fiber ou les wavelength services sont étudiées
- l’objectif est qu’une application ne perçoive aucune différence entre une base de données dans la même salle et une base située dans un bâtiment voisin à quatre pâtés de maisons
- cette conception vise à améliorer la résilience face à la panne d’un datacenter individuel
Racks, allées, refroidissement et chemins de câbles
- Dans un datacenter, les racks sont disposés en rangées et les allées entre eux servent à gérer les flux d’air
- Dans la Cold Aisle, l’installation fournit de l’air froid, que les serveurs aspirent avant de le rejeter à l’arrière dans la Hot Aisle
- Pour gagner en efficacité, l’air ne doit pas se mélanger entre la Cold Aisle et la Hot Aisle
- Même si les équipements utilisent un format de 19 pouces de large, les racks peuvent être choisis en hauteur, largeur et profondeur selon les besoins des équipements et du câblage
- La plupart des équipements serveurs peuvent être tirés vers l’avant sur des rails pour la maintenance ; les dimensions de la cage doivent donc le permettre
- Le câblage et sa gestion prennent aussi de la place, ce qui impose un compromis entre remplir les racks au maximum et le nombre de racks qu’on peut placer dans la cage
- D’après l’expérience de Railway, l’alimentation et le refroidissement sont plus souvent limitants que l’espace réel
- Sur les nouveaux sites, Railway a choisi des racks plus larges de 800 mm pour améliorer l’airflow en éloignant les câbles du chemin d’évacuation de l’air
- Au-delà des racks eux-mêmes, il faut aussi une infrastructure et des chemins en hauteur pour transporter l’électricité et les données
- il faut router la fibre depuis le bord de la cage jusqu’à chaque rack
- il faut aussi router les câbles entre les racks
- ces éléments sont parfois inclus par l’opérateur du datacenter dans le devis de la cage
- Railway utilise une forte densité de câbles fibre switch-to-server par rack ; l’entreprise achète donc des switchs à airflow inversé dont les ports font face à l’arrière du rack
- ce sont des switchs qui expulsent l’air du côté où se trouvent les ports réseau
- les chemins de câbles sont alignés pour que tout le câblage se fasse d’un seul côté du rack
- cela évite des câbles qui zigzaguent entre l’avant et l’arrière des racks
Documentation d’installation et rack-and-stack
- Railway a d’abord tenté d’effectuer elle-même le câblage, mais le résultat manquait d’homogénéité ; des spécialistes ont ensuite été mobilisés pour une installation correcte
- Un package documentaire complet est nécessaire pour que les installateurs sachent quoi placer où
- Deux documents sont typiquement utilisés
- Cabling matrix : définit, pour chaque extrémité de câble, l’emplacement de l’équipement, le port, les spécifications du câble, le type de fibre, la longueur, etc.
- Rack elevation : représente visuellement la position et l’orientation de chaque équipement dans le rack
- Chaque phase d’installation chez Railway comprend plus de 60 équipements, plus de 300 câbles individuels et des dizaines de détails à suivre
- Les spécifications écrites et les feuilles de calcul qui servent de base à l’installation et à la mise en service sont produites manuellement
- Une fois le matériel arrivé sur site, il faut environ 6 à 14 jours pour terminer toute l’installation
- Railway a ensuite créé un outil interne pour automatiser la génération des build specifications
- Construire une cage dans un datacenter n’a pas grand-chose à voir avec le déploiement habituel d’un logiciel, d’une stack DevOps ou Terraform ; cela ressemble beaucoup plus à la construction d’une maison
- Les méthodes diffèrent légèrement selon les installations, les prestataires et les fournisseurs, parfois même au sein d’une même organisation, ce qui exige une attention opérationnelle très fine
Exceptions et problèmes physiques rencontrés sur le terrain
- Sur un site, un PDU avait été installé à l’envers, et comme l’alimentation arrivait par le sol, la numérotation prévue des prises s’est retrouvée inversée
- Sur le site d’Amsterdam, l’infrastructure faisait entrer directement la liaison fibre externe dans un boîtier à l’intérieur du rack, au lieu d’utiliser un point de démarcation dédié
- Certaines installations câblaient les prises électriques en phase-to-neutral, alors que d’autres utilisaient du phase-to-phase
- Dans un cas, un prestataire ne savait pas que l’équipement réseau utilisait un reverse airflow et a voulu le monter dans l’autre sens, concluant à tort que les câbles de données étaient trop courts
- Si un lien ne montait pas sur certains câbles, la cause était parfois une erreur de polarité de la fibre ; c’est ainsi que Railway a découvert les « rolling fibre cables »
- il s’agit de retirer les connecteurs d’un connecteur LC pour les inverser
- Environ 24 PDU d’un fournisseur présentaient des défauts de prise : les connecteurs d’alimentation ne s’enclenchaient pas correctement, même en forçant physiquement
Le travail logiciel après l’installation physique
- Une fois le matériel en place, le travail bascule vers un domaine logiciel plus familier
- Les tâches nécessaires incluent
- configuration de BGP
- installation de l’OS
- configuration du monitoring
- configuration des équipements réseau
- rédaction de la configuration des routeurs
- mise à jour des enregistrements du RIR, c’est-à-dire du registre Internet régional
- Railway utilise les API Redfish pour accéder aux contrôleurs dédiés des serveurs et des PDU
- L’entreprise utilise PXE pour démarrer les serveurs via le réseau
- La conception réseau de Railway repose sur des whitebox network switchs exécutant FRR et SONiC
- Cela permet de construire un réseau piloté par logiciel en L3 uniquement, profondément intégré au control plane de Railway
- Ces derniers mois, Railway a développé de nouveaux outils logiciels, Railyard et MetalCP
- conception de nouvelles cages
- suivi et visualisation des câbles
- installation de l’OS des serveurs
- outils permettant une expérience en un clic jusqu’à la mise en ligne des serveurs sur Internet
- Un prochain article expliquera comment transformer un groupe de serveurs dans une salle en une zone Railway pleinement fonctionnelle
1 commentaires
Avis sur Hacker News
D’après mon expérience et ce genre d’articles, j’ai l’impression que Google déteste avoir des clients.
Quelqu’un a décidé qu’« il fallait faire du cloud public », donc ils l’ont fait, mais on a l’impression qu’ils aimeraient tenir les clients à distance avec une perche de trois mètres.
Je suis sûr à 100 % qu’un chargé de compte AWS est quelqu’un qui se roulera avec vous dans la boue si nécessaire. En situation de crise, si vous le lui demandez, il dormira par terre avec vous.
À l’inverse, les chargés de compte Google Cloud me rendent triste. Parce qu’on voit bien qu’ils sont encore moins aimés et moins soutenus que nous en interne chez Google. C’est triste de voir quelqu’un essayer de convaincre sa propre entreprise de vendre et d’assurer correctement son service, et on a l’impression qu’ils ont été mis en position d’échec.
Les gens de Microsoft, eux, sont blindés, bons en vente, assurent bien le service, et arrivent à me soutirer tout l’argent de mes poches tout en me faisant croire dur comme fer que c’est bon pour moi. Mais leur cloud est quelque chose de très étrange…
Le fait que Railway passe au bare metal, après environ 15 ans à en avoir fait, je ne voudrais absolument, absolument, absolument jamais y retourner. Ça n’en vaut pas la peine. Mais j’imagine qu’il faut le vivre soi-même pour le comprendre, et c’est comme ça que ça se passe.
Ils vont bientôt comprendre pourquoi Google se donne autant de mal. Cela dit, si l’envie de vendre des services aux gens est vraiment plus forte que celle de construire Borg ou un cerveau artificiel, ils peuvent faire 100 fois mieux que Google.
Cela dit, je ne pense pas qu’il se roulerait dans la boue avec moi, ce qui m’étonne un peu. Je me demande combien il faut dépenser pour atteindre le niveau « accompagnement dans la boue ».
L’ensemble du service cloud donne l’impression d’avoir été conçu par quelqu’un qui ne connaît rien au cloud computing et ne connaît que la « location de serveurs bare metal ». C’est bien du cloud computing, mais d’une manière qui sape le concept même de cloud computing.
L’outil en ligne de commande de GCP,
gcloud, donne aussi l’impression d’être mieux conçu.Cela nous aurait évité des mois de travail préparatoire.
D’après mon expérience personnelle, le support Google Cloud nous a plutôt bien traités alors que nous étions une petite équipe de trois personnes avec très peu de dépenses, et dans une autre entreprise Microsoft nous a aussi très bien traités. Mais à ce moment-là, le niveau de dépense était probablement tel qu’on aurait pu le suivre via la surveillance du réseau électrique du datacenter.
En revanche, AWS a menti sur une fonctionnalité et, au final, n’a même jamais donné de réponse.
Les chargés de compte qui discutent avec la direction de contrats AWS indispensables à plusieurs millions de dollars semblent très bien savoir comment parler à ces dirigeants.
Mais quand il s’agit de développer et de fournir réellement un produit pour d’autres, nous avons été laissés seuls dans la poussière.
Le plus drôle, c’est que la fonctionnalité mensongère en question nous avait été vendue comme essentielle pour offrir une excellente expérience aux utilisateurs finaux.
J’ai répondu au ticket de support, mais je n’ai eu aucun retour, et j’ai envoyé un e-mail à deux interlocuteurs AWS, sans réponse non plus.
Ça me rappelle l’époque de Rackspace. C’était vraiment une suite d’incidents dignes d’une guerre.
Des gens d’EMC étaient venus installer du matériel de stockage de test et, en se prenant les pieds les uns dans les autres, ils ont fait tomber tout un rack de serveurs comme dans une comédie. Évidemment, ils n’ont pas décroché le contrat.
Un chauffeur de camion a fait une crise cardiaque, et l’accident a mis le datacenter DFW hors ligne. Il y avait des bornes pour éviter ce genre de situation, mais elles n’étaient pas encore remplies de ciment.
À un moment, on a même établi une liaison provisoire en envoyant de la bande passante par laser jusqu’à un autre bâtiment de l’autre côté de la rue.
Un jour, un serveur a littéralement commencé à brûler, alors on a cassé une fenêtre et acheté des ventilateurs box fan.
L’ingénierie des datacenters a pas mal progressé depuis les débuts. À l’époque, on travaillait avec Facebook sur l’OpenCompute Project, et il y avait des concepts d’infrastructure très en avance pour l’époque.
Le lien micro-ondes principal tombait sans cesse, avec des erreurs de paquets intermittentes profondément au niveau de la couche liaison de données. Après enquête, les arbres de l’autre côté de la route avaient des feuilles, et des branches se balançaient dans la ligne de visée des équipements de notre bâtiment. Une échelle, une scie et 10 minutes ont suffi à rétablir la connexion.
Le routeur BGP principal sortant du datacenter redémarrait en boucle. Il n’y avait pas d’équipement redondant. Après vérification, la température du datacenter était trop élevée et le refroidissement tellement mauvais que l’air à l’entrée des ventilateurs dépassait 60 °C. On a posé provisoirement un ventilateur pointé dessus.
Quelques semaines plus tard, la climatisation d’une autre salle a aussi lâché et a commencé à projeter de l’eau sur un Nortel DMS-100. C’était un FAI dial-up avec son propre commutateur. Je n’avais pas vraiment envie d’aider à essuyer, en me disant que l’eau pouvait être sous tension, mais je n’ai pas vraiment eu le choix.
Ensuite, j’ai aussi travaillé sur une petite île isolée : le lien Internet principal était un lien à 1 MB/s via satellite GS, avec plus de 500 ms de ping. Les habitants se connectaient en dial-up via un réseau téléphonique micro-ondes homologué à 9600 bauds, mais, allez savoir comment, les modems 56k fonctionnaient.
Un jour, on s’est rendu compte qu’il manquait un
.soimportant sur une machine Solaris, sans sauvegarde locale ni support d’installation. J’ai appelé un ami au Royaume-Uni pour lui demander de déposer une copie sur un serveur FTP, ce qui a permis de remettre la machine en ligne.Quelques années plus tard, j’ai aussi installé un lien laser au-dessus d’Oxford Road à Manchester, alors la ligne de bus la plus fréquentée d’Europe, pour relier un bureau au campus universitaire. C’était une époque amusante.
Tout cela était incroyablement fun, mais je suis vraiment content de ne presque plus faire que du logiciel aujourd’hui.
Même si les serveurs n’ont pas littéralement pris feu, ouvrir les fenêtres et utiliser des ventilateurs, c’est aussi arrivé en janvier 2024 dans le datacenter Equinix CH1 de Chicago. Azure ExpressRoute est tombé.
D’après ce que j’ai entendu, il faisait tellement froid que les CRAC n’ont pas tenu. Ils auraient laissé toutes les portes et fenêtres ouvertes pour maintenir suffisamment de froid, mais ça a fini par échouer. Quand les CRAC lâchent, les serveurs suivent.
Ce switch était forcément maudit. Plus tard dans la même semaine, une erreur de configuration de spanning tree sur le même équipement a mis LINX à l’arrêt pendant plusieurs heures, et la moitié du peering des FAI britanniques s’est retrouvée temporairement dans le chaos. Toutes les autres personnes impliquées dans ce projet sont aussi décédées dans les deux ans.
Quelques années plus tard, en visitant les installations, la carcasse grillée était encore par terre en dessous.
Le passage disant qu’« même en dépensant plusieurs millions de dollars par an, on ne reçoit pas plus de support que quelqu’un qui dépense 100 dollars » fait mal. C’est un vrai gros problème chez Google.
Ce texte m’a particulièrement intéressé parce que nous avons vécu des aventures similaires en construisant l’infrastructure de Blekko.
Pour une entreprise comme Blekko, où le trafic entre racks — c’est-à-dire le trafic est-ouest — dépasse le trafic entrant et sortant vers Internet, il était essentiel que les services physiquement colocalisés ne se disputent pas la bande passante avec d’autres serveurs. C’était bien plus économique que de payer, chez SoftLayer, le cloud captif d’IBM, pour ce cas d’usage particulier.
Il existe aussi des entreprises assez impressionnantes qui fabriquent des enceintes autour des allées froides. En gros, elles garantissent que tout l’air froid venant du plancher entre à l’arrière des serveurs et ne s’échappe pas ailleurs. Elles empêchent aussi l’air moins froid sur les côtés d’être aspiré par les serveurs.
Le calcul de la capacité HVAC/CRAC d’un datacenter est aussi intéressant. Dans notre premier site de colocation, nous avions un droit de premier refus pour nous étendre sur la surface au sol à côté de notre cage, mais au moment de l’extension réelle, cela ne servait à rien : le site n’avait plus de capacité de refroidissement disponible.
Après être passé par ce genre d’expérience, on comprend beaucoup mieux la solution 0xide.
C’est comme ça qu’on peut bâtir une entreprise dominante. Ils ont bien fait d’ignorer la sagesse conventionnelle geignarde qui pousse à s’enfermer chez les hyperscalers.
Une entreprise d’infrastructure doit posséder directement le bare metal qu’elle vend. Sinon, elle n’est qu’un intermédiaire cloud, et elle risque à tout moment de se faire battre sur les prix par un concurrent bare metal avec 0 dollar de coût de sortie.
Comme la colocation et le peering permettent de ramener les coûts de sortie à 0 dollar, Cloudflare peut proposer une offre gratuite, et un nouvel entrant qui se contente de revendre des services cloud ne peut pas rivaliser avec Cloudflare.
En réalité, pour les hyperscalers, les tarifs abusifs sur la bande passante ne sont pas seulement une source de revenus : ce sont des douves. Ils empêchent de construire le prochain AWS sur AWS, et créent au-dessus de l’IaaS un segment de marché entièrement nouveau, appelé « PaaS », stratégiquement plus faible.
Avec ça, on peut réduire ces coûts de moitié, baisser aussi les coûts de stockage, et supprimer la tarification « par siège ».
J’ai vraiment hâte.
C’est un assez bon article. Une chose me vient à l’esprit : pourquoi avoir créé soi-même un outil interne de gestion des racks ? NetBox existe déjà.
NetBox est excellent, et j’aurais aimé l’avoir au milieu des années 2000, quand je gérais plus de 50 racks.
https://github.com/netbox-community/netbox
Mais la raison pour laquelle notre outil, Railyard, nous convient bien, c’est qu’il est profondément intégré à toute notre pile logicielle, matérielle et d’orchestration.
Le problème des outils open source, c’est qu’ils sont trop génériques. Au lieu de résoudre le problème, on finit par tordre le problème pour qu’il corresponde au modèle de données de l’outil.
Au bout du compte, il y a de fortes chances que nous intégrions cet outil directement dans Railway. Si vous voulez passer à l’on-premise, cela pourrait fournir, d’un clic, la conception matérielle, la mise en service, le déploiement et l’expérience développeur. Un peu comme ce que fait Oxide, mais en abordant le sujet par l’autre bout.
https://github.com/netbox-community/netbox/issues?q=is%3Aiss...
NetBox veut être la « source de vérité » de l’infrastructure réseau.
Ce qui compte varie selon les situations, mais l’histoire aurait pu être différente si NetBox avait visé un dépôt central sans insister sur le fait que, pour certains éléments, aucun autre système ne peut faire autorité.
Nous avons appris que les tentatives de centraliser la complexité et le contrôle ne fonctionnent pas. On l’a compris presque immédiatement après l’adoption du Clinger-Cohen Act, et désormais ITIL et TOGAF traitent aussi clairement ce point. Je pense que les consultants vont beaucoup exploiter ce filon dans les prochaines années.
Il faut une méthode centrale et cohérente pour trouver l’état des choses, afin d’éviter toute ambiguïté sur l’endroit où trouver l’information faisant autorité.
Mais pour passer à l’échelle, croître ou s’adapter à de nouveaux changements, il faut éviter ce genre de systèmes prescriptifs de boîte divine centralisée.
Ce n’est pas un logiciel très gratifiant à utiliser.
C’est un cas classique de « nous avons besoin de X et Y fait X », en ignorant que Y fait aussi Z, M, Q et même la vaisselle, et que vous n’en avez pas besoin.
Parfois, la solution la plus simple est de construire uniquement ce dont on a besoin. Surtout quand ce dont on a besoin, c’est du CRUD devant une base de données.
En pratique, il s’agit simplement d’élargir le périmètre. NetBox est un bon point de départ si vous commencez par là et que vous êtes prêt à adapter votre système autour de lui.
Mais si vous avez déjà un système, ou si vous devez faire quelque chose qui ne colle pas à la logique de NetBox, il est très probable qu’il vaille mieux simplement étendre votre système existant.
Dans ce cas, Railway doit gérer beaucoup plus d’informations supplémentaires que les seuls racks, adresses IP et serveurs physiques.
J’ai travaillé sur l’automatisation de la réparation d’équipements dans une grande entreprise tech. À mon avis, la réparation est sous-estimée, mais c’est l’un des sujets les plus difficiles à gérer.
Quand on tourne sur AWS, on se soucie très peu du matériel défaillant. En général, il est réparé automatiquement.
Quand on exploite soi-même son infrastructure, on n’a pas ce luxe. Il faut des pièces de rechange, des techniciens pour réparer, des procédures pour retirer la charge des hôtes puis les réintégrer, des suites de tests, des outils de supervision matérielle, et 1001 autres choses.
À petite échelle, on peut bâcler certaines de ces choses, mais on finit par le payer. Et là, on ne parle que des serveurs.
Les équipements réseau apportent leur propre lot de problèmes amusants et, en cas de panne, ils peuvent faire tomber tout un rack. Dans quelle mesure pouvez-vous faire confiance à votre fournisseur de colocation pour ne pas perdre l’alimentation pendant un pic de charge ? J’espère que vous ferez des exercices de reprise après sinistre pour ce genre de situation.
Bonne chance à cette équipe. Ça a l’air intéressant.
Cela me rappelle quelques journées de ma carrière. Entre 2003 et 2010, j’ai dû déployer des dizaines de milliers de serveurs et j’ai appris des choses assez intéressantes sur les data centers.
La gestion des câbles et la standardisation étaient d’une importance extrême. On ne pouvait pas survivre avec des pratiques désordonnées.
Là où nous déployions des centaines de serveurs par semaine, quand un serveur différait de l’un des principaux clusters, les opérateurs avaient un menu dans lequel choisir. En gros, il y avait deux châssis : de gros serveurs de disques 2U, ou des boîtiers « pizza box » 1U. Pour les disques, on pouvait choisir entre du SCSI 9/36/146 Go.
Tous étaient des machines biprocesseurs avec les mêmes processeurs, et on mettait une dizaine de boîtiers 2U en bas du rack, puis plus de vingt boîtiers 1U pour le reste.
Si ma mémoire est bonne, nous avions obtenu un très bon prix pour l’électricité, probablement parce que nous utilisions les racks de l’installation dans notre cage. Je crois qu’en utilisant ces racks, les deux premiers circuits 30 A 240 V étaient fournis gratuitement.
C’était un contrat de 10 ans, sans comptage, donc nous remplissions chaque rack autant que possible. Nous mettions deux circuits 30 A d’un côté et deux circuits 20 A de l’autre.
Vu la chaleur que nous dégagions et notre consommation électrique, je pense que le data center devait être à peu près à l’équilibre. Peut-être qu’ils se rattrapaient sur les coûts de connectivité ou de peering.
Je ne me souviens plus bien des détails, il faudrait que je vérifie auprès d’un ami qui y travaillait à l’époque.
Certaines charges ont leur place dans le cloud, d’autres non. Le meilleur exemple, ce sont les applications à forte bande passante ou très gourmandes en disque.
Si l’on regarde Netflix, presque tout est dans le cloud, mais la diffusion vidéo elle-même se fait sur leur propre matériel. Même à l’échelle de Netflix, je me demande si cela aurait été économiquement viable de payer quelqu’un d’autre pour le faire.
En modifiant légèrement un chiffre que j’ai souvent vu, 20 Po de trafic sortant à 0,02 dollar par Go, cela fait 400 000 dollars par mois.
20 Po correspondent grosso modo à 67 Gbit/s au 95e percentile.
Il n’est pas difficile de trouver une liaison 100 Gbit/s forfaitaire à 5 000 dollars par mois.
Bien sûr, c’est un calcul beaucoup trop simplifié, et dans la réalité beaucoup plus de facteurs entrent en jeu. Mais l’écart reste énorme.
Pour certaines entreprises, 4,68 millions de dollars par an peuvent être négligeables ; pour d’autres, cela peut être une question de survie.
J’aimerais qu’il y ait beaucoup plus de détails. La section WTF était la meilleure
Le matériel aurait besoin de marquages du genre « orienter ce côté vers l’ennemi », ou d’affordances appropriées qui empêchent de l’insérer autrement que dans un seul sens
Avez-vous standardisé la disposition au niveau des racks ? Quelles procédures de poka-yoke avez-vous mises en place pour éviter les erreurs ?
À quoi ressemble la stack, du bare metal jusqu’au boot ?
Ayant travaillé chez deux fournisseurs de cloud différents et monté moi-même un cloud interne avec des hôtes en boot PXE, je trouve ce genre de détails vraiment passionnant
Quand on lance un nouveau datacenter, mieux vaut en profiter au maximum pour tester tous les scénarios de panne imaginables, ainsi que ceux auxquels on n’a pas pensé via de l’injection aléatoire de défaillances
Nous standardisons désormais la disposition au niveau des racks. Nous ne l’avons compris qu’après le deuxième site. Cela rend la validation beaucoup plus simple
La validation est difficile et, jusqu’ici, elle est faite manuellement. J’aimerais extraire les données LLDP, mais la stack logicielle des switches a des bugs
C’est un processus en évolution constante. Plus nous travaillons avec différents prestataires de construction, plus nous découvrons et intégrons de cas particuliers
La plus grosse amélioration a été de créer notre DCIM interne pour modéliser les designs de racks sous forme de templates, et de générer pour les techniciens sur site un « explorateur de câblage » interactif. Il inclut aussi des schémas annotés détaillés des équipements, avec les noms de ports, etc. La capture d’écran de l’élévation de rack dans l’article fait partie de cet outil
Du bare metal jusqu’au boot, nous avons quelque chose bricolé par-dessus https://github.com/danderson/netboot/tree/main/pixiecore. Cela sert un netboot Debian et des fichiers preseed
Nous avons aussi un worker Temporal custom qui se connecte à l’API Redfish du BMC pour piloter la machine. Ensuite, un agent hôte custom provisionne des VM QEMU, et l’hôte annonce les IP attribuées en BGP via FRR
Concernant les scénarios de panne dans les nouveaux datacenters, nous avons déjà testé en faisant sauter des disjoncteurs, ce qui nous a permis de découvrir un déséquilibre de phases. Sur un autre site, nous sommes venus avec une caméra thermique
Le site AMS doit être mis en ligne la semaine prochaine, et l’objectif est de voir jusqu’où nous pouvons pousser un fabric de switches entièrement rempli
Bon article. Quand on a besoin de débits 100G, Google facture vraiment très cher. Presque de façon insultante
Par exemple, un Dedicated Interconnect 100G redondant coûte environ 35 000 dollars par mois, sans compter les VLAN attachments, les coûts de cross-connect en colocation, le transit, etc. En plus, les VLAN attachments plafonnent à 50G
Si l’on compare ce coût, avec la même somme on peut acheter deux nouveaux switches Arista 100G à 32 ports
En Amérique du Nord, on peut obtenir une liaison WAN 100G, c’est-à-dire une Wavelength managée, pour moins de 5 000 dollars par mois. Dans un métro local, on peut même obtenir de la fibre noire moins cher et la faire tourner à la vitesse souhaitée