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

7
Example use cases
The following are several example scenarios that can benefit from the Serviceguard integration with Integrity VM:
HA for development and test environments: Traditional development and test environments typically are not highly
available usually for cost reasons. Using Integrity VM with Serviceguard provides HA for the VMs created to
consolidate the applications used in these environments. The VMs can be failed over to another node in the event of a
VM host failure.
Maintenance and load balancing: VM guests running applications used for development or production activities can
be easily moved as Serviceguard packages to other nodes within a cluster. This is helpful when planned system
maintenance is required or to balance system loads during peak operating times.
HA for non-clustered production applications: Any production applications that were never considered critical enough
to run in a clustered environment, or applications and operating systems that do not work with Serviceguard will gain
improved availability without modification by simply moving them onto VMs and using Serviceguard to provide HA
for the VM with the possible addition of application monitoring. Serviceguard can restart the VM on another VM host
in the event of a VM host or VM guest failure. As an example, Serviceguard is not supported on Microsoft
®
Windows, but a Windows VM can be protected by Serviceguard.
Usage considerations
When implementing VMs as Serviceguard packages, several key points should be considered:
Integrity VM host nodes should only run VM guests and not other user applications.
The Integrity VM fair-share scheduler provides control of entitlements (i.e., the percentage or number of CPU clock cycles
that are guaranteed to a VM) for VMs running on the VM host. The scheduler cannot monitor or respond to VM
processing requirements with other workloads running on the VM host; therefore it is recommended to only run Integrity
VM host software and VM guests on the Serviceguard cluster nodes. This rule also applies to non-Serviceguard
configurations.
VM guests within Serviceguard packages can only failover to other Serviceguard cluster nodes that are running
Integrity VM host software.
VM guests can only run on pre-configured VM hosts. For a successful Serviceguard VM guest package failover, the
failover node must be a VM host. Having pre-requisite software installed on a failover node to support the execution
of any application within a Serviceguard package is a basic requirement for Serviceguard cluster configurations.
Serviceguard versions prior to A.11.19 can only monitor the status of the VM guest running as a Serviceguard
package not the applications running within the VM.
With a VM guest running as a Serviceguard package, Serviceguard versions prior to A.11.19 monitor the status of
the VM guest executing as an HP-UX process on the VM host and not the applications running within the guest. In this
case, any VM guest package failovers would be based on a failure of either the VM guest or its VM host node, and
not due to any application-specific failures. Techniques for monitoring applications within VM guests prior to A.11.19
and the application monitoring capabilities provided in the Serviceguard A.11.19 and later releases are described in
the application monitoring sections of this white paper.
Failover of VM guest applications is slower than clustered applications.
Applications designed for clustered environments and running on a host node can be operational after a failover
quickly as compared to an application running in a VM guest (where the guest is failed over) because they do not
have the added time required to start (i.e., boot-up) the VM before the application can be restarted. In that case, the
VM guest and its applications are being failed over together, so the total time required for an application to be
available for use consists of the VM start time, guest OS boot-up time, and the application start-up time. However, the
VM start time and guest OS boot-up time for a VM guest is significantly faster than the boot-up time of a physical
node. If failover time is a primary concern, application recovery time measurements should be taken for both
standard Serviceguard and VMs as packages configurations to determine which configuration would offer best
balance between your application consolidation and availability requirements. Also note that online migration only
eliminates restart time for a planned move but does not provide any benefit in a failover.