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

26
documentation and Serviceguard support matrix for updates on the support
status or contact your HP support representative.
An obvious workaround to the cached name resolution issue is to restart the entire SAP application
stack if one of the instances fails over to a different subnet. Stopping the SAP application instance
would also be necessary to implement the NFS forcibly un-mount workaround as described in the NFS
section.
Once the SAP instances have been stopped and the NFS file systems are forcibly un-mounted, the file
systems may be re-mounted using the new virtual IP address of the package running in the adoptive
subnet. Before re-mounting and SAP startup can be initiated, the name resolution on all involved
systems needs to be updated by means discussed in the “General application integration
considerations” section.
The use of some GSLB devices violates current SAP networking guidelines. These guidelines require a
name resolution mechanism which provides a consistent hostname lookup with a unique one-to-one
relationship between hostname and IP and a consistent reverse lookup. This means that at any given
time when a gethostbyname(host-A) returns “IP-A”, a gethostbyaddr(IP-A) should return
“host-A”. This is not the case for some GSLBs devices when used to dynamically resolve the
hostnames. Please check the specifications of the particular device you are interested in deploying.
SAP ABAP frontend client connections
SAP ABAP front-end clients either connect directly to an application server instance, or utilize a load
balancing feature called SAPLOGONGROUP. When using SAPLOGONGROUP, clients first contact
the SAP message server to be forwarded to the least utilized application server instance providing the
requested service. If an application failure happens, the user needs to initiate a new log-on to the SAP
system.
Since the log-on is a manual, user-initiated process in either case, two different login destinations
could be configured, one for the “normal” case and one for the disaster recovery scenario pointing to
a destination in the other subnet. In this case each relocatable IP address would have its own name
and a re-resolution would not be required.
If a single name is configured at the SAP frontend client, the name needs to be re-resolved after a
cross-subnet failover and before the user tries to reconnect. This can be achieved by any of the
methods described in the “Name resolution update upon cross-subnet failure” section.
Connecting directly to an SAP instance makes sense if that instance is clustered and known to the
client by the same name regardless of in which subnet the instance is running. If such an instance fails
over to a different subnet, the state of the client is known by the instance and the client can resume its
work from where it left before the failure. In this scenario, the client needs to know about all potential
SAP application server instances.
When using SAPLOGONGROUP to connect to an SAP instance, the client only needs to know how to
reach the message server and not how to reach individual application servers.
However since it is not known to which instance the client will be forwarded, the client’s state
information from before the failure is likely not to be available at the application server. For this
reason, clients start at the root level menu when logging on to an SAP instance.
Summary
Cross-subnet support provides higher availability and easier troubleshooting and management of
networks.
To fully benefit from cross-subnet support, be sure to follow all of the configuration requirements and
recommendations described in this paper. As a summary, a cross-subnet cluster must have: