Chapter 5. Managing Multipath I/O for Devices / 5.3. Multipath Management Tools
	5.2. Planning for Multipathing		5.4. Configuring the System for Multipathing

Multipath Management Tools

The multipathing support in SUSE Linux Enterprise Server 10 is based on the Device Mapper Multipath module of the Linux 2.6 kernel and the multipath-tools userspace package. You can use mdadm to view the status of multipathed devices.

Device Mapper Multipath Module

The Device Mapper Multipath (DM-MP) module provides the multipathing capability for Linux. DM-MP is the preferred solution for multipathing on SUSE Linux Enterprise Server 10. It is the only multipathing option shipped with the product that is completely supported by Novell® and SUSE.

DM-MP features automatic configuration of the multipathing subsystem for a large variety of setups. Configurations of up to 8 paths to each device are supported. Configurations are supported for active/passive (one path active, others passive) or active/active (all paths active with round-robin load balancing).

The DM-MP framework is extensible in two ways:

Using specific hardware handlers. For information, see Section 5.2.3.3, “Storage Arrays that Require Specific Hardware Handlers”.
Using more sophisticated load-balancing algorithms than round-robin

The user-space component of DM-MP takes care of automatic path discovery and grouping, as well as automated path retesting, so that a previously failed path is automatically reinstated when it becomes healthy again. This minimizes the need for administrator attention in a production environment.

DM-MP protects against failures in the paths to the device, and not failures in the device itself. If one of the active paths is lost (for example, a network adapter breaks or a fiber-optic cable is removed), I/O is redirected to the remaining paths. If the configuration is active/passive, then the path fails over to one of the passive paths. If you are using the round-robin load-balancing configuration, the traffic is balanced across the remaining healthy paths. If all active paths fail, inactive secondary paths must be waked up, so failover occurs with a delay of approximately 30 seconds.

If a disk array has more than one storage processor, make sure that the SAN switch has a connection to the storage processor that owns the LUNs you want to access. On most disk arrays, all LUNs belong to both storage processors, so both connections are active.

	Note
On some disk arrays, the storage array manages the traffic through storage processors so that it presents only one storage processor at a time. One processor is active and the other one is passive until there is a failure. If you are connected to the wrong storage processor (the one with the passive path) you might not see the expected LUNs, or you might see the LUNs but get errors when trying to access them.

Note

On some disk arrays, the storage array manages the traffic through storage processors so that it presents only one storage processor at a time. One processor is active and the other one is passive until there is a failure. If you are connected to the wrong storage processor (the one with the passive path) you might not see the expected LUNs, or you might see the LUNs but get errors when trying to access them.

Table 5.1. Multipath I/O Features of Storage Arrays

Features of Storage Arrays	Description
Active/passive controllers	One controller is active and serves all LUNs. The second controller acts as a standby. The second controller also presents the LUNs to the multipath component so that the operating system knows about redundant paths. If the primary controller fails, the second controller takes over, and it serves all LUNs. In some arrays, the LUNs can be assigned to different controllers. A given LUN is assigned to one controller to be its active controller. One controller does the disk I/O for any given LUN at a time, and the second controller is the standby for that LUN. The second controller also presents the paths, but disk I/O is not possible. Servers that use that LUN are connected to the LUN’s assigned controller. If the primary controller for a set of LUNs fails, the second controller takes over, and it serves all LUNs.
Active/active controllers	Both controllers share the load for all LUNs, and can process disk I/O for any given LUN. If one controller fails, the second controller automatically handles all traffic.
Load balancing	The Device Mapper Multipath driver automatically load balances traffic across all active paths.
Controller failover	When the active controller fails over to the passive, or standby, controller, the Device Mapper Multipath driver automatically activates the paths between the host and the standby, making them the primary paths.
Boot/Root device support	Multipathing is supported for the root (`/`) device in SUSE Linux Enterprise Server 10 and later. The host server must be connected to the currently active controller and storage processor for the boot device.

Device Mapper Multipath detects every path for a multipathed device as a separate SCSI device. The SCSI device names take the form /dev/sdN, where N is an autogenerated letter for the device, beginning with a and issued sequentially as the devices are created, such as /dev/sda, /dev/sdb, and so on. If the number of devices exceeds 26, the letters are duplicated so that the next device after /dev/sdz will be named /dev/sdaa, /dev/sdab, and so on.

If multiple paths are not automatically detected, you can configure them manually in the /etc/multipath.conf file. The multipath.conf file does not exist until you create and configure it. For information, see Section 5.4.5, “Creating and Configuring the /etc/multipath.conf File”.

Multipath I/O Management Tools

The multipath-tools user-space package takes care of automatic path discovery and grouping. It automatically tests the path periodically, so that a previously failed path is automatically reinstated when it becomes healthy again. This minimizes the need for administrator attention in a production environment.

Table 5.2. Tools in the multipath-tools Package

Tool	Description
multipath	Scans the system for multipathed devices and assembles them.
multipathd	Waits for maps events, then executes multipath.
devmap-name	Provides a meaningful device name to udev for device maps (devmaps).
kpartx	Maps linear devmaps to partitions on the multipathed device, which makes it possible to create multipath monitoring for partitions on the device.

For a list of files included in this package, see the multipath-tools Package Description.

Ensure that the multipath-tools package is installed by entering the following at a terminal console prompt:
```
rpm -q multipath-tools
```
If it is installed, the response repeats the package name and provides the version information, such as:
```
multipath-tools-04.7-34.23
```
If it is not installed, the response reads:
```
package multipath-tools is not installed
```

Using mdadm for Multipathed Devices

In SUSE Linux Enterprise Server 10, Udev is the default device handler, and devices are automatically known to the system by the Worldwide ID instead of by the device node name. This resolves problems in previous releases where mdadm.conf and lvm.conf did not properly recognize multipathed devices.

Just as for LVM2, mdadm requires that the devices be accessed by the ID rather than by the device node path. Therefore, the DEVICE entry in /etc/mdadm.conf should be set as follows:

DEVICE /dev/disk/by-id/*

This is the default handling in SUSE Linux Enterprise Server 10 and later, as noted above.

To verify that mdadm is installed:

Ensure that the mdadm package is installed by entering the following at a terminal console prompt:
```
rpm -q mdadm
```
If it is installed, the response repeats the package name and provides the version information. For example:
```
mdadm-2.6-0.11
```
If it is not installed, the response reads:
```
package mdadm is not installed
```

The Linux multipath(8) Command

Use the Linux multipath(8) command to configure and manage multipathed devices.

General syntax for the multipath(8) command:

multipath [-v verbosity] [-d] [-h|-l|-ll|-f|-F] [-p failover|multibus|group_by_serial|group_by_prio|group_by_node_name]

General Examples

Configure multipath devices:

multipath

Configure a specific multipath device:

multipath devicename

Replace devicename with the device node name such as /dev/sdb (as shown by udev in the $DEVNAME variable), or in the major:minor format.

Selectively suppress a multipath map, and its device-mapped partitions:

multipath -f

Display potential multipath devices, but do not create any devices and do not update device maps (dry run):

multipath -d

Configure multipath devices and display multipath map information:

multipath -v2 <device>

multipath -v3

Display the status of all multipath devices, or a specified multipath device:

multipath -ll

multipath -ll <device>

Flush all unused multipath device maps (unresolves the multiple paths; it does not delete the device):

multipath -F

multipath -F <device>

Set the group policy:

multipath -p [failover|multibus|group_by_serial|group_by_prio|group_by_node_name]

Specify one of the group policy options that are described in Table 5.3, “Group Policy Options for the multipath -p Command”:

Table 5.3. Group Policy Options for the multipath -p Command

Policy Option	Description
failover	One path per priority group. You can use only one path at a time.
multibus	All paths in one priority group.
group_by_serial	One priority group per detected SCSI serial number (the controller node worldwide number).
group_by_prio	One priority group per path priority value. Paths with the same priority are in the same priority group. Priorities are determined by callout programs specified as a global, per-controller, or per-multipath option in the `/etc/multipath.conf` configuration file.
group_by_node_name	One priority group per target node name. Target node names are fetched in the `/sys/class/fc_transport/target*/node_name` location.