Ceph, StarWind, Synology: Wie ich versehentlich jede Storage-Idee gleichzeitig ausprobiert habe
Auf jeder Homelab-Reise kommt der Moment, in dem man aufhört, Dinge zu bauen, und anfängt, mit ihnen zu verhandeln. Reparieren oder optimieren tut man dann nicht mehr, man verhandelt. Ihr Storage-Stack sieht Sie an und sagt: „Wir müssen reden."
So kam es, dass ich am Ende Ceph, StarWind VSAN und Synology gleichzeitig betrieben habe. Geplant hatte ich keine elegante mehrstufige Architektur. Jeder Versuch, die Dinge zu vereinfachen, fügte nur irgendwie eine weitere Schicht hinzu, bis ein Storage-Turducken entstand, in der Theorie köstlich und in der Praxis beunruhigend.
Jede Storage-Idee auf einmal auszuprobieren war nie mein Ziel. Ich wollte genau eine Sache: hochverfügbaren Bulk-Storage, der nicht explodiert, sobald ein Node niest. Das war der ganze Traum, und alles Weitere habe ich mir selbst angetan.
Der ursprüngliche Plan (natürlich perfekt)
Ich betreibe einen kleinen Proxmox-Cluster mit fünf Nodes, nichts Wildes, und er läuft seit Jahren vor sich hin. Irgendwann 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 Ceph hat funktioniert, für VM-Disks, für Container und für alles, was weiterlaufen muss, wenn ein Host stirbt. Da gibt es nichts zu meckern.
Dann war da aber noch der Bulk-Storage: Plex-Bibliotheken, Frigate-Aufnahmen und Mediendateien, denen IOPS egal sind, die aber online bleiben sollen. Zeug, das einmal gemountet und danach nie wieder angefasst werden will.
Dafür gab es die Synology RackStation. Sie tat genau, was sie sollte, mit SMB, NFS und einer einzigen IP. Bombenfest, langweilig, wunderschön. Sie stand einfach da und machte kompetent ihre Arbeit, während ich so tat, als sei sie nur „vorübergehend."
Und dann dachte ich: „Was, wenn ich diesen Storage in den Cluster verschiebe?"
Ab da lief alles aus dem Ruder.
StarWind: „Das wird einfach" (Erzähler: War es nicht)
Ceph war schon da, aber für den Bulk-Storage wollte ich etwas, das ein bisschen mehr nach SAN aussah. Etwas mit synchroner Replikation, das sich wie ein Block-Device anfühlte, über das ich nachdenken konnte.
Also kam StarWind VSAN dazu. Fairerweise muss man sagen, dass StarWind gehalten hat, was es versprach: iSCSI-Volumes, HA, Mirroring und die beruhigende Illusion, dass Enterprise-Software mir die schweren Entscheidungen abnimmt.
Jetzt hatte ich:
- Ceph für VM- und Container-Disks
- StarWind für HA-Bulk-Storage
- Synology für … Backups? Emotionale Unterstützung?
Mein Storage-Diagramm passte inzwischen nicht mehr auf einen Bildschirm.
Ob der Storage replizierte, war dabei gar nicht die Frage. Ich wollte wissen, wie ich das Ganze tatsächlich nutze, ohne dass alles aus Panzertape besteht.
Das IP-Problem (a.k.a. „Warum kann sich das nicht einfach wie ein NAS verhalten?")
Synology bekommt eine Sache absolut perfekt hin. Sie mounten das NAS, es hat eine IP, und wenn etwas kaputtgeht, failt es over, ohne dass Ihre Mounts es überhaupt merken. Das ist der Goldstandard und die Messlatte.
Ich wollte das HA-Verhalten von Synology, aber mit meinem glänzenden VSAN-Storage dahinter. Stattdessen blickte ich lange in einen Abgrund aus Cluster-Dateisystemen, Volume-Managern und „technisch möglichen" Lösungen.
Block-Storage ist nämlich einfach, die Semantik eines Shared Filesystems ist es nicht. iSCSI liefert ein Block-Device, auf das nur eine Instanz schreiben darf, wenn man kein Chaos will.
Also stapelten sich 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:
- Die iSCSI-LUN mehreren Nodes präsentieren
- Ein Cluster-Dateisystem obendrauf legen
- Überall mounten
- Per Bind-Mount in Container einbinden
- Profit
In der Realität entscheidet man bei jedem Schritt zwischen Zerbrechlichkeit, Performance und Komplexität. Zwei davon kann man haben, manchmal nur eins.
Cluster-Dateisysteme sind fantastisch, wenn sie von Anfang an im Stack eingeplant sind. Nachträglich angeschraubt, nur damit Plex einen Node-Neustart überlebt, sind sie weniger fantastisch.
Und die Performance? Irrsinnigen Durchsatz brauche ich nicht, Benchmarks jage ich auch nicht hinterher. Aber 200 MB/s hätte ich schon gern, ohne das Gefühl, das Schicksal herauszufordern.
Irgendwann wurde mir klar, dass ich gerade ein NAS aus Dingen baute, die ausdrücklich keine NAS sind. Wie gesagt, ich habe mir das selbst angetan.
CephFS betritt den Chat
Jede Storage-Reise führt irgendwann zu Ceph zurück, als gäbe es eine Art Storage-Schwerkraft.
CephFS klingt perfekt:
- Shared Filesystem
- Nativ im Cluster
- Aktiv auf mehreren Nodes
- Keine merkwürdigen Fencing-Rituale
CephFS bringt aber 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, und ja, es erkennt Korruption. Trotzdem schlafen Pools mit wenigen Replikaten nachts nicht gut.
Am glücklichsten ist Ceph, wenn Sie ihm Folgendes geben:
- Mehrere Nodes
- Mehrere OSDs
- Schnelle Netzwerke
- Geduld
Weniger glücklich ist es, wenn Sie verlangen, dass es sich wie ein gemütliches kleines NAS benimmt.
Währenddessen steht die Synology einfach da
Dieser Teil macht einen richtig fertig. Die Synology beschwert sich nicht, stellt keine philosophischen Fragen und braucht kein Whiteboard. Sie bedient NFS, behält ihre IP, repliziert auf Anfrage und existiert, sonst nichts.
Irgendwann fragte 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, schon HA hat? Warum Ceph oder VSAN zum NAS verbiegen, wenn ein echtes NAS die NAS-Aufgaben längst hervorragend erledigt?
Die Antwort war leider Neugier, dazu Stolz und der Glaube, es müsse doch einen sauberen Weg geben, alles zu vereinheitlichen. Den gab es nicht, jedenfalls nicht wirklich.
Was daraus wurde: ein Storage-Waffenstillstand
Die eine perfekte Lösung habe ich nicht gefunden. Herausgekommen ist ein Kompromiss, eine Art 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
Die wichtigste Erkenntnis: Hochverfügbarkeit heißt nicht, dass alles geclustert sein muss. Manches muss nur zuverlässig sein, manches schnell wieder online kommen, und manches ist langweilig einfach besser.
Wer allen Storage gleich behandeln will, landet genau so bei drei Storage-Plattformen und einem Blogpost wie diesem.
Die Erkenntnis, bevor ich noch mehr Hardware kaufe
Wenn Sie HA-Bulk-Storage innerhalb eines Virtualisierungs-Clusters anstreben, fragen Sie sich zuerst, ob es elegant sein soll oder ob es funktionieren soll. Eleganz kostet meist Komplexität, und für Komplexität kommt später immer eine Rechnung.
Streng genommen habe ich nicht versehentlich jede Storage-Idee auf einmal ausprobiert. Ich habe nur immer wieder „das wird die Dinge vereinfachen" gesagt und es mir jedes Mal selbst geglaubt. Vereinfacht hat es nichts, aber ich habe viel gelernt.
Vor allem, dass die beste Architekturentscheidung manchmal darin besteht, jedes Tool das tun 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 anzustarren, bevor ich auch noch Object Storage hinzufüge, „nur um zu sehen, wie sich das anfühlt."