Designing High Availability Solutions with HP Serviceguard and HP Integrity Virtual Machines

Note that changing the maximum memory value allocated for a VM requires the VM to be restarted with the new

value. In addition, VM memory allocation may be slow or may not be able to reach the original boot size of the VM

when VM host memory is tight or very fragmented.

Note:

Dynamic memory allocation can be done for Serviceguard Legacy packages by

placing the appropriate hpvmmgmt commands in the

customer_defined_run_cmds and customer_defined_halt_cmds functions.

Example use cases

Virtual machines as Serviceguard nodes configurations offer a variety of possible use cases for providing both

application consolidation and high availability. The following are a list of several examples:

Production application availability.

Important applications can be protected by Serviceguard and moved to another VM guest or physical node in the

event of a failure to minimize application downtime. This functionality is identical to a traditional Serviceguard cluster

using standalone physical systems or hard partitions.

Cluster node consolidation.

Both primary and standby nodes in single and multiple Serviceguard clusters can be consolidated using VM guests on

a single system to reduce hardware costs, data center floor space, and power usage, in addition to improving system

utilization while maintaining application isolation.

For Serviceguard “cluster in a box” configurations using VM guests, potential use cases include:

• Serviceguard cluster testing with minimal hardware. A Serviceguard cluster can be easily setup for testing purposes

using a “cluster in a box” configuration without requiring additional system hardware for cluster nodes.

• Reducing data center floor space and power usage while improving availability. “Cluster in a box” configurations

reduce data center floor space and power requirements while providing some level of high availability for the

applications running within the VM guests serving as nodes on a single VM host server. However, the VM host

system is still a SPOF in these configurations.

Usage considerations

Virtual machines as Serviceguard nodes configurations should be considered whenever there is a need for

consolidating systems in Serviceguard clusters and the applications require full HA monitoring and failover

functionality that is provided by Serviceguard. These configurations allow for a reduction in the total number of

physical systems required for clusters by moving cluster nodes from individual physical systems to multiple VMs

running on fewer physical systems.

As with VM as Serviceguard package configurations, Integrity VM host nodes should only run VM guests and not

other user applications, as this may adversely affect the allocation of system resources to the VM guests running on

the VM hosts.

Monitoring of applications within a VM as Serviceguard node configuration is the same as in a traditional

Serviceguard cluster because Serviceguard is running within the VM guest. No specialized monitoring agents are

required as is the case of VM as Serviceguard package configurations.

Package failover times for VM as Serviceguard node configuration will be somewhat similar to traditional

Serviceguard cluster failovers because application packages are simply restarted on their pre-configured adoptive

nodes. These configurations will not experience the additional VM boot time that is part of a VM as Serviceguard

package configuration, where the failed over VM guest package must restart the VM guest on its adoptive node.

Cluster reformation time will be somewhat longer for VM as Serviceguard node configurations (approximately

40–70 seconds longer compared to a Serviceguard cluster consisting of only physical nodes) to allow for all

outstanding I/O requests from the VM guests through the VM host virtualization layer to complete before cluster

activities can resume following a cluster reformation. Serviceguard uses an io_timeout_extension parameter that is set