Managing Serviceguard Extension for SAP Version B.05.10, September 2010

The described shutdown operation for Dialog Instance packages can be specified in any SGeSAP
legacy package directly. In modularized SGeSAP, it is recommended to use generic Serviceguard
package dependencies instead.
Handling of Redundant Dialog Instances
Non-critical SAP Application Servers can be run on HP-UX, Novell SLES or RedHat RHEL Linux
application server hosts. These hosts do not need to be part of the Serviceguard cluster. Even if
the additional SAP services are run on nodes in the Serviceguard cluster, they are not necessarily
protected by Serviceguard packages. A combination of Windows/HP-UX application servers is
technically possible, but additional software is required to access HP-UX filesystems or HP-UX-like
remote shells from the Windows system.
All non-packaged ABAP instances are subsequently 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, Additional Dialog Instances can be started, stopped or restarted with any
SGeSAP package that secures critical components. Some SAP applications require the whole set
of Dialog Instances to be restarted during failover of the Central Service package. This can be
triggered with SGeSAP means.
It helps to better understand the concept, if one considers that all of these operations for
non-clustered instances are considered inherently non-critical. If they fail, this failure won’t have
any impact on the ongoing package operation. A best-effort attempt is made, but there are no
guarantees that the operation succeeds. If such operations need to succeed, package dependencies
in combination with SGeSAP Dialog Instance packages need to be used.
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.
The described functionality can be achieved by adding the module sgesap/sapextinstance
to the package. Legacy SGeSAP provides similar functionality, but SAP JAVA instances are not
handled.
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 got
explained in the previous section.
If 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.
20 Designing SGeSAP Cluster Scenarios