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

Benefits and challenges of cross-subnet support

Benefits of a cross-subnet network architecture in a Serviceguard cluster

Cross-subnet support is particularly beneficial for clusters spanning multiple locations such as

Metroclusters and some Extended Distance Cluster (EDC) configurations. EDC with CVM/CFS are

currently not supported in a cross-subnet configuration since CVM requires level two connectivity

between all cluster nodes. Additionally cross-subnet support can be useful for Serviceguard clusters

that span any distance.

Benefits of cross-subnet support in terms of network architecture include:

 Easier troubleshooting – Each site in a cluster can now be isolated on its own subnet, minimizing

the impact of events such as broadcast storms and other networking problems which can be difficult

to diagnose if the sites are on a single IP subnet.

 Less complexity and higher availability – It is simpler to implement distributed networks across

multiple subnets. Distributed networks on a single IP subnet over long distances can increase the

number of single points of failure and lead to lower availability.

 Manageability – Corporate IP addressing and security policies may prevent you from stretching a

single subnet across sites or even across single site. Cross-subnet support allows Serviceguard

clusters to adhere to such policies.

Challenges for applications in a cross-subnet Serviceguard cluster

While cross-subnet support in Serviceguard brings several benefits in terms of network architecture,

support for packages failing over between different subnets presents some challenges. This is because

the relocatable IP address bound to a package will change when the package fails over from one

subnet to another. This breaks with a long-time assumption under which applications have been

integrated into Serviceguard clusters.

Below are the challenges for applications when the relocatable IP address changes upon failover:

 Identifying the sudden loss of a destination of an IP connection. This challenge is sometimes the

same as in a configuration in which the relocatable IP address stays the same, unless the

application relies on the relocatable IP address remaining the same when the package fails over.

 If an application depends upon a specific domain name, but not on a specific IP address, the DNS

information needs to be updated with the relocatable IP address of the other subnet upon failover

across subnets. This update needs to happen within a short time after the site failure and often on a

company-wide basis. Sometimes these updates need to happen across company boundaries if the

computing systems are interconnected with each other.

 Updating the DNS information is often not sufficient. The clients or application components of multi-

tier applications which stay up while their IP communication endpoints fail over to a different subnet

also need to re-resolve the DNS name to become aware of the changed IP address. Clients and

applications may cache the name resolution and keep using IP addresses from before the failure or

DNS system update. This leads to unsuccessful connection attempts.

These challenges, along with descriptions of how they can be resolved, are discussed in this

whitepaper.

Network configuration requirements and recommendations

The existing Serviceguard network configuration requirements also apply for cross-subnet network

configuration unless specified otherwise. The requirements listed below are cross-subnet specific

unless otherwise specified, or when we want to reiterate an existing requirement.