Traditional SAN vs. VMware vSAN: Architecture, Trade-offs, and How to Choose

Traditional storage area networks (SANs) and VMware vSAN both provide shared storage for applications and virtual machines, but they organize hardware and operations differently. A traditional SAN connects hosts to storage arrays over a storage network; vSAN pools devices inside ESXi hosts and presents the distributed capacity as a datastore.

That distinction matters more than a simple “hardware versus software” label. It affects failure domains, network design, scaling, supportability, operating skills, and how storage policies are enforced. This guide separates the two architectures and gives infrastructure teams a practical way to evaluate them against real workloads.

What Are Traditional SAN and VMware vSAN?

A traditional SAN is a dedicated block-storage architecture: one or more external storage arrays expose logical units to servers over a fabric, commonly Fibre Channel or iSCSI. Hosts see block devices and format or cluster them using an appropriate filesystem or application stack.

VMware vSAN is VMware’s software-defined, distributed storage platform integrated with ESXi. It combines eligible local devices across hosts in a vSAN cluster and presents the resulting capacity as a shared datastore. Virtual machine files are stored as distributed objects whose placement and protection follow storage policies.

The terminology can be confusing. “Virtual SAN” is sometimes used generically for virtualized storage, while vSAN is VMware’s product name. Neither term means that storage no longer depends on hardware or a network: vSAN still requires compatible devices, hosts, and a correctly designed storage network.

Why Compare the Architectures?

Both approaches can support virtual machines, databases, and other block-oriented workloads. The trade-off is where storage services run and which layer the team must design and operate.

With an external array, storage capacity and many data services are managed in the array. Hosts access it through a storage fabric, which can be a separately managed Fibre Channel network or an Ethernet-based iSCSI network. With vSAN, the storage data path is distributed across ESXi hosts; the cluster’s server hardware, network, and storage policies become part of the storage system.

This changes the questions to ask. Instead of comparing generic claims about speed or cost, assess workload latency and I/O patterns, failure and recovery requirements, existing equipment, growth plans, support contracts, and the skills available to operate the design.

How SAN and vSAN Work

Traditional SAN data path: application or VM → host filesystem or hypervisor datastore → multipath I/O → Fibre Channel or iSCSI fabric → array controllers → protected drives.

The array presents logical units (LUNs) to authorized hosts. Multipathing provides more than one route where the design supports it, while array controllers handle functions such as caching, RAID, snapshots, and replication. Fibre Channel commonly uses purpose-built switches and adapters; iSCSI carries SCSI commands over TCP/IP and can use Ethernet infrastructure designed for storage traffic. See IETF RFC 7143 for the iSCSI protocol specification.

VMware vSAN data path: application or VM → virtual disk object → vSAN policy and distributed data services → local devices on cluster hosts, coordinated over the vSAN network.

Each host contributes eligible storage devices. vSAN combines those devices into a datastore and distributes VM storage objects across the cluster according to policy. The policy specifies availability and placement requirements; vSAN translates those requirements into components and replicas or erasure-coded layouts where supported. When a host or device fails, the cluster evaluates object compliance and may rebuild or re-protect data on remaining capacity. The exact behavior and supported policy choices depend on the vSAN release, topology, and hardware configuration.

Broadcom’s vSAN 8 planning and deployment documentation describes vSAN as a distributed software layer integrated with ESXi. In both designs, the management interface is not a substitute for understanding the data path: storage-network latency, congestion, queueing, and the location of failures still affect applications.

Components, Variants, and Comparison

Core components

• Traditional SAN: storage arrays and controllers, drives, host bus adapters or Ethernet NICs, fabric switches, zoning or access controls, LUN masking, host multipathing, and the host-side filesystem or datastore.
• VMware vSAN: ESXi hosts, compatible storage controllers and devices, a network for vSAN traffic, a vSAN datastore, storage policies, and vCenter-based cluster management. Two-node and stretched designs also use a witness component for quorum; the witness is not a copy of workload data.
• Protection and placement: arrays commonly expose protection through RAID groups, pools, snapshots, and replication features. vSAN uses per-object policy settings, such as failures to tolerate and, where supported, mirroring or erasure coding. Policy availability depends on the number and arrangement of fault domains and on release-specific rules.

VMware vSAN has evolved through different storage architectures. Original Storage Architecture (OSA) designs use cache and capacity device roles; Express Storage Architecture (ESA) uses a different, single-tier device model. These are not interchangeable deployment recipes: check the documentation and compatibility requirements for the exact vSAN release and hardware before selecting a design.

At-a-glance comparison

Neither column guarantees a particular latency, availability, or total cost. Those outcomes depend on the complete design and workload rather than the product label.

Real-World Use Cases

A traditional SAN is often a strong fit when:

• The organization already operates arrays and a storage fabric with trained administrators and support coverage.
• Multiple hypervisor clusters, physical databases, or other servers need shared block storage from the same array platform.
• Array-level services, operational separation, or established replication workflows are requirements.
• A workload has specific latency or throughput targets that testing shows are best met by the array and fabric design.

VMware vSAN is often a strong fit when:

• Most storage consumers run as VMs on a VMware cluster, and the team wants to manage storage policy alongside virtual machines.
• A scale-out cluster using host-local devices fits the capacity and failure-domain plan.
• The organization can operate and support the complete ESXi, device, and network stack as a single system.
• Branch, edge, or private-cloud environments benefit from a distributed datastore, provided they meet the required topology and support constraints.

These are starting points, not rules. A traditional array can be a better fit for a VMware environment, and a distributed design can be appropriate for workloads beyond ordinary VMs. Test with the actual I/O profile and confirm application support.

Practical Selection and Operations Guide

Use a workload-first process rather than comparing list prices or peak benchmark numbers.

1. Record workload requirements. Measure read/write mix, block size, queue depth, working-set size, peak IOPS, throughput, and latency percentiles. Include growth, maintenance windows, and recovery objectives.
2. Define failure behavior. Identify which device, host, rack, site, or network failures the service must tolerate. Translate that requirement into an array protection and replication design or a vSAN topology and storage policy.
3. Check the full support matrix. For vSAN, validate the exact server, controller, firmware, drive, and ESXi/vSAN combination against the Broadcom Compatibility Guide. For a SAN, validate array, switch, adapter, driver, and multipathing interoperability with the vendors.
4. Estimate usable capacity, not raw capacity. Include protection overhead, metadata, snapshots, rebuild space, operational reserve, and expected growth. For vSAN, assess whether the cluster still has sufficient free capacity to restore the required policy after a failure.
5. Model network and I/O paths. Measure end-to-end latency and congestion under normal load and recovery activity. Keep storage traffic isolated or appropriately controlled, and confirm redundant paths behave as intended.
6. Compare lifecycle cost and responsibility. Include software and support subscriptions, array or node refreshes, switches and adapters, power, rack space, training, migration, and the operational cost of upgrades. Product packaging changes; verify current entitlements with the vendors rather than relying on an old per-terabyte or per-socket estimate.
7. Pilot and test failures. Replay representative workloads, test planned maintenance and component failures, observe rebuild impact, and prove application-level recovery. A storage policy or array replication feature is not itself a backup plan.

For a VMware environment, these read-only ESXi commands provide a basic view of cluster membership and devices; run them on a host with appropriate administrative access:

esxcli vsan cluster get
esxcli vsan storage list

Use the VMware vSAN technology overview and the release-specific Broadcom guide when interpreting output or planning changes. Do not make production configuration changes from a generic command example; validate the workflow for the deployed version and topology.

For conventional iSCSI environments, review iSCSI multipathing concepts and the iSCSI SAN implementation guide before designing redundant paths.

Common Misconceptions

• “vSAN removes the storage network.” It does not. Hosts exchange storage traffic over the network, so bandwidth, latency, redundancy, and traffic control are integral to the design.
• “Every virtual SAN is VMware vSAN.” No. VMware vSAN is one product; other hyperconverged and software-defined storage systems have different architectures and requirements.
• “HCI is always cheaper and simpler.” Consolidating compute and storage can simplify some operations, but it also couples their scaling and failure domains. Include support, licensing, hardware refresh, and staff costs in a workload-based comparison.
• “More nodes automatically mean more resilience.” Resilience depends on fault-domain placement, policy, available rebuild capacity, and the failures the design can survive—not just the cluster’s node count.
• “RAID or storage policies replace backups.” Redundancy can keep service available after certain failures, but it may also reproduce deletion, corruption, or ransomware changes. Maintain and test independent backups.
• “A SAN is always faster than vSAN.” Performance depends on the application, device, network, queueing, caching, and protection layout. Benchmark the complete supported configuration with a representative workload.

Related Articles

• Storage virtualization technologies: concepts and types
• iSCSI multipathing explained
• iSCSI SAN implementation guide
• Block storage performance optimization
• Storage Spaces Direct architecture

Photo by Nao Triponez.