HP Serviceguard Extended Distance Cluster for Linux A.11.20.20 Deployment Guide, August 2013

hangs when access to a mirror is lost. However, the MD device resumes activity when the specified
hang period expires. This ensures that no data is lost.
This parameter is required to address a scenario where an entire datacenter fails but all its
components do not fail at the same time but undergo a rolling failure. In this case, if the access to
one disk is lost, the MD layer hangs and data is no longer written to it. Within the hang period,
the node goes down and a cluster reformation takes place. When the package fails over to another
node, it starts with a disk that has current data.
3.3.1.2 Configuring Single Path to Storage
For Fibre Channel cards, you can configure the timeout parameter using the Link Down Timeout
parameter. Link Down Timeout parameter, in turn can be configured using SANSurfer CLI tool
on Red Hat Enterprise Linux 5 and 6 or SUSE Linux Enterprise Server 11 SP1 and using
QConvergeConsoleCLI tool on SUSE Linux Enterprise Server SP2.
For Emulex cards, you can configure the timeout parameter using the Link Down Timeout
parameter that can be configured using HBAAnywhere tool.
3.3.1.3 Configuring Multiple Paths to Storage
In addition to configuring the Link Down Timeout parameter for each card as described in the
previous section, you need to configure the dev_loss_tmo parameter in the /etc/
multipath.conf file to a value greater than the cluster reformation time.
3.3.2 Using Persistent Device Names
Once the storage is configured, you need to create persistent device names using udev. In cases
of disk or link failure and subsequent reboot, it is possible that device names are renamed or
reoriented. Since the MD mirror device starts with the names of the component devices, a change
in the device name prevents the MD mirror from starting. To avoid this problem, HP requires that
you make the device names persistent.
When there is a disk related failure and subsequent reboot, there is a possibility that the devices
are renamed. Linux names disks in the order they are found. The device that was /dev/sdf may
be renamed to /dev/sde if any “lower” device is failed or removed. As a result, you cannot
activate the MD device with the original name.
HP requires that the device names be persistent to avoid reorientation after a failure and reboot.
For more information on creating persistent device names, see the Using udev to Simplify HP
Serviceguard for Linux Configuration white paper that is available at the following location:
http://www.hp.com/go/linux-serviceguard-docs
When creating persistent device names, ensure that the same udev rules file exists in all the nodes.
This is necessary for the symlinks to appear and point to the correct device. Use these persistent
device names wherever there is a need to specify the devices for extended cluster configuration
or during recovery process after a failure. A persistent device created based on the instructions in
the document mentioned earlier will have a device name that starts with/dev/hpdev/.
NOTE: The name of the MD device must be unique across all packages in the cluster. Also, the
names of each of their component udev devices must also be unique across all nodes in the cluster.
udev rule files are stored in the /etc/udev/rules.d directory.
3.3.3 Creating a Multiple Disk Device
To enable Software RAID in your environment, you need to first create the mirror setup. This implies
that you specify two disks to create a Multiple Device (MD). When configuring disks in RAID 1
level, use a disk or LUN from each datacenter as one mirror half. Be sure to create disk sets of the
same size as they need to store data that are of identical sizes. Differences in disk set size results
24 Configuring your Environment for Software RAID