Managing Serviceguard Extension for SAP on Linux (IA64 Integrity and x86_64), April 2009

Handling of Redundant Dialog Instances
Non-critical SAP WAS ABAP Application Servers can be run on HP-UX, SUSE or RedHat Linux application
server hosts. These hosts do not need to be part of the Serviceguard cluster. Even if the additional SAP WAS
services are run on nodes in the Serviceguard cluster, they are not necessarily protected by Serviceguard
packages. A combination of Windows/Linux application servers is technically possible but additional
software is required to access Linux file systems or Unix-like remote shells from the Windows system. All
non-packaged instance are called Additional Dialog Instances or sometimes synonymously Additional SAP
Application Servers to distinguish them from mission-critical Dialog Instances. An additional Dialog Instance
that runs on a cluster node is called an Internal Dialog Instance. External Dialog Instances run on HP-UX or
Linux hosts that are not part of the cluster. Even if Dialog Instances are external to the cluster, they may be
affected by package startup and shutdown. For convenience, non-critical Dialog Instances can be started
and stopped with any Serviceguard Extension for SAP on Linux package that secures critical components.
Some SAP applications require the whole set of Dialog Instances to be restarted during failover of the Central
Instance package. This can also be done with Serviceguard Extension for SAP on Linux means. Dialog
Instances can be marked to be of minor importance. They will then be shut down, if a critical component
fails over to the host they run on in order to free up resources for the non-redundant packaged components.
Additional Dialog Instances never get reflected in package names.
NOTE: Declaring non-critical Dialog Instances in a package configuration doesn't add them to the
components that are secured by the package. The package won't react to any error conditions of these
additional instances. The concept is distinct from the Dialog Instance packages that was explained in the
previous section.
Standard Serviceguard Extension for SAP on Linux scenarios will protect database, NFS, Message Server
and Enqueue Server. It is recommended that you also protect at least one instance of each additional SAP
WAS ABAP Application Service in the Serviceguard cluster. If non-packaged Additional Dialog Instances
are used, certain rules should be followed:
Use saplogon with Application Server logon groups. When logging on to an application server group
with two or more Dialog Instances, you don't need a different login procedure even if one of the Application
Servers of the group fails. Also, using login groups provides workload balancing between Application
Servers.
Avoid specifying a destination host when defining a batch job. This allows the batch scheduler to choose a
batch server that is available at the start time of the batch job. If you must specify a destination host, specify
the batch server running on the Central Instance or a packaged Application Server Instance.
Print requests stay in the system until a node is available again and the Spool Server has been restarted.
These requests could be moved manually to other spool servers if one spool server is unavailable for a long
period of time. An alternative is to print all time critical documents through the highly available spool server
of the central instance.
Configuring the Update Service as part of the packaged Central Instance is recommended. Consider using
local update servers only if performance issues require it. In this case, configure Update Services for
application services running on the same node. This ensures that the remaining SAP Instances on different
nodes are not affected if an outage occurs on the Update Server. Otherwise a failure of the Update Service
will lead to subsequent outages at different Dialog Instance nodes.
Enqueue Replication
Typically, the SAP Enqueue maintains a table of exclusive locks that you can temporarily grant to ongoing
SAP dialog transactions. This lock mechanism prevents simultaneous access to the same data in the database.
However, in case of a failure of the Enqueue Server, the table with all locks that have been granted get lost.
After failover and restart of the Enqueue Server on another cluster node, the Dialog Instances are notified
that the Enqueue locks are no longer valid. All SAP dialog transactions are canceled and must be restarted
manually.
The newer SAP Enqueue Replication consists of two components; the Enqueue Replication Service and the
Standalone Enqueue Service, of which both must be configured as Serviceguard packages. The Standalone
Enqueue Service mirrors its lock contents to an Enqueue Replication Service instance, running on a remote
node in the cluster.
22 Understanding Serviceguard Extension for SAP on Linux