Using udev to Simplify HP Serviceguard for Linux Configuration, October 2006

3
Naming Considerations
To better understand when to use persistent naming, it is useful to know what functions can
have problems if device names change. Three potential problem areas with Serviceguard
for Linux are:
•
LockLUN
•
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.
The Serviceguard for Linux disk monitoring daemon cmresserviced, is required when there
is only one path to shared storage from a server. The control script passes one or more
disk names to cmresserviced. 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.
CCISS
CCISS devices (MSA500 family) are not supported with udev. Because of the nature of
the MSA500 family, device names will not change unless a device is deleted. To prevent
issues with Serviceguard, do not delete a MSA500 device whose identifier is between two
other devices.