How to Configure Linux Multipath I/O (MPIO) for SAN Storage

The Single Point of Failure

In a modern enterprise datacenter, Linux servers do not rely on local hard drives to store their massive Oracle or PostgreSQL databases. Instead, they connect over a high-speed Storage Area Network (SAN) via Fibre Channel or iSCSI to a massive, million-dollar centralized storage array (like a Dell EMC or Pure Storage array).

If you connect a Linux server to a SAN using a single fiber optic cable, you have a critical single point of failure. If a technician accidentally unplugs that cable, or if a port on the SAN switch burns out, the Linux server instantly loses contact with the storage array. The database crashes, and production halts.

To solve this, hardware engineers install multiple Host Bus Adapters (HBAs) in the server, run multiple cables through entirely separate physical SAN switches, and plug them into different controllers on the storage array. However, this creates a software nightmare. When Linux scans the hardware, it sees the exact same 10-Terabyte LUN (Logical Unit Number) arriving via four different physical cables. The Linux kernel thinks it has four entirely separate 10TB hard drives (/dev/sdb, /dev/sdc, /dev/sdd, /dev/sde). If you try to mount them all, you will corrupt the filesystem instantly.

The Solution: Multipath I/O

To safely utilize redundant physical connections, you must configure Multipath I/O (MPIO) (specifically the device-mapper-multipath daemon). MPIO intercepts the four identical raw devices, mathematically proves they are the same physical disk by reading their unique SCSI WWIDs (World Wide Identifiers), hides the four raw devices from the operating system, and presents a single, virtual “Multipath Device” (e.g., /dev/mapper/mpatha).

When you format and mount /dev/mapper/mpatha, MPIO handles the traffic. If fiber cable #1 gets cut, MPIO instantly, seamlessly reroutes the database read/write commands over fiber cable #2 in milliseconds, entirely preventing downtime.

Step 1: Installing the Multipath Daemon

First, install the userspace tools required to manage the device-mapper kernel module.

On RHEL/CentOS/Rocky Linux:

sudo dnf install device-mapper-multipath

On Ubuntu/Debian:

sudo apt-get update
sudo apt-get install multipath-tools

Step 2: Generating the Initial Configuration

You must explicitly tell the multipath daemon to take control of the SAN disks. By default, it ignores everything to prevent accidentally hijacking local NVMe drives.

# Generate a baseline configuration file
sudo mpathconf --enable --with_multipathd y

This creates the master configuration file at /etc/multipath.conf and starts the daemon.

Step 3: Configuring the Multipath Policy

Open the configuration file in a text editor to define exactly how the traffic should be routed.

sudo nano /etc/multipath.conf

The defaults section defines the global behavior. A highly optimized, modern configuration looks like this:

defaults {
    # Ask the SAN for the preferred path, rather than guessing
    prio "alua" 
    
    # Use all healthy paths simultaneously to increase bandwidth (Active/Active)
    path_grouping_policy "multibus" 
    
    # Send an identical amount of I/O down each fiber cable
    path_selector "round-robin 0" 
    
    # If a path fails, check it every 10 seconds to see if it came back online
    polling_interval 10 
    
    # Tell the database to wait (queue) if ALL paths fail temporarily, instead of crashing immediately
    no_path_retry "queue" 
    
    # Automatically assign friendly names (like mpatha) instead of long WWIDs
    user_friendly_names yes 
}

(Note: You should also use the blacklist section to explicitly exclude your local OS drives, e.g., devnode "^sda").

Step 4: Applying and Verifying the Configuration

Save the file and restart the multipath daemon to apply the new routing logic to the Linux kernel.

sudo systemctl restart multipathd
sudo systemctl enable multipathd

Now, execute the command to verify the topology:

sudo multipath -ll

You will see a beautiful output demonstrating the active intelligence of the MPIO subsystem:

mpatha (36006016024902c00cc71cfc24c7a23c6) dm-2 PURE,FlashArray
size=10G features='1 queue_if_no_path' hwhandler='1 alua' wp=rw
`-+- policy='round-robin 0' prio=50 status=active
  |- 1:0:0:1 sdb 8:16  active ready running
  |- 1:0:1:1 sdc 8:32  active ready running
  |- 2:0:0:1 sdd 8:48  active ready running
  `- 2:0:1:1 sde 8:64  active ready running

The Linux kernel has successfully fused the four raw fiber connections (sdb, sdc, sdd, sde) into the single, highly resilient mpatha virtual drive. You can now safely run mkfs.xfs /dev/mapper/mpatha, knowing your enterprise database is shielded from physical hardware failure.