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

This section of the white paper discusses the issues involved with the failover of an NFS server

package in a cross-subnet Serviceguard cluster. This paper does not address the concept of a

Serviceguard failover involving NFS client systems.

Known limitations with the Serviceguard NFS Toolkit in a cross-subnet

cluster

At this time, the Serviceguard NFS Toolkit is generally not supported in cross-subnet configurations

due to the following limitations:

 The use of a cross-subnet cluster implies the virtual IP address associated with the NFS server

package will change when the package transitions from one IP subnet to another subnet. NFS

client systems that have file systems mounted using the original virtual IP address will hang once this

happens because they continue sending NFS requests to the old IP address. There is currently no

mechanism that allows NFS clients to automatically recover from this event.

 It is currently not known if NFS file locks can be successfully recovered following a package failover

to a different physical IP subnet.

The only configuration which is not subject to the above limitations is a disaster tolerant configuration

in which it is guaranteed that the NFS server and all associated NFS clients always run in the same

subnet. This requires that during any failure which involves either the NFS server or one of the NFS

clients moving to a different subnet, the entire collection of NFS server and clients need to move

together to that subnet.

Please refer to the current “Serviceguard NFS Toolkit Release Notes” for any update to HP’s support

policy regarding cross-subnet Serviceguard clusters. The latest version of the release notes may be

found here: http://docs.hp.com/en/ha.html#Highly%20Available%20NFS.

Potential workarounds for using NFS in a cross-subnet cluster

As stated earlier, the primary reason why the Serviceguard NFS toolkit is not supported in a cross-

subnet cluster is that the virtual IP address associated with the NFS server package changes when the

package transitions to a node in a different IP subnet. For any mounted NFS file system clients keep

using the original virtual IP address for any further communication with the NFS server – even if the

NFS server package failed over to a node on a different subnet. This section of the paper discusses a

number of potential ways to work around the limitations described above.

Note:

Implementing the workarounds described in this section does not imply that

HP will support the use of the Serviceguard NFS Toolkit in a cross-subnet

configuration. This would need to be evaluated on a per-

customer/application basis.

Workaround 1: Forcible unmount

One potential workaround to the issue of hung NFS file systems is to “forcibly” unmount the file

systems on the NFS client and re-mount them using the new IP address of the Serviceguard package

running in the adoptive subnet. HP introduced the “forcible” unmount option (umount –f) in HP-UX

11i v2. This option allows NFS client systems to unmount NFS file systems even if they are hung due

to a non-responsive server, or in the cross-subnet cluster case, when the server’s IP address has

changed. Any open files or NFS file locks held at the time of the forcible unmount request will be

released.

Refer to the umount_nfs(1M) man page for more information about the “–f” umount option.