The Storage Redundancy Challenge
In enterprise Linux deployments, physical servers rarely store their databases or virtual machines on internal hard drives. Instead, they connect to a massive, multi-million-dollar Storage Area Network (SAN) array via high-speed Fibre Channel or iSCSI networks.
Because the data on the SAN is mission-critical, the server never connects to the SAN using a single cable. An enterprise Ubuntu server will have at least two physical Host Bus Adapters (HBAs), and the SAN will have multiple storage controllers. The administrator wires HBA 1 to Controller A, and HBA 2 to Controller B.
This creates physical redundancy, but it introduces a catastrophic logical problem for the Linux kernel. When the Ubuntu server scans the storage fabric, it sees the exact same 10-Terabyte LUN (Logical Unit Number) arriving via two different physical cables. Linux assumes these are two completely different hard drives. It maps the first path as /dev/sdb and the second path as /dev/sdc. If a database administrator attempts to format /dev/sdb while simultaneously writing to /dev/sdc, the filesystem will instantly corrupt itself, destroying the data.
To solve this, Linux engineers use Multipath I/O (multipathd). The multipath daemon intercepts all physical paths (/dev/sdb and /dev/sdc), recognizes they point to the exact same physical disk sector on the SAN, hides the raw physical paths from the operating system, and presents a single, highly resilient virtual block device (e.g., /dev/mapper/mpatha). If a cable is cut, multipath seamlessly routes the traffic down the surviving path without dropping a single byte of data.
Step 1: Installing and Enabling Multipath Tools
By default, standard Ubuntu Server installations do not include the multipath daemon. You must install the package from the main repository:
sudo apt update
sudo apt install multipath-tools -yOnce installed, you must enable the daemon to start automatically on boot:
sudo systemctl enable multipathd
sudo systemctl start multipathdStep 2: Discovering the Physical Paths
Before configuring the virtual device, you must understand how the Linux kernel currently sees the SAN fabric.
Run the lsscsi command (you may need to sudo apt install lsscsi) or the lsblk command.
lsblkYou will likely see multiple disks with the exact same storage capacity (e.g., sdb is 10TB, sdc is 10TB).
To definitively prove they are the exact same physical disk, you must query their unique World Wide Identifier (WWID). The WWID is a hardware serial number hardcoded into the LUN by the SAN array (like NetApp or EMC).
sudo /lib/udev/scsi_id -g -u -d /dev/sdb
sudo /lib/udev/scsi_id -g -u -d /dev/sdcIf both commands return the exact same 32-character hexadecimal string (e.g., 3600a0980383044546a2b4c5d6e7f8a9b), they are identical paths to the same disk.
Step 3: Creating the Multipath Configuration File
Multipath requires a strict configuration file to dictate how it handles failover and load balancing.
Create the default configuration file:
sudo nano /etc/multipath.confThe file is structured into blocks. The most critical block is the multipaths definition, where you map the hardware WWID to a human-readable virtual device name.
defaults {
user_friendly_names yes
find_multipaths yes
}
multipaths {
multipath {
wwid 3600a0980383044546a2b4c5d6e7f8a9b
alias san_database_vol
path_grouping_policy multibus
path_selector "round-robin 0"
failback immediate
}
}Decoding the Parameters:
wwid: The exact hexadecimal serial number you extracted in Step 2.alias: Instead of generating a generic name likempatha, it will create the virtual drive as/dev/mapper/san_database_vol, preventing catastrophic formatting mistakes by junior administrators.path_grouping_policy multibus: This dictates Load Balancing. Instead of leavingsdcidle as a standby failover, it uses both cables simultaneously, doubling the bandwidth to the SAN.
Step 4: Compiling the Virtual Device
Save the configuration file and restart the multipath daemon to force it to re-scan the SCSI bus and build the virtual topology.
sudo systemctl restart multipathdNow, run the primary diagnostic command to view the live topology:
sudo multipath -llThe output is a hierarchical tree. It will show the alias (san_database_vol) at the root, and nested beneath it, the active physical paths (sdb and sdc), their SCSI addresses, and their status (e.g., active ready running).
Step 5: Formatting and Mounting the Virtual Path
This is the most critical rule of SAN administration: Never touch the physical /dev/sdX paths again.
If you need to format the drive with the XFS filesystem, you explicitly target the virtual mapper device:
sudo mkfs.xfs /dev/mapper/san_database_volWhen you add the drive to your /etc/fstab file for persistent mounting on reboot, you use the mapper path:
/dev/mapper/san_database_vol /var/lib/postgresql xfs defaults 0 0Step 6: Testing the Failover (Chaos Engineering)
Before migrating a production database to the SAN volume, you must prove the redundancy works.
While running a heavy write workload to the mount point (e.g., using the dd command), forcefully disable one of the physical paths at the kernel level:
echo 1 | sudo tee /sys/block/sdb/device/deleteInstantly run multipath -ll. You will see sdb flagged as failed. However, the dd command writing to the disk will not crash. The multipath daemon silently routed 100% of the traffic to sdc. When you rescan the SCSI bus to restore the path, the daemon will automatically failback and resume load balancing.
Conclusion
Connecting a mission-critical Ubuntu server to a dual-controller SAN without multipath architecture guarantees catastrophic data corruption. By deploying the multipathd daemon, Linux engineers abstract away the fragility of physical hardware cables, creating an impenetrable, self-healing logical volume capable of surviving severe physical fabric outages without interrupting application I/O.