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

details on individual timeouts and methods of how to set them on HP-UX are documented

in “HP-UX 11i TCP/IP Performance White Paper”.

o When an error condition is encountered, clients should keep trying to reconnect to the

clustered application through its relocatable IP address until the application is eventually

up and running on the adoptive node. In a cross-subnet Serviceguard cluster, those

reconnect attempts need to consider the fact that the application might be available at a

different relocatable IP address. This is the case if the application failed over to a node in

a different subnet. There are generally two options available depending on whether a

client can be made aware of two different destinations; each is discussed below.

The client is aware of two different destinations

The client software is aware of the two different relocatable IP addresses under which the application

might be reachable. In this case, client configuration files allow specifying either multiple IP addresses

or domain names resolving to the relocatable IP addresses. Examples are:

 Oracle clients using a tnsnames.ora file with multiple destination protocol entries, and

 NFS client site failover configurations.

Both are described in more detail in the application-specific section later in this document. In this

case, the name resolution for the relocatable IP addresses of

db-srv1.hp.com  15.84.120.5 and

db-srv2.hp.com  15.84.136.5

do not have to change. Clients can either use the domain names or the IP address in their

configuration, but need to have a mechanism in place indicating when to choose one over the other

destination.

The client is not aware of two potential destinations

If the client has no method of configuring multiple destinations for the application to connect to, the

client can’t use the relocatable IP addresses directly. In this case, the client must use a domain name

to connect to the application, and this domain name needs to resolve to one of the relocatable IP

address. While the application runs on a node connected to subnet-A, the domain name of the

package must resolve to IP-A. When the application moves to a node connected to subnet-B, the name

resolution for the package domain name needs to change to IP-B. Two requirements must be fulfilled

to allow a client to successfully connect and reconnect to an application after a failover to a node in a

different subnet:

 The name resolution needs to be updated on a cross-subnet fail-over of the application. Methods to

achieve this are pointed to in the next section.

 Clients must re-resolve the name-to-IP-address mapping before trying to reconnect to the application

and not just use a cached IP address for the reconnect attempt.

Name resolution update upon cross-subnet failure

If a client is unaware of the two different relocatable IP addresses associated with a clustered

application in a cross-subnet configuration, and uses a single name (hostname) to refer to the

application, the mapping of that name to the appropriate IP address needs to change depending on

which subnet the application is running on. There are several aspects to this change:

First, the mapping between the name and IP address needs to be updated after a cross-subnet failure.

Names can either be resolved by using local configuration files, by a name resolution service/system,

or by a hardware device.