Das Rechenzentrum in der Wohnung

2026-08-21 · Tiefe: die Architektur · 17 Min. · Architektur und Entscheidung

Wie eine Person ein privates Rechenzentrum betreibt: Git hält die Absicht fest, CI ist das Tor für jede Änderung an der Infrastruktur, KI-Agenten übernehmen das Tippen — und ein Mensch behält die Hoheit über Merge und Apply. Was läuft, was Ziel ist, und warum das Design so geworden ist. Geprüft gegen das laufende System am 2026-09-08; was geplant ist, heißt geplant.

TycStation hält Smart Home, Medien, Websites, Geheimnisse und einen großen Teil des Netzes einer Kölner Wohnung unter lokaler Kontrolle. Das Ungewöhnliche daran ist nicht die Hardware, sondern das Betriebsmodell. Die Live-Verifikation entscheidet, ob eine Änderung wirklich gewirkt hat, nicht der abgeschlossene Merge, und der Haushalt funktioniert weiter, wenn das Internet es nicht tut. Diese Notiz beantwortet drei Fragen: Was läuft wo, wer darf es ändern, und woher weiß man, dass eine Änderung gewirkt hat.

Was läuft

• Smart Home — Home Assistant und die Haushaltsautomationen laufen als Container auf einer eigenen VM; die Geräte erreichen sie über Zigbee, Thread, Matter und MQTT. Der eigene Sprachassistent der Zentrale läuft lokal; die Amazon-Echo-Boxen, die weiter in Benutzung sind, sind bauartbedingt Cloud-Geräte.
• Medien — Plex liefert die Mediathek des Haushalts; die Mediendateien selbst bleiben auf dem NAS.
• Websites und Ingress — Traefik liefert Websites (auch diese) und ausgewählte öffentliche Dienste aus. Öffentlicher Ingress ist gewollt und ausschließlich IPv4 — eine im September getroffene Entscheidung, keine Zwischenstufe, die noch auf die Adressplanung wartet.
• Identität und Geheimnisse — OpenBao stellt kurzlebige, pro Repository begrenzte CI-Zugangsdaten über GitLab-OIDC aus: Der Job weist nach, für welches Repository er läuft, und bekommt genau dafür Zugangsdaten, statt ein hinterlegtes Passwort mitzuführen.
• Speicher und Wiederherstellung — das Synology-NAS liefert geteilten Speicher, und ein eigener Backup-Server nimmt inzwischen die nächtlichen Archive auf und verschlüsselt sie, bevor sie den Knoten verlassen; eine bewiesene Wiederherstellungsübung über die ganze Flotte ist weiter ein Tor auf dem Weg.
• Beobachtbarkeit — Grafana, Loki und Prometheus laufen. Die Abdeckung der Flotte wächst und ist noch nicht vollständig.

Der physische Fußabdruck ist ein senkrechtes Mini-Rack voll gewöhnlicher Geräte — der Hardware-Abschnitt unten listet es auf.

Die Hardware

Die Bedingung, die diese Liste geformt hat, ist die Geräuschgrenze. Dieser Aufbau ist in der Lücke zwischen Schreibtisch und Lautsprecherturm groß geworden, und eine Maschine, die sirrt, ist disqualifiziert, bevor ihr Datenblatt gelesen wird. Das schließt Rack-Gehäuse mit ihren 40-mm-Lüftern aus, was auch immer sie pro Kern kosten, und treibt den ganzen Aufbau zu kleinen, sparsamen Maschinen — Wärme ist es, die Lüfter erzwingt.

Das Zimmer, in dem das Rack steht: Die Geräte stehen in der Lücke zwischen Schreibtisch und Lautsprecherturm.

Oktober 2025, vor dem Umbau: das ursprüngliche Mini-Rack in derselben Lücke.

Juli 2026: Die drei MikroTik-Switches kommen an und bekommen auf dem Schreibtisch ihre erste Verkabelung — der Core-Switch oben, PoE- und Access-Switch darunter.

Die Switches brachten dasselbe Problem im Kleinen mit: 40-mm-Lüfter, genau das Bauteil, das das Geräuschbudget auf Gehäuseebene schon ausgeschlossen hatte. Sie wurden an dem Tag, an dem sie aus den Kartons kamen, auf dem Tisch geöffnet und mit Noctua-Lüftern NF-A4x20 PWM bestückt — ein 40 × 20 mm großes Bauteil mit vierpoligem Anschluss —, bevor einer von ihnen verkabelt wurde.

Sauber passt es nicht überall, und genau das ist der Teil, den man wissen sollte. Die Serienlüfter haben nicht alle dieselbe Bautiefe: Die tieferen messen 40 × 28 mm, und dagegen ist der Noctua acht Millimeter flacher. Er sitzt auf demselben Rahmen und demselben Lochbild, füllt das Gehäuse aber nicht aus — dort ist es also ein teilweiser Sitz und kein glatter Tausch.

Juli 2026: beide Switches offen am Tag ihrer Ankunft. Die Lüfter sitzen am Rand der Platine, direkt neben dem Kühlkörper, den sie kühlen sollen.

23. August 2026, die Nacht, in der diese Seite überarbeitet wurde: Das Fabric ist drin, senkrecht in derselben Lücke montiert wie zuvor — und noch nicht fertig eingebaut. Verkabelung und die endgültige Halterung stehen noch aus.

Zwei Dinge, die diese Liste nicht hat. Erstens: keine Angabe zur Lautstärke — die wurde nie gemessen; der Stromverbrauch wird durchgehend gemessen, aber Leerlaufwerte je Gerät stehen hier nicht einzeln. Zweitens: Es gibt keine Kauflinks.

Warum es so geworden ist

Jede Schicht beantwortet einen Ausfall, eine Grenze oder eine Wiederherstellungslücke, die im früheren System beobachtet wurde.

• Ein ausgefallenes Gateway nahm die Wohnung vom Netz. → Eine fest zugeordnete OPNsense-VM pro physischem Knoten. CARP und pfsync schützen den Dienst, von dem alles andere abhängt: Beide Firewalls antworten auf dieselbe Adresse, und jede führt eine Kopie der offenen Verbindungen der anderen. Die eine DSL-Leitung wählt sich trotzdem neu ein.
• Das erste Segmentierungsmodell wurde brüchig und leckte auf Layer 2. → Acht geroutete Zonen mit Policy am Edge: weniger Risikoklassen, ein VLAN pro Zone, explizite Flüsse und generierte Invarianten über die Ebenen hinweg.
• Die Steuerung von Consumer-Switches stritt mit der Regel „Git besitzt die Absicht“ und stieß an eine PoE-Grenze. → Ein RouterOS-Fabric; nur der UniFi-Access-Point bleibt. MikroTik ist vollständig codegesteuert und liefert das nötige PoE++; das WLAN bleibt bei der stärkeren Funkplattform.
• Langlebige Automations-Zugangsdaten erzeugen stilles, flottenweites Risiko. → OpenBao plus GitLab-OIDC pro Repository. Jobs erhalten kurzlebige, eng begrenzte Tokens; Plan- und Apply-Material bleiben getrennt.
• Add-ons von Home Assistant OS ließen sich nicht wie gewöhnliche Dienste festpinnen und neu bauen. → Home Assistant und seine Begleiter zogen in Container, versioniert als Code; die Instanz validiert und zieht main selbst.
• Keine Wiederherstellung war je bewiesen. → Backup-Verifikation und ein vollständiger Wiederherstellungsbeweis sind Tore, nichts nachträglich Angebautes.

Komplexität wurde auch abgelehnt. Kein Kubernetes ohne auslösende Workload, keine Firewall-Konfigurationshoheit außerhalb von Git, keine Neuinstallation physischer Knoten und kein vorgetäuscht nahtloses WAN-Failover.

Sicht 01 — Systemkontext (Diagramme englisch beschriftet).

Die Betriebsprinzipien

Privatsphäre — lokale Verarbeitung als Standard. Widerstandsfähigkeit — Haushaltsdienste überstehen einen Ausfall des Providers. Eigentum — Daten und Konfiguration bleiben wiederherstellbar. Handwerk — professionelle Plattformpraxis im Maßstab einer Wohnung.

Keines dieser Muster ist in einer Cloud-Plattform ungewöhnlich: Jobs, die nachweisen, wer sie sind, statt ein Passwort mitzuführen; ein Grundriss aus öffentlichen, privaten und eingeschränkten Zonen; ein Firewall-Paar, das seinen Zustand teilt, sodass jede Hälfte übernehmen kann; Regeln, die in Git liegen statt in einer Konsole; eine Wiederherstellung, die wirklich durchgeführt wurde; und Telemetrie von allem. Vier der sechs sind da; die Full-Stack-Beobachtbarkeit läuft, aber noch nicht flottenweit, und ein bewiesener Wiederherstellungspfad steht noch aus. Das ganze Set hinter einem Wohnungsschreibtisch unterzubringen, ist das Ungewöhnliche.

Die Datumsangaben sagen, wann etwas zuletzt geprüft wurde.

Was wovon abhängt

Sicht 02 — der Stack. Schichten zeigen Abhängigkeit, nicht Rollout-Status; geplante Elemente sagen es.

Ebenen

Die Werkzeuge sortieren sich in vier Spuren — welches Werkzeug welche Aufgabe besitzt. Diese Karte beantwortet „welche Technologien?“; sie sagt absichtlich nichts über die Platzierung — das tut die Deployment-Sicht.

Heute gegenüber dem Plan

Deklarationen im Repository beweisen Absicht, nicht Rollout. Stand der Evidenz-Momentaufnahme vom 2026-09-08:

Was heute läuft

• Zwei physische Proxmox-Knoten tragen die Flotte, und die dritte Cluster-Stimme ist ein Tie-Breaker-Dienst auf dem NAS; das kleine Hilfsmitglied, das sie früher hielt, ist außer Dienst.
• Die zwei OPNsense-Edge-VMs laufen je eine pro physischem Knoten und besitzen die WAN-Anschlüsse. Sie sind ein CARP/pfsync-Paar: Beide halten jede Adresse, an die das Netz seinen Verkehr schickt, der Firewall-Zustand wird zwischen ihnen synchronisiert, und DHCP läuft im Hot-Standby — die zweite Kopie ist geladen und aktuell, sie startet nicht erst beim Ausfall der ersten. Am 2026-08-23 hat ein echter Wechsel mit Rückwechsel die Master-Rolle und die Einwahlsitzung mitgenommen.
• Das Acht-Zonen-Switch-Fabric ist aktiv — die umnummerierten VLANs, die Zonen-Gateways und die Policy zwischen den Zonen sind das, was das Netz heute fährt.
• Gäste ziehen nacheinander auf ihre Zonenadressen und Speicherstufen um; jeder Ersatz läuft neben seinem Vorgänger, bis eine eigene, geprüfte Außerdienststellung folgt.
• Hochverfügbarkeit ist scharf geschaltet, zwölf Gäste stehen unter ihr. Beide Übungen sind am 2026-09-01 bestanden. Ein Knoten wurde planmäßig durchgestartet — seine Gäste zogen vorher auf den Partner — und kam mit seinen eigenen Gästen zurück; der andere wurde hart zum Absturz gebracht, und jeder eingetragene Gast lief rund zwei Minuten später auf dem überlebenden Knoten. Die Replikation spiegelt jeden Gast des Reparaturpfads zwischen den Knoten, die nächtlichen Drift-Prüfungen laufen, und gestaffelte Ziele sind erwartete Unterschiede, keine Fehler.
• Die nächtlichen Archive gehen an einen eigenen Backup-Server, der sie dedupliziert, das Gehaltene durch erneutes Lesen verifiziert und sie schon auf dem Knoten verschlüsselt, bevor sie geschrieben werden. Die Speicherbox hält weiterhin die Bytes und kann sie nicht mehr lesen. Ein Gast wurde aus diesem verschlüsselten Speicher zurückgeholt; die Übung über die ganze Flotte steht aus.

Was geplant ist

• Die harten Ausfallübungen des Edge-Paars: WAN-Kabel des Masters gezogen, der Knoten mit dem Master ausgeschaltet, ein Trunk-Mitglied ausgefallen — jeweils mit gemessener Zeit bis zum Failover. Der sanfte Wechsel ist bewiesen; die harten Messwerte stehen aus.
• Der vollständige Wiederherstellungsbeweis über die ganze Flotte und die Verwahrung des Schlüssels, der die Archive öffnet: Er liegt im Tresor der Flotte selbst, eine Kopie außerhalb der Flotte fehlt. Ein Schlüssel, der nur in dem liegt, was er aufschließt, ist noch kein Schlüssel, den man hat.
• Die dritte Stimme des Clusters zieht von der Speicherbox auf den Access-Switch. Der Grund ist Konzentration, nicht Verfügbarkeit: Quorum, jede Speicherstufe und jede Backup-Bahn sind heute das eine Gerät, und die Stimme ist davon das am billigsten zu Verlegende. Am neuen Platz antwortet noch nichts, und der alte trägt sie, bis es so weit ist.
• Die vorhandenen Knoten konvergieren an Ort und Stelle: keine Neuinstallation, keine Umbenennung.

Sicht 03 — Deployment; Edge-Paar, Fabric und die Stimme bei Gleichstand laufen. Die Cluster-Namen bleiben TYCPVE und Tyc2pve; die kleingeschriebenen Namen sind DNS-Rollen-Aliase.

Das WAN kreuzt nie einen Switch: Die zwei LAN-Anschlüsse des Modems sind direkt an die zwei Knoten verkabelt, in jedem eine Edge-VM. Die Knoten-Bonds tragen die LAN-Trunks; Speicher und die Stimme bei Gleichstand fahren über getrennte NAS-Anschlüsse.

Eine Landing Zone wie in der Cloud, in einer Wohnung

Sicht 04 — Netz und Landing Zone; Gäste-Umzüge laufen.

Eine Landing Zone ist ein Netz-Grundriss, der feststeht, bevor etwas einzieht: welche Zonen es gibt, was zwischen ihnen laufen darf und wer das ändern darf. Das ist dasselbe Muster aus öffentlich/privat/eingeschränkt, das die Varianten in der Cloud verwenden, heruntergebrochen auf ein physisches Fabric. Jeder Pfad zwischen Zonen kreuzt den Edge und wird verweigert, sofern kein expliziter Fluss ihn erlaubt. Die veröffentlichte Eingangstür wohnt in Z-DMZ (Traefik) — der einen Zone, die aus dem Internet erreichbar ist, abgetrennt gehalten, damit ein Einbruch dort nirgendwo sonst ankommt. Einige dokumentierte NAS-Resilienz-Ports umgehen diese Zone absichtlich. Plex sitzt in der Smart-Home- und AV-Zone bei den Geräten, die es bespielt. Die privaten Zonen trennen die vertrauenswürdigen Hosts des Haushalts, die Smart-Home-Geräte, die Gäste und ein Segment „ferne Seite, nicht unseres“, das Internet bekommt und nichts Laterales. Die eingeschränkten Zonen tragen den Geheimnis-Tresor und das Quorum, das Management von Switches, AP und KVM sowie eine Kamerazone. Stabile interne Identität fährt über ein privates ULA-/48-Präfix — einen IPv6-Bereich, der nur für dieses Netz erzeugt und im Internet nie geroutet wird. Das Präfix des Providers rotiert; Namen und Policy tun es nicht.

Ehrliche Grenzen: Verkehr innerhalb einer Zone wird nicht gefiltert, die vertrauenswürdige Zone bleibt breit, und Mikrosegmentierung pro Workload — eine Regel je Workload statt je Zone — ist absichtlich eine eigene Härtungsphase nach Abschluss der Migration.

Wie eine Änderung Wirklichkeit wird

KI verändert die Tippkapazität, nicht die Autorität. Agenten erkunden, schlagen vor und prüfen. Ein Mensch genehmigt den Merge und die gesicherte Veränderung an der Infrastruktur. Die Verifikation beobachtet das entstandene System.

Sicht 05 — Auslieferung von Änderungen.

Auslieferung von Änderungen

Veränderungen an der Infrastruktur laufen nur über CI, abgesehen von dokumentierter Break-Glass-Wiederherstellung: einem im Voraus aufgeschriebenen Notweg für die Fälle, in denen die Pipeline an das Kaputte nicht herankommt. Ein sauberer Plan beweist die Absicht; die Abnahme gegen das laufende System beweist den Abschluss. Home Assistant ist die bewusste Ausnahme im Transport: Sein Container zieht und validiert main selbst, fail-closed — es gibt keinen CI-Push ins Smart Home.

Sicht 06 — Automatisierung. Fünf OpenTofu-States, je ein Lock.

Auslieferung und Automatisierung

Ein OpenTofu-State ist die Aufzeichnung dessen, was das Werkzeug gebaut zu haben glaubt. Fünf davon — der Virtualisierungs-Hub, das Netz-Fabric, das Edge-Paar, DNS und der WLAN-Controller — sind getrennte Lock-Domänen: Unabhängige Änderungen laufen parallel, während jeder State für sich serialisiert bleibt. Die States pro Edge-Knoten wurden am 2026-08-23 abgeschafft; die Pipeline verweigert die Arbeit gegen sie. Merge-Request-Pipelines sind nur lesend — nur Plan und Check. Ein Plan liest den geteilten State und die Geheimnisse der Plan-Seite; die Zugangsdaten, die etwas verändern können, hängen am geschützten Branch und erreichen nur den Apply-Job. Apply ist ein Mensch, der auf einem Runner im LAN einen Knopf drückt, mit kurzlebigen OpenBao-Zugangsdaten, die genau auf diesen Job begrenzt sind. Geteilte CI-Vorlagen liefern die Vorgaben, aber Review und geschützte Branches bleiben Teil der Kontrolle — eine Consumer-Pipeline kann eine geerbte Regel immer noch aufweichen, deshalb ist die Branch-Regel der Wächter, nicht die Vorlage.

Zwei Wächter laufen fail-closed. Der eine durchsucht die gesamte Git-Historie des Projekts nach Zugangsdaten, nicht nur die Änderung, die vor ihm liegt, und er läuft in jeder Pipeline und in jedem Repository; der andere liest jede Infrastruktur-Deklaration auf Fehlkonfiguration, in den Repositories, die welche tragen. Keiner von beiden darf warnen, statt zu scheitern.

Die Verifikation ist ein eigener, benoteter Durchlauf, kein Blick ins Protokoll. Elf Invarianten werden von den Switches selbst zurückgelesen und einzeln bewertet; eine zwölfte wird vor jedem Lauf gegen den Quelltext geprüft. Der Lauf druckt dann seine eigenen blinden Flecken neben die Ergebnisse. Wer die Switches nur über die Ebene erreicht, die er prüft, kann einen Bruch in genau dieser Ebene nicht sehen. Die Prüfer selbst laufen gegen ein synthetisches Netz, in dem für jede Invariante ein Fehler ausgesät ist — so fällt ein Prüfer auf, der nichts mehr merkt.

Drift wird in zwei Richtungen geprüft. Der eine Vergleich hält die laufende Welt gegen die Aufzeichnung und findet Änderungen, die an der Pipeline vorbei gemacht wurden; der andere hält die Aufzeichnung gegen sich selbst und findet Änderungen, die gemergt und dann nie angewendet wurden — ein anderer Fehler, der seinen eigenen Alarm braucht. Keiner der beiden darf weich scheitern: Eine Drift-Prüfung, die warnt, statt zu scheitern, ist ein falsches Grün.

Die Pipelines sind von Repository zu Repository unterschiedlich geschnitten, und keine von ihnen trägt jede Stufe — ein Repository fährt die, die sein Inhalt braucht. Die Arten von Prüfung und die Jobs, die sie tragen:

Die Migration: das Ziel bauen, ohne die Knoten neu zu installieren

Die Abfolge ist bewusst gestaffelt und bis zur endgültigen Außerdienststellung umkehrbar, in vier Stufen: das neue Substrat aufbauen, die vorhandenen Knoten an Ort und Stelle konvergieren, Wiederherstellung und Failover beweisen, dann versiegeln.

Sicht 07 — die Migration; die Substrat-Stufe ist fertig und die Gäste-Umzüge laufen, die Hochverfügbarkeit ist scharf geschaltet und beide Cluster-Übungen sind bestanden, die Wiederherstellungsübung steht noch aus. Keine Neuinstallation physischer Knoten und keine Umbenennung.

Migrationsplan

Stand 2026-09-08 ist die Substrat-Stufe fertig: Konsolenzugang und Backups wurden bewiesen, bevor irgendetwas verändert wurde, die Umnummerierung des Fabrics ist aktiv, beide Ersatz-Firewalls laufen mit direkt an die Knoten verkabeltem WAN, und die geteilte Speicherebene existiert. Die Gäste ziehen in der Reihenfolge ihrer Wiederherstellungsstufe um. Dann wird jeder Knoten hinter seinem funktionierenden Firewall-Partner leergezogen und konvergiert — das Hilfsmitglied ist bereits außer Dienst und die Stimme bei Gleichstand läuft. Hochverfügbarkeit ist scharf geschaltet und beide Übungen sind bestanden; die flottenweite Wiederherstellungsübung steht noch aus. Rollback-Mittel werden erst nach einer Stabilitätsphase entfernt, und dieser Schritt ist der einzige unumkehrbare.

Die Entscheidungen, die die Plattform definieren

• Git hält die Absicht fest; die Beobachtung entscheidet über die Wahrheit. Pläne und Dokumentation ersetzen nie die Live-Abnahme.
• Der Edge ist ein festes Paar, kein schwebender Gast. Eine OPNsense-VM pro Knoten; CARP und pfsync verschieben den Dienst, nicht die VM. Eine der beiden Firewalls ist die Konfigurationshoheit und schiebt jeden synchronisierten Abschnitt über den herstellereigenen Sync-Kanal zur Partnerin; Git ist der einzige Ursprung dieser Konfiguration, und auf der Standby-Firewall wird nichts verfasst.
• Speicher folgt der Wiederherstellungsstufe. Gäste des Reparaturpfads bleiben NAS-unabhängig auf repliziertem lokalem ZFS; geeignete VMs nutzen geteiltes NFS.
• ULA trägt Identität und Policy. Das Präfix des Providers rotiert; stabile interne Namen und Regeln nutzen ein privates ULA-/48-Präfix.
• Die Quorum-Stimme ist eine Stimme, kein Rechenknoten. Zwei physische Mitglieder plus ein eigener Tie-Breaker-Dienst — heute auf der Speicherbox, im September zum Umzug auf den Access-Switch entschieden, der ihn in einem eigenen Container tragen wird.
• Acht Zonen jetzt; Workload-Isolation später. Die Grenzen der Risikoklassen stehen fest, ohne so zu tun, als gäbe es schon Mikrosegmentierung innerhalb der Zonen.

Akzeptierte Restrisiken

• Eine DSL-Leitung heißt: Ein Firewall-Failover wählt neu ein; es ist Knoten-Redundanz, keine Leitungs-Redundanz.
• Gleichzeitiger Verlust von NAS und Knoten nimmt das Quorum und braucht Break-Glass mit bestätigt totem Partner.
• Der Verlust des Core-Switch-Chassis isoliert den geswitchten Verkehr, aber nicht das Paar selbst: Zwei der drei internen Cluster-Verbindungen und der geteilte Firewall-Zustand fahren über Kabel, die direkt zwischen den Knoten liegen.
• Verkehr innerhalb einer Zone wird nicht gefiltert, und die vertrauenswürdige Zone bleibt breit.
• Default-Deny pro Workload ist eine eigene Härtungsphase nach Abschluss der Migration.

Drei Vorfälle, die das Design verändert haben

• Ausfall des einzigen Edge — beförderte das Firewall-Paar von „später“ in den verbindlichen Plan.
• Docker auf NFS — etablierte explizite Ausnahmen für lokales ZFS und Speicherstufen.
• Layer-2-Leck — ersetzte die brüchige Segmentierung durch acht geroutete Risikozonen und abgeleitete Invarianten.

Von außen geprüft

Im September wurde die gesamte Umgebung von außen nach innen gegen ein Enterprise-Raster geprüft und kam auf 45 von 132. Die Methode, die Kosten und die Stellen, an denen die Prüfung über sich selbst falsch lag, stehen in 45 von 132; die Befunde selbst werden nicht veröffentlicht.

Alles oben wurde am 2026-09-08 geprüft. Was läuft, stammt aus der API des Clusters selbst und aus der Smart-Home-Zentrale; die Switch- und die Firewall-Ebene wurden aus den Deklarationen gelesen, die CI auf sie anwendet, nicht an diesem Tag von den Geräten selbst. Geplante Punkte sind als geplant markiert.

Weitere Feldnotizen →