HP Serviceguard Monitoring LVM Disks Through Event Monitoring Service, Replacing Failed I/O Cards

Monitoring LVM Disks Through Generic Resources Monitoring Service

If you are using LVM, you can configure disk monitoring to detect a failed mechanism by using the disk monitor capabilities of the System Fault Management, available as a separate product, and integrating it in Serviceguard by configuring generic resources in packages. Monitoring can be set up to trigger a package failover or to report disk failure events to Serviceguard by writing monitoring scripts, which can be configured as a service in a package.

Monitoring scripts are user-written scripts that must contain the core logic to monitor a resource and set the status of a generic resource using the generic resource commands, cmgetresource(1m) and cmsetresource(1m).

For more information, see:

•“Using Generic Resources to Monitor Volume Groups” (page 100)

•“Monitoring Script for Generic Resources” (page 390)

•“Getting and Setting the Status/Value of a Simple/Extended Generic Resource” (page 135) and the manpages

Monitoring LVM Disks Through Event Monitoring Service

If you are using LVM, you can configure disk monitoring to detect a failed mechanism by using the disk monitor capabilities of the EMS HA Monitors, available as a separate product. Monitoring can be set up to trigger a package failover or to report disk failure events to a Serviceguard, to another application, or by email. For more information, see “Using EMS to Monitor Volume Groups” (page 101).

Monitoring VxVM and CVM Disks

The HP Serviceguard VxVM Volume Monitor provides a means for effective and persistent monitoring of VxVM and CVM volumes. The Volume Monitor supports Veritas Volume Manager versions 4.1 and 5.0, as well as Veritas Cluster Volume Manager (CVM) versions 4.1and 5.0.

You can configure the Volume Monitor (cmvxserviced) to run as a service in a package that requires the monitored volume or volumes. When a monitored volume fails or becomes inaccessible, the service will exit, causing the package to fail on the current node. (The package’s failover behavior depends on its configured settings, as with any other failover package.)

For example, the following service_cmd monitors two volumes at the default log level 0, with a default polling interval of 60 seconds, and prints all log messages to the console:

/usr/sbin/cmvxserviced /dev/vx/dsk/cvm_dg0/lvol1 /dev/vx/dsk/cvm_dg0/lvol2

For more information, see the cmvxserviced (1m) manpage. For more information about configuring package services, see the parameter descriptions starting with service_name (page 243).

Replacing Failed Disk Mechanisms

Mirroring provides data protection, but after a disk failure, the failed disk must be replaced. With conventional disks, this is done by bringing down the cluster and replacing the mechanism. With disk arrays and with special HA disk enclosures, it is possible to replace a disk while the cluster stays up and the application remains online. The process is described under “Replacing Disks” (page 324) .

Replacing Failed I/O Cards

Depending on the system configuration, it is possible to replace failed disk I/O cards while the system remains online. The process is described under “Replacing I/O Cards” (page 326).

34 Understanding Serviceguard Hardware Configurations