Planning for Multipathing

Guidelines for Multipathing

Use the guidelines in this section when planning your multipath I/O solution.

Prerequisites

  • Multipathing is managed at the device level.

  • The storage array you use for the multipathed device must support multipathing. For more information, see Section 5.2.8, “Supported Storage Arrays for Multipathing”.

  • You need to configure multipathing only if multiple physical paths exist between host bus adapters in the server and host bus controllers for the block storage device. You configure multipath for the logical device as seen by the server.

Vendor-Provided Multipath Solutions

For some storage arrays, the vendor will provide its own multipathing software to manage multipathing for the array’s physical and logical devices. In this case, you should follow the vendor’s instructions for configuring multipathing for those devices.

Disk Management Tasks

Perform the following disk management tasks before you attempt to configure multipathing for a physical or logical device that has multiple paths:

  • Use third-party tools to carve physical disks into smaller logical disks.

  • Use third-party tools to partition physical or logical disks. If you change the partitioning in the running system, the Device Mapper Multipath (DM-MP) module does not automatically detect and reflect these changes. DM-MP must be reinitialized, which usually requires a reboot.

  • Use third-party SAN array management tools to create and configure hardware RAID devices.

  • Use third-party SAN array management tools to create logical devices such as LUNs. Logical device types that are supported for a given array depend on the array vendor.

Software RAIDs

The Linux software RAID management software runs on top of multipathing. For each device that has multiple I/O paths and that you plan to use in a software RAID, you must configure the device for multipathing before you attempt to create the software RAID device. Automatic discovery of multipathed devices is not available. The software RAID is not aware of the multipathing management running underneath.

High-Availability Solutions

High-availability solutions for clustering typically run on top of the multipathing server. For example, the Distributed Replicated Block Device (DRBD) high-availability solution for mirroring devices across a LAN runs on top of multipathing. For each device that has multiple I/O paths and that you plan to use in a DRDB solution, you must configure the device for multipathing before you configure DRBD.

Volume Managers

Volume managers such as LVM2 and EVMS run on top of multipathing. You must configure multipathing for a device before you use LVM2 or EVMS to create segment managers and file systems on it.

Virtualization Environments

When using multipathing in a virtualization environment, the multipathing is controlled in the host server environment. Configure multipathing for the device before you assign it to a virtual guest machine.

Using Multipathed Devices Directly or in EVMS

If you want to use the entire LUN directly (for example, if you are using the SAN features to partition your storage), you can simply use the /dev/disk/by-id/xxx names directly for mkfs, fstab, your application, etc.

If the user-friendly names option is enabled in the /etc/multipath.conf file, you can optionally use the /dev/mapper/mpathn device name because this name is aliased to the devices ID. For information, see Section 5.4.5.3, “Configuring User-Friendly Names or Alias Names in /etc/multipath.conf”.

Using LVM2 on Multipath Devices

By default, LVM2 does not recognize multipathed devices. To make LVM2 recognize the multipathed devices as possible physical volumes, you must modify /etc/lvm/lvm.conf. It is important to modify it in a way that it does not scan and use the physical paths, but only accesses the multipath I/O storage through the multipath I/O layer.

To modify /etc/lvm/lvm.conf for multipath use:

  1. Open the /etc/lvm/lvm.conf file in a text editor.

  2. Change the filter and types entry in /etc/lvm/lvm.conf as follows:

    filter = [ "a|/dev/disk/by-id/.*|", "r|.*|" ]
    

    This allows LVM2 to scan only the by-id paths and reject everything else.

  3. If you are also using LVM2 on non-multipathed devices, make the necessary adjustments to suit your setup.

  4. Save the file.

  5. Add dm-multipath to /etc/sysconfig/kernel:INITRD_MODULES.

  6. Make a new initrd to ensure that the Device Mapper Multipath services are loaded with the changed settings. Enter

    mkinitrd -f mpath
    
  7. Reboot the server to apply the changes.

Using mdadm with Multipath Devices

The mdadm tool 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.

Using --noflush with Multipath Devices

The option --noflush should always be used when running on multipath devices.

For example, in scripts where you perform a table reload, you use the --noflush option on resume to ensure that any outstanding I/O is not flushed, because you need the multipath topology information.

load
resume --noflush

Partitioning Multipath Devices

SUSE Linux Enterprise Server 10

In SUSE Linux Enterprise Server 10, the kpartx software is used in the /etc/init.d/boot.multipath to add symlinks to the /dev/dm-* line in the multipath.conf configuration file for any newly created partitions without requiring a reboot. This triggers udevd to fill in the /dev/disk/by-* symlinks. The main benefit is that you can call kpartx with the new parameters without having to reboot the server.

SUSE Linux Enterprise Server 9

In SUSE Linux Enterprise Server 9, it is not possible to partition multipath I/O devices themselves. If the underlying physical device is already partitioned, the multipath I/O device reflects those partitions and the layer provides /dev/disk/by-id/<name>p1 ... pN devices so you can access the partitions through the multipath I/O layer. As a consequence, the devices need to be partitioned prior to enabling multipath I/O. If you change the partitioning in the running system, DM-MP does not automatically detect and reflect these changes. The device must be reinitialized, which usually requires a reboot.

Supported Architectures for Multipath I/O

The multipathing drivers and tools in SUSE® Linux Enterprise Server 10 support all seven of the supported processor architectures: IA32, AMD64/EM64T, IPF/IA64, p-Series (32-bit/64-bit), z-Series (31-bit and 64-bit).

Supported Storage Arrays for Multipathing

The multipathing drivers and tools in SUSE Linux Enterprise Server 10 support most storage arrays. The storage array that houses the multipathed device must support multipathing in order to use the multipathing drivers and tools. Some storage array vendors provide their own multipathing management tools. Consult the vendor’s hardware documentation to determine what settings are required.

Storage ArraysThat Are Automatically Detected for Multipathing

The multipath-tools package automatically detects the following storage arrays:

3PARdata VV
Compaq* HSV110
Compaq MSA1000
DDN SAN MultiDirector
DEC* HSG80
EMC* CLARiiON* CX
EMC Symmetrix
FSC CentricStor*
Hewlett Packard* (HP*) A6189A
HP HSV110
HP HSV210
HP Open-
Hitachi* DF400
Hitachi DF500
Hitachi DF600
IBM* 3542
IBM ProFibre 4000R
NetApp*
SGI* TP9100
SGI TP9300
SGI TP9400
SGI TP9500
STK OPENstorage DS280
Sun* StorEdge 3510
Sun T4

In general, most other storage arrays should work. When storage arrays are automatically detected, the default settings for multipathing apply. If you want non-default settings, you must manually create and configure the /etc/multipath.conf file. For information, see Section 5.4.5, “Creating and Configuring the /etc/multipath.conf File”.

Hardware that is not automatically detected requires an appropriate entry for configuration in the DEVICES section of the /etc/multipath.conf file. In this case, you must manually create and configure the configuration file. For information, see Section 5.4.5, “Creating and Configuring the /etc/multipath.conf File”.

Consider the following caveats:

Tested Storage Arrays for Multipathing Support

The following storage arrays have been tested with SUSE Linux Enterprise Server:

EMC
Hitachi
Hewlett-Packard/Compaq
IBM
NetApp
SGI

Most other vendors’ storage arrays should also work. Consult your vendor’s documentation for guidance. For a list of the default storage arrays recognized by the multipath-tools package, see Section 5.2.8.1, “Storage ArraysThat Are Automatically Detected for Multipathing”.

Storage Arrays that Require Specific Hardware Handlers

Storage arrays that require special commands on failover from one path to the other or that require special nonstandard error handling might require more extensive support. Therefore, the Device Mapper Multipath service has hooks for hardware handlers. For example, one such handler for the EMC CLARiiON CX family of arrays is already provided.

[Important]

Consult the hardware vendor’s documentation to determine if its hardware handler must be installed for Device Mapper Multipath.

The multipath -t command shows an internal table of storage arrays that require special handling with specific hardware handlers. The displayed list is not an exhaustive list of supported storage arrays. It lists only those arrays that require special handling and that the multipath-tools developers had access to during the tool development.

[Important]

Arrays with true active/active multipath support do not require special handling, so they are not listed for the multipath -t command.

A listing in the multipath -t table does not necessarily mean that SUSE Linux Enterprise Server was tested on that specific hardware. For a list of tested storage arrays, see Section 5.2.8.2, “Tested Storage Arrays for Multipathing Support”.


SUSE® Linux Enterprise Server Storage Administration Guide 10 SP3