vSAN vs. a Traditional Storage Appliance: When Local-Disk Distributed Storage Is the Right Call

A traditional storage appliance and vSAN solve the same problem, giving a cluster of hosts a shared place to put VM data, but they get there in almost opposite ways. An appliance is dedicated hardware with its own controllers, sitting behind a switch fabric that every host connects into. vSAN takes the disks already inside each ESXi host and pools them into a single distributed datastore across the cluster, using the network the hosts are already connected to instead of a separate storage fabric.

How vSAN Actually Works

Each host in a vSAN cluster contributes local disks, split into cache and capacity tiers, into disk groups. vSAN then stripes and replicates data across those disk groups on multiple hosts, so a single host failure doesn't mean data loss. There's no external array, no dedicated storage controller, and no separate storage network protocol to manage. Policy for a given VM, how many host failures it can tolerate and how it gets striped, is set per virtual machine through Storage Policy Based Management rather than provisioned once at the array level for everything sitting on it.

Where vSAN Is the Right Call

vSAN earns its place when compute and storage need to scale together and when a dedicated Fibre Channel or iSCSI fabric adds cost and complexity the environment doesn't need. Adding a host adds both compute and storage capacity in one step, instead of a separate conversation with the storage side about array headroom. For a cluster built primarily to run VMware workloads, that simplicity is real. There's one less piece of dedicated hardware to maintain, patch, and eventually replace at end of life, and the network requirement, 10 Gigabit Ethernet at minimum, faster for larger clusters, is often already in place for other reasons.

Where an Appliance Still Makes Sense

A dedicated appliance still wins in a few specific situations. Workloads with extremely deterministic, sustained IOPS requirements can benefit from storage controllers tuned specifically for that job. An environment where non-VMware systems, physical database servers, or other hypervisors, need to share the same storage pool has a real reason to keep a shared array rather than a datastore that's fundamentally tied to ESXi hosts. And an organization that already has a recently purchased, well-amortized appliance under support has a legitimate cost argument for running it out its useful life before switching models.

What to Check Before Deciding

• Minimum host count. A standard vSAN cluster needs at least three hosts for full fault tolerance; a two-node cluster works for remote sites but needs a separate witness appliance.
• Disk group design. Cache tier and capacity tier devices need to be sized and matched correctly, this isn't a place to reuse whatever drives were already on hand.
• Network capacity. vSAN traffic runs across the same fabric as everything else unless a dedicated VLAN is carved out, so bandwidth planning has to account for storage traffic, not just VM traffic.
• Existing appliance depreciation. If a current SAN still has real years of useful life and support left, that's a legitimate reason to wait.

How Fault Tolerance Actually Gets Configured

The failure tolerance a vSAN policy provides isn't a single setting, it's a choice between methods with real capacity and performance tradeoffs. Mirroring, effectively RAID-1 across hosts, gives the best performance and the simplest recovery path after a failure, at the cost of using roughly double the raw capacity for every unit of usable storage. Erasure coding, RAID-5 or RAID-6 depending on cluster size, uses capacity far more efficiently but adds write overhead and needs a larger minimum cluster to implement safely. Neither is a universal default. The right policy depends on whether the workload sitting on it is more sensitive to storage efficiency or to write latency, and that's a per-VM decision vSAN is actually built to support rather than a cluster-wide compromise.

The right answer depends on what's already sitting in the rack and what the workload actually needs, not on which approach is newer. Gibson IT assesses both before recommending either. Call (407) 485-8884 or request a free evaluation to find out which one fits your environment.