Skip to Content
Technical Articles
Author's profile photo Juan Reyes

SAP ASCS High Availability using ERS explained

SAP ASCS High Availability using ERS explained

I have read and written many blogs on SAP High Availability but people seem to struggle to understand the inner workings of the mechanism that makes the SAP central services instance highly available

SAP Standard approach for making ASCS instance highly available is ERS

What is ERS?

ERS stands for Enqueue replication server and its job is to keep an up to date replica of the lock table so if something tragic was to happen to the ASCS instance the state of the table locks is safeguarded

That’s it?…. well yeah… its not a magic box!… or is it?….  on its own it does not guarantee the availability of the system, it just does what is stated above, to deliver the high availability desired its capabilities need to be combined with the features of a cluster with an automatic failover mechanism, that way when (or if) the ASCS instance crashes, its brought back to a different host/node where it will use the replication table to create a new lock table so the system can resume operation

What is the basic architecture of a highly available central instance?

At its leanest expression you need at least 2 nodes and a shared file system, for the purpose of this blog I’m just going to focus on the ASCS/ERS instances and the assumption is that the rest of the components are distributed on other nodes

Also you need a cluster provider with an automatic failover mechanism, again I’m not going to focus on a particular provider and make this as generic as possible so it applies to most scenarios

ASCS / ERS installation

In order for the ASCS and ERS instances to be able to move from one node to the other they need to be installed on a shared filesystem and using virtual hostnames, why?… because together with the virtual IP will be added to the cluster resource group so they can all switch as one logical unit.

A few high level tips for the installations,

Installation executable should point to that virtual host

./sapinst SAPINST_USE_HOSTNAME=<virtual hostname>

For this exercise the ASCS instance will be installed on sapnode1 using virtual hostname sapascs and the ERS instance will be installed in sapnode2 with virtual hostname sapers

Also post installation you need to make sure you have created mount points for both ASCS and ERS in their counterpart hosts (/usr/sap/<SID>/ASCSXX and /usr/sap/<SID>/ERSXX)

There is a number of other installation specific steps which are required but for the sake of keeping this generic I’ll leave those aside (I have included a few links at the bottom of this blog where you can check some of those)

Below is a representation of the basic requirements to kick the cluster basic configuration going  including the inactive (grey) instance requirements

Once your cluster config is completed and your ASCS/ERS instances (and rest of your system components) are operational your system will look as below,

So, what happens If sapnode2 crashes?

Well, the system will continue to operate as normal because ASCS availability was unaffected. ERS will be brought back once sapnode2 is back online

What happens when sapnode1 fails?

Heartbeat monitor will trigger a cluster resource failover and the ASCS instance will be spun on sapnode2 together with ERS….  (this is part of the cluster colocation configuration) and will use the replication table to create a new table lock and resume operations, at the same time ERS will be shutdown (again also part of colocation rules) and will be shifted and brought back on sapnode1 once the host is back online

Just to be clear for a small period of time both ASCS and ERS will be running in parallel, this is necessary as the replication table is kept on memory in the node ERS is running and only once the ASCS has completed reading and recreating the lock table the ERS node will be killed and will wait to be moved to the other node once is back online

Ultimately once sapnode1 is back online the ERS instance will be started and will create a new lock replication table and the ASCS will be once more highly available

I hope this paints a picture on how the ASCS/ERS instances work and how together with the cluster guarantee the ASCS instance availability and hence the SAP system uptime and the business continuity

Last but not least, I would like to quote here some documentation and white papers I found very helpful,

High Availability with the Standalone Enqueue Server

RedHat configuration guide for ASCS/ERS 

Suse SAP NetWeaver Enqueue Replication with High Availability Cluster – Setup Guide for SAP NetWeaver 7.40 and 7.50

Love to hear your comments,

Regards, JP

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo S Sriram
      S Sriram

      Hi JP

      Good one



      Author's profile photo Reagan Benjamin
      Reagan Benjamin

      The traditional ENSA setup is still used widely wherein the ASCS follows ERS in the event of a failover and takes over the lock table. There is a new concept called the ENSA2 where a third host is involved and in the event of the ASCS crash, it starts the ASCS on the third host by retrieving the lock table over the network from the host where ERS runs. The same rule applies if the ERS fails. I haven't worked or used the new setup yet.

      Nice to see you around Juan. Been a long time.



      Author's profile photo Mário Zakorchini Junior
      Mário Zakorchini Junior

      Great and simple explanation! I Teach SAP on AWS and had doubts on how this failover works, thanks for the simple but great explanation!