Newsletter

    Newsletter abonnieren

    Neue Infrastruktur-Guides, Vergleichsberichte und Migrationshinweise direkt ins Postfach.

    Infrastruktur-Notizen, Guides und neue Tools. Jederzeit abbestellbar.

    Zurück zum Blog
    Proxmox
    Ceph
    Storage
    Hochverfügbarkeit
    StarWind
    Synology

    Ceph, StarWind, Synology: Wie ich versehentlich jede Storage-Idee gleichzeitig ausprobiert habe

    25. Januar 2026
    6 Min. Lesezeit

    Es gibt einen bestimmten Moment auf jeder Homelab-Reise, in dem man aufhört, Dinge zu bauen, und anfängt, mit ihnen zu verhandeln.

    Nicht reparieren. Nicht optimieren. Verhandeln.

    Es ist der Punkt, an dem Ihr Storage-Stack Sie ansieht und sagt: „Wir müssen reden."

    Das ist die Geschichte davon, wie ich am Ende Ceph, StarWind VSAN und Synology gleichzeitig betrieben habe — nicht weil ich eine elegante mehrstufige Architektur geplant hatte, sondern weil jeder Versuch, die Dinge zu vereinfachen, irgendwie stattdessen eine weitere Schicht hinzufügte. Ein Storage-Turducken. In der Theorie köstlich. In der Praxis beunruhigend.

    Ich hatte nicht vor, jede Storage-Idee auf einmal auszuprobieren. Ich wollte nur eine Sache:

    Hochverfügbaren Bulk-Storage, der nicht explodiert, sobald ein Node niest.

    Das war's. Das war der Traum. Ich habe mir das selbst angetan.


    Der ursprüngliche Plan (der natürlich perfekt war)

    Ich betreibe einen kleinen Proxmox-Cluster. Fünf Nodes. Nichts Wildes. Er läuft seit Jahren vor sich hin. Irgendwann in der Vergangenheit habe ich das Vernünftige getan und Ceph aufgesetzt, weil:

    • Es nativ ist
    • Es „enterprise" ist
    • Alle „nimm einfach Ceph" sagen, mit der Selbstsicherheit von jemandem, der schon gelitten hat

    Und ehrlich gesagt? Ceph hat funktioniert. Für VM-Disks. Für Container. Für Dinge, die weiterlaufen müssen, wenn ein Host stirbt. Da gibt's nichts zu meckern.

    Aber dann war da noch der Bulk-Storage.

    Plex-Bibliotheken. Frigate-Aufnahmen. Mediendateien, denen IOPS egal sind, denen es aber wichtig ist, online zu bleiben. Zeug, das einmal gemountet und danach nie wieder angefasst werden will.

    Auftritt: die Synology RackStation.

    Die Synology tat genau das, was sie sollte. SMB. NFS. Eine einzige IP. Bombenfest. Langweilig. Wunderschön. Sie saß einfach da, still kompetent, während ich so tat, als sei sie nur „vorübergehend."

    Und dann dachte ich:

    „Was, wenn ich diesen Storage in den Cluster verschiebe?"

    Hier ist alles aus dem Ruder gelaufen.


    StarWind: „Das wird einfach" (Erzähler: War es nicht)

    Ceph existierte bereits. Aber ich wollte für den Bulk-Storage etwas, das ein bisschen mehr … SAN-förmig war. Etwas mit synchroner Replikation. Etwas, das sich wie ein Block-Device anfühlte, über das ich nachdenken konnte.

    Also fügte ich StarWind VSAN hinzu.

    Und um fair zu sein, StarWind hat gehalten, was es versprach. iSCSI-Volumes. HA. Mirroring. Die beruhigende Illusion, dass Enterprise-Software die schweren Entscheidungen für mich trifft.

    Jetzt hatte ich:

    • Ceph für VM- und Container-Disks
    • StarWind für HA-Bulk-Storage
    • Synology für … Backups? Emotionale Unterstützung?

    An diesem Punkt passte mein Storage-Diagramm nicht mehr auf einen Bildschirm.

    Aber die eigentliche Frage war nicht, ob der Storage replizierte. Sie lautete:

    Wie nutze ich das tatsächlich, ohne dass alles aus Panzertape besteht?


    Das IP-Problem (a.k.a. „Warum kann sich das nicht einfach wie ein NAS verhalten?")

    Das ist die Sache, die Synology absolut perfekt hinbekommt:

    Sie mounten es. Es hat eine IP. Geht etwas kaputt, failt es over. Ihre Mounts kümmert das nicht.

    Das ist der Goldstandard. Das ist die Messlatte.

    Was ich wollte, war das HA-Verhalten von Synology, aber mit meinem glänzenden VSAN-Storage im Rücken.

    Was ich stattdessen bekam, war ein langer Blick in den Abgrund aus Cluster-Dateisystemen, Volume-Managern und „technisch möglichen" Lösungen.

    Weil Block-Storage einfach ist. Shared-Filesystem-Semantik ist es nicht.

    iSCSI gibt Ihnen ein Block-Device. Aber nur eine Sache darf darauf schreiben, wenn Sie kein Chaos wollen.

    Also stapelten sich jetzt die Fragen:

    • Reiche ich das iSCSI-Volume direkt an Container durch?
    • Wickle ich es in LVM ein?
    • Verabschiede ich mich ganz von Proxmox-LVs?
    • Brauche ich GFS2? OCFS2? Irgendeine andere Abkürzung, die nach Schmerz riecht?

    Jede Antwort kam mit einem Warnhinweis.


    „Nimm einfach ein Cluster-Dateisystem" (Cool, cool, cool)

    Auf dem Papier sieht die Lösung unkompliziert aus:

    1. Die iSCSI-LUN mehreren Nodes präsentieren
    2. Ein Cluster-Dateisystem obendrauf legen
    3. Überall mounten
    4. Per Bind-Mount in Container einbinden
    5. Profit

    In der Realität ist jeder Schritt eine Wahl zwischen:

    • Zerbrechlichkeit
    • Performance
    • Komplexität

    Wählen Sie zwei. Manchmal nur eine.

    Cluster-Dateisysteme sind fantastisch, wenn sie von Anfang an in den Stack eingeplant sind. Sie sind weniger fantastisch, wenn man sie nachträglich anschraubt, nur weil Plex einen Node-Neustart überleben soll.

    Und Performance? Klar, ich brauche keinen irrsinnigen Durchsatz. Ich jage keinen Benchmarks hinterher. Aber ich hätte gern 200 MB/s, ohne das Gefühl zu haben, das Schicksal herauszufordern.

    Irgendwann wurde mir klar, dass ich versuchte, ein NAS zu bauen … aus Dingen, die explizit keine NAS sind.

    Nochmal: Ich habe mir das selbst angetan.


    CephFS betritt den Chat

    Jede Storage-Reise führt irgendwann zurück zu Ceph. Es ist wie Storage-Schwerkraft.

    CephFS klingt perfekt:

    • Shared Filesystem
    • Nativ im Cluster
    • Aktiv auf mehreren Nodes
    • Keine merkwürdigen Fencing-Rituale

    Aber CephFS bringt seine eigenen Realitätschecks mit:

    • HDD-basierte Pools mögen Metadaten-Workloads nicht besonders
    • Alles mit nur zwei Nodes ist … spirituell unsicher
    • Die Replikations-Mathematik wird schnell unbequem

    Ja, Ceph hat Checksummen. Ja, es kann Korruption erkennen. Nein, das lässt Pools mit wenigen Replikaten nachts trotzdem nicht gut schlafen.

    Ceph ist am glücklichsten, wenn Sie ihm Folgendes geben:

    • Mehrere Nodes
    • Mehrere OSDs
    • Schnelle Netzwerke
    • Geduld

    Es ist weniger glücklich, wenn Sie es bitten, sich wie ein gemütliches kleines NAS zu verhalten.


    Währenddessen sitzt die Synology einfach nur da

    Das ist der Teil, der einen richtig fertigmacht.

    Die Synology beschwert sich nicht. Sie stellt keine philosophischen Fragen. Sie braucht kein Whiteboard.

    Sie macht einfach:

    • Bedient NFS
    • Behält ihre IP
    • Repliziert auf Anfrage
    • Existiert

    Irgendwann sagte eine sehr vernünftige Stimme in meinem Kopf:

    „Warum tust du dir das an?"

    Warum Bulk-Storage in den Cluster verschieben, wenn der Cluster dort, wo es zählt, bereits HA hat?

    Warum Ceph oder VSAN dazu zwingen, ein NAS zu werden, wenn ein echtes NAS NAS-Dinge bereits extrem gut erledigt?

    Die Antwort war leider Neugier. Und Stolz. Und der Glaube, es müsse doch einen sauberen Weg geben, alles zu vereinheitlichen.

    Gab es nicht. Nicht wirklich.


    Was daraus wurde (ein Storage-Waffenstillstand)

    Ich bin nicht bei der einen perfekten Lösung gelandet. Ich bin bei einem Kompromiss gelandet. Einem Waffenstillstand.

    • Ceph bleibt dort, wo es glänzt: VM-Disks, Container, Dinge, die schnelle Wiederherstellung brauchen
    • StarWind hat bewiesen, dass HA auf Block-Ebene funktioniert, fügt aber Schichten hinzu, die ich für Medien eigentlich nicht brauche
    • Synology macht weiterhin Bulk-Storage, weil es darin peinlich gut ist

    Und die große Erkenntnis war diese:

    Hochverfügbarkeit bedeutet nicht, dass alles geclustert sein muss.

    Manche Dinge müssen einfach nur zuverlässig sein. Manche Dinge müssen einfach nur schnell wieder online kommen. Manche Dinge sind besser langweilig.

    Der Versuch, allen Storage gleich verhalten zu lassen, ist genau der Weg, auf dem man bei drei Storage-Plattformen und einem Blogpost wie diesem landet.


    Die Erkenntnis (bevor ich noch mehr Hardware kaufe)

    Wenn Sie HA-Bulk-Storage innerhalb eines Virtualisierungs-Clusters anstreben, stellen Sie sich zuerst eine Frage:

    Will ich, dass das elegant ist — oder will ich, dass es funktioniert?

    Denn Eleganz kostet meist Komplexität.

    Und Komplexität schickt später immer eine Rechnung.

    Ich habe nicht versehentlich jede Storage-Idee auf einmal ausprobiert. Ich habe einfach immer wieder „das wird die Dinge vereinfachen" gesagt und mir das jedes Mal selbst geglaubt.

    Hat es nicht. Aber ich habe viel gelernt.

    Vor allem, dass manchmal die beste Architekturentscheidung ist, jedes Tool das machen zu lassen, worin es langweilig gut ist — und dem Drang zu widerstehen, alles zu vereinheitlichen, nur weil man es kann.

    Wenn Sie mich jetzt entschuldigen, ich muss aufhören, Storage-Diagramme anzusehen, bevor ich noch Object Storage hinzufüge, „nur um zu sehen, wie sich das anfühlt."

    Weiterführende Ressourcen