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

19
Serviceguard revision A.11.19 and later handle runtime delays differently than earlier revisions:
• For Serviceguard A.11.19 and later revisions, an option to handle runtime delays is to increase the Serviceguard
cluster MEMBER_TIMEOUT to a value larger than the run delay reported in the syslog file. The default value for this
cluster parameter is 14 seconds, and the maximum recommended value is 300 seconds. For most installations, a
setting of 14 seconds is usually appropriate. Note that by increasing the MEMBER_TIMEOUT value, this will have
the affect of the cluster taking longer to react to an actual node failure. Also note that after a node has not
responded to cluster heartbeats for longer than the MEMBER_TIMEOUT value, that node will be evicted from the
cluster with no chance to rejoin until after it has rebooted.
• For Serviceguard A.11.18 and earlier revisions, an option to handle runtime delays is to increase the Serviceguard
cluster NODE_TIMEOUT to a value larger than the run delay reported in the syslog file. The default value for this
cluster parameter is 2 seconds, and the maximum recommended value is 30 seconds. However, for most installations,
a setting between 5–8 seconds is usually more appropriate. Note that by increasing the NODE_TIMEOUT value, this
will have the affect of the cluster taking longer to react to an actual node failure. Also note that after a node has not
responded to cluster heartbeats for longer than the NODE_TIMEOUT value, a cluster reformation is triggered.
However, since no node had actually failed, the cluster will reform potentially with the same number of nodes it
originally had before the cmcld run delay was reported, depending on the length of the runtime delay.
In summary, advantages of VM as Serviceguard node configurations include:
• Reducing the number of physical systems required for a cluster by consolidating nodes using VMs
• Providing standard Serviceguard monitoring and HA for applications without incurring VM boot time during
failover
VM as Serviceguard node configurations have the following limitations:
• VM instances are not highly available
• A failure of a VM guest is similar to a node failure in a Serviceguard cluster
• Failover VMs will use additional VM host resources, which could be used by other VMs running on the VM host
Combining VM as Serviceguard package and node models
Starting with the HP-UX 11i v3 March 2009 product distribution, virtual machines as Serviceguard packages and virtual
machines as Serviceguard nodes in separate clusters can co-exist on the same VM hosts, allowing failover of the VM guests
and application packages within their respective clusters. An example of this configuration is shown in figure 12.
Figure 12: VMs as Serviceguard packages and nodes on the same VM hosts
VM Host VM Host
VM Guest
VM Guest package failover
VM Guest
VM Guest
Primary Node Standby Node
VM Host
Serviceguard cluster
VM Guest Node
Serviceguard cluster
VM Node package failover
VM Host VM Host
VM Guest
VM Guest package failover
VM Guest
VM Guest
Primary Node Standby Node
VM Host
Serviceguard cluster
VM Guest Node
Serviceguard cluster
VM Node package failover