Managing Serviceguard Extension for SAP on Linux (IA64 Integrity and x86_64), February 2008

Understanding Serviceguard Extension for SAP on Linux
Clustering Stand-Alone J2EE Components
Chapter 1 23
Standard Serviceguard Extension for SAP on Linux scenarios at least
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.