Wer anfängt, sich ein eigenes HomeLab aufzubauen, steht schnell vor denselben Fragen: Welche Hardware? Wie viele Maschinen? Und wie kommt man von außen rein, wenn der ISP keine statische IP vergibt? Dieser Post beschreibt meinen aktuellen Stand — mit Entscheidungen, die ich so wieder treffen würde, und ein paar Dingen, die ich heute anders angehen würde.
Proxmox als Fundament
Proxmox VE ist eine Open-Source-Virtualisierungsplattform auf Basis von KVM und LXC. Sie bringt ein Web-Interface mit, kann mehrere physische Maschinen zu einem Cluster zusammenfassen und verwaltet VMs und Container über eine einheitliche Oberfläche. Für ein HomeLab ist das die naheliegendste Wahl: Enterprise-Features, kein Enterprise-Preis.
Wie viele Nodes brauche ich?
Proxmox-Cluster funktionieren nach dem Mehrheitsprinzip (Quorum). Damit ein Cluster Entscheidungen treffen kann — z.B. welche Node noch aktiv ist und welche als ausgefallen gilt — braucht er eine Mehrheit der stimmberechtigten Mitglieder.
Die praktischen Konsequenzen:
| Nodes | Quorum | Kann ausfallen |
|---|---|---|
| 1 | — | kein Cluster, kein HA |
| 2 | braucht externen Quorum-Dienst | 0 ohne QDevice |
| 3 | 2 von 3 | 1 Node |
| 5 | 3 von 5 | 2 Nodes |
Empfehlung für den Einstieg: drei Nodes. Das ist die kleinste Konfiguration, die ohne Zusatz-Infrastruktur einen stabilen Cluster bildet. Fällt eine Maschine aus, halten die beiden verbleibenden Nodes das Quorum und die Dienste laufen weiter — sofern die VMs auf einem noch aktiven Node liegen.
Zwei Nodes sind technisch möglich, erfordern aber einen externen Quorum-Dienst (corosync-qdevice auf einer dritten, kleinen Maschine — z.B. einem Raspberry Pi). Das ist eine zusätzliche Abhängigkeit, die bei einem Drei-Node-Setup entfällt.
Hardware
Für ein HomeLab sind Mini-PCs die erste Wahl: geringer Stromverbrauch, leise, kompakt. Die folgenden Modelle werden in der Community am häufigsten eingesetzt, weil sie gut verfügbar, günstig gebraucht und für Proxmox gut dokumentiert sind.
Lenovo ThinkCentre M-Serie (Tiny)
Die M710q, M720q und M920q sind der Standard-Tipp — und das aus gutem Grund. Sie sind gebraucht für 80–150 € pro Stück zu bekommen, unterstützen bis zu 64 GB RAM, haben einen PCIe-Slot für eine NVMe-SSD und verbrauchen unter Last etwa 15–35 W.
Prozessor: Intel Core i5/i7 (6.–9. Generation)
RAM: 2× SO-DIMM DDR4, max. 64 GB
Speicher: 1× M.2 NVMe + 1× 2,5" SATA
Netzwerk: 1 GbE onboard (Intel I219)
Formfaktor: 179 × 183 × 36 mmDer Intel-NIC ist wichtig: er wird von Proxmox ohne Zusatztreiber erkannt und läuft stabil.
HP EliteDesk 800 G5 Mini
Ähnliche Klasse wie die Lenovo-Serie, ebenfalls gut verfügbar. Vorteil: etwas kompaktere Bauform, häufig mit Intel-NIC der i219-Familie.
Beelink / Minisforum (Neukauf)
Wer neu kauft statt gebraucht zu nehmen, findet bei Beelink und Minisforum aktuelle Modelle mit AMD Ryzen oder Intel N-Serie ab ca. 150–250 €. Die N-Serie (N100, N305) ist besonders sparsam — etwa 6–12 W Leerlauf — aber auch deutlich schwächer als ein i5/i7.
Mein Cluster: drei Lenovo M710q
Drei identische Maschinen zu verwenden vereinfacht das Management erheblich. Gleiche BIOS-Versionen, gleiche Treiber, gleiche RAM-Konfiguration — es gibt keine Sonderbehandlung für einzelne Nodes.
Netzwerkkonfiguration
Das Netzwerk ist der Teil, der bei Proxmox am häufigsten unterschätzt wird. Ein paar Grundprinzipien:
Corosync braucht eine stabile, dedizierte Verbindung. Corosync ist das Herzstück des Clusters — es prüft kontinuierlich, ob alle Nodes erreichbar sind. Wenn Corosync-Pakete verloren gehen oder verzögert ankommen, denkt der Cluster, eine Node sei ausgefallen, und reagiert entsprechend. Im schlimmsten Fall kommt es zu einem Split-Brain.
Empfehlung: Corosync auf ein separates Netz legen. Das kann ein zweiter NIC sein oder ein dediziertes VLAN. Mit Mini-PCs, die oft nur einen NIC haben, ist VLAN die praktikablere Lösung.
Eine typische VLAN-Struktur für ein Drei-Node-Cluster:
| VLAN | Zweck | Adressbereich |
|---|---|---|
| VLAN 1 (native) | Management / Proxmox UI | 192.168.1.0/24 |
| VLAN 10 | VM-Traffic | 192.168.10.0/24 |
| VLAN 20 | Corosync (Cluster-intern) | 10.10.20.0/29 |
Für VLAN-Trennung braucht der Switch, an dem die Nodes hängen, VLAN-Unterstützung (Managed Switch). Einfache Heimrouter reichen hier nicht aus.
Proxmox-Bridges: Proxmox erstellt für jede Netzwerkverbindung eine Linux-Bridge (vmbr0, vmbr1, …). VMs und Container werden an diese Bridges angebunden. Eine typische Grundkonfiguration für einen Node mit einem NIC und VLAN-Trunking:
# /etc/network/interfaces (vereinfacht)
iface eno1 inet manual
auto vmbr0
iface vmbr0 inet static
address 192.168.1.10/24
gateway 192.168.1.1
bridge-ports eno1.1
bridge-stp off
auto vmbr1
iface vmbr1 inet static
address 192.168.10.1/24
bridge-ports eno1.10
bridge-stp off
auto vmbr2
iface vmbr2 inet static
address 10.10.20.1/29
bridge-ports eno1.20
bridge-stp offCorosync-Konfiguration auf zwei Ringe: Proxmox erlaubt es, Corosync auf zwei separate Netzwerkpfade zu konfigurieren (ring0 und ring1). Das erhöht die Ausfallsicherheit des Clusters selbst, ohne dass man dafür extra Software braucht.
Speicher und Hochverfügbarkeit
Das ist der Punkt, an dem sich HomeLab und Produktionsumgebung am stärksten unterscheiden. Hochverfügbarkeit (HA) in Proxmox bedeutet: wenn ein Node ausfällt, startet Proxmox die VMs automatisch auf einem anderen Node neu. Das funktioniert aber nur, wenn alle Nodes auf denselben Speicher zugreifen können.
In meinem Setup laufen die VMs auf lokalem Speicher — jede VM lebt auf genau einem Node. Fällt dieser Node aus, ist die VM nicht erreichbar, bis der Node wieder hochkommt oder ich sie manuell auf einen anderen Node migriere. Das ist kein Problem für ein HomeLab, in dem Ausfallzeiten von Minuten akzeptabel sind.
Wer echte HA braucht, kommt um ein Shared-Storage-System nicht herum. Die naheliegendste Lösung für Proxmox ist Ceph.
Ceph als Seitennote: Ceph ist ein verteiltes Speichersystem, das direkt in Proxmox integriert ist. Jeder Node stellt Festplatten als OSDs (Object Storage Daemons) bereit, Ceph repliziert die Daten automatisch über alle Nodes. Proxmox kann Ceph-Storage dann wie lokalen Speicher ansprechen — VMs lassen sich live zwischen Nodes migrieren, und HA funktioniert ohne manuelle Eingriffe. Der Haken: Ceph braucht dedizierte Festplatten (SSDs empfohlen), ein eigenes Storage-Netzwerk mit ausreichend Bandbreite (10 GbE ist die sinnvolle Untergrenze), und die Konfiguration hat eine steile Lernkurve. Für ein erstes HomeLab ist das meist zu viel Komplexität auf einmal.
Pragmatische Alternative: Regelmäßige Backups mit Proxmox Backup Server (PBS). PBS lässt sich als eigene VM oder auf einem dedizierten Node installieren und sichert VMs inkrementell. Damit ist der Datenverlust im Fehlerfall begrenzt — auch ohne HA.
Erreichbarkeit ohne statische IP: Pangolin
Wer seinen Server von außen erreichen will, braucht entweder eine statische IP oder einen Weg, sie zu umgehen. Viele ISPs — besonders im DSL- und Kabelbereich — vergeben heute nur noch CGNAT-Adressen: der Anschluss hat zwar eine öffentliche IP, aber diese wird mit vielen anderen Kunden geteilt. Port-Forwarding im heimischen Router funktioniert damit nicht mehr.
Die klassische Lösung ist ein VPS (Virtual Private Server) als Relay: eine kleine gemietete VM in einem Rechenzentrum mit statischer IP, die den Traffic entgegennimmt und an den Heimserver weiterleitet. Das kann man manuell mit WireGuard aufbauen — ist aber Konfigurationsarbeit. Pangolin macht genau das, nur fertig verpackt.
Was ist Pangolin?
Pangolin ist ein selbst gehostetes Tunnel-System. Es besteht aus zwei Teilen:
- Pangolin (läuft auf dem VPS): übernimmt das Routing, die TLS-Terminierung und das Benutzermanagement. Erreichbar über eine öffentliche IP.
- Newt (läuft auf dem Heimserver): baut einen WireGuard-Tunnel zum VPS auf und meldet, welche internen Dienste nach außen exponiert werden sollen.
Der Mechanismus: Newt baut eine ausgehende Verbindung vom Heimserver zum VPS auf — damit entfällt die Notwendigkeit, Ports im Heimnetz zu öffnen. Der VPS leitet eingehende Anfragen über den Tunnel durch.
Browser → VPS (statische IP, Port 443) → WireGuard-Tunnel → Heimserver → DienstTLS wird vom VPS terminiert, Pangolin kann Zertifikate über Let’s Encrypt automatisch verwalten. Der Heimserver muss dafür nicht direkt aus dem Internet erreichbar sein.
Warum Pangolin und nicht Cloudflare Tunnel?
Cloudflare Tunnel ist die bekanntere Alternative — kostenlos, einfach zu konfigurieren, keine eigene Infrastruktur nötig. Der Unterschied liegt in der Kontrolle: bei Cloudflare Tunnel läuft der gesamte Traffic über Cloudflare-Server. Für viele Anwendungsfälle ist das kein Problem; für selbst gehostete Dienste, bei denen man keine Dritten im Datenpfad haben möchte, ist Pangolin die konsequentere Wahl.
Vor- und Nachteile
Vorteile:
- Keine statische IP am Heimanschluss nötig
- Keine Port-Freigaben im Heimrouter
- Funktioniert auch hinter CGNAT
- Vollständig selbst gehostet, kein externer Anbieter im Datenpfad
- TLS und Zertifikatsverwaltung automatisch
- Feingranulares Zugriffsmanagement pro Dienst
Nachteile:
- Abhängigkeit von einem VPS — fällt der VPS aus, sind alle exponierten Dienste nicht erreichbar
- Latenz: jede Anfrage geht den Umweg über den VPS. Je nach VPS-Standort und eigener Internetanbindung können das 10–50 ms extra sein
- Laufende Kosten für den VPS (typisch 4–8 €/Monat für eine kleine Instanz)
- Initialer Aufwand für VPS-Setup und Pangolin-Konfiguration ist höher als bei fertigen Lösungen
Für mein Setup ist der Kompromiss sinnvoll: Die Dienste, die ich von außen erreiche, sind nicht latenz-sensitiv (Dashboards, Verwaltungsinterfaces, dieser Blog). Der VPS ist ein kleines Debian-System mit minimalem Footprint — Ausfallrisiko ist gering, und wenn doch, konfiguriert man Pangolin in 20 Minuten neu.
Fazit
Ein Drei-Node-Proxmox-Cluster aus gebrauchten Mini-PCs ist heute der effizienteste Einstieg ins HomeLab: überschaubare Kosten, reale Cluster-Erfahrung, und genug Spielraum um zu wachsen. Shared Storage und HA sind der sinnvolle nächste Schritt — aber kein Pflichtprogramm für den Anfang. Und wer keine statische IP hat, findet mit Pangolin eine saubere Lösung, ohne auf externe Dienste angewiesen zu sein.