Shared storage: NAS, SAN, iSCSI and Fibre Channel

Why this matters

Storage inside one server serves one server. As soon as two servers need the same data, as a failover cluster does, or a virtualisation host wants to move running machines between hosts, the storage has to live outside any single server and be reached over a network.

There are two fundamentally different ways to do that, and confusing them is both a common exam error and a real way to destroy data. This lesson separates them, then walks through the protocols, the redundancy, and the one operation where a careless click erases a volume.

The lesson

Direct-attached, NAS and SAN, and whether they share files or blocks

Direct-attached storage (DAS) is connected to one server: its internal drives, or an external drive enclosure cabled to it by SAS. It is fast and simple, and it belongs to that server alone.

Shared storage comes in two kinds, and the question that separates them is what is shared.

• Network-attached storage (NAS) shares files. The NAS device owns the disks and the file system, and servers and users reach folders on it through file-sharing protocols: SMB (used mainly by Windows) and NFS (used mainly by Linux and Unix). Clients ask for files by name; the NAS decides where they live on disk.
• A storage area network (SAN) shares blocks. The storage array presents raw disk space to servers, and each server sees it as if it were a local disk, formats it with its own file system and manages it itself. The unit of storage a SAN presents is a LUN, a logical unit.

That difference decides what each is for. A NAS suits file shares, home directories and anything people or applications access as files. A SAN suits databases, virtual machine storage and clusters, which want a disk rather than a folder.

iSCSI initiators, targets and LUNs

iSCSI carries storage commands over an ordinary TCP/IP network, which makes it a SAN built from Ethernet equipment. Its vocabulary is worth learning exactly:

• The initiator is the client, the server that wants the storage. It is usually software built into the operating system; a dedicated iSCSI adapter can offload the work.
• The target is the storage side, which presents one or more LUNs.
• Initiators and targets are identified by names, usually in IQN (iSCSI qualified name) format, such as iqn.2026-09.com.example:server01.
• iSCSI uses TCP port 3260.

Because it runs over the network, iSCSI traffic should be kept apart from general traffic, on its own network or VLAN, and usually with jumbo frames enabled end to end for efficiency. Targets should require authentication, commonly CHAP, so that an arbitrary machine on the network cannot connect to a LUN.

Fibre Channel, HBAs and zoning, and where FCoE fits

Fibre Channel (FC) is a storage network built for the purpose, separate from the Ethernet network, running at speeds such as 16, 32 and 64 Gbps. It is the traditional high-end SAN.

• Servers connect through a host bus adapter (HBA), a card dedicated to Fibre Channel.
• HBAs and storage ports connect through Fibre Channel switches, which together form a fabric.
• Every port is identified by a World Wide Name (WWN), and specifically a WWPN for a port.

Two controls decide who can see what, and they work at different places. Zoning is configured on the FC switches and controls which initiators can communicate with which storage ports at all. LUN masking is configured on the storage array and controls which hosts are presented which LUNs. Used together, a server sees only the storage meant for it.

Fibre Channel over Ethernet (FCoE) carries Fibre Channel frames over Ethernet instead of a separate FC network, using converged network adapters (CNAs) that handle both. It requires a lossless Ethernet configuration, because Fibre Channel does not tolerate dropped frames the way TCP does.

Multipathing, so one cable or switch is not a single point of failure

A server that reaches its storage through one adapter, one cable and one switch loses that storage if any of them fails. Multipathing removes those single points of failure: two adapters, cabled to two separate switches or fabrics, reaching two controllers on the storage array.

The operating system then sees the same LUN more than once, once per path. A multipathing driver, called MPIO in Windows and multipath (dm-multipath) in Linux, recognises that these are all the same LUN and presents it as a single disk. It sends traffic down the paths in failover mode (one active, the rest standing by) or balances load across them, and it switches paths automatically when one fails.

Without multipathing configured, a server that can see a LUN through two paths may treat them as two separate disks. That is not just untidy: writing to both as if they were independent can corrupt the data.

Presenting a LUN to a server and bringing it online without destroying data

Connecting a server to new SAN storage follows the same sequence whatever the protocol:

1. On the storage array, create the LUN and map or mask it to the server's initiator name or WWPN.
2. On the server, connect to the target and rescan for disks.
3. The new disk appears. In Windows Disk Management it typically shows as offline and not initialised; on Linux it appears as a new block device.
4. For a genuinely new, empty LUN, bring it online, initialise it (GPT for anything large), create a volume and format it.

Step four is where data is destroyed. Initialising and formatting erase whatever is on the disk, and a LUN is not always new. It may hold existing data from another server, or it may be a shared cluster disk that is already in use. Before initialising anything, confirm from the storage side exactly which LUN this is and that it is supposed to be empty.

The second danger is sharing. An ordinary file system such as NTFS or ext4 assumes it is the only system writing to its disk. If two servers that are not part of a cluster both mount the same LUN and write to it, each overwrites the other's metadata, and the file system is corrupted. Only cluster-aware file systems, such as Windows Cluster Shared Volumes or VMware's VMFS, are designed to be written by several servers at once. A LUN mapped to more than one ordinary server is an incident waiting to happen, and masking should make it impossible.