Using udev to simplify HP Serviceguard for Linux configuration, March 2014

Technical white paper | Using udev to simplify HP Serviceguard for Linux configuration
2
Introduction
Device names are generally assigned by Linux at boot time. Using these device names in scripts or other applications can
cause problems as configurations change over time. HP Serviceguard for Linux requires the use of device names in user
modified scripts and for LockLUN or mirror halves of an MD in context of Extended Distance Cluster (XDC). This white paper
describes the use of the Linux function udev to provide persistent device names with Serviceguard for Linux so that scripts
are not affected by changes in system configuration.
This white paper is not intended to replace the main page and other udev documentation (see the
learn more section at the
end of the white paper). The intent is to highlight tools and configuration recommendations that are known to work with
HP Serviceguard for Linux.
Configuring an HP Serviceguard for Linux cluster requires the configuration and use of storage. When a Linux system boots,
it assigns a name to each storage device it discovers. Typically, these devices have names of the form /dev/sdN or
/dev/cciss/cXdY where N is one or more letters and X, Y, and Z are numbers. In multipath environment, these devices have
names of the form /dev/dm-X where X is a number. In a cluster, we are most concerned with shared storage. Since the
storage arrays that are used are configurable, these device name assignments can change if the array configuration is
changed. While there may be other actions within the system that can cause a change, the important factor is that any name
change might affect the cluster configuration. To simplify management of the cluster, these name changes should be
“hidden” from Serviceguard for Linux.
In some cases, the Linux function udev can provide this persistent naming. The method of using udev with Serviceguard is
described here.
This white paper covers only Red Hat 5, Red Hat 6, and Novell SLES 11 SP1 and SP2. Red Hat 5, Red Hat 6,
and Novell SLES 11 SP1 use the “2.6” Linux Kernel and Novell SLES 11 SP2 uses the “3.0” Linux Kernel.
Audience
This document is for users of HP Serviceguard on Linux who are setting up a cluster or writing package control scripts.
It is assumed that the reader has a general understanding of HP Serviceguard for Linux and of configuring a Linux system.
Naming considerations
To better understand when to use persistent naming, it is useful to know what functions can have problems if device names
change. Four potential problem areas with Serviceguard for Linux are:
• LockLUN
• Mirror halves of an MD device
• cmresserviced
• LVM
When configuring a LockLUN with Serviceguard, a LUN name must be given. Typically, the LUN name is based on the device
name. This is then built into the Serviceguard configuration. If this device name changes on a particular node, that node will
no longer have access to the LockLUN device and cannot establish quorum. This problem can only occur when a node is
rebooting so it will not take down a cluster. It may prevent a node from joining a cluster, prevent the cluster from starting, or
report errors that may cause problems if further failures occur.
When configuring packages in Serviceguard-XDC environment, MD device and the mirror halves which comprise the MD
device must be given in the package configuration file. Typically, the names of the mirror halves are based on the device
name. This is then built into the Serviceguard configuration. If the device name changes on a particular node, that node will
no longer have access to the mirror half and it can jeopardize MD functionality. Since XDC uses MD driver for data replication,
data replication can be compromised. This problem may only occur when a node is rebooting.
The Serviceguard for Linux disk monitoring daemon cmresserviced is required when there is only one path to shared
storage from a server. The cmresserviced daemon can be configured to monitor one or more disks. If the disk names
change then cmresserviced is either monitoring the wrong disk or trying to monitor a disk that no longer exists. This could
prevent a package from running.
Serviceguard recommends naming persistence with LVM and the logical volume definitions. In most systems, vgscan is run
at boot time and LVM finds all of the devices that are used. LVM looks at information that was put on the disk at VG creation,
so LUN name persistence is not critical. Problems may occur if, for some reason LUNs are added or deleted while the system
is running. Also, it is easier to manage a system when the LUN names are user defined rather than system defined.