Managing Serviceguard Extension for SAP on Linux (IA64 Integrity and x86_64), April 2009

NOTE: Multiple dialog instances can be configured to start from a single SGeSAP package compared to
all the other once from the appropriate package e.g. a SGeSAP database package can only start one
database, a SCS package can only start one Enqueue and Message Sever.
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.
One can simulate this flexibility by installing Dialog Instances on every host and activating 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.
Using Dialog Instance package SAP adoptive computing, packages become highly available, and the system
itself becomes more robust and flexible.
Figure 1-5 Failover Node with Application Server package
Figure 1-5 illustrates a common configuration with the adoptive node running as a Dialog Server during
normal operation. node1 and node2 have equal computing power and the load is evenly distributed between
the combination of database and Central Instance on node1 and the additional Dialog Instance on node2.
All software services provided by the Dialog Instance are also configured as part of the Central Instance. If
node1 fails, the Dialog Instance package will be shut down during failover of the (dbciSID) package.
This is similar to a one-package setup without Dialog Instance packaging. The advantage of this setup is,
that after repair of node1, the Dialog Instance package can just be restarted on node1 instead of node2.
This saves downtime that would otherwise be necessary caused by a fail back of the (dbciSID) package.
The two instances can be separated to different machines without impacting the production environment
negatively. It should be noted that for this scenario with just two hosts there is no requirement to enable
automatic failover for the Dialog Instance package.
Clustering Stand-Alone J2EE Components 21