Managing Serviceguard Extension for SAP, December 2007

Understanding Serviceguard Extension for SAP
The Replicated Enqueue
Chapter 1 33
The ASCS Instance will then use the stand-alone Enqueue Server and is
able to replicate its status. On the alternate node a Replicated Enqueue
needs to be started that receives the replication information. The
SGeSAP packaging of the ASCS Instance provides startup and shutdown
routines, failure detection, split-brain prevention and quorum services to
the stand-alone Enqueue Server.
SGeSAP delivers an EMS monitor that implements a resource called
/applications/sap/enqor/<SID>[a]scs for each Replicated Enqueue
in the cluster. Monitoring requests can be created to regularly poll the
status of each Replicated Enqueue.
The EMS monitor can be used to define a resource in the Serviceguard
packages. This can be used to implement a follow-and-push behavior for
the packages that include Enqueue and its replication. As a result,
Enqueue and its replication server are never started on the same node
initially. Enqueue will not invalidate the replication accidentally by
starting on a non-replication node while replication is active elsewhere.
It is possible to move the package with the replication server to any free
node in a multi-node cluster without a requirement to reconfigure the
Enqueue package failover policy.
During failover of Enqueue, its replication will be located dynamically
and the Enqueue restarts on the currently active replication node.
Enqueue synchronizes with the local replication server. As a next step,
the package with the replication service shuts down automatically and
restarts on a healthy node, if available. In case of a failover in a
multi-node environment this implements a self-healing capability for the
replication function. Enqueue will failover to just any node from the list
of statically configured hosts if no replication package is running.
Two replication instances are required if Enqueue Replication Services
are to be used for both the JAVA stack and the ABAP stack. From this
approach several configuration options derive. In most cases, it is the
best practice to create separate packages for ASCS, SCS and the two
ERS instances. It is also supported to combine the replication instances
within one SGeSAP package. It is also supported to combine ASCS and
SCS in one package, but only if the two ERS instances are combined in
another package. It is not supported to combine ASCS and SCS in one
package and keep the two ERS instances in two separate packages.
Otherwise, situations can arise in which a failover of the combined
ASCS/SCS package is not possible. Finally, ASCS can not be combined
with its ERS instance (AREP) in the same package. For the same reason,
SCS can not be combined with its ERS instance (REP).