Brand & Persönliches

Vom Pi-Cluster zum echten Server — das Homelab ist erwachsen geworden

Im Januar habe ich hier von meinem 19-Zoll-Rack erzählt: Pi-Cluster, selbstgebautes Netz, viel Monitoring. Seither ist einiges passiert. Im Rack steht jetzt ein echter Server — und aus der Spielwiese ist eine kleine Produktion geworden.

Konkret: ein HPE ProLiant DL360 Gen9 mit 40 Cores und 94 GB RAM als Proxmox-Host, davor eine USV mit 1500 VA, dazu Gitea mit eigenem CI-Runner und Container-Registry — weil das GitHub-Actions-Budget aufgebraucht war. Die fünf Pis sind geblieben: USV-Server, DNS- und Proxy-Redundanz, WireGuard-Gateway, Monitoring-Hub. Bewusst kein Kubernetes. Eine Docker-VM pro App, aus einem Template geklont. Das reicht, und es bleibt verstehbar.

Warum der Aufwand? Weil man manches nur lernt, wenn man es selbst betreibt. Drei Beispiele aus den ersten Wochen:

Die USV war eingerichtet, alle Hosts als NUT-Clients, sauberer Shutdown bis zum Proxmox-Host. Nach einem Reboot band der NUT-Server nur noch auf localhost — die Kette war still gebrochen. Kein Alarm, nichts rot. Und der Echttest mit gezogenem Stecker steht ehrlicherweise noch aus.
Der Server ist nachts um vier abgestürzt und fünf Minuten später von selbst wieder hochgekommen. Die VMs blieben trotzdem drei Stunden aus — das onboot-Flag fehlte. Ein Häkchen. Seit dem Tag Standard bei jeder neuen VM.
Enterprise-Blech hat eigene Regeln: Nach dem Crash mit leerer Cache-Batterie hat der RAID-Controller seinen Write-Cache dauerhaft abgeschaltet. Neue Batterie rein, Cache bleibt tot. Kein Datenrisiko, nur Performance — aber kein Reboot der Welt löst das.

Und dann der Teil, der am meisten mit meinem Job zu tun hat: Die laufende Wartung fährt inzwischen ein AI-Operator. Anders als der Health-Report-Agent aus meinem Juni-Post darf dieser anfassen: Pakete, Container, Reboots — über fünfzehn Hosts. Vorher liest er den Zustand aus Prometheus, Loki und den Grafana-Alerts, klärt mit needrestart, welche Dienste wirklich neu müssen, misst nachher nach und dokumentiert jede Runde im Repo. Sein Gedächtnis ist eine Markdown-Datei mit über 150 KB Runbooks und Learnings. Die Regeln: pro Phase erklären, was passiert, bevor es passiert. Ausfallfenster ansagen. Firewall nur lesend. Und alles, was Daten nach aussen bewegt, löst der Mensch aus.

Dabei kommen Dinge hoch, die vorher niemand gesehen hat: neun VMs, die drei Tage mit ersetzten Bibliotheken in PID 1 liefen, ohne dass ein Dashboard es zeigte — die Kernel-Metrik prüft eben nur den Kernel. Und ja, er baut auch Mist: Eine Alert-Regel von ihm hat wegen eines einzigen Timeouts zwei Stunden Fehlalarm geschlagen. Ursache analysiert, Regel korrigiert und gegen die echten Daten rückgetestet hat er dann selbst.

Das Rack ist kein Spleen und keine Spielwiese mehr. Es ist der Ort, an dem ich ausprobiere, was ich Kunden später empfehle — inklusive der Frage, wie viel Betrieb man einem Agenten anvertraut.

Was steht bei euch im Rack — und was davon würdet ihr einem Agenten überlassen?

◰ Alle Insights