Managing Serviceguard Extension for SAP Version B.05.10, 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 HA NFS shared filesystems with heavy traffic if possible.
For many implementations, this gives the option to use one SAPNFS package for all HA NFS needs
in the SAP consolidation cluster without the risk to create a serious performance bottleneck.
HA 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.
Dialog Instance Clusters as Simple Tool 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. SAP ABAP Dialog Instances can also be packages in SGeSAP legacy
package type 'd.' SAP JAVA Dialog Instances can be packaged using SGeSAP legacy package
type 'jd.'
Dialog Instance packages allow an uncomplicated 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.
Dialog Instance Clusters as Simple Tool for Adaptive Enterprises 15