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

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

      Hi JP

      Good one

      Regards

      SS

      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.

      Cheers

      RB

      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!

      Author's profile photo Admonsap Admonsap
      Admonsap Admonsap

      Hi Juan

      I don't understand very well why ERS is necessary in a cluster. 
      
      If ASCS and DB are running on node1, when node1 fails ASCS and DB resources will be moved to node2, and in a few minutes the system will be available. 
      
      Why do you need the ERS, so as not to lose the lock table data?.
      
      Thanks a lot.
      
      Javier
      Author's profile photo Juan Reyes
      Juan Reyes
      Blog Post Author

      Hi Javier,

      Yes, ERS maintains a copy of the enque lock table so when the failover happen the system continue operations without issues,

      Regards, JP

      Author's profile photo Mauricio Zeledon
      Mauricio Zeledon

      Hello Juan, and others.

      I have installed S/4HANA HA on SUSE Linux, with SAP HANA 2.0 HA, also on SUSE Linux. I have PAS and AAS, using SAP GUI and Logon Group, we get to have HA on our system. Problem is, we need user to access to Fiori directly (using an URL). I have been reading and looking and I can't find a document or some blog, that will help me configure that in a way that user do not have to connect to a different URL in case of failure. We are also using SSO with SAML2.

      Any ideas are more than welcome!

      Regards

      Author's profile photo Juan Reyes
      Juan Reyes
      Blog Post Author

      Hi Mauricio,

      For Fiori load balancing (or any other Java or html based system) you need to use a web dispatcher,  web dispatcher can usually be installed either integrated with the SCS instance or standalone.

      Regards, JP

      Author's profile photo Mauricio Zeledon
      Mauricio Zeledon

      Thank you Juan for your reply.

       

      I actually have a web dispatcher as part of the ASCS instance. The thing is, I need users to use just one singe URL to connect to Fiori using SSO. The way it is configured now, we have two URLs - one for each app server.

      SSO actually returns an error that the server that sends the request to the ADFS, is different than the one that receives it, so we can't authenticate by SSO.

      I hope I was able to explain myself.

      Regards

      Author's profile photo Juan Reyes
      Juan Reyes
      Blog Post Author

      I think you should open a question on the SAP Basis forum as this is unrelated to ASCS/ERS HA

      Author's profile photo Mauricio Zeledon
      Mauricio Zeledon

      Will do just that.

       

      Thank you!

      Author's profile photo Mauricio Zeledon
      Mauricio Zeledon

      Hello Juan. I want to post what I did. It may help other people.

      We configured SAP Web Dispatcher as part of the ASCS instance. Most config was already in place after installation. I just added/modified some parameters to meet our requirements.

      Then we configured Fiori Launchpad on t-code SICF to use the logon group.

      For SSO, we set up SAML2 using our SAP Web Dispatcher as the hostname (t-code SAML2). From there, we exported metadata to the IdP, and configured SAML2 as needed. The way we did it before, directly connected to one the app servers, created metadata using just THAT app server as hostname, which was not the correct way to do it.

      Finally, we configured Fiori Launchpad (t-code SICF), so that it would use the "Alternative Logon Procedure" - SAML Logon, and it worked.

      If one of our app servers is down, we can always reach the Launchpad.

      Thank you for your comments.

      Regards.

      Author's profile photo Premkishan Chourasia
      Premkishan Chourasia

      Hi Juan,

      Really a wonderful blog !

      Thanks a lot for explaining the ERS HA setup in such simple format .

       

      Regards,

      Premkishan Chourasia

      Author's profile photo Juan Reyes
      Juan Reyes
      Blog Post Author

      Thanks!

      Author's profile photo Chang Yong Choi
      Chang Yong Choi

      Hello Juan,
      It's really great blog.
      Thank you for your effort.
      I have a question.

      We have the same HA system configuration as the scenario you described above.
      SAP Application : NW 7.5 Enterprise Portal with HANA DB
      Node 1 : SCS01 - ASCS (ERS Standby)
      Node 2 : ERS11 - ERS (ASCS Standby)
      Node 3 : J00 - PAS
      Node 4 : J00 - AAS

      Of course, I know the ERS system is not a SPoF in the SAP configuration system.

      Therefore, even if the ERS Server goes down, the entire SAP system should not be affected at all.

      Unfortunately, only the ERS server was down for a while in our system recently,
      but for about 6 minutes (Probably the time the ERS server rebooted) , the system connection was not established normally.

      We reproduced the same situation as at that time to determine the cause,
      but it did not adversely affect the system.

      Could it be that ERS is down and unlucky causes an other problems connecting to the system?
      Or have you ever had such a similar experience?

      Thanks and regards,

      CY Choi

      Author's profile photo Juan Reyes
      Juan Reyes
      Blog Post Author

      Hi CY,

      Maybe the root cause of your issue was not the ERS server but some of the mounted filesystems, if the shared filesystems are affected it may impact both ASCS and ERS. If the ERS was running on a dedicated server and it went down is unlikely to impact the system availability.

      Regards, JP