A Storage Area Network (SAN) is a dedicated, high-speed network that connects servers to shared pools of block-level storage devices, making that storage appear to each server as if it were a local, directly attached disk.
SANs sit apart from the general-purpose local area network (LAN) that carries ordinary application and user traffic, which is what allows them to deliver the low latency and high throughput that transaction-heavy workloads like databases, virtualization platforms, and email systems require. Because a SAN moves data in raw blocks rather than files, the server’s operating system and file system manage the data exactly as they would with a local hard drive, even though the physical disk may be racks away. SANs have long been the standard architecture for enterprise block storage, and the same block-access model now underpins block storage offerings from cloud and hybrid-cloud infrastructure providers, including Zadara.
How a SAN Works
A SAN’s job is to make storage that lives on a separate array of disks behave, from the server’s point of view, exactly like a disk plugged directly into that server. It does this by carrying SCSI or NVMe commands over a dedicated network fabric instead of a local bus, using three basic building blocks: initiators, targets, and the fabric that connects them.
An initiator is the component on the server side — typically a host bus adapter (HBA) or a network interface configured for storage traffic — that originates read and write requests. A target is the storage array or controller that receives those requests and serves the actual data from its disks. Between them sits the fabric: one or more dedicated switches, plus the cabling, that route traffic between every initiator and every target on the network. Unlike a shared LAN switch, a SAN fabric switch is purpose-built for storage traffic, and Fibre Channel fabrics in particular use their own addressing scheme (World Wide Names, or WWNs) and zoning rules to control exactly which initiators can see which targets.
Zoning and LUN masking are the two access-control layers that make a shared SAN safe for multiple servers at once. Zoning, configured at the fabric switch, restricts which initiators and targets can even communicate. LUN masking, configured at the storage array, further restricts which specific logical unit numbers (LUNs — the individual block volumes carved out of the array) each initiator is allowed to mount. Together, they let dozens or hundreds of servers share one physical array while each server sees only the volumes assigned to it.
SAN Protocols
A SAN can run over more than one underlying protocol, and the choice affects cost, performance, and how much specialized hardware is required. All of them ultimately carry block-level storage commands (SCSI or, in newer designs, NVMe) between initiator and target.
Fibre Channel (FC)
Fibre Channel is a purpose-built storage networking protocol that runs over dedicated optical or copper cabling and dedicated switches, independent of standard Ethernet. It has historically offered the lowest latency and highest reliability of the mainstream SAN protocols, which is why it remains common in large enterprise data centers running mission-critical databases. Fibre Channel speeds are typically described by generation — 8, 16, and 32 gigabit FC (GFC) are widely deployed, with 64GFC available in newer arrays and switches and 128GFC defined by the Fibre Channel Industry Association’s roadmap for future deployment.
iSCSI
iSCSI (Internet Small Computer System Interface) encapsulates SCSI commands inside standard TCP/IP packets, letting a SAN run over ordinary Ethernet switches and network interface cards rather than dedicated Fibre Channel hardware. That makes iSCSI substantially cheaper to deploy and easier to manage, at the cost of somewhat higher and less predictable latency than Fibre Channel, particularly on shared or congested networks. iSCSI is a common choice for mid-sized deployments and cloud-delivered block storage, where the flexibility of standard IP networking outweighs the last increment of performance.
FCoE (Fibre Channel over Ethernet)
FCoE encapsulates native Fibre Channel frames directly inside Ethernet frames, aiming to combine FC’s low-latency, lossless delivery with the goal of converging storage and data traffic onto a single Ethernet fabric. It requires Ethernet hardware that supports Data Center Bridging (DCB) to guarantee the lossless behavior FC traffic depends on. FCoE saw meaningful enterprise adoption as a network-convergence strategy, though it has since been overtaken in new deployments by iSCSI’s simplicity and by NVMe-oF’s performance advantages.
NVMe-oF (NVMe over Fabrics)
NVMe over Fabrics extends the low-latency, highly parallel NVMe protocol — originally designed for local flash storage attached directly over PCIe — across a network fabric, using transports such as Fibre Channel (FC-NVMe), RDMA over Converged Ethernet (RoCE), or TCP. Because NVMe was designed from the ground up for flash rather than adapted from spinning-disk-era SCSI, NVMe-oF SANs can support far more simultaneous command queues and generally deliver lower latency than SCSI-based Fibre Channel or iSCSI, making it the protocol of choice for new all-flash SAN deployments where performance is the priority.
Key Components of a SAN
Host Bus Adapters (HBAs) and Network Adapters
The physical or virtual adapter installed in each server that connects it to the SAN fabric and acts as the initiator. Fibre Channel deployments use dedicated FC HBAs; iSCSI deployments can use standard Ethernet NICs with software initiators or offload-capable iSCSI HBAs.
Fabric Switches
Dedicated switches that interconnect every initiator and target on the SAN. Fibre Channel fabrics use FC switches with fabric-specific services (naming, zoning, routing); iSCSI and NVMe/TCP SANs run over standard, though often segregated, Ethernet switches.
Storage Arrays and Controllers
The physical disk enclosures — spinning disk, all-flash, or a hybrid of both — along with the controller hardware that presents storage out as LUNs and serves the actual read/write I/O. The array is the target side of every SAN transaction.
Cabling and Transceivers
Fibre Channel typically runs over fiber-optic cable with SFP transceivers matched to the link speed; iSCSI and NVMe/TCP run over standard copper or fiber Ethernet cabling. Cabling and transceiver choice directly caps the maximum throughput of the link.
SAN Management Software
Tools for provisioning LUNs, configuring zoning and multipathing, monitoring fabric health, and managing snapshots or replication. In larger environments this software also handles capacity planning and performance monitoring across the whole fabric.
Benefits of a SAN
High Performance
Because the SAN is a dedicated network carrying only block storage traffic, it avoids contention with general application and user traffic on the LAN, which keeps latency low and throughput consistent — critical for I/O-intensive workloads like OLTP databases.
Centralized, Consolidated Storage
Multiple servers share pools of storage on shared arrays instead of each server carrying its own local disks. This raises utilization, simplifies capacity planning, and reduces the amount of stranded, underused capacity spread across individual machines.
Scalability
Capacity and performance can generally be added by expanding the array or the fabric without disrupting the servers already attached to it, which suits environments where storage needs grow independently of compute.
High Availability and Resilience
Redundant HBAs, multiple fabric paths, and dual controllers on the array let a well-designed SAN survive the failure of a single cable, switch, or controller without an application outage — a level of fault tolerance that’s harder to achieve with storage local to a single server.
Efficient Backup, Replication, and Snapshots
Because all the storage is centralized and network-accessible, SANs simplify array-based snapshots, block-level replication, and centralized backup, without needing to pull data back through each individual server’s local I/O path.
SAN vs. NAS
SAN and NAS are the two classic architectures for network storage, and the distinction that matters most is the level at which each one hands data to the client: a SAN presents raw blocks, while a NAS presents complete files.
A SAN target is mounted by the server’s operating system as if it were a local disk; the server’s own file system (NTFS, ext4, and so on) is what turns those raw blocks into files and folders. A NAS device, by contrast, already runs its own file system and shares out fully formed files over a network file-sharing protocol, most commonly NFS (Linux/Unix) or SMB/CIFS (Windows). That single difference — block access versus file access — drives most of the practical differences in performance, sharing behavior, and typical use case between the two.
| Attribute | SAN (Storage Area Network) | NAS (Network-Attached Storage) |
|---|---|---|
| Storage type | Block-level storage (raw volumes/LUNs) | File-level storage (shared files and folders) |
| Common protocols | Fibre Channel, iSCSI, FCoE, NVMe-oF | NFS, SMB/CIFS |
| Access method | Server OS mounts a LUN as if it were a local disk; the server’s own file system manages it | Clients connect over the network directly to a shared file system on the NAS device |
| Typical use case | Databases, virtualization/hypervisor datastores, transactional applications | Shared file repositories, home directories, document collaboration, media libraries |
| Performance profile | Generally lower latency and higher, more predictable throughput; well suited to high-IOPS random I/O | Generally higher latency than SAN due to file-system and network-protocol overhead; well suited to sequential and shared-access file workloads |
In practice, many organizations run both: a SAN for latency-sensitive databases and virtual machine storage, and a NAS for shared user and application file data. Some modern platforms — including converged and software-defined storage systems — can present both block and file access from the same underlying capacity pool, blurring the line administratively even though the block-versus-file distinction still holds at the protocol level.
Common SAN Use Cases
- Relational databases and OLTP systems — high-IOPS, low-latency workloads such as Oracle, SQL Server, and PostgreSQL that are highly sensitive to storage latency.
- Server virtualization — hypervisor platforms (VMware, Hyper-V, KVM) commonly use shared SAN LUNs as datastores so virtual machines can be migrated live between physical hosts without moving their storage.
- Enterprise email and messaging systems — platforms like Microsoft Exchange that generate heavy, latency-sensitive I/O at scale.
- Data center consolidation — replacing many servers’ worth of direct-attached storage with a smaller number of centrally managed arrays.
- Disaster recovery and business continuity — array-based block replication between SANs at different sites underpins many enterprise DR strategies.
Challenges and Considerations
Upfront Cost and Complexity
Dedicated Fibre Channel fabrics require specialized switches, HBAs, and cabling that are more expensive than standard Ethernet gear, and even Ethernet-based SANs benefit from careful network segmentation. Designing, deploying, and tuning a SAN generally calls for specialized storage-networking expertise.
Ongoing Management Overhead
Zoning, LUN masking, multipathing, firmware compatibility across HBAs/switches/arrays, and capacity planning all require dedicated administration, which is a real operational cost even after the SAN is installed.
Fabric Distance and Latency Limits
Fibre Channel in particular is optimized for the tight latency budgets of a single data center or a small number of nearby sites; stretching a SAN fabric over long distances (for remote replication, for example) introduces latency and typically requires purpose-built extension technology.
Vendor Interoperability
Mixing HBAs, switches, and storage arrays from different vendors can introduce compatibility issues, and many enterprise environments standardize on a single vendor’s fabric to reduce that risk — which in turn increases the practical cost of switching vendors later.
Scaling Beyond a Single Array
Traditional SAN arrays scale by adding controllers or shelves to that array, which has practical ceilings; environments that need storage to scale out more elastically than a single array allows increasingly look to scale-out or software-defined storage architectures instead.
The Future of SAN Architecture
The core idea behind a SAN — a dedicated network delivering block storage to servers as if it were local disk — remains foundational to enterprise infrastructure, but its implementation keeps shifting. NVMe-oF is steadily displacing SCSI-based Fibre Channel and iSCSI in new all-flash deployments because it better exploits the low latency and parallelism flash media can deliver. At the same time, software-defined and cloud-delivered approaches are decoupling the SAN’s logical behavior — block volumes, multipathing, snapshots, replication — from any specific physical fabric, letting that same block-storage experience run on commodity networking or be consumed as a managed cloud service rather than a proprietary Fibre Channel fabric an enterprise has to build and operate itself. Cloud infrastructure providers, including Zadara, now offer block storage with SAN-like characteristics — dedicated, high-performance, block-level volumes attached to compute instances — without customers having to own or manage the underlying fabric hardware. For most organizations, the practical question is no longer whether to use SAN-style block storage, but which protocol and delivery model — on-premises Fibre Channel, iSCSI, NVMe-oF, or a cloud-based block storage service — best fits a given workload’s latency, cost, and operational requirements.