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

the local subnet. Should a failover occur, the NFS client will eventually detect that the primary server

is not responding and automatically begin sending requests using the FQDN of the NFS package in

the adoptive subnet.

If your applications only require read access to NFS file systems, using client-side failover may be a

viable solution for automated recovery in a cross-subnet cluster environment. For more information

about client-side failover, refer to the “NFS Services Administrator’s Guide: HP-UX 11i version 3”

manual found on http://docs.hp.com at http://docs.hp.com/en/B1031-90068/B1031-90068.pdf.

SAP with SGeSAP in a cross-subnet cluster

Serviceguard Extension for SAP (SGeSAP) extends Serviceguard high availability and disaster

recovery capabilities to SAP environments. SGeSAP seamlessly integrates SAP into a Serviceguard

cluster. It continuously monitors the health of each SAP node to protect critical SAP and database

instances. Those instances are associated with a relocatable IP address in a Serviceguard cluster.

Known limitations with the SGeSAP in a cross-subnet cluster

At this time, the Serviceguard Extension for SAP is generally not supported in cross-subnet

configurations due to the following limitations:

 SAP instances can be configured using an IP address or a name resolving to an IP address. Even

when using names in the configuration, SAP instances only resolve the name at initial startup and

cache the IP resolution during the entire time an instance is up. If a second instance fails-over to a

node in a different subnet, the first instance keeps trying to reconnect to second instance using the

cached IP address. This applies to the communication between various SAP instances as well as to

the communication between the SAP instances and database.

 Most SAP systems depend on NFS. There are limitations with NFS in a cross-subnet cluster which

also need to be addressed in an SAP environment. These limitations are documented in the “NFS in

a cross-subnet cluster” section.

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

in which it is guaranteed that all the SAP instances and database of an SAP system always run in the

same subnet or are restarted if one of the instances fails over to a different subnet. This is achievable

if the SAP system with all its instances has no external connectivity to other SAP systems or third party

software interacting with the clustered SAP system. However, if external connections to the clustered

SAP system exist, they need to be analyzed in regards to how they can handle a change of the IP

address under which the clustered SAP system is currently running.

See the current “Serviceguard Extension for SAP Release Notes” or “Serviceguard Support Matrix” for

any updates to HP’s support policy regarding SGeSAP in a cross-subnet Serviceguard cluster. Both

documents can be found at http://docs.hp.com -> High Availability.

Potential workarounds for using SAP in a cross-subnet cluster

The primary reason why SGeSAP is not yet generally supported in a cross-subnet cluster is that the

different SAP instances cache the hostname resolution at application startup and have no means to

update it during run-time.

Note

Implementing the workarounds described in this section does not imply that

HP will support the use of the SGeSAP in a cross-subnet configuration. In

absence of a generally supported solution, this would need to be evaluated

on a per-customer/application Please check the current SGeSAP