Managing HP Serviceguard Extension for SAP for Linux, December 2013

SGeSAP setups are designed to avoid NFS with heavy traffic on shared filesystems if possible. For
many implementations, this allows the use of one SAPNFS package for all NFS needs in the SAP
consolidation.
2.10 Virtualized dialog instances for adaptive enterprises
Databases and Central Instances are Single Points of Failure where as ABAP and JAVA Dialog
Instances can be installed in a redundant fashion. In theory, there are no SPOFs in redundant
Dialog Instances. This does not mean that these Dialog Instances are free of any SPOFs. A simple
example for the need of a SAP Application Server package is to protect dedicated batch servers
against hardware failures.
Any number of SAP Application Server instances can be added to a package that uses the module
sgesap/sapinstance.
Dialog Instance packages allow simple approach to achieve abstraction from the hardware layer.
It is possible to shift around Dialog Instance packages between servers at any given time. This
might be desirable if the CPU resource consumption is eventually balanced poorly due to changed
usage patterns. Dialog Instances can then be moved between the different hosts to address this.
A Dialog Instance can also be moved to a standby host to allow planned hardware maintenance
for the node it was running on.
To simulate this flexibility, you can install Dialog Instances on every host and activate them if
required. This might be a feasible approach for many purposes and saves the need to maintain
virtual IP addresses for each Dialog Instance. But there are ways that SAP users unintentionally
create additional short-term SPOFs during operation if they reference a specific instance via its
hostname. This could e.g. be done during batch scheduling. With Dialog Instance packages, the
system becomes invulnerable against this type of user error.
Dialog Instance virtualization packages provide high availability and flexibility at the same time.
The system becomes more robust using Dialog Instance packages. The virtualization allows moving
the instances manually between the cluster hosts on demand.
2.11 Handling of redundant dialog instances
Non-critical SAP Application Servers can be run on HP-UX, SLES or 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.
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.
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.
2.10 Virtualized dialog instances for adaptive enterprises 21