Managing HP Serviceguard Extension for SAP for Linux, December 2013

Figure 3 Two-package failover with mutual backup scenario
ciC11
DB and CI package
can fail and
recover independently
SGeSAP Cluster
Mutual Failover
Node 1 Node 2
Application Servers
dbC11
Shared Disks
LAN
It is a best practice to base the package naming on the SAP instance naming conventions whenever
possible. Each package name must also include the SAP System Identifier (SID) of the system to
which the package belongs. If similar packages of the same type get added later, they have a
distinct namespace because they have a different SID.
For example, a simple mutual failover scenario for an ABAP application defines two packages,
called dbSID and ascsSID (or ciSID for old SAP releases).
2.5 Example 3: Follow-and-push with automated enqueue replication
In case an environment has very high demands regarding guaranteed uptime, it makes sense to
activate a Replicated Enqueue with SGeSAP. With this additional mechanism, it is possible to
failover ABAP and/or JAVA System Central Service Instances without impacting ongoing transactions
of the Dialog Instances.
NOTE: It only makes sense to activate Enqueue Replication for systems that have Dialog Instances
that run on nodes different from the primary node of the System Central Service package.
A standard SAP Enqueue Service maintains a table of exclusive locks that are temporarily granted
exclusively to an ongoing transaction. This mechanism avoids inconsistencies that could be caused
by parallel transactions that access the same data in the database simultaneously. In case of a
failure of the Enqueue Service, the table with all granted locks gets lost. After package failover
and restart of the Enqueue Service, all Dialog Instances need to get notified that the lock table
14 SAP cluster concepts