Das ineffizienteste Rechenzentrum der Welt bauen

Was Sie bauen

Jede Anleitung auf dieser Website zeigt Ihnen, wie Sie etwas korrekt umsetzen: die Befehle in der richtigen Reihenfolge, das erwartete korrekte Ergebnis und die benannten Fehlerfälle. Diese Anleitung ist anders. Heute entwerfen wir rein hypothetisch das ineffizienteste Rechenzentrum, das sich mit Geld, Strom und Selbstüberschätzung bauen lässt.

Wir brauchen eine Kennzahl und verwenden deshalb die branchenübliche: PUE, Power Usage Effectiveness. Sie ist das Verhältnis der Gesamtleistung der Einrichtung zur Leistung, die tatsächlich die Rechentechnik erreicht. Ein Hyperscale-Rechenzentrum liegt bei etwa 1.1: Fast jedes Watt verrichtet nützliche Arbeit. Ein ordentliches Serverraum eines Unternehmens erreicht 1.5. Unser Ziel ist 4.0 oder höher. Das bedeutet: Auf jedes Watt für die Rechenleistung kommen drei weitere Watt, die nutzlos verloren gehen. Wir werden diese Zahl häufig erwähnen, so wie ernsthafte Anleitungen Backups erwähnen.

Standortwahl: Wärme ist das Ziel

Die Kühlung verursacht in einem echten Rechenzentrum den größten einzelnen Kostenblock. Deshalb wird unser Standort die Thermodynamik in ihrem eigenen Revier bekämpfen. Der ideale Standort ist ein Dachboden. Nach Süden ausgerichtet. Idealerweise mit einem Oberlicht, das direkt auf den Server scheint, damit die Maschine sowohl ihre eigene Abwärme als auch die Sonnenwärme erhält: eine Zusammenarbeit zwischen Ihrer Stromrechnung und einem Stern.

Im Winter erfolgt die Kühlung durch Öffnen des Fensters. Echte Rechenzentren nutzen Außenluft. Diese Technik heißt Free Cooling und wird geplant, gefiltert sowie hinsichtlich der Luftfeuchtigkeit geregelt. Wir werden sie versehentlich nutzen, durch ein Fenster, das außerdem Regen, Pollen und mindestens einmal pro Quartal einen verwirrten Vogel hereinlässt.

Für echte Kunst installieren Sie eine Klimaanlage und stellen dann zwei Fuß von ihrem Thermostat entfernt einen Heizlüfter auf. Stellen Sie dessen Solltemperatur zwei Grad höher ein als die der Klimaanlage. Beide Geräte laufen nun dauerhaft, für immer, in vollkommener Uneinigkeit. Der Stromversorger schickt Ihnen zu Weihnachten eine Karte.

Ein Server, groß und geliebt

Redundanz verwässert die Bindung. Unser Rechenzentrum enthält genau einen Server, und er ist enorm groß, weil sich eine einzelne Maschine mit 512 GB RAM wie Infrastruktur anfühlt, während vier kleine Maschinen wie eine To-do-Liste wirken.

Der Server hat einen Namen. Keinen Hostnamen, einen Namen. Meistens Gandalf oder Odin. Odin kann nicht außer Betrieb genommen werden. 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 erfüllt uns mit Stolz. Deshalb erstellen Sie einen Screenshot davon und veröffentlichen ihn. Jeder Angreifer, der den Screenshot sieht, findet sie ebenfalls beeindruckend: 1.847 Tage Betriebszeit bedeuten 1.847 Tage Kernel-Sicherheitslücken, die niemand gepatcht hat. Ein Neustart kommt ohnehin nicht infrage. Bei einem Neustart stellen Sie fest, welche Dienste 2021 manuell gestartet wurden und nie in eine systemd-Unit eingetragen worden sind. Niemand erinnert sich an diese Dienste. Der Server ist inzwischen im Organigramm tragend.

Speicher: Geschwindigkeit und andere Wege, Daten zu verlieren

Die Datenträger sind aus Performance-Gründen als RAID 0 konfiguriert. Die Null steht für die Anzahl der Datenträger, die ausfallen dürfen. Für maximale Wirkung verteilen Sie das Array über Speicher unterschiedlicher Herkunft: zwei geeignete SSDs, einen alternden Festplatten-Datenträger und einen USB-Stick von einer Konferenz. Das Array ist genau so zuverlässig wie der Konferenz-Stick. Das ist der Zweck dieses Designs.

Backups werden über ein Verzeichnis auf demselben Array mit dem Namen backup_final_v2_REAL abgewickelt. Es enthält ein Tarball der vorherigen Namenskonvention. Offsite-Backups werden durch einen Haftnotizzettel mit dem Text „Offsite-Backups einrichten“ dargestellt. Technisch befindet er sich außerhalb des Standorts, sobald Sie ihn auf der Laptop-Abdeckung mit nach Hause nehmen.

Ein korrektes Ergebnis sieht so aus: df meldet eine Auslastung von 97 %, und es gibt einen Plan, der sich im nächsten Sprint darum kümmert.

Netzwerk: ein einziger Strang für alles

Der DNS-Server läuft direkt auf dem Rechner. Wenn der Server ausfällt, fällt damit auch der DNS-Eintrag aus, über den Sie herausfinden würden, warum er ausgefallen ist. Das wird Konsolidierung genannt.

Die Firewall wurde 2021 vorübergehend deaktiviert, um ein Problem zu analysieren. Die Analyse ist abgeschlossen. Die Firewall wurde jedoch nicht wieder aktiviert. Jeder Port des Routers wird an den Server weitergeleitet, „um später Zeit zu sparen“. Das Administrationspanel des Routers ist mit dem werkseitigen Passwort von der WAN-Seite aus erreichbar, damit die Remoteverwaltung bequem möglich ist. Für Sie und für andere.

Der Server läuft in letzter Zeit ungewöhnlich warm, selbst nach Dachbodenmaßstäben. top zeigt, dass der Prozess mit der höchsten Auslastung xmrig heißt. Wir nehmen an, dass dies das von uns verwendete Monitoring-Tool ist. Wir haben es nicht installiert. Es ist kurz nach der Weiterleitung der Ports von selbst aufgetaucht. Wir werten das als Zeichen dafür, dass das Ökosystem funktioniert. Es überwacht den Server rund um die Uhr.

Die Stromversorgung erfolgt über eine Kette handelsüblicher Mehrfachsteckdosen. Ihre Gesamtlänge übersteigt die Wegstrecke zum Sicherungskasten. Das ist in gewisser Hinsicht effizient, weil Sie den Sicherungskasten häufig aufsuchen werden.

Redundanz durch Komplexität

Nachdem wir Redundanz dort verweigert haben, wo sie wichtig wäre, fügen wir sie nun dort hinzu, wo sie nicht erforderlich ist. Die Unternehmens-Homepage, eine einzige statische HTML-Datei, wird von einem Kubernetes-Cluster mit zwölf Knoten ausgeliefert. Damit entsteht das, was Ingenieure als lebenslauforientierte Architektur bezeichnen: Die Seite wird in denselben vierzig Millisekunden geladen, die nginx benötigt hätte. Sie kann nun jedoch auf Arten ausfallen, für die ein Berater erforderlich ist.

Zur Isolation läuft der Cluster selbst innerhalb einer virtuellen Maschine in einer virtuellen Maschine in einer virtuellen Maschine. Jede Ebene soll die Sicherheit erhöhen, so wie jede Schicht eines Turducken ein weiteres Geflügeltier hinzufügt. Das Kontaktformular besteht aus neun Microservices. Zwei davon wurden noch nie aufgerufen. Einer davon ist unverzichtbar, und niemand weiß, welcher.

Heizen als Dienst

Ein moderner Server wandelt elektrische Energie in Rechenleistung und Wärme um. Wir wollen die zweite Ausgabe maximieren. Ein Medienserver ohne GPU ist der klassische Ansatz: Das Transcodieren eines einzelnen 4K-Streams per CPU lastet 16 Kerne vollständig aus und erwärmt ein kleines Schlafzimmer. So entsteht ein Heizgerät, das zusätzlich Filme abspielt. Der ambitionierte Betreiber geht einen Schritt weiter und betreibt ein Large Language Model auf der CPU. Das ist ein Heizgerät mit 70 Milliarden Parametern und API. Die Token-Ausgabe lässt sich am besten saisonal messen.

Der Monitor überwacht sich selbst

Observability ist wichtig. Deshalb stellen wir einen selbst gehosteten Uptime-Monitor auf demselben Server bereit, den er überwacht. Wenn Odin ausfällt, fällt auch der Monitor aus. Der elegante Teil ist: Es werden keine Alarme ausgelöst. Keine Alarme bedeuten keine Vorfälle. Keine Vorfälle bedeuten eine perfekte gemessene Verfügbarkeit. Der Monatsbericht sah noch nie besser aus.

Alarm-E-Mails werden der Vollständigkeit halber über einen Mailserver weitergeleitet, der ebenfalls auf Odin läuft. Die Alarmierungskette ist damit vollständig in sich geschlossen. Die Ursache ist dieselbe wie bei einer Schlange, die ihren eigenen Schwanz frisst.

Der unangenehme Teil

Hier ist der Abschnitt, den ich bisher aufgeschoben habe. Nichts davon ist erfunden. Den geliebten, unersetzlichen Server, RAID 0 mit Backups auf demselben Volume, die „vorübergehend“ deaktivierte Firewall, den Kubernetes-Cluster, der eine einzige Seite bereitstellt, und das Monitoring, das sich selbst überwacht, habe ich in Produktionsumgebungen bereits gesehen. Einige dieser Fälle habe ich in diesem Jahr gesehen. Einen oder zwei davon habe ich in meinen Anfangsjahren selbst eingerichtet.

Wie echte Effizienz aussieht, ist langweilig. Deshalb verliert sie im Moment die Diskussion und setzt sich über ein Jahrzehnt hinweg durch: eine PUE, über die Sie nie nachdenken müssen, weil sie von jemand anderem geplant und umgesetzt wurde. Maschinen, die an ihre Workload angepasst sind und nicht an das Selbstbild ihres Besitzers. Eine vorab betrachtete Auswirkungsreichweite. Backups, die nach einem festen Zeitplan durch Wiederherstellungen getestet werden, mit einer Kalendererinnerung und ohne Heldentum. Redundanz, die langweilig ist: Zwei Exemplare des günstigen Systems sind jedem einzelnen hervorragenden System überlegen. Das galt bei jedem Ausfall, für den ich jemals Bereitschaftsdienst hatte.

Und das effizienteste Rechenzentrum, das Sie betreiben können, ist das, welches Sie nicht betreiben. Ein VPS überlässt Stromversorgung, Kühlung, Redundanz und Hardwareausfälle um 3 Uhr morgens Anbietern, die diese Aufgaben in großem Maßstab und routiniert erledigen. Das ist das höchste Lob, das Infrastruktur verdienen kann. Ihnen bleibt der wirklich interessante Teil: eigene Dienste darauf zu betreiben, auf einer Maschine, deren Verlust Sie verkraften können. Nur auf solchen Maschinen sollten Sie jemals experimentieren.

FAQ

Sollte ich das wirklich alles machen?

Nein. Jeder Abschnitt dieses Leitfadens beschreibt ein dokumentiertes Anti-Pattern mit einer langen Liste verlorener Wochenenden. Wenn Ihre aktuelle Konfiguration mehr als zwei Abschnitten ähnelt, springen Sie in dieser FAQ direkt zur letzten Frage und gehen Sie die Punkte in der angegebenen Reihenfolge durch. Das ist die Triage.

Was ist eigentlich ein guter PUE-Wert?

Hyperscale-Rechenzentren erreichen etwa 1.1. Ein gut betriebenes Unternehmensrechenzentrum liegt bei 1.4 bis 1.6. Ein ungekühlter Abstellraum mit einem Heizlüfter kann tatsächlich einen Wert von über 3 erreichen. Zu Hause können Sie mit 1.1 nicht sinnvoll konkurrieren. Das ist das nüchterne wirtschaftliche Argument dafür, Rechenleistung von einem Anbieter zu mieten, der diese Effizienz erreichen kann.

Ist es realistisch, ein Gebäude mit Servern zu beheizen?

Ja, wenn es richtig umgesetzt wird. Fernwärmeprojekte in mehreren Ländern nutzen Wärmetauscher, um die Abwärme von Rechenzentren aufzufangen und planmäßig über Rohrleitungen in Wohngebäude zu führen. Die Satire oben besteht nicht darin, dass Serverwärme einen Raum beheizen kann. Das Problem ist, dies ungeplant zu tun und den Zufall als Strategie zu bezeichnen.

Mein Server sieht bereits so aus. Was soll ich zuerst tun?

Erstellen Sie noch heute Sicherungen an einem Ort, der sich nicht auf dem Server befindet. Testen Sie anschließend eine Wiederherstellung. Eine nicht getestete Sicherung ist nur ein Gerücht. Zweitens installieren Sie die ausstehenden Patches und führen Sie den bisher vermiedenen Reboot in einem geplanten Wartungsfenster durch. So sehen Sie, was ausfällt, während Sie den Vorgang beobachten können. Drittens beseitigen Sie den Single Point of Failure: Verschieben Sie DNS und Monitoring auf ein anderes System. Alles andere kann bis zu einer ruhigeren Woche warten. Diese drei Maßnahmen nicht.