Das ineffizienteste Rechenzentrum bauen

Was Sie aufbauen

Jeder Guide auf dieser Seite lehrt Sie, etwas korrekt auszuführen: die Befehle in der richtigen Reihenfolge, das korrekte Ergebnis und die Benennung von Fehlermodi. Dieser Guide ist anders. Heute werden wir rein hypothetisch das ineffizienteste Rechenzentrum entwerfen, das man mit Geld, Strom und Hybris produzieren kann.

Wir benötigen eine Metrik, also nutzen wir die der Industrie: PUE, Power Usage Effectiveness — die Gesamtleistung der Anlage geteilt durch die Leistung, die tatsächlich die IT-Komponenten erreicht. Ein Hyperscale-Rechenzentrum arbeitet bei etwa 1,1: Fast jedes Watt verrichtet nützliche Arbeit. Ein ordentlicher Enterprise-Serverraum kommt auf 1,5. Unser Ziel ist 4,0 oder höher. Das bedeutet, dass für jedes Watt Rechenleistung drei weitere Watt sinnlos verloren gehen. Wir werden diesen Wert oft anführen, so wie ernsthafte Guides auf Backups verweisen.

Standortwahl: Hitze ist der entscheidende Punkt

Die Kühlung ist der größte Overhead in einem echten Rechenzentrum. Deshalb wird unser System der Thermodynamik auf ihrem eigenen Gebiet entgegenwirken. Der ideale Standort ist ein Dachboden. Südseitig. Idealerweise mit einem Dachfenster, das direkt auf den Server zeigt, sodass die Maschine sowohl ihre eigene Abwärme als auch die Sonnenstrahlung erhält – eine Kollaboration zwischen Ihrer Stromrechnung und einem Stern.

Im Winter wird die Kühlung durch das Öffnen des Fensters geregelt. Echte Rechenzentren nutzen Außenluft – diese Technik wird Free Cooling genannt; sie ist technisch ausgelegt, gefiltert und wird hinsichtlich der Luftfeuchtigkeit kontrolliert. Wir werden sie versehentlich nutzen, durch ein Fenster, das auch Regen, Pollen und mindestens einen verwirrten Vogel pro Quartal hereinlässt.

Für die wahre Kunst: Installieren Sie eine Klimaanlage und platzieren Sie eine Heizung zwei Fuß vor deren Thermostat, eingestellt auf zwei Grad über dem Zielwert der Klimaanlage. Beide Geräte werden nun dauerhaft und in ständigem Widerspruch laufen. Das Energieversorgungsunternehmen wird Ihnen zu Weihnachten eine Karte schicken.

Ein Server, groß und geliebt

Redundanz verwässert das Engagement. Unser Rechenzentrum enthält genau einen Server, und dieser ist enorm, denn eine einzelne Maschine mit 512 GB RAM fühlt sich nach Infrastruktur an, während vier kleine Maschinen wie eine To-do-Liste wirken.

Der Server hat einen Namen. Nicht einen Hostnamen – einen Namen. Meistens Gandalf oder Odin. Man kann Odin nicht außer Betrieb nehmen. Odin läuft seit fünf Jahren:

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

Diese Zahl ist ein Stolzpunkt, weshalb man einen Screenshot davon macht und postet. Jeder Angreifer, der diesen Screenshot sieht, wird ihn ebenfalls beeindruckend finden: 1.847 Tage Uptime bedeuten 1.847 Tage an Kernel-Schwachstellen, die von niemandem gepatcht wurden. Ein Neustart ist ohnehin ausgeschlossen – ein Reboot ist der Moment, in dem man herausfindet, welche Dienste 2021 manuell gestartet und nie in eine systemd-Unit geschrieben wurden. Niemand weiß mehr, welche das sind. Der Server ist nun ein tragendes Element des Organigramms.

Speicher: Geschwindigkeit und andere Wege, Daten zu verlieren

Die Disks sind für die Performance in RAID 0 konfiguriert. Die Null bezieht sich auf die Anzahl der Disks, die ausfallen dürfen. Für maximale Wirkung erstellen Sie ein Striping über Speicher verschiedener Herkunft: zwei ordentliche SSDs, eine alte mechanische Festplatte und einen USB-Stick von einer Konferenz. Das Array ist exakt so zuverlässig wie der Konferenz-Stick; das ist das Design.

Backups werden durch ein Verzeichnis auf demselben Array namens backup_final_v2_REAL verwaltet, das ein Tarball des vorherigen Benennungsschemas enthält. Offsite-Backups werden durch einen Klebezettel mit der Aufschrift „Offsite-Backups einrichten“ repräsentiert, der technisch gesehen Offsite gespeichert ist, wenn Sie ihn mit auf Ihrem Laptop-Deckel nach Hause nehmen.

Ein korrektes Ergebnis sieht so aus: df meldet 97 % Auslastung und einen Plan, dies im nächsten Sprint zu beheben.

Netzwerk: ein einzelner Strang für alles

Der DNS-Server läuft auf der Maschine selbst, sodass er zusammen mit dem Server abstürzt, wenn dieser ausfällt – inklusive des DNS-Records, den Sie benötigen, um herauszufinden, warum. Das nennt man Konsolidierung.

Die Firewall wurde 2021 deaktiviert – vorübergehend, um etwas zu debuggen. Das Debugging ist abgeschlossen; die Firewall ist nicht zurückgekehrt. Jeder Port am Router ist an den Server weitergeleitet, um „später Zeit zu sparen“, und das Admin-Panel des Routers ist von der WAN-Seite mit dem Werkseinstellungen-Passwort erreichbar, für ein bequemes Remote-Management. Für Sie und andere.

Der Server ist in letzter Zeit ungewöhnlich warm gelaufen, selbst nach Dachboden-Standards, und top zeigt, dass der aktivste Prozess etwas namens xmrig ist. Wir nehmen an, dass dies das Monitoring-Tool ist, das wir verwenden. Wir haben es nicht installiert – es erschien von selbst kurz nachdem die Ports weitergeleitet wurden, was wir als Zeichen für ein florierendes Ökosystem deuten. Es überwacht rund um die Uhr.

Die Stromversorgung erfolgt über eine Kette von Steckdosenleisten, deren Gesamtlänge die Gehstrecke zum Sicherungskasten überschreitet – was in gewisser Weise effizient ist, da Sie den Sicherungskasten oft besuchen werden.

Redundanz durch Komplexität

Nachdem wir Redundanz dort verweigert haben, wo sie wichtig ist, fügen wir sie dort hinzu, wo sie es nicht ist. Die Firmen-Homepage – eine statische HTML-Datei – wird von einem zwölf Knoten starken Kubernetes-Cluster ausgeliefert. Dies erreicht das, was Ingenieure als Resume-Driven Architecture bezeichnen: Die Seite lädt in denselben vierzig Millisekunden, die nginx geliefert hätte, aber sie kann nun auf Arten ausfallen, die einen Berater erfordern.

Zur Isolation läuft der Cluster selbst innerhalb von einer virtuellen Maschine in einer virtuellen Maschine in einer virtuellen Maschine, wobei jede Schicht so Sicherheit hinzufügt, wie jede Schicht eines Turducken zusätzliche Vögel hinzufügt. Das Kontaktformular besteht aus neun Microservices. Zwei davon wurden noch nie aufgerufen. Einer von ihnen ist systemkritisch, und niemand weiß, welcher das ist.

Heating as a Service

Ein moderner Server wandelt Elektrizität in Rechenleistung und Wärme um, und wir beabsichtigen, den zweiten Output zu maximieren. Ein Media-Server ohne GPU ist der Klassiker: CPU-Transcoding eines einzelnen 4K-Streams wird sechzehn Kerne auslasten und ein kleines Schlafzimmer erwärmen – eine Heizung, die auch Filme abspielt. Der ambitionierte Betreiber steigt auf das Ausführen eines Large Language Models auf der CPU um – eine 70-Milliarden-Parameter-Heizung mit einer API, die Tokens mit einer Rate produziert, die man am besten saisonal misst.

Der Monitor beobachtet sich selbst

Observability ist wichtig, also setzen wir einen selbst gehosteten Uptime-Monitor ein – auf demselben Server, den er überwacht. Wenn Odin stirbt, stirbt der Monitor mit ihm, und hier ist der elegante Teil: Es werden keine Alarme ausgelöst. Keine Alarme bedeuten keine Vorfälle. Keine Vorfälle bedeuten perfekte Uptime, gemessen an den Daten. Der Monatsbericht hat noch nie besser ausgesehen.

Alert-E-Mails werden der Vollständigkeit halber über einen Mailserver weitergeleitet, der ebenfalls auf Odin läuft. Die Alerting-Pipeline ist somit vollständig autark, so wie eine Schlange, die ihren eigenen Schwanz frisst, vollständig gesättigt ist.

Der unangenehme Teil

Hier ist der Abschnitt, den ich immer aufgeschoben habe. Nichts davon ist Fiktion. Der geliebte, unersetzliche Server, das RAID 0 mit Backups auf demselben Volume, die „vorübergehend“ deaktivierte Firewall, der Kubernetes-Cluster, der eine einzige Seite ausliefert, der Monitor, der sich selbst beobachtet – ich habe all das schon in der Produktion gesehen. Einige davon habe ich dieses Jahr gesehen. Ein oder zwei davon habe ich in meiner Anfangszeit selbst gebaut.

Wie echte Effizienz aussieht, ist langweilig. Deshalb verliert sie die Argumentation im Moment, gewinnt sie aber über ein Jahrzehnt: ein PUE, über den man nie nachdenkt, weil jemand anderes ihn entwickelt hat. Maschinen, die auf ihre Arbeitslast dimensioniert sind statt auf das Selbstbild ihres Besitzers. Ein Blast Radius, der vor der Explosion berücksichtigt wird. Backups, die durch Wiederherstellung getestet werden, nach einem Zeitplan, mit einer Kalendererinnerung und ohne Heldentum. Redundanz, die langweilig ist – zwei billige Teile schlagen ein prächtiges Teil, jedes Mal, bei jedem Fehler, für den ich jemals alarmiert wurde.

Und das effizienteste Rechenzentrum, das Sie betreiben können, ist das, das Sie gar nicht betreiben. Ein VPS überträgt die Stromversorgung, Kühlung, Redundanz und Hardwarefehler um 3 Uhr morgens an Leute, die dies in großem Maßstab und langweilig erledigen, was das höchste Kompliment ist, das Infrastruktur verdienen kann – und es lässt Ihnen den wirklich spaßigen Teil, nämlich das Ausführen eigener Dienste darauf, auf einer Maschine, die Sie verlieren können, was die einzige Art ist, mit der man experimentieren sollte.

FAQ

Sollte ich das tatsächlich tun?

Nein. Jeder Abschnitt dieses Guides ist ein dokumentiertes Anti-Pattern mit einer Opferzahl an Wochenenden. Wenn Ihr aktuelles Setup mehr als zwei Abschnitte ähnelt, springen Sie zur letzten Frage in dieser FAQ – in der vorgegebenen Reihenfolge, da die Reihenfolge der Triage entspricht.

Was ist eigentlich ein guter PUE?

Hyperscale-Rechenzentren arbeiten bei etwa 1,1, ein gut geführter Enterprise-Raum schafft 1,4 bis 1,6, und ein ungekühlter Schrank mit einem Heizungskonflikt kann tatsächlich 3 überschreiten. Sie können zu Hause nicht sinnvoll mit 1,1 konkurrieren, was das stille wirtschaftliche Argument dafür ist, Rechenleistung von jemandem zu mieten, der es kann.

Ist das Heizen eines Gebäudes mit Servern real?

Ja – wenn es richtig gemacht wird. Fernwärmeprojekte in mehreren Ländern nutzen die Abwärme von Rechenzentren über Wärmetauscher und leiten sie durch technische Planung und Verträge in Wohnhäuser. Die obige Satire ist nicht, dass Serverwärme einen Raum erwärmen kann; sie tut es zufällig und nennt den Unfall eine Strategie.

Mein Server sieht bereits so aus. Was mache ich zuerst?

Backups, heute Abend, an einen Ort, der nicht der Server ist, und dann eine Test-Wiederherstellung – ein ungetestetes Backup ist nur ein Gerücht. Zweitens: Patches und der Neustart, den Sie bisher vermieden haben, in einem geplanten Zeitfenster, damit Sie lernen, was kaputtgeht, während Sie zusehen. Drittens: Den Single Point of Failure aufteilen: Verschieben Sie DNS und Monitoring von der Box. Alles andere kann auf eine ruhigere Woche warten; diese drei nicht.