Upgrading to HP Serviceguard 11.17 with Cluster Volume Manager/Cluster File Systems, December 2005

HP Serviceguard/VERITAS interoperability considerations

With Serviceguard A.11.17, as with previous versions of Serviceguard, Logical Volume Manager

(LVM) and VERITAS Volume Manager (VxVM) volumes can coexist on the cluster and can continue to

be used in the same packages, if desired. Because cluster lock disks can only be configured on LVM

Volume Groups (VGs), this functionality provides an alternative to using a Quorum Server for cluster

lock functionality.

Before version A.11.17, Serviceguard supported CVM by running VERITAS daemons in a

SYSTEM_MULTI_NODE package (SMNP) VxVM-CVM-pkg. In A.11.17, Serviceguard continues to use

the same method for working with CVM 3.5. When CVM 4.1 or above is installed, Serviceguard

closely interacts with CVM in establishing and managing cluster membership. The immediately visible

change with CVM 4.1 or higher is that the SMNP has a new name, SG-CFS-pkg, and when one of

the CFS bundles is installed, a new command, cfscluster, is available to simplify configuring and

managing this package.

Before Serviceguard A.11.17, CVM storage was specified with the STORAGE_GROUP attribute in the

package ASCII configuration file and by configuring script variables CVM_DG[*] and

CVM_DISK_ACTIVATION in the package control script. This usage continues to be supported with

Serviceguard A.11.17 for backward compatibility. In addition, with A.11.17, Serviceguard adds a

new model of management for CVM/CFS by adding several new features and commands to make

storage management both easier and more flexible. This model allows the storage infrastructure to be

configured independently of the application package configuration for improved manageability.

These new capabilities and commands are available only when one of the CFS bundles is installed.

Cluster-wide disk groups, file systems mount points, checkpoints, and snapshots can be defined in

their own Serviceguard packages, which have instances running on multiple nodes; these are called

MULTI_NODE packages (MNPs). MNPs differ from System Multi-Node packages in that the package

instance on individual nodes can be stopped and started without affecting cluster membership. The

relationships between an application and its storage are defined by declaring in the package ASCII

file that an application package depends on an MNP. This is done instead of specifying any

STORAGE_GROUP attributes and CVM_ script variables. The following is an example from an

application package’s ASCII configuration file that describes its dependency on an MNP named

SG-CFS-DG-01:

DEPENDENCY_NAME SG-CFS-DG-01

DEPENDENCY_CONDITION SG-CFS-DG-01 = UP

DEPENDENCY_LOCATION SAME_NODE

This declares that an instance of MNP named SG-CFS-DG-01 must be running on a node for the

application to start and keep running on that node. If the MNP represents a CVM disk group (as it

does in this example, according to the naming convention used), this means that availability of the

disk group is enforced by Serviceguard on the same node where the application package is running.

An application could declare its dependency on a file system MNP in a similar manner.

Dependencies are also used to establish relationships between file system MNPs (including mount

points, checkpoints, and snapshots) and disk group MNPs. A set of new commands, described in the

following section, is provided to configure and manage these specialized disk group and file system

MNPs. Configuration of MNPs other than with these commands is not supported in Serviceguard

A.11.17.

There are no changes in supported storage management capabilities for non-CVM storage with

Serviceguard A.11.17. Several data migration scenarios from non-CFS storage to CVM/CFS are

explored in later sections of this paper.