Chapter 5. Managing Multipath I/O for Devices / 5.4. Configuring the System for Multipathing | ||||
|---|---|---|---|---|
 | 5.3. Multipath Management Tools | 5.5. Enabling and Starting Multipath I/O Services |  | |
Chapter 5. Managing Multipath I/O for Devices / 5.4. Configuring the System for Multipathing | ||||
|---|---|---|---|---|
| 5.3. Multipath Management Tools | 5.5. Enabling and Starting Multipath I/O Services | | |
Before configuring multipath I/O for your SAN devices, prepare the SAN devices, as necessary, by doing the following:
Configure and zone the SAN with the vendor’s tools.
Configure permissions for host LUNs on the storage arrays with the vendor’s tools.
Install the Linux HBA driver module. Upon module installation, the driver automatically scans the HBA to discover any SAN devices that have permissions for the host. It presents them to the host for further configuration.
![[Note]](admon/note.png) | Note |
|---|---|
Ensure that the HBA driver you are using does not have native multipathing enabled. | |
See the vendor’s specific instructions for more details.
After the driver module is loaded, discover the device nodes assigned to specific array LUNs or partitions.
If the LUNs are not seen by the HBA driver, lsscsi can be used to check whether the SCSI devices are seen correctly by the operating system. When the LUNs are not seen by the HBA driver, check the zoning setup of the SAN. In particular, check whether LUN masking is active and whether the LUNs are correctly assigned to the server.
If the LUNs are seen by the HBA driver, but there are no corresponding block devices, additional kernel parameters are needed to change the SCSI device scanning behavior, such as to indicate that LUNs are not numbered consecutively. For information, see Options for SCSI Device Scanning in the Novell Support Knowledgebase.
Partitioning devices that have multiple paths is not recommended, but it is supported.
In SUSE Linux Enterprise Server 10, you can use the kpartx tool to create partitions on multipathed devices without rebooting. You can also partition the device before you attempt to configure multipathing by using the Partitioner function in YaST2 or by using a third-party partitioning tool.
In SUSE Linux Enterprise Server 9, if you want to partition the device, you should configure its partitions before you attempt to configure multipathing by using the Partitioner function in YaST2 or by using a third-party partitioning tool. This is necessary because partitioning an existing multipathed device is not supported. Partitioning operations on multipathed devices fail if attempted.
If you configure partitions for a device, DM-MP automatically recognizes the partitions and indicates them by appending p1 to pn to the device’s ID, such as
/dev/disk/by-id/26353900f02796769p1
To partition multipathed devices, you must disable the DM-MP service, partition the normal device node (such as /dev/sdc), then reboot to allow the DM-MP service to see the new partitions.
The system must be manually configured to automatically load the device drivers for the controllers to which the multipath I/O devices are connected within the INITRD. Therefore add the needed driver module to the variable INITRD_MODULES in the file /etc/sysconfig/kernel.
For example, if your system contains a RAID controller accessed by the cciss driver and multipathed devices connected to a QLogic* controller accessed by the driver qla2xxx, this entry would look like:
INITRD_MODULES="cciss"
Because the QLogic driver is not automatically loaded on start-up, add it here:
INITRD_MODULES="cciss qla23xx"
After having changed /etc/sysconfig/kernel, you must re-create the INITRD on your system with the command mkinitrd, then reboot in order for the changes to take effect.
When you are using LILO as a boot manager, reinstall it with the command /sbin/lilo. No further action is required if you are using GRUB.
Use either of the methods in this section to add multipath I/O services (multipathd) to the boot sequence.
The /etc/multipath.conf file does not exist unless you create it. The /usr/share/doc/packages/multipath-tools/multipath.conf.synthetic file contains a sample /etc/multipath.conf file that you can use as a guide for multipath settings. See /usr/share/doc/packages/multipath-tools/multipath.conf.annotated for a template with extensive comments for each of the attributes and their options.
Section 5.4.5.2, “Verifying the Setup in the etc/multipath.conf File”
Section 5.4.5.3, “Configuring User-Friendly Names or Alias Names in /etc/multipath.conf”
Section 5.4.5.4, “Blacklisting Non-Multipathed Devices in /etc/multipath.conf”
Section 5.4.5.5, “Configuring Default Multipath Behavior in /etc/multipath.conf”
Section 5.4.5.6, “Applying Changes Made to the /etc/multipath.conf File”
If the /etc/multipath.conf file does not exist, copy the example to create the file:
In a terminal console, log in as the root user.
Enter the following command (all on one line, of course) to copy the template:
cp /usr/share/doc/packages/multipath-tools/multipath.conf.synthetic /etc/multipath.conf
Use the /usr/share/doc/packages/multipath-tools/multipath.conf.annotated file as a reference to determine how to configure multipathing for your system.
Make sure there is an appropriate device entry for your SAN. Most vendors provide documentation on the proper setup of the device section.
The /etc/multipath.conf file requires a different device section for different SANs. If you are using a storage subsystem that is automatically detected (see Section 5.2.3.2, “Tested Storage Arrays for Multipathing Support”), the default entry for that device can be used; no further configuration of the /etc/multipath.conf file is required.
Save the file.
After having set up the configuration, you can perform a “dry run” by entering
multipath -v2 -d
This command scans the devices, then displays what the setup would look like. The output is similar to the following:
26353900f02796769
[size=127 GB]
[features="0"]
[hwhandler="1 emc"]
\_ round-robin 0 [first]
\_ 1:0:1:2 sdav 66:240 [ready ]
\_ 0:0:1:2 sdr 65:16 [ready ]
\_ round-robin 0
\_ 1:0:0:2 sdag 66:0 [ready ]
\_ 0:0:0:2 sdc 8:32 [ready ]
Paths are grouped into priority groups. Only one priority group is ever in active use. To model an active/active configuration, all paths end up in the same group. To model active/passive configuration, the paths that should not be active in parallel are placed in several distinct priority groups. This normally happens automatically on device discovery.
The output shows the order, the scheduling policy used to balance I/O within the group, and the paths for each priority group. For each path, its physical address (host:bus:target:lun), device node name, major:minor number, and state is shown.
A multipath device can be identified by either its WWID or an alias that you assign for it. The WWID (World Wide Identifier) is an identifier for the multipath device that is guaranteed to be globally unique and unchanging. The default name used in multipathing is the ID of the logical unit as found in the /dev/disk/by-id directory. Because device node names in the form of /dev/sdn and /dev/dm-n can change on reboot, referring to multipath devices by their ID is preferred.
The multipath device names in the /dev/mapper directory reference the ID of the LUN and are always consistent because they use the /var/lib/multipath/bindings file to track the association. These device names are user-friendly names such as mpath0.
You can specify your own device names to use via the ALIAS directive in the /etc/multipath.conf file. Alias names override the use of ID and /dev/mapper/mpathN names.
![[Important]](admon/important.png) | Important |
|---|---|
We recommend that you do not use aliases for the root device, because the ability to seamlessly switch off multipathing via the kernel command line is lost because the device name differs. | |
For an example of multipath.conf settings, see the /usr/share/doc/packages/multipath-tools/multipath.conf.synthetic file.
In a terminal console, log in as the root user.
Open the /etc/multipath.conf file in a text editor.
Uncomment the Defaults directive and its ending bracket.
Uncomment the user_friendly_names option, then change its value from No to Yes.
For example:
## Use user friendly names, instead of using WWIDs as names.
defaults {
user_friendly_names yes
}
Optionally specify your own user-friendly names for devices using the alias directive in the multipath section.
For example:
multipath {
wwid 26353900f02796769
alias sdd4l0
}
Save your changes, then close the file.
The /etc/multipath.conf file should contain a blacklist section where all non-multipathed devices should be listed. For example, local IDE hard drives and floppy drives are not normally multipathed. If you have single-path devices that multipath is trying to manage and you want multipath to ignore them, put them in the blacklist section to resolve the problem.
For example, to blacklist local devices from being managed by multipath, the blacklist section looks like this:
devnode_blacklist {
wwid 26353900f02796769
devnode "^(ram|raw|loop|fd|md|dm-|sr|scd|st|sda)[0-9]*"
devnode "^hd[a-z][0-9]*"
devnode "^cciss!c[0-9]d[0-9]*[p[0-9]*]"
}
Afterwards, the local devices should no longer be listed in the multipath maps when you issue the multipath -ll command.
The /etc/multipath.conf file should contain a defaults section where you can specify default behaviors. If the field is not otherwise specified in a device section, the default setting is applied for that SAN configuration.
The following defaults section specifies a simple failover policy:
defaults {
multipath_tool "/sbin/multipath -v0"
udev_dir /dev
polling_interval 10
default_selector "round-robin 0"
default_path_grouping_policy failover
default_getuid_callout "/sbin/scsi_id -g -u -s /block/%n"
default_prio_callout "/bin/true"
default_features "0"
rr_min_io 100
failback immediate
Changes to the /etc/multipath.conf file cannot take effect when multipathd is running. After you make changes, save and close the file, then do the following to apply the changes:
