A LUN Is a Disk That Crossed the Network — iSCSI and Multipath

In one line

iSCSI carries SCSI commands over TCP to hand a block device across the network. To the server it looks like a local disk as /dev/sdX, but underneath it there is a network. So three things that local disks never had come into play: mount ordering (_netdev), access control (ACL and CHAP), and path redundancy (multipath).

Why you need this

NFS shares files. The server owns the filesystem, and the client asks "please read this file for me." But a database or a hypervisor wants not files but a block device. It wants to build its own filesystem and manage caching and write ordering by itself. If you plug disks into every server, capacity is trapped inside the server. So the structure in which disks are gathered in one place (a storage appliance) and part of it is carved out and lent to servers as raw blocks is a SAN, and carrying that over Ethernet and TCP is iSCSI.

How it works

There are only a few terms that RFC 7143 defines.

Term	Meaning
Initiator	The side that uses the disk. The server
Target	The side that provides the disk. The storage
IQN	The name of each side. The format is iqn.<연-월>.<뒤집은 도메인>:<고유 이름> (year-month, reversed domain, and a unique name)
Portal	The IP and port the target listens on. 3260/tcp by default
LUN	One logical disk carved out inside a target

The initiator on Linux is open-iscsi, and there is a single command, iscsiadm. The flow has three stages. Discovery — iscsiadm -m discovery -t sendtargets -p <포털> asks the portal which targets it has and saves the answer as local node records. Login — iscsiadm -m node -T <IQN> -p <포털> --login establishes a session, and at that moment a new SCSI disk appears in the kernel. Use — that disk shows up as iscsi in the TRAN column of lsblk, and because the name can change at every boot, you refer to it by a fixed path such as /dev/disk/by-path/ip-<포털>-iscsi-<IQN>-lun-<번호> or by the filesystem UUID. If you set node.startup in the node record to automatic, it logs in automatically when the service starts. (In these commands, replace the placeholders with the portal address, the target IQN, and the LUN number.)

The Linux kernel contains the target side as well. It is called LIO, and you configure it with targetcli. You fill in the tree in the order backstore (a file or a block device) → iSCSI target (IQN) → LUNs, ACLs, and portals under a TPG, and leave the configuration in a file with saveconfig. An ACL is a rule that says "only initiators with this IQN see this LUN." An IQN is a name that anyone can claim as their own, so in real operation you add secret verification with CHAP and put storage traffic on a separate VLAN or a dedicated network.

Mount ordering. A local disk exists early in the boot, but an iSCSI disk appears only after the network is up and the login is done. systemd.mount(5) explains that in this case you should attach _netdev to the fstab options. This is because the filesystem type alone cannot tell whether it is a network device. Without this option, systemd tries to mount before the network, waits because the device is not there, and the boot slows down or hangs.

Multipath. A SAN usually has more than one path. The server's two NICs go through different switches to reach the storage's two controllers. Then the same LUN is seen twice on the server, as /dev/sdb and /dev/sdc. If you mount a separate filesystem on each of the two devices, it amounts to writing to the same disk from two places, and the data is ruined. dm-multipath recognizes that the two devices are the same LUN (the same WWID) and bundles them into a single /dev/mapper/mpathX. When one path breaks, it passes the I/O over to the other path (failover), and depending on configuration it may use both paths together. multipath -ll shows the active or failed state of each path.

What it looks like in the field

A standard cause of "I rebooted and the server got stuck in the emergency shell" is an iSCSI fstab line without _netdev. The device is not there yet, so it waits for the mount until it times out, and the services that depend on that mount stop one after another. The work plan for attaching a new LUN includes, along with the fstab line, "confirm automatic login and mount after reboot."

Using a LUN that has two paths without multipath is also a common accident. If lsblk shows two disks of the same size, suspect multipath first. If the storage team said "we gave you one LUN" and you see two disks, it is almost certain. And a multipath device is used not as /dev/sdX but by its name under /dev/mapper/.

Expansion requests come often too. Even if you grow the LUN on the storage, the server does not know. You make it reread (rescan) the SCSI device, update the map size if it is multipath, and then grow the PV, LV, and filesystem on top, in turn. It is the "grow each layer separately" you saw in the previous module, one layer deeper.

After this module

This module ends with reading and a quiz, and the hands-on part is done in the next module together with performance measurement. You set up a LIO target inside the same VM to provide a LUN, log in to that LUN, mount it with _netdev, and then measure I/O on it with fio. Multipath can only be imitated in a lab environment with a single path, so it is covered as a concept.