Managing Serviceguard Extension for SAP Version A.06.00 for Linux, December 2012

A dedicated SAPNFS package is specialized to provide access to shared filesystems that are
needed by more than one mySAP component. Typical filesystems served by SAPNFS would be the
common SAP transport directory or the global MaxDB executable directory of MaxDB 7.7. The
MaxDB client libraries are part of the global MaxDB executable directory and access to these files
is needed by APO and liveCache at the same time. Beginning with MaxDB 7.8 isolated
installations, each database installation keeps a separate client.
SGeSAP setups are designed to avoid NFS shared filesystems with heavy traffic if possible. For
many implementations, this gives the option to use one SAPNFS package for all NFS needs in the
SAP consolidation cluster without the risk to create a serious performance bottleneck.
NFS might still be required in configurations that use Cluster File Systems in order to provide access
to the SAP transport directories to SAP instances that run on hosts outside of the cluster.
Virtualized dialog instances for adaptive enterprises
Databases and Central Instances are Single Points of Failure. ABAP and JAVA Dialog Instances
can be installed in a redundant fashion. In theory, additional SPOFs in Dialog Instances are
avoided. This doesn't mean that it is impossible to configure the systems including SPOFs on Dialog
Instances. 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.
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.
Virtualized dialog instances for adaptive enterprises 17