Managing Serviceguard Extension for SAP Version B.05.10, September 2010

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.
Figure 1-4 Failover Node with Application Server package
Figure 1-4 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 Service Instance on node1 and the
additional Dialog Instance on node2. 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 failback 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 not necessarily a requirement to enable automatic failover
for the Dialog Instance package.
Dialog Instance Clusters as Simple Tool for Adaptive Enterprises 19