Hoe ontwerpt u het minst efficiënte datacenter?

Wat u bouwt

Elke handleiding op deze site leert u hoe u iets correct uitvoert: de commando's in de juiste volgorde, hoe een correct resultaat eruitziet en wat de bekende faalmodi zijn. Deze handleiding is anders. Vandaag gaan we, volledig hypothetisch, het minst efficiënte datacenter ontwerpen dat met geld, elektriciteit en hoogmoed kan worden gebouwd.

We hebben een meeteenheid nodig, dus we lenen die uit de industrie zelf: PUE, Power Usage Effectiveness, het totale vermogen van de faciliteit gedeeld door het vermogen dat daadwerkelijk de computerapparatuur bereikt. Een hyperscale-datacenter draait rond de 1.1: bijna elke watt verricht nuttig werk. Een degelijke zakelijke serverruimte haalt 1.5. Ons doel is 4.0 of hoger, wat betekent dat voor elke watt aan rekenkracht, er drie extra watt verloren gaan aan niets. We zullen vaak naar dit getal verwijzen, op de manier waarop serieuze handleidingen naar back-ups verwijzen.

Locatiekeuze: hitte is het doel

Koeling is de grootste kostenpost in een echt datacenter, en daarom zal het onze de thermodynamica op eigen terrein bestrijden. De ideale locatie is een zolder. Op het zuiden gericht. Bij voorkeur met een dakraam dat zo is geplaatst dat het direct op de server schijnt, zodat de machine zowel zijn eigen restwarmte als die van de zon ontvangt; een samenwerking tussen uw elektriciteitsrekening en een ster.

In de winter wordt de koeling geregeld door het raam open te zetten. Echte datacenters gebruiken inderdaad buitenlucht; deze techniek heet free cooling en is technisch ontworpen, gefilterd en voorzien van luchtvochtigheidsregeling. Wij zullen het per ongeluk gebruiken, via een raam dat ook regen, pollen en minstens één verwarde vogel per kwartaal binnenlaat.

Voor echt vakmanschap installeert u een airconditioner en plaatst u vervolgens een straalkachel op zestig centimeter van de thermostaat, ingesteld op twee graden warmer dan de doeltemperatuur van de airconditioner. Beide apparaten zullen nu continu en voor eeuwig draaien, in perfecte onenigheid. Het energiebedrijf zal u met Kerstmis een kaart sturen.

Eén server, groot en geliefd

Redundantie verwatert de betrokkenheid. Ons datacenter bevat precies één server, en die is enorm. Eén machine met 512 GB aan RAM voelt als infrastructuur, terwijl vier kleine machines voelen als een takenlijst.

De server heeft een naam. Geen hostnaam, maar een naam. Meestal Gandalf, of Odin. U kunt Odin niet buiten gebruik stellen. Odin draait al vijf jaar:

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

Dat getal is een punt van trots. Daarom maakt u er een screenshot van en plaatst u het online. Elke aanvaller die het screenshot ziet, vindt het eveneens indrukwekkend: 1.847 dagen uptime betekent 1.847 dagen aan kwetsbaarheden in de kernel die door niemand zijn gepatcht. Herstarten is sowieso uitgesloten. Een herstart is de manier om te ontdekken welke services in 2021 handmatig zijn gestart en nooit in een systemd unit zijn vastgelegd. Niemand weet meer welke dat zijn. De server is inmiddels een dragend onderdeel van het organigram.

Opslag: snelheid en andere manieren om data te verliezen

De schijven zijn geconfigureerd in RAID 0 voor betere prestaties. De nul verwijst naar het aantal schijven dat mag uitvallen. Voor maximaal effect verdeelt u de array over opslagmedia van uiteenlopende herkomst: twee degelijke SSD's, één verouderde harde schijf en een USB-stick van een conferentie. De betrouwbaarheid van de array is exact gelijk aan die van de conferentiestick; dat is het ontwerp.

Back-ups worden beheerd via een map op dezelfde array genaamd backup_final_v2_REAL, die een tarball bevat van het vorige naamgevingsschema. Off-site back-ups worden vertegenwoordigd door een memoblaadje met de tekst "off-site back-ups instellen", dat technisch gezien off-site is opgeslagen wanneer u het op de klep van uw laptop mee naar huis neemt.

Een correct resultaat ziet er als volgt uit: df rapporteert 97% gebruik, en er is een plan om dit in de volgende sprint aan te pakken.

Netwerken: een enkele streng van alles

De DNS-server draait op de machine zelf. Wanneer de server uitvalt, neemt deze het DNS-record mee dat u nodig heeft om de oorzaak van de uitval te achterhalen. Dit noemen we consolidatie.

De firewall werd in 2021 tijdelijk uitgeschakeld om een probleem te debuggen. Het debuggen werd afgerond, maar de firewall is nooit meer ingeschakeld. Elke poort op de router wordt doorgestuurd naar de server "om later tijd te besparen". Het admin-paneel van de router is bereikbaar vanaf de WAN-zijde met het fabrieks-wachtwoord, voor handig beheer op afstand. Voor u, en voor anderen.

De server draait de laatste tijd ongewoon warm, zelfs voor zolderstandaarden, en top laat zien dat het drukste proces xmrig is. We gaan ervan uit dat dit de monitoring-tool is die we gebruiken. We hebben deze niet zelf geïnstalleerd; het verscheen vanzelf kort nadat de poorten werden doorgestuurd. Wij zien dit als een teken dat het ecosysteem floreert. Het monitort dag en nacht.

Stroom wordt geleverd via een keten van consumenten-stekkerdozen waarvan de totale lengte de loopafstand naar de groepenkast overschrijdt. Dat is in zekere zin efficiënt, aangezien u de groepenkast vaak zult bezoeken.

Redundantie door complexiteit

Nadat we redundantie hebben geweigerd waar het ertoe doet, voegen we het nu toe waar dat niet het geval is. De homepage van het bedrijf, één statisch HTML-bestand, wordt geserveerd door een Kubernetes-cluster met twaalf nodes. Dit bereikt wat engineers 'resume-driven architecture' noemen: de pagina laadt in dezelfde veertig milliseconden die nginx nodig zou hebben gehad, maar kan nu falen op manieren waarvoor een consultant nodig is.

Voor isolatie draait het cluster zelf binnen een virtuele machine in een virtuele machine in een virtuele machine, waarbij elke laag beveiliging toevoegt op de manier waarop elke laag van een 'turducken' vogel toevoegt. Het contactformulier bestaat uit negen microservices. Twee daarvan zijn nog nooit aangeroepen. Eén ervan is cruciaal voor de werking en niemand weet welke.

Verwarming als een dienst

Een moderne server zet elektriciteit om in rekenkracht en warmte, en het is de bedoeling om die tweede output te maximaliseren. Een mediaserver zonder GPU is de klassieke methode: het transcoderen van een enkele 4K-stream via de CPU belast zestien cores volledig en verwarmt een kleine slaapkamer; een straalkacheltje dat ook nog films afspeelt. De ambitieuze beheerder stapt over op het draaien van een large language model op de CPU, een straalkachel met 70 miljard parameters en een API, die tokens produceert in een tempo dat het best per seizoen kan worden gemeten.

De monitor houdt zichzelf in de gaten

Observability is essentieel, dus implementeren we een zelfgehoste uptime-monitor op dezelfde server die hij controleert. Wanneer Odin uitvalt, sterft de monitor mee, en dit is het elegante deel: er worden geen waarschuwingen verstuurd. Geen waarschuwingen betekent geen incidenten. Geen incidenten betekent een perfecte uptime, zoals gemeten. Het maandelijkse rapport zag er nog nooit zo goed uit.

Waarschuwingsmails worden, voor de volledigheid, doorgestuurd via een mailserver die eveneens op Odin draait. De waarschuwingsketen is daarmee volledig autonoom, op de manier waarop een slang die zijn eigen staart opeet volledig gevoed is.

Het ongemakkelijke deel

Dit is het gedeelte dat ik voor me uit heb geschoven. Niets hiervan is fictie. De geliefde, onvervangbare server, de RAID 0 met back-ups op hetzelfde volume, de firewall die "tijdelijk" is uitgeschakeld, het Kubernetes-cluster dat één pagina serveert, de monitor die zichzelf in de gaten houdt; ik heb ze allemaal in productie gezien. Sommige daarvan heb ik dit jaar nog gezien. Een of twee ervan heb ik in mijn beginjaren zelf gebouwd.

Hoe echte efficiëntie eruitziet is saai, en dat is de reden waarom het op het moment zelf de discussie verliest, maar over een decennium wint: een PUE waar u nooit over nadenkt omdat iemand anders het heeft ontworpen. Machines die zijn afgestemd op hun werklast in plaats van op het zelfbeeld van de eigenaar. Een blast radius waarover is nagedacht vóór de explosie. Back-ups die worden getest door ze te herstellen, volgens een schema, met een agendamelding en zonder heldendom. Redundantie die saai is; twee goedkope onderdelen zijn altijd beter dan één prachtig onderdeel, bij elke storing waarvoor ik ooit ben opgeroepen.

En het meest efficiënte datacenter dat u kunt beheren, is het datacenter dat u niet beheert. Een VPS draagt de stroomvoorziening, koeling, redundantie en hardwarestoringen om 3 uur 's nachts over aan mensen die dit op grote schaal doen, op een saaie manier. Dat is het grootste compliment dat infrastructuur kan krijgen. Het laat voor u het werkelijk leuke gedeelte over, namelijk het draaien van uw eigen services daarbovenop, op een machine die u kunt missen; dat is het enige type machine waarop u ooit zou moeten experimenteren.

FAQ

Moet ik dit eigenlijk wel doen?

Nee. Elk onderdeel van deze handleiding is een gedocumenteerd anti-patroon dat al menig weekend heeft verpest. Als uw huidige configuratie op meer dan twee onderdelen lijkt, ga dan direct naar de laatste vraag in deze FAQ, in de aangegeven volgorde; de volgorde is namelijk de triage.

Wat is eigenlijk een goede PUE?

Hyperscale-datacenters zitten rond de 1.1, een goed beheerde bedrijfsruimte haalt 1.4 tot 1.6, en een ongekoelde bezemkast die strijdt tegen een straalkachel kan de 3 ruim overschrijden. Thuis kunt u niet zinvol concurreren met 1.1; dat is het stille economische argument om rekenkracht te huren van iemand die dat wel kan.

Is het verwarmen van een gebouw met servers echt een ding?

Ja, mits goed uitgevoerd. Stadsverwarmingsprojecten in verschillende landen vangen restwarmte van datacenters op via warmtewisselaars en leiden deze via leidingen naar woningen, volgens ontwerp, met engineering en contracten. De satire hierboven is niet dat serverwarmte een kamer kan verwarmen; het is dat men dit per ongeluk doet en dat ongeluk vervolgens als strategie bestempelt.

Mijn server ziet er al zo uit. Wat moet ik als eerste doen?

Back-ups, vanavond nog, naar een locatie die niet de server zelf is, en voer daarna een test-restore uit; een ongeteste back-up is slechts een gerucht. Ten tweede, patches en de reboot die u steeds uitstelt, in een gepland venster, zodat u leert wat er kapotgaat terwijl u meekijkt. Ten derde, elimineer het single point of failure: verplaats DNS en monitoring naar een andere machine. Al het andere kan wachten tot een rustigere week; die drie niet.