NAS vs SAN: Which Storage Fits Which Workload

NAS and SAN are two ways of giving servers access to shared storage. Network attached storage serves files over the existing Ethernet network using protocols such as SMB and NFS, and the storage system owns the filesystem. A storage area network serves raw blocks over a dedicated fabric, usually Fibre Channel or iSCSI, and the server owns the filesystem. That single difference explains almost everything else about how they behave and what they cost.

Who owns the filesystem

This is the whole distinction, and it is worth being precise about it.

With NAS, a client asks for a file by name and the storage system finds it, checks permissions and returns it. Directories, quotas, snapshots and access control all live on the NAS. Several machines can read and write the same share at once because the NAS arbitrates.

With SAN, the array hands the server a volume of raw blocks. The server formats it, builds a filesystem on it and treats it as a local disk. Nothing arbitrates between servers, which is why two servers writing to the same unclustered SAN volume corrupt it.

What each is good at

Why databases prefer block

A database manages its own on-disk layout and expects predictable, low-latency writes that complete in a known order. A block volume gives it exactly that. A file protocol adds a layer that has to translate, lock and arbitrate, and on a shared network it also adds contention from traffic that has nothing to do with storage.

The same argument applies to virtualisation clusters. Hypervisors want shared block volumes with consistent latency so that a virtual machine’s disk behaves the same on any host in the cluster.

Why file shares prefer NAS

If forty people need to read and write the same folder, something has to arbitrate. That is what a NAS does natively and what a SAN cannot do without a clustered filesystem layered on top, which is extra software, extra complexity and extra licensing.

NAS also carries the permissions model your users already understand, and it snapshots at the share level, which makes restoring one deleted file a two-minute operation rather than a restore of an entire volume.

Unified arrays blur the line

Most current midrange platforms serve block, file and sometimes object from one system. That does not remove the distinction, it removes the requirement to buy two boxes. The protocol you use for a given workload is still a real decision with real performance consequences; you just no longer need separate hardware to make it.

The practical benefit of unified is operational: one system, one support contract, one set of knowledge in the team. That saving is worth most where the storage team is small.

Fibre Channel or iSCSI

Fibre Channel is a purpose-built storage fabric with its own switches and adapters. It is deterministic and it stays out of the way of user traffic, and it costs more in hardware and in the skills to run it.

iSCSI carries the same block protocol over Ethernet. It is far cheaper because it reuses networking you already understand, and it performs well when it runs on a dedicated or properly isolated network. Running iSCSI over the same switches as user traffic is the usual reason people conclude that iSCSI is slow.

All-flash and hybrid

An all-flash array uses solid-state media throughout, so latency is consistently low and does not depend on where the data sits. A hybrid array mixes flash and spinning disks and promotes hot data to the flash tier, which makes capacity much cheaper per terabyte but leaves performance dependent on how well the working set fits.

Data reduction narrows the price gap considerably on the right dataset. Databases and virtual machine images reduce well; already-compressed media does not.

Raw, usable and effective

Three different numbers, and vendors quote whichever flatters them. Raw is the sum of the media. Usable is what remains after the protection scheme takes its share. Effective is usable multiplied by an assumed data reduction ratio.

We quote raw and usable separately and state the assumed ratio when effective capacity is mentioned, because a comparison built on someone’s optimistic ratio is not a comparison.

Object storage, the third option

Object storage is neither file nor block. Data is stored as objects addressed by an identifier, accessed over HTTP with an S3-compatible interface, and there is no directory tree and no filesystem to mount. It scales further than either alternative and it is cheaper per terabyte at scale.

What it is not is a drop-in replacement. Applications have to be written for it, latency is higher than block, and you cannot install a database on it. Object suits backups, archives, media libraries and anything an application accesses through an API rather than a mount point.

Direct-attached storage still has a place

Not every workload needs shared storage. Direct-attached storage, disks inside the server or in a shelf connected only to it, is the simplest and fastest option per pound spent, and it removes an entire network from the failure analysis.

What it does not give you is mobility. A virtual machine cannot move to another host if its disk lives inside the first one, and capacity stranded in one server cannot be lent to another. That is the trade the shared approaches exist to solve, and it is worth being explicit about whether you actually need it.

What to send with an enquiry

• Usable capacity required, and the growth expected over the contract period
• Protocols your hosts actually speak
• Performance target in IOPS or latency, not just capacity
• Whether replication or snapshot retention is in scope
• If this replaces an existing array, its current utilisation

Our storage page lists the families we supply across all-flash, hybrid, entry SAN and scale-out NAS. The server side of the decision usually travels with it.