Managing Serviceguard Extension for SAP on Linux (IA64 Integrity and x86_64), February 2008

Understanding Serviceguard Extension for SAP on Linux
Clustering Stand-Alone J2EE Components
Chapter 1 19
Dialog Instance Clusters as Simple Tool for Adaptive
Enterprises
Databases and Central Instances are Single Points of Failure. ABAP
Dialog Instances can be installed in a redundant fashion. In theory, this
allows to avoid additional SPOFs in Dialog Instances. 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.
SAP ABAP Dialog Instances can be packages using package type (d).
This reflects the SAP abbreviation for Dialog Services. Dialog Instance
packages differ from other packages in that there might be several of
them for one SAP SID. Therefore the naming convention is slightly
altered and the unique Instance Number of the Application Server is
added. A Dialog Instance package for Instance Number 01 of SAP
System SID would be called (d01SID).
As with any other SAP component, Dialog Instances can now freely be
added to packages that also protect other parts of the setup. It is
suggested to only apply the Dialog Instance naming convention if there
are no mission-critical core components in the package. In other words,
adding a Dialog Server to a (dbciSID) package should not change the
package name.
NOTE Most SAP software components for a specific SAP application can only be
specified once in a cluster. Likewise they can also only be specified once
within a single package. Dialog Instances make an exception in that
there can be an array of these clustered by a single package. There can
also be multiple packages with Dialog Instances.
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.