Managing Serviceguard Extension for SAP on Integrity Linux, December 2005

Understanding Serviceguard Extension for SAP on Integrity Linux
Application Servers
Chapter 116
For all application server nodes outside the Serviceguard for Linux
cluster, refer to the following for each of the SAP services:
• Dialog—Logon using saplogon for an application server groups
instead of sapgui for each individual application server. When
logging on to an application server group with two or more
application servers, you not 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.
• Update—Configure an update service on a node only for application
services running on the same node. This ensures that the remaining
SAP servers, running on different nodes, are affected if an outage
occurs on the update server. However, if the update server is
configured to be responsible for application servers running on
different nodes, any failure of the update server will lead to
subsequent outages at these nodes. Configuring the update service
on the high available central instance is recommended. Consider
using local update servers only if performance issues require it.
• Batch—Do not specify 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 highly
available central instance.
• Spool—Print requests stay in the system until the 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.
• Gateway—The gateway processes gwrd and gwwr are not single
points of failure.