How I Ended Up Running Ceph, StarWind and Synology at Once
There's a specific moment in every homelab journey where you stop building things and start negotiating with them. You're past fixing and past optimizing at that point. It's when your storage stack looks back at you and says, "We need to talk."
This is a story about how I ended up running Ceph, StarWind VSAN, and Synology at the same time. None of it was planned as a multi-tier architecture. It happened one simplification attempt at a time, and each attempt added another layer. The result was a storage turducken, delicious in theory and concerning in practice.
I didn't set out to try every storage idea at once. I just wanted one thing: high availability bulk storage that doesn't explode when a node sneezes. That was the whole dream, and yes, I did this to myself.
The original plan (which was perfect, obviously)
I run a small Proxmox cluster, five nodes, nothing wild, and it's been humming along for years. At some point I did the sensible thing and set up Ceph because:
- It's native
- It's "enterprise"
- Everyone says "just use Ceph" with the confidence of someone who has already suffered
And Ceph worked, for VM disks, for containers, and for things that need to stay up when a host dies. No complaints there.
Then there was bulk storage: Plex libraries, Frigate footage, media files that don't care about IOPS but do care about staying online. That's the kind of stuff you want to mount once and never think about again.
Enter the Synology RackStation. It did exactly what it was supposed to do, with SMB, NFS, and a single IP. It was rock solid, boring, and beautiful, and it sat there being competent without any fuss while I pretended it was "temporary."
And then I thought, "What if I moved that storage into the cluster?" That's where everything went off the rails.
StarWind: "this will be simple" (narrator: it wasn't)
Ceph already existed, but I wanted something a little more… SAN-shaped for bulk storage, with synchronous replication, something that felt like a block device I could reason about. So I added StarWind VSAN.
To be fair, StarWind did what it promised: iSCSI volumes, HA, mirroring, and the comforting illusion of enterprise software making hard decisions for me. Now I had:
- Ceph for VM and container disks
- StarWind for bulk HA storage
- Synology for… backups? emotional support?
By then my storage diagram no longer fit on one screen. Replication worked fine. The open question was how to actually use it without everything being duct tape.
The IP problem (a.k.a. "why can't this just behave like a NAS?")
Synology absolutely nails one thing. You mount it, it has an IP, and if something breaks it fails over while your mounts don't care. That's the gold standard, and that's the bar.
What I wanted was Synology HA behavior backed by my shiny VSAN storage. What I got was a long stare into the abyss of clustered filesystems, volume managers, and "technically possible" solutions.
Block storage is easy, and shared filesystem semantics are not. iSCSI gives you a block device, but only one thing gets to write to it unless you want chaos. So the questions started piling up:
- Do I pass the iSCSI volume directly to containers?
- Do I wrap it in LVM?
- Do I abandon Proxmox LVs entirely?
- Do I need GFS2? OCFS2? Some other acronym that smells like pain?
Every answer came with a warning label.
"Just use a clustered filesystem" (cool cool cool)
On paper, the solution looks straightforward:
- Present the iSCSI LUN to multiple nodes
- Put a clustered filesystem on top
- Mount it everywhere
- Bind-mount into containers
- Profit
In reality, every step is a trade-off between fragility, performance, and complexity. Pick two, or sometimes one.
Clustered filesystems are amazing when they're designed into the stack. They are less amazing when bolted on because you want Plex to survive a node reboot. As for performance, I don't need insane throughput and I'm not chasing benchmarks, but I'd like to hit 200 MB/s without feeling like I'm tempting fate.
At some point I realized I was trying to build a NAS out of things that are explicitly not NASes. Again, I did this to myself.
CephFS enters the chat
Every storage journey eventually loops back to Ceph. It's like storage gravity. CephFS sounds perfect:
- Shared filesystem
- Native to the cluster
- Active on multiple nodes
- No weird fencing rituals
But CephFS comes with its own reality checks:
- HDD-backed pools don't love metadata workloads
- Two-node anything is… spiritually unsafe
- Replication math gets uncomfortable fast
Yes, Ceph has checksums, and yes, it can detect corruption. No, that doesn't magically make low-replica pools feel good at night. Ceph is happiest when you give it multiple nodes, multiple OSDs, fast networks, and patience. It's less happy when you ask it to behave like a cozy little NAS.
Meanwhile, the Synology is just sitting there
This part really messes with you. The Synology doesn't complain, doesn't ask philosophical questions, and doesn't need a whiteboard. It serves NFS, keeps its IP, replicates when asked, and otherwise just exists.
Eventually a very reasonable voice in my head asked, "Why are you doing this?" Why move bulk storage into the cluster when the cluster already has HA where it matters? Why force Ceph or VSAN to become a NAS when an actual NAS is already doing NAS things extremely well?
The answer, unfortunately, was curiosity, pride, and the belief that there had to be a clean way to unify everything. There wasn't, not really.
What this turned into (a storage truce)
I didn't end up with a single perfect solution. I ended up with a compromise, more of a ceasefire:
- Ceph stays where it shines: VM disks, containers, things that need fast recovery
- StarWind proved block-level HA works, but adds layers I don't actually need for media
- Synology keeps doing bulk storage, because it is embarrassingly good at it
The big realization was that high availability doesn't mean everything must be clustered. Some things just need to be reliable, some just need to come back online quickly, and some are better boring. Trying to make all storage behave the same is how you end up with three storage platforms and a blog post like this.
The takeaway (before I buy more hardware)
If you're chasing HA bulk storage inside a virtualization cluster, ask yourself one question first: do I want this to be elegant, or do I want it to work? Elegance usually costs complexity, and complexity always sends an invoice later.
I didn't accidentally try every storage idea at once. I just kept saying "this will simplify things" and believing myself every time. It never did, though I learned a lot, mostly that the best architecture decision is sometimes letting each tool do the thing it's boringly good at and resisting the urge to unify everything just because you can.
Now if you'll excuse me, I need to stop looking at storage diagrams before I add object storage "just to see how it feels."