Mein Homelab Upgrade V7

Author
Published

Nachdem ich in den letzten Artikeln die Entwicklung meines Homelabs von Version 1 bis V6+ beschrieben habe, geht es diesmal um das nächste große Upgrade: Version 7.
Der Weg dorthin war alles andere als reibungslos – geprägt von unerwarteten Problemen, spontanen Workarounds und einigen grundlegenden Architekturentscheidungen.

Am Ende steht jedoch ein deutlich stabileres und sauberer aufgebautes Setup.

Das ursprüngliche Problem

Im Zuge eines früheren Upgrades, hatte ich vom local-path-provisioner hin zum nfs-csi gewechselt. Das Ziel war es, meine anderen Nodes flexibler nutzen zu können. Die Annahme war nun, dass ich endlich mein Homelab im Vollausbau betreibe!

Nach kurzer Zeit  musste ich aber leider feststellen, dass mein gesamtes Cluster und alle Workloads unregelmäßig und teilweise mehrfach pro Tag unresponsiv werden.

Gemeinsam mit Arbeitskollegen schaute ich mir das Problem an und stellte fest, dass durch den Neustart des NFS-Server-Pods die Clients den NFS-Mount nicht mehr selbstständig unmounten konnten, da ich den nfs-csi mit der Mount-Option “hard” angelegt hatte.

Diese Mount-Option ist bei NFS-Clients wichtig, um sicherzustellen, dass keine IO (und somit Daten) verloren gehen können. Nach ein wenig Recherche stellte sich heraus, dass das NFS-Server-Image von openSUSE den NFS-Kernel-Server nutzt. Dies bedeutet das beim Herunterfahren des Clusters nach automatischen OS Updates das k3s Cluster heruntergefahren wird, dabei der NFS Server gestoppt wird und alle Container die noch offene NFS Mounts haben dann mit ihre geblocken IO niemals gestoppt werden können.

Die temporäre Lösung

Ich habe tatsächlich mehrfach pro Tag über mein out-of-band-management der Server einen harten Reset durchgeführt, jeweils über den virtuellen Einschaltknopf der Server. Durch den Fakt, dass der Load Balancer schon heruntergefahren wurde, ist niemals wichtige IO von Nutzern verloren gegangen. In der Praxis konnte ich das nicht nachprüfen, ich kann aber bis heute noch keine Verluste von Daten feststellen.

Das noch größere Problem

Ich stellte nach einem btrfs scrub fest, dass ich unkorrigierbare Blöcke auf meiner Festplatte hatte. Also habe ich einen Bug in unserem Bugzilla aufgemacht. Das Ergebnis von Gesprächen im Büro war, dass es wieder Probleme mit den Stable Pages geben könnte, ein Debugging davon ist aber extrem aufwändig und das Ergebnis ist höchstwahrscheinlich inkonklusiv, da man keine IO hat, die das Problem explizit reproduzieren kann. Mittelfristig hatte ich hierbei keine Probleme, da ich ja von allem Backups habe.

Die Lösung

Die Lösung für meine Probleme ist eigentlich relativ offensichtlich: Den NFS-Server aus dem Cluster rausziehen.

Konkret hat das für mich bedeutet, dass ich mir einfach ein dediziertes Network Attached Storage (kurz: NAS) selbst gebaut habe. Die Komponenten sind hierbei bis auf das Rack-Mounted-Chassis für eine neue Worker Node und zwei WD HC550 18TB alle gebraucht gewesen (Kleinteile ausgenommen).

Die Umsetzung

Auch wenn die Aktion länger als drei Tage gedauert hat, ist der Hauptteil der Arbeit auf ein Wochenende gefallen.

Freitag

Mein Plan für Freitag war es, die Hardware zum Funktionieren zu bekommen. Ich habe es also geschafft, folgende Dinge zu erledigen:

  1. Den Host-Bus-Adapter (kurz: HBA) in den verschiedenen Servern ausprobieren.
  2. Die Motherboards zwischen den zwei Rack-Chassis tauschen.
  3. Nachdem der HBA erfolgreich getestet wurde, sind die verbliebenen drei U.2-zu-M.2-Adapter auf Amazon zu bestellen.
  4. Den BliKVM zum Monitoring des vierten Hosts anschließen.

Samstag

Obwohl die Hardware erfolgreich getestet worden ist, ist noch ein wenig was zu erledigen, was noch nichts mit dem k3s-Cluster zu tun hat:

  1. Den neuen Server via BliKVM mit MicroOS bespielen.
  2. Fixe IPs vergeben für die neuen Hosts (EUI-64 interface naming)
  3. Nach Hause fahren und ausruhen

Sonntag

Nachdem die Hardware und das Betriebssystem nun erfolgreich konfiguriert sind, geht es nun darum, das k3s-Cluster aufzusetzen:

  1. Mapping der NFS-Server-Daten aus k3s rausziehen
  2. MariaDB-Daten sichern von loki zu thor
  3. thor mit MicroOS bespielen
  4. NFS-Server auf thor aufsetzen
  5. NFS Client auf loki & hulk testen
  6. k3s Reset auf allen Nodes (Deinstallation von thor)
  7. Leeren K3s Server auf loki aufsetzen (vorher checken dass alles gesichert ist)
  8. k8s Config für FluxCD im Git leeren (rename auf `-old`)
  9. Neues Cluster für FluxCD mit Namen `primary-location` erstellen

Montag

Vor der Arbeit wollte ich eigentlich nur noch “schnell” die letzten drei Applikationen wiederherstellen, aber ich habe nach Photoprism abgebrochen. TYPO3 & Jellyfin habe ich dann nach der Arbeit erfolgreich wiederherstellen dürfen.

k3s Cluster Bootstrap

Nachdem ich die Hardware und das Betriebssystem fertig vorbereitet hatte auf mein neues Cluster, ging es darum das alte Cluster zu zerstören und das neue aufzusetzen. Ich habe mein Cluster in drei Teile geteilt mit FluxCD: Infrastruktur, Infrastruktur-Addons und Apps. Infrastruktur bezeichnet hierbei Komponenten, die die Grundfunktionen des Clusters bereitstellen, die die Anwendungen benötigen.

Infrastruktur

Damit mein Cluster ordentlich funktioniert, habe ich die folgende Reihenfolge genutzt, um das Cluster funktionstüchtig zu bekommen:

  1. FluxCD installieren ins Cluster
  2. MetalLB
  3. nfs-csi
  4. ddclient
  5. traefik (for all networks)
  6. cert-manager
  7. cert-manager webhook Hetzner
  8. k8s dashboard
  9. gitops dashboard
  10. dns
  11. k8up
  12. monitoring
Applikationen

Damit die Applikationen extern wieder verfügbar sind, habe ich folgende Reihenfolge genutzt:

  1. vaultwarden
  2. typo3
  3. ldap
  4. nextcloud
  5. photoprism
  6. jellyfin
  7. frigate

Im Gegensatz zur Infrastruktur spielt die Reihenfolge bei den Applikationen keine Rolle, da die Applikationen voneinander getrennt sind (mit Ausnahme der LDAPs für die Nextcloud).

Offene Punkte

Wie bei jedem größeren Umbau bleiben auch nach erfolgreichem Abschluss einige offene Themen, die in zukünftigen Iterationen adressiert werden sollen:

  • Analyse und Behebung verbleibender NFS-Probleme in Nextcloud
  • Bessere Dokumentation der Zuordnung von PVCs zu Workloads
  • Entscheidung über den zukünftigen Einsatz eines SUSE Build Workers
  • Konsistente Namenskonvention für Netzwerkgeräte (Router, Switches)
  • Evaluierung eines PoE-Switches (aktuell mindestens sieben Geräte)
  • Planung eines Upgrades auf 10 Gbit/s
  • Einführung restriktiver NetworkPolicies im k3s-Cluster
  • Aktivierung von IPv6 im WireGuard-Netzwerk
  • Review der Firewall-Konfiguration im MikroTik-Umfeld

Fazit

Das Upgrade auf Version 7 war mit erheblichem Aufwand verbunden und hat einige grundlegende Schwächen in meiner bisherigen Architektur offengelegt.

Die wichtigste Erkenntnis: Storage gehört nicht in den Cluster. (Ausnahme: Rook)

Durch die Trennung von Storage und Compute sowie den Neuaufbau des Clusters ist mein Homelab jetzt deutlich stabiler, wartbarer und besser skalierbar.

Auch wenn noch nicht alle offenen Punkte geklärt sind, bildet die aktuelle Architektur eine solide Grundlage für zukünftige Erweiterungen.

Comments

No Comments