Ceph, StarWind oder doch etwas anderes? Das unbequeme Mittelfeld von HA-Storage in Proxmox

Es gibt einen ganz bestimmten Moment, den jeder Proxmox-Admin irgendwann erlebt. Ihr kleiner Cluster läuft rund. Live-Migration funktioniert. HA-Neustarts verhalten sich meistens brav. Ihre Dashboards sehen sauber aus. Und dann stellen Sie die verbotene Frage: Was, wenn mein Storage einfach weiterlaufen soll, wenn ein Node stirbt?

Nicht „irgendwann wiederherstellen." Nicht „degradiert, aber okay, solange ich nichts anfasse." Sie wollen langweilige Verfügbarkeit nach Enterprise-Art. Dieselbe IP. Derselbe Mount. Dieselbe Samba- oder NFS-Freigabe. Ein Node verschwindet, und alles tuckert weiter, als wäre nichts gewesen.

Genau da wird es seltsam.

Auf dem Papier gibt Ihnen Proxmox Optionen. Jede Menge davon. In der Praxis landen die meisten Leute in einem unbequemen Mittelfeld zwischen „das funktioniert technisch" und „warum ist das so viel schwerer als bei meiner Synology."

Und genau in dieser Spannung prallen Ceph, StarWind VSAN, Cluster-Dateisysteme und selbstgebaute NAS-Ideen aufeinander.

Das Synology-förmige Loch in Proxmox

Wenn Sie jemals Synology High Availability betrieben haben, wissen Sie, wie sehr einen das verwöhnt. Zwei Boxen. Eine aktiv, eine passiv. Eine Floating IP. CIFS und NFS ist es egal, welche Box gerade lebt. Plex gerät nicht in Panik. Container brauchen danach keine Therapie.

Zu versuchen, dieses Erlebnis in einem Proxmox-Cluster nachzubilden, fühlt sich an wie das Reverse Engineering eines Zaubertricks.

Sie können durchaus Shared Storage bekommen. Sie können Redundanz bekommen. Sie können sogar ordentliche Performance bekommen. Schwierig wird es, das alles gleichzeitig zu bekommen, ohne Ihr Setup in ein Wissenschaftsexperiment zu verwandeln.

Die meisten gehen mit dem Gedanken heran: „Ich habe schon HA-Storage, also lege ich einfach Netzwerkdienste obendrauf." Genau da beginnt die Realität, sich zu wehren.

Ceph: die Antwort, die alle geben, selbst wenn es wehtut

Ceph kommt in diesen Gesprächen sofort zur Sprache, aus gutem Grund. Es ist nativ. Es ist integriert. Proxmox schubst Sie praktisch jedes Mal in diese Richtung, wenn Sie auf „Datacenter" klicken.

Block-Storage mit RBD? Solide. HA-VM-Disks? Großartig. CephFS für gemeinsamen Zugriff? Jetzt wird's interessant.

CephFS kann Ihnen ein einziges, gemeinsam genutztes Dateisystem geben, das mehrere Nodes gleichzeitig mounten. Das klingt genau nach dem, was Sie für Medien, Überwachungsaufnahmen und Bulk-Storage-Workloads brauchen. In der Theorie richten Sie Ihre Container einfach auf CephFS aus, und die Sache ist erledigt.

In der Praxis erbt CephFS den gesamten Rucksack von Ceph.

Kleine Cluster tun sich schwer. Zwei-Node-Pools sind ein Albtraum für die Haltbarkeit. Ein Betrieb mit size=2-Replikaten mag gut aussehen, bis etwas korrumpiert und Ceph keine Ahnung mehr hat, welche Kopie „korrekt" ist. HDD-basierte Pools fühlen sich langsam an, wenn Sie nicht mehr Spindeln und schnelleres Networking gegen das Problem werfen. Und Recovery-Traffic kann Ihre normalen Workloads plattwalzen, wenn Sie das Netzwerk nicht von Anfang an richtig ausgelegt haben.

Ceph scheitert nicht elegant. Es scheitert laut, mit einer Meinung dazu.

Deshalb sagen erfahrene Admins immer wieder dasselbe: Ceph funktioniert am besten, wenn jeder Node mitmacht, die Failure Domain auf Host-Ebene liegt und das Netzwerk schnell genug ist, um Rebuilds zu verkraften, ohne mit der Wimper zu zucken. Alles darunter bedeutet, ein Risiko einzugehen, ob Sie das nun zugeben oder nicht.

StarWind VSAN: großartiger Block-Storage, unbequeme Dateidienste

StarWind VSAN sitzt an einer interessanten Stelle. Als replizierte iSCSI-Lösung tut es genau das, was es verspricht. Hochverfügbare Block-Devices. Vorhersehbares Verhalten. Weniger bewegliche Teile als Ceph.

Für VM-Disks ist es sauber und zuverlässig. Für Bulk-Dateizugriff wird es kompliziert.

In dem Moment, in dem Sie sagen „Ich will Samba oder NFS mit Floating IP", haben Sie StarWinds Komfortzone verlassen. Jetzt brauchen Sie obendrauf auf diesem replizierten Block-Device etwas, das Clustering, Fencing und Failover versteht.

Dieselbe LVM-basierte Volume-Group von mehreren Nodes gleichzeitig zu mounten, ist ein klares Nein. So korrumpieren Sie Daten im Handumdrehen. Also schauen Sie sich Cluster-Dateisysteme wie GFS2 oder OCFS2 an, und plötzlich wird aus Ihrer einfachen Storage-Frage eine Doktorarbeitsverteidigung.

Cluster-Dateisysteme funktionieren, aber sie verzeihen nichts. Locking-Verhalten spielt eine Rolle. Latenz spielt eine Rolle. Container verhalten sich nicht immer brav mit ihnen. Und Troubleshooting wird zur Übung im Lesen von Man-Pages, die von Leuten geschrieben wurden, die davon ausgehen, dass Sie die Antworten schon kennen.

StarWind gibt Ihnen starke Primitive. Es gibt Ihnen kein Synology-artiges Erlebnis von Haus aus.

Die Falle „einfach an Container durchreichen"

Ein verbreiteter Instinkt ist es, VMs ganz zu vermeiden und Storage direkt an Container durchzureichen. Das klingt elegant. Weniger Overhead. Weniger Schichten. Mehr Kontrolle.

Das funktioniert, bis Ihnen einfällt, dass Container Shared-Write-Probleme nicht auf magische Weise lösen.

Wenn mehrere Nodes denselben Container ausführen könnten oder ihn während eines Failovers neu starten, brauchen sie alle konsistenten Zugriff auf dieselben Daten. Das bedeutet entweder ein Cluster-Dateisystem oder zu jedem Zeitpunkt genau einen aktiven Node.

Sobald Sie „single active" einführen, bauen Sie im Grunde HA von Grund auf neu. Sie brauchen eine Leader-Wahl. Sie brauchen IP-Failover. Sie müssen sicherstellen, dass der Storage immer an genau einer Stelle gemountet ist.

An diesem Punkt sind Sie ohnehin schon auf halbem Weg zu einer NAS-VM.

Warum „Active-Active-NAS" seltener ist, als Sie denken

Leute fragen oft, warum nicht mehr offene Lösungen einfach das tun, was NetApp oder Enterprise-Arrays tun. Die Antwort ist einfach: Es ist schwer, und es ist teuer.

Echtes Active-Active-NAS erfordert enge Koordination, absolut solides Locking und jahrzehntelange Erfahrung im Umgang mit Grenzfällen. NetApp verlangt, was es verlangt, weil dieser Feinschliff nicht über Nacht entstanden ist.

Open-Source-Projekte neigen dazu, sich auf eine Spur festzulegen. Ceph konzentriert sich auf verteilte Storage-Primitive. TrueNAS konzentriert sich darauf, ein NAS zu sein. Proxmox konzentriert sich auf Virtualisierung. Keines von ihnen ersetzt die anderen vollständig, ohne Kompromisse einzugehen.

Sie können TrueNAS auf HA-Storage betreiben. Sie können IPs mit keepalived oder Corosync floaten lassen. Sie können das alles zusammenkleben.

Aber niemand behauptet, das sei einfach.

Performance-Erwartungen vs. Realität

Viele dieser Debatten laufen letztlich auf Erwartungen hinaus. 200 MB/s Lese- und Schreibgeschwindigkeit zu wollen, ist nicht überzogen. Was Leuten zum Verhängnis wird, ist, wie sich diese Performance im Fehlerfall verhält.

Zwei-Node-Replikation bedeutet, dass jeder Schreibvorgang an beide Nodes geht. Verlieren Sie einen Node, sind Sie sofort degradiert. Rebuilds hämmern auf die verbleibende Disk ein. Die Latenz schießt hoch. Dienste stottern.

Das heißt nicht, dass es unbrauchbar ist. Es heißt, dass Sie ehrlich sein müssen, wie „Hochverfügbarkeit" zu Hause tatsächlich aussieht. Manchmal heißt das „es kommt schnell wieder." Nicht „niemand merkt etwas."

Die stille Wahrheit: Backups zählen mehr als perfektes HA

Eine der bodenständigsten Einsichten in diesen Diskussionen ist auch die am wenigsten aufregende: Konzentrieren Sie sich auf Backups.

Proxmox Backup Server zu betreiben, auf ein NAS zu replizieren, lokale Kurzzeit-Backups und Langzeit-Backups außerhalb des Nodes vorzuhalten — dieses Setup rettet mehr Homelabs als jedes exotische HA-Design.

HA hält den Betrieb am Laufen. Backups retten Ihre Daten. Wer die beiden verwechselt, ärgert sich am Ende über Ceph, obwohl es genau das tut, wofür es entworfen wurde.

Was ist also die am wenigsten schlechte Antwort?

Es gibt nicht die eine Antwort. Das ist der unbequeme Teil.

Wenn Sie enge Proxmox-Integration wollen und ordentlich skalieren können, bleibt Ceph die sauberste Lösung — besonders wenn Sie seine Regeln akzeptieren und darum herum planen.

Wenn Sie StarWind VSAN bereits vertrauen, behandeln Sie es als Block-Storage und legen Sie Dienste vorsichtig darüber, im Wissen, dass Sie etwas Individuelles bauen.

Wenn Sie Synology-Niveau an Politur wollen, ist es keine Schande, ein NAS einfach ein NAS sein zu lassen und Proxmox auf Compute zu fokussieren.

Das Mittelfeld existiert. Es ist nur nicht glatt.

Und genau davor warnt einen niemand wirklich.