The Danger of Single Paths in SAN Architecture
In a standard Ubuntu server deployment, a hard drive is physically cabled directly to the motherboard. If that SATA or SAS cable fails, the hard drive goes offline, and the server crashes.
In enterprise architectures, servers do not have internal hard drives. Instead, they boot from and store data on massive, highly redundant Storage Area Networks (SANs) located across the data center, accessed via protocols like iSCSI (SCSI commands over TCP/IP) or Fibre Channel.
However, simply connecting an Ubuntu server to an iSCSI SAN introduces a massive single point of failure. If the Ethernet cable connecting the server to the switch is unplugged, or the switch itself reboots for a firmware update, the server loses connection to its hard drive and crashes.
To solve this, enterprise servers are equipped with multiple network cards, connected to multiple independent network switches, which connect to multiple independent ports on the SAN array. This creates multiple physical paths to the exact same hard drive. To manage these paths intelligently, Ubuntu relies on the Multipath I/O (multipathd) daemon.
Step 1: The Multipath Illusion
If you connect an Ubuntu server to a SAN using two different network paths, the Linux kernel gets confused. It will detect the exact same 2TB LUN (Logical Unit Number) on Path A and assign it the device name /dev/sdb. A millisecond later, it will detect the exact same 2TB LUN on Path B and assign it the device name /dev/sdc.
If a junior administrator formats /dev/sdb and mounts it, and another process tries to write to /dev/sdc, they will corrupt the filesystem instantly because both devices point to the exact same physical disk blocks.
The multipathd service intercepts these raw block devices, hides sdb and sdc from the operating system, and creates a single, virtual, abstracted block device (e.g., /dev/mapper/mpatha). You format and mount the virtual mpatha device. The multipath daemon then silently routes the read/write I/O down whichever physical path is currently active.
Step 2: Installing the Utilities
Before configuring the virtual devices, you must install the multipath tools:
sudo apt update
sudo apt install multipath-tools -yOnce installed, enable and start the daemon:
sudo systemctl enable multipathd
sudo systemctl start multipathdStep 3: Generating the Configuration File
By default, Ubuntu does not ship with a multipath configuration file, as it relies on internal kernel heuristics to identify SAN hardware. However, for a stable production environment, you must explicitly define the configuration.
Copy the default configuration template to the correct directory:
sudo cp /usr/share/doc/multipath-tools/examples/multipath.conf.synthetic /etc/multipath.confStep 4: Blacklisting Local Drives
The multipath daemon aggressively scans every block device on the system. You absolutely do not want it attempting to manage your local internal boot drive (e.g., /dev/sda) or a USB thumb drive.
Open the configuration file:
sudo nano /etc/multipath.confLocate the blacklist section. By default, it usually blacklists everything (which breaks your iSCSI drives). You must configure it to explicitly ignore local IDE/SATA drives, but allow external WWIDs (World Wide Identifiers).
blacklist {
devnode "^(ram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]*"
devnode "^hd[a-z]"
# Explicitly blacklist the local SDA boot drive
devnode "^sda"
}Step 5: Configuring Aliases and Polling
Instead of referencing obscure WWID strings (like 3600140509b55cdbd), you should configure multipath to assign friendly aliases to your LUNs.
Scroll down to the multipaths section. You must input the exact WWID of your iSCSI drive (which you can find by running sudo multipath -ll before defining the alias).
multipaths {
multipath {
wwid "3600140509b55cdbd7424d45543306"
alias "mysql_data_lun"
}
}Save the file and restart the daemon to apply the configuration:
sudo systemctl restart multipathdStep 6: Verifying Path Failover
To verify the health of your SAN topology, run the list command:
sudo multipath -llThe output will beautifully map the virtual device to its physical paths.
mysql_data_lun (3600140509b55cdbd7424d45543306) dm-2 HITACHI,OPEN-V
size=2.0T features='0' hwhandler='0' wp=rw
`-+- policy='round-robin 0' prio=1 status=active
|- 1:0:0:1 sdb 8:16 active ready running
`- 2:0:0:1 sdc 8:32 active ready runningThis output proves that the mysql_data_lun is actively utilizing two physical paths (sdb and sdc) using a “round-robin” load balancing algorithm (which doubles the bandwidth).
If you physically unplug the Ethernet cable for Path A, the kernel will flag sdb as “failed.” However, because you mounted /dev/mapper/mysql_data_lun, the database will not crash; multipathd will simply route 100% of the I/O down the surviving sdc path without dropping a single packet.
Conclusion
Connecting an enterprise server to a SAN using a single iSCSI session is a recipe for catastrophic downtime. By deploying the multipathd daemon, Ubuntu administrators can abstract the raw block devices, seamlessly aggregating multiple physical network paths to provide active/active load balancing and instantaneous, invisible failover when data center hardware inevitably fails.