A SAN, short for storage area network, is a dedicated network that connects servers to shared storage devices at the block level. Servers see the storage as locally attached disks, called LUNs or volumes, even though the data lives on separate storage arrays reached through switches and specialized protocols.
In server storage, a SAN separates compute from capacity: storage can be pooled, protected, expanded and moved between servers without opening each machine. This makes the SAN a traditional foundation for virtualization clusters, databases and other workloads that need consistent latency and high availability.
How a storage area network works
A SAN has three main parts. Hosts contain adapters such as Fibre Channel host bus adapters or Ethernet network cards. A fabric of switches carries storage traffic. Storage arrays contain disks or flash, controllers, cache and the software that carves capacity into logical volumes.
The host operating system sends SCSI or NVMe commands for numbered blocks, exactly as it would to an internal disk. The file system, such as NTFS, XFS or VMFS, runs on the host, not on the array. This is the defining difference from file-level storage, where the storage device manages the file system itself.
Access is controlled at two levels. Zoning on the switches decides which host ports can see which array ports, and LUN masking on the array decides which hosts may access which volumes. Together they prevent servers from writing to volumes that belong to other systems.
SAN protocols and transport options
SANs can be built on several transports. The choice determines latency, required hardware and operational skills. The table below compares the main options with typical link speeds.
| Protocol | Network | Typical link speeds | Characteristics |
|---|---|---|---|
| Fibre Channel (FC) | Dedicated FC fabric | 16, 32 or 64 Gbit/s | Lossless, low latency, specialized skills |
| iSCSI | Standard TCP/IP Ethernet | 10 to 100 Gbit/s | Lower cost, uses familiar network equipment |
| FCoE | Lossless Data Center Bridging Ethernet | 10 to 40 Gbit/s | Converged network, now uncommon |
| NVMe over Fabrics | FC, RDMA or TCP | 25 to 100 Gbit/s and above | Very low latency for flash arrays |
Fibre Channel was long the default for enterprise SANs because its fabric is designed to avoid packet loss. iSCSI made SANs accessible to smaller organizations, and NVMe over Fabrics now extends the low-latency NVMe command set across the network to exploit modern flash storage.
SAN compared with NAS and other storage models
The most frequent comparison is SAN versus NAS. The acronyms look alike, but they describe different access methods: a SAN delivers raw blocks, while a NAS delivers files over a network share.
| Model | Access level | Typical protocols | Typical use |
|---|---|---|---|
| SAN | Block | Fibre Channel, iSCSI, NVMe-oF | Databases, virtual machine datastores |
| NAS | File | NFS, SMB | Shared folders, home directories, media |
| Direct-attached storage | Block, one host | SAS, SATA, local NVMe | Single servers, boot disks |
| Software-defined storage | Block, file or object | Ceph RBD, CephFS, S3 | Scale-out clusters on standard servers |
| Cloud block storage | Block | Provider-specific virtual disks | Volumes attached to cloud instances |
Because block storage has no awareness of files, two servers cannot simply mount the same SAN volume with an ordinary file system. Shared access requires a cluster file system such as VMFS, GFS2 or OCFS2, or an application that coordinates access itself; otherwise data corruption is likely.
Designing and operating a SAN
Production SAN designs emphasize redundancy at every layer. A typical layout uses two independent fabrics, called fabric A and fabric B, so that every host has at least two physical paths to every volume. Multipathing software on the host balances traffic across paths and fails over when one path breaks.
The following table lists the design parameters administrators decide on and the values commonly used.
| Parameter | Typical choice | Why it matters |
|---|---|---|
| Fabric redundancy | Two separate fabrics | No single switch failure stops storage |
| Paths per volume | Two to eight | Bandwidth and failover capacity |
| Zoning style | Single initiator, single target | Limits disruption and simplifies troubleshooting |
| RAID or erasure coding on the array | RAID 6, RAID 10 or vendor equivalents | Protects against drive failures |
| Provisioning | Thin provisioning with capacity alerts | Efficient use of capacity, needs monitoring |
| iSCSI network | Dedicated VLANs or switches, jumbo frames where supported | Isolates storage traffic from user traffic |
Performance is described with IOPS, throughput and latency. All-flash arrays commonly deliver latencies well below one millisecond, while arrays built on spinning disks typically show several milliseconds. Workload patterns, such as small random writes from databases versus large sequential reads from backups, decide which metric limits the system.
Limitations and common mistakes
SANs deliver strong performance and availability but bring cost and complexity. They are justified when several servers need shared, highly available block storage, and less so for a single server or for file sharing.
| Problem | Cause | Prevention |
|---|---|---|
| Volume corruption | Two hosts mounting one LUN without a cluster file system | Strict LUN masking and documented ownership |
| Outage during switch maintenance | Single fabric or single path | Dual fabrics and verified multipathing |
| Array suddenly read-only | Thin pool exhausted | Capacity alerts and overcommit limits |
| Poor iSCSI performance | Storage traffic shares busy user networks | Separate VLANs, flow control, tuned MTU |
| Slow latency under load | Saturated controllers or ports | Monitor queue depth and rebalance workloads |
A SAN also does not replace backup. Snapshots and replication on the array protect against many failures, but they share the same management plane and can be affected by the same error, ransomware or firmware fault, so independent backups remain necessary.
A non-technical view
A SAN is a separate high-speed network built only for storage. Instead of each server keeping its own disks inside the case, many servers share a large central pool of disks that they reach through this network.
To each server, its share of the pool looks and behaves like its own hard drive. Because the storage is central, it can be protected, enlarged and moved to another server without unplugging anything.
A concrete example
A regional hospital runs its patient record system on a cluster of six virtualization hosts. All virtual machines live on an all-flash array connected through two independent Fibre Channel fabrics at 32 Gbit/s, and each host reaches every datastore through four paths with multipathing enabled.
When one fabric switch fails during a night shift, multipathing moves all traffic to the remaining fabric within seconds. Clinicians notice no interruption, the failed switch is replaced the next morning, and because each host could also restart virtual machines from shared storage, a later host failure caused only a brief restart instead of hours of downtime.