Technical Considerations for a Serviceguard Cluster that Spans Multiple IP Subnets, July 2009

14
Advantages of modular packages in cross-subnet clusters
As mentioned in the section Challenges for applications in a cross-subnet Serviceguard cluster, upon
failover of an application package from one subnet to another, the relocatable IP address which is
bound to the package changes. Both legacy and modular packages in Serviceguard enable
automatic failover of packages across subnets by means of the new parameter
monitored_subnet_access. Change of subnets and relocatable IP addresses are now allowed upon
remote failover for a package. Among changes made for this enhancement are:
 For modular packages, a new parameter ip_subnet_node is introduced so user can indicate which
nodes a package subnet is configured on.
 For legacy packages, you cannot indicate which node a package subnet is configured on. Instead,
you will need to create a separate control script to be used by the nodes on each subnet if you are
using relocatable IP addresses. That means you cannot share a single package control script among
nodes on different subnets.
For this reason, HP recommends using modular packages for simpler (or less error prone) package
configuration in a cross-subnet cluster.
For more information on how to configure packages in a cross-subnet cluster, see “About Cross-subnet
Failover” in Chapter 4 and “Package Parameter Explanations” in Chapter 6 of the “Managing
Serviceguard” manual, which you can find on http://docs.hp.com under High Availability 
Serviceguard. For information about modular versus legacy packages, see Chapter 6 of Managing
Serviceguard.
General application integration considerations
This chapter focuses on application specific considerations and potential issues when integrating an
application in a cross-subnet Serviceguard cluster. Those applications are referred to as “clustered
applications” in this document. Client programs and other applications that need to connect to these
clustered applications face new challenges in a cross-subnet configuration.
In the past, applications were integrated with Serviceguard under the assumption that the IP address
bound to a clustered application remains the same when failing over to another cluster node. Refer to
Appendix B “Designing Highly Available Cluster Applications” of the “Managing Serviceguard”
manual for general guidelines on how to make applications highly available in a Serviceguard
cluster. In a cross-subnet Serviceguard cluster this is different. The relocatable IP address will change
when the package fails over to a node in a different subnet. The considerations discussed here result
from this difference.
Handling of application failures from client’s perspective
There are two scenarios for clients when a clustered application fails over from one node to another:
 Clients that make new connections after the failover need to be directed to the appropriate cluster
node. In a non-cross-subnet configuration, clients simply use the relocatable IP address or the
name resolving to it for this connection request. In a cross-subnet configuration, there are two
relocatable IP addresses to choose from. There needs to be a mechanism put in place that allows
clients to connect to the appropriate relocatable IP address.
 Clients that have an existing connection open to the application when it fails over to another node
will run into an error condition or a hang state.
o For situations in which the connection hangs on the client while the clustered application
is failing over to an adoptive node and the client did not implement application-specific
timeouts, customers might chose to set system-wide TCP timeouts to break these
connections out of their hang state. While this is not specific to cross-subnet clusters,