HP Serviceguard Extension for SAP (SGeSAP) manual Follow-and-Push Clusters with Replicated Enqueue

If the primary node fails, the database and the Central Instance fail over and continue functioning on an adoptive node. After failover, the system runs without any manual intervention needed. All redundant Application Servers and Dialog Instances, even those that are not part of the cluster, can either stay up or be restarted triggered by a failover. A sample configuration in Figure 1-2 shows node1 with a failure, which causes the package containing the database and central instance to fail over to node2. A Quality Assurance System and additional Dialog Instances get shut down, before the database and Central Instance are restarted.

Figure 1-2 One-Package Failover Scenario

Follow-and-Push Clusters with Replicated Enqueue

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 on 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.

Each SAP Enqueue Service maintains a table of exclusive locks that can temporarily be 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 locks that have been granted gets lost. After package failover and restart of the Enqueue Service, all Dialog Instances need to get notified that the lock table content got lost. As a reaction they cancel ongoing transactions that still hold granted locks. These transactions need to be restarted.

Enqueue Replication provides a concept that prevents the impact of a failure of the Enqueue Service on the Dialog Instances. Transactions no longer need to be restarted. The Enqueue Server has the ability to create a copy of its memory content to a Replicated Enqueue Service that needs to be running as part of a Enqueue Replication Service Instance (ERS) on a remote host. This is a real-time copy mechanism and ensures that the replicated memory accurately reflects the status of the Enqueue Server at all times.

There might be two ERS instances for a single SAP system, replicating SCS and ASCS locks separately.

Follow-and-Push Clusters with Replicated Enqueue 15