In the world of cloud hosting, shared storage systems like SANs and Ceph clusters are often marketed as the foundation of high availability. They promise transparent live migration, automatic failover, and zero-downtime maintenance. It sounds compelling — until you witness one fail. We have seen it too many times. That is why BinaryLane is philosophically opposed to network-attached storage for VPS infrastructure, and why we believe true high availability belongs at the application layer, not buried inside a storage fabric you cannot control.
The Allure of Shared Storage
The pitch is straightforward: put all your virtual machine disks on a centralised storage cluster — a SAN, a Ceph pool, or some proprietary distributed filesystem. Because the storage is decoupled from the compute node, the hypervisor can live-migrate VMs between physical hosts seamlessly. A host needs maintenance? Migrate the VMs. A host dies? Restart the VMs on another host — the disks are already accessible from everywhere.
On paper, this is elegant. In practice, it introduces a single point of failure that is far more dangerous than the one it claims to eliminate.
The Hidden Risk: Shared Failure Domains
When every VM on a platform reads and writes to the same storage fabric, that fabric becomes the most critical component in the entire infrastructure. And when it fails — not if, but when — the blast radius is catastrophic.
| Failure Type | Local RAID10 Impact | Shared Storage (SAN/Ceph) Impact |
|---|---|---|
| Disk failure | One node degraded, RAID rebuilds | Potentially all nodes experience degraded I/O |
| Controller or network failure | One node loses storage | Every VM on the cluster loses storage |
| Firmware bug | One node affected | Entire storage fabric affected |
| Corruption or split-brain | One node’s data at risk | Cluster-wide data integrity risk |
| Blast radius | 1 server | Hundreds of servers |
We have seen shared storage arrays take down entire hosting platforms. A single firmware update gone wrong. A network partition between storage nodes causing a split-brain. A failed controller that cascaded into a full cluster lockup. Every time, the result is the same: every customer on the platform goes down simultaneously, and recovery takes hours — sometimes days — because the complexity of the shared system makes diagnosis and repair painfully slow.
Local RAID10: Smaller Blast Zones
BinaryLane takes a fundamentally different approach. Each compute node has its own local RAID10 storage array. Your VPS disk lives on the same physical machine that runs your VPS. There is no storage network, no shared fabric, no centralised controller sitting between your VM and its data.
RAID10 provides excellent redundancy at the disk level — multiple drives can fail without data loss. But more importantly, each node is an isolated failure domain. If a node suffers a catastrophic hardware failure — motherboard, PSU, or otherwise — only the VMs on that specific node are affected. Every other node on the platform continues operating normally.
Backups are performed to separate backup infrastructure, not to the same node. So even in a total node loss scenario, your data is recoverable and a new VPS can be provisioned and restored.
This is a deliberate engineering choice: do not build a bigger bomb — build smaller blast zones.
Why a Single Instance Can Never Be Highly Available
Here is a truth that shared storage vendors do not like to advertise: no single virtual server instance is highly available, regardless of the storage layer underneath it.
A single VPS on a SAN-backed platform can survive a disk failure — but so can a single VPS on local RAID10. Neither can survive a compute node failure without downtime. The SAN-backed platform might restart your VM on another host automatically, but that still involves downtime — the VM must boot, services must start, connections must re-establish. That is not high availability. That is automated disaster recovery, which is a different thing entirely.
True high availability means zero downtime during any single component failure. By definition, this requires multiple independent instances with automated failover — and that is an application-layer concern, not a storage-layer one.
HA Belongs at the Application Layer
Only you know your application’s availability requirements. Only you know which failures you need to survive, what your recovery time objectives are, and how much redundancy is worth the cost. Pushing HA down into the storage infrastructure takes that control away from you and replaces it with a one-size-fits-all solution that may not actually meet your needs.
Application-layer HA gives you:
- Control over failover behaviour — you decide what happens when a component fails
- Geographic distribution — you can spread across cities and regions, not just hosts
- No vendor lock-in — your HA design is portable across any infrastructure provider
- True fault isolation — each instance is independent, with no shared failure domains
- Cost efficiency — you add redundancy where it matters, not everywhere uniformly
This Site Is the Proof
This very website — wp.adamhomenet.com — runs on BinaryLane infrastructure with no shared storage and no infrastructure-level HA. Instead, high availability is built entirely at the application layer:
| Layer | Implementation | What It Survives |
|---|---|---|
| Load Balancing | BinaryLane anycast load balancer | Automatic traffic rerouting on node failure |
| Web Tier | 6 web servers across Sydney, Melbourne, and Brisbane | Loss of any node, host, or entire region |
| Host Separation | Partner servers guaranteed on different physical hosts | Complete compute node failure |
| Database | MariaDB primary + 2 cross-region replicas with HyperDB read/write splitting | Replica failure, region loss, read scaling |
| Backups | Daily backups to separate backup infrastructure | Total node loss with full data recovery |
Every component can fail independently without taking down the site. No shared storage required. No live migration needed. Just multiple independent instances, in multiple cities, with automated failover — which is what high availability actually means.
💡 The Bottom Line
Shared storage creates the illusion of high availability by hiding complexity behind a storage fabric. Local storage with application-layer HA creates genuine high availability by eliminating shared failure domains entirely. We would rather give you cheap, reliable, isolated compute nodes and let you build the redundancy your application actually needs — than charge you a premium for a shared storage layer that might one day take down every server on the platform at once.