Managing Serviceguard Extension for SAP Version B.05.10, December 2012

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 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. In addition, JAVA AAS is supported. 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.
• 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.
Dedicated Failover Host
More complicated clusters that consolidate a couple of SAP applications often have a dedicated
failover server. While each SAP application has its own set of primary nodes, there is no need to
also provide a failover node for each of these servers. Instead, there is one commonly shared
secondary node that is capable of replacing any single failed primary node. Often, some or all
of the primary nodes are partitions of a large server.
Dedicated Failover Host 17