HP Serviceguard manual Problems with VxVM Disk Groups, Package Movement Errors

You can also check the syslog file for information.

CAUTION: Do not use the HP-UX mount and umount commands in a CFS cluster. Use cfsmount and cfsumount for legacy CFS packages; cmhaltpkg and cmrunpkg for modular CFS packages. Commands such as mount -o cluster, dbed_chkptmount, or sfrac_chkptmount could cause conflicts with subsequent command operations on the file system or Serviceguard packages. Non-CFS mount commands will not create an appropriate multi-node package, with the result that the cluster packages are not aware of the file system changes.

Problems with VxVM Disk Groups

This section describes some approaches to solving problems that may occur with VxVM disk groups in a cluster environment. For most problems, it is helpful to use the vxdg list command to display the disk groups currently imported on a specific node. Also, you should consult the package control script log files for messages associated with importing and deporting disk groups on particular nodes.

Force Import and Deport After Node Failure

After certain failures, packages configured with VxVM disk groups will fail to start, logging an error such as the following in the package log file:

vxdg: Error dg_01 may still be imported on ftsys9 ERROR: Function check_dg failed

This can happen if a package is running on a node which then fails before the package control script can deport the disk group. In these cases, the host name of the node that had failed is still written on the disk group header.

When the package starts up on another node in the cluster, a series of messages is printed in the package log file

Follow the instructions in the messages to use the force import option (-C) to allow the current node to import the disk group. Then deport the disk group, after which it can be used again by the package. Example:

vxdg -tfC import dg_01

vxdg deport dg_01

The force import will clear the host name currently written on the disks in the disk group, after which you can deport the disk group without error so it can then be imported by a package running on a different node.

CAUTION: This force import procedure should only be used when you are certain the disk is not currently being accessed by another node. If you force import a disk that is already being accessed on another node, data corruption can result.

Package Movement Errors

These errors are similar to the system administration errors, but they are caused specifically by errors in the control script for legacy packages. The best way to prevent these errors is to test your package control script before putting your high availability application on line.

Adding a set -xstatement in the second line of a legacy package control script will cause additional details to be logged into the package log file, which can give you more information about where your script may be failing.

Node and Network Failures

These failures cause Serviceguard to transfer control of a package to another node. This is the normal action of Serviceguard, but you have to be able to recognize when a transfer has taken place and decide to leave the cluster in its current condition or to restore it to its original condition.

Solving Problems 337