Wir haben die wichtigsten Container eines Proxmox-Clusters hochverfügbar gemacht – ohne Shared Storage, nur mit ZFS-Replikation zwischen zwei Nodes. Das Prinzip ist einfach, die Stolpersteine lagen im Detail.
Der Aufbau
- Die Container liegen auf einem ZFS-Pool, den es auf beiden Nodes gibt.
- Proxmox repliziert sie alle 15 Minuten auf den zweiten Node (
pvesr), mit Bandbreitenlimit, weil sich die Netzwerkkarte die Leitung mit Corosync teilt. - Eine HA-Regel mit Prioritäten sorgt dafür, dass die Container normal auf dem Haupt-Node laufen, nur bei einem Ausfall auf den zweiten wechseln und danach wieder zurückgehen (Failback).
auto-rebalancebleibt aus: Der Pool auf dem zweiten Node liegt auf einer HDD, dort sollen die Container nur im Notfall laufen.
Wichtig für die Erwartungshaltung: Bei einem Failover gehen bis zu 15 Minuten an Änderungen verloren. Für Webseiten, Passwort-Safe oder Reverse Proxy ist das vertretbar, für eine Datenbank mit vielen Schreibzugriffen nicht.
Umzug im laufenden Betrieb
Für den Umzug auf den replizierbaren Pool haben wir ein Skript gebaut: Vorkopie im Betrieb, Container kurz stoppen, inkrementell nachsenden, Konfiguration anpassen, starten, Ports prüfen, Replikation einrichten – und die HA-Regel erst nach der ersten vollständigen Replikation setzen. Die Auszeit pro Container lag im Bereich von Sekunden.
Stolperstein 1: Consumer-SSD bremst alles aus
Der Ziel-Pool auf dem Haupt-Node ist eine QLC-SSD. Bei großen Kopien ist ihr Cache schnell voll – dann blockiert ZFS alle Container auf diesem Pool, nicht nur den gerade kopierten. Lösung: große Kopien drosseln (bei uns rund 12 MB/s) und über Nacht laufen lassen.
Stolperstein 2: Fehlalarm durch zufällige Ports
Das Skript vergleicht die lauschenden Ports vor und nach dem Neustart. Auf einem Container lauschte containerd auf 127.0.0.1 mit einem zufälligen Port – nach jedem Start ein anderer. Ergebnis: Fehlalarm, obwohl der Dienst die ganze Zeit lief. Seitdem vergleichen wir nur Ports, die von außen erreichbar sind, und blenden 127.x und ::1 aus.
Stolperstein 3: Die Router-Sitzung auf dem Jumphost
Auf dem Jumphost lief noch eine Winbox-Sitzung zu einem MikroTik-Router – im Safe Mode. Beim Umzug war der Jumphost 17 Sekunden weg, die Sitzung brach ab, und RouterOS hat brav alle Änderungen seit Beginn des Safe Mode zurückgenommen. Ein frisch eingerichteter VPN-Zugang war damit verschwunden.
Zwei Konsequenzen: Safe Mode nach dem Prüfen sofort verlassen, und vor dem Neustart eines Jumphosts nachfragen, ob dort gerade eine Sitzung offen ist.
Fazit
HA ohne Shared Storage funktioniert mit Proxmox gut, solange man den möglichen Datenverlust kennt und die Hardware nicht überschätzt. Die meiste Arbeit steckt nicht in der HA-Konfiguration, sondern in einem sauberen, prüfbaren Umzug.