The Single Point of Failure
In a true enterprise data center, Linux servers do not boot from internal hard drives. They boot from massive Storage Area Networks (SANs). A database server might be connected to a 50-Terabyte LUN (Logical Unit Number) hosted on an EMC or NetApp storage array.
However, connecting a server to a SAN requires physical infrastructure: a Host Bus Adapter (HBA) card in the server, a fiber optic cable, and a SAN fabric switch. If you only run one fiber optic cable, you have created a catastrophic single point of failure. If that cable is accidentally unplugged, or the HBA card burns out, the server instantly loses access to its hard drive and the operating system crashes.
To achieve high availability, hardware engineers install two separate HBA cards and run two separate cables through two different network switches. However, this creates a massive software problem. When the Ubuntu kernel scans the hardware, it sees the exact same 50TB LUN arriving down two different physical paths. It assumes these are two completely different hard drives, mounting them as /dev/sdb and /dev/sdc. If an application tries to write to both simultaneously, the filesystem will instantly corrupt.
To solve this, Linux administrators use multipathd (Device Mapper Multipathing). Multipath intercepts the multiple physical paths, mathematically realizes they point to the exact same physical disk, and merges them into a single, highly resilient virtual block device. It handles load balancing across the cables and automatic failover if a cable is cut.
Step 1: Installing and Enabling the Daemon
Multipathing is not enabled by default in standard Ubuntu installations.
Install the core utilities:
sudo apt update
sudo apt install multipath-tools -yBy default, Ubuntu might ignore local SATA/NVMe drives but it needs a basic configuration file to begin managing SAN paths. You must generate the initial configuration template:
sudo mpathconf --enable --with_multipathd yThis command creates the /etc/multipath.conf file and ensures the multipathd daemon starts automatically on boot.
Step 2: Identifying the WWID
Before configuring the virtual device, you must identify the exact SAN volume. You cannot rely on labels like /dev/sdb because they can change upon reboot.
Instead, you rely on the WWID (World Wide Identifier). The WWID is a globally unique cryptographic string baked into the SAN LUN by the storage array manufacturer. It never changes, regardless of which physical cable the data travels down.
Run the multipath command with the verbose flag to scan the bus:
sudo multipath -v2The output will show you the WWID of the discovered volumes. It usually looks like a massive string of hexadecimal characters, e.g., 3600508b1001c3d1b0000000000000000.
Step 3: Configuring the Multipath Alias
Using a 32-character WWID to manage a database drive is incredibly annoying for system administrators.
You can use the multipath.conf file to assign a human-readable “Alias” to the specific WWID.
Open /etc/multipath.conf in your text editor. Scroll to the multipaths block (or create it if it doesn’t exist) and define the alias:
multipaths {
multipath {
wwid "3600508b1001c3d1b0000000000000000"
alias "db_storage_01"
}
}Save the file and restart the daemon to apply the new name:
sudo systemctl restart multipathdStep 4: Interacting with the Virtual Device
The Linux kernel has now merged the underlying physical paths (/dev/sdb and /dev/sdc). You must never format or mount those raw physical devices again.
Instead, the device mapper has created a brand new, highly resilient virtual block device located in the /dev/mapper/ directory, using the alias you defined.
Your new drive is perfectly accessible at: /dev/mapper/db_storage_01.
You treat this virtual path exactly like a normal hard drive. You can format it with XFS or mount it in /etc/fstab.
sudo mkfs.xfs /dev/mapper/db_storage_01
sudo mount /dev/mapper/db_storage_01 /var/lib/postgresqlStep 5: Verifying Path Redundancy and Failover
To mathematically prove the redundancy is working, you run the multipath topology command:
sudo multipath -llThe output is a brilliant ASCII tree. It will show you the alias (db_storage_01), the size of the LUN, and crucially, the active paths.
db_storage_01 (3600508b1001c3d1b0000000000000000) dm-0 COMPELNT,Compellent Vol
size=50T 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 proves that both the sdb and sdc physical paths are grouped together, and the I/O is being load-balanced in a round-robin fashion.
If you physically unplug the fiber cable for sdb, the database will not crash. If you run multipath -ll again, you will see sdb marked as failed, but the sdc path remains active ready running. The multipathd daemon instantly re-routes 100% of the traffic down the surviving cable. When you plug the cable back in, the daemon detects the carrier signal and automatically restores the load-balanced pool.
Conclusion
Running a mission-critical database on a single storage cable is architectural malpractice. By mastering multipathd on Ubuntu, systems engineers decouple the operating system from the physical hardware layer. The ability to intercept multiple raw SAN paths and abstract them into a single, alias-driven virtual block device guarantees high-throughput I/O load balancing and instantaneous failover, ensuring that a physical hardware failure in the data center never results in application downtime.