Managing Serviceguard Extension for SAP, December 2007

Understanding Serviceguard Extension for SAP
Designing SGeSAP Cluster Scenarios
Chapter 118
Every ABAP Engine also requires a database service. Usually, this is
provided by ORACLE or MAXDB RDBMS systems. For certain setups,
IBM INFORMIX and IBM DB/2 are also supported. DB/2 can not be used
for server consolidation scenarios. The package type db clusters any type
of these databases. It unifies the configuration, so that database package
administration for all vendors is treated identically.
If you are planning a three-tier SAP layout, use the SGeSAP
two-package model. The SAP WAS functionality is separated into two
SGeSAP packages, one for the database (db) and the other for the SAP
WAS Central Instance (ci). In small and medium size environments, the
database package gets combined with HA NFS server functionality to
provide all filesystems that are required by the software in both
packages.
There are a some advantages to this approach. Usually a Central
Instance can reconnect to a failed database, once the database got
restarted by SGeSAP on the failover node. A failed Central Instance will
never cause a failover of the underlying database if it is separated in a
different package.
The process of failover results in downtime that can last several minutes,
depending on the work in progress when the failover takes place. A main
portion of downtime is needed for the recovery of a database. The total
recovery time of a failed database can not be predicted easily.
By tuning the Serviceguard heartbeat on a dedicated heartbeat LAN, it
is possible to achieve failover times in the range of about a minute or two
for a ci package that contains a lightweight (A)SCS instance without
database.
A cluster can be configured in a way that two nodes back up each other.
The principle layout is depicted in figure 1-1. This picture as well as the
following drawings are meant to illustrate basic principles in a clear and