Skip to Content
Personal Insights

Enqueue Replication Server 2 – for HYPERSCALERS(AWS)

This blog explains benefits of Enqueue2(ENQ2) in the HYPERSCALERS using some native features from the HYPERSCALERS. In this blog we take example of AWS(Amazon Web Services).

Pre-requisites

Most of the HYPERSCALERS offers native features like ‘Auto Recovery’ or ‘Self healing’ for the virtual machines running in their DCs. In AWS it is called ‘Auto Recovery’ and has to be explicitly enabled for a virtual machine from the AWS console.

What does Auto Recovery do?

  • If there is an issue with the VM due to power, network OR the underlying hypervisors then AWS automation takes care of rebooting the VM automatically on a different hypervisor. The new virtual machine is identical to the previous one is all aspects like Instance ID, Instance Name, storage, IP etc. This is clearly an advantage as compared to a classical DC where such feature could only be achieved by extremely complex automation OR a cluster kind of setup.During ‘Auto Recovery’ basically the virtual machine reboots and it gives the end user the possibility to configure any business processes OR components to start during the system reboots.

In a typical NW based system the ASCS instance which mainly has 2 processes i.e. message server and enqueue server. Enqueue server holds the locks for SAP transaction and if these locks are lost then it could lead to a data inconsistencies. The startup behaviour for the SAP instance can be controlled using the autostart parameter, add the parameter “Autostart = 1” (case sensitive!) to the START profiles (or instance profiles in case your system does not use START profiles). Once the parameter is added, then during VM reboot the ASCS instance will be automatically started.

NW high availability setup requires an Enqueue Replication Server, basically the lock table from the Enqueue server is replicated and in event of a failure of hte ASCS instance the locks are still preserved on  the ERS instance running on a different server.

With ENQ2 we have an advantage that during the startup it can read the replicated lock table entry from the ERS instance and rebuild the lock table. This is different from the classical ENQ<->ERS setup where the ASCS instance needs to be failed over to the host where the ERS instance is running.

For a NW high availability setup in AWS there is an advantage.In an event of any unplanned downtime of the virtual machine where the ASCS instance is running the ‘Auto Recovery’ from AWS takes care of bringing the Virtual machine back and the Autostart parameter takes care of starting the ASCS instance.

ENQ2 process can build the lock table again after reading the replicated lock table from the ERS instance. There is no need to failover the ASCS instance to any other host.

This setup works without the need of a cluster kind of setup. Below diagram shows one such setup.

In the above diagram AZ1 & AZ2 are 2 availability zones in the AWS Regionindicates that ‘Auto Recovery’ is enabled for these Virtual Machines in AWS environment.

 

Summary:

With simple steps high availability setup for NW based system(NW release higher that 7.52) can be done in AWS so that all the single point of failures can be avoided. ASCS instance and ERS are protected against Virtual Machine failures with AWS “Auto Recovery”, ENQ2 ensures that after the restart of ASCS the lock table is built reading the replicated lock table in ERS instance.

With AWS Auto Recovery and ENQ2, the overhead of maintaining a cluster setup can be avoided and there is reduction in the TOC from a customer perspective.

Note: In case of entire failure of an availability zone where the ASCS instance is running there would not be any auto-recovery possible from AWS. In such rare scenarios ASCS instance needs to be failed over to virtual machine where the ERS instance is running in the second availability zone OR can be started on a new virtual machine.

4 Comments
You must be Logged on to comment or reply to a post.
  • Hello Kumar,

    Nice blog! I think solution looks feasible and it overcomes the complexity of clustering. It offers technical simplification to attain high availability.

    But is this solution approved by SAP? Because there are many simplified solution that can be attained on cloud but SAP does not support such solution like “Use of AWS SMS for migrating virtualized SAP workloads to the AWS cloud”.

    • Hi Dennis,

      SAP cannot approve any solution which is based on the under lying infrastructure and makes use of some of its features.

      It is an inherent feature of advanced ENQ2 to rebuild the lock table by reading the replicated lock table in the ERS instance. ENQ can be stared on any virtual machine, as long as the ERS instance is reachable it can build the lock table.

      ‘AWS auto recovery’ is recommended by AWS for SAP and HANA setups. You can find it in the SAP white-papers published by AWS.

      At the end one has to test and then implement a particular solution… to the best of my knowledge it works 🙂

       

      BR, Avi

       

      • Hello Avi,

        I got all about ENQ2 features and don’t doubt about it’s implementation on AWS the way you have mentioned. It is possible.

        My point is when designing SAP HA Solution for business, customer is always looking for a solution which is supported by SAP HA Partners (2711036 – Usage of the Standalone Enqueue Server 2 in an HA Environment) without that they won’t go ahead, because they don’t want to risk their Production system.

        Even I can foresee many new practices that can be adopted with SAP on Public Cloud, by directly consuming cloud services like below, which can considerably simplify customer landscape and reduce time/effort to move SAP workload to cloud.

        Elastic Load Balancer instead of Web Dispatcher
        AWS SMS Service to move SAP workload to AWS over Export/Import, SUM

        With all this simplification offered by Cloud services, still there are customers who prefer to go for traditional practices, as they say Web Dispatcher is supported by SAP whereas Elastic Load Balancer is not. Same goes with moving SAP workload.

        My discussion is based on the customer interaction and outlook, I like this simplified solution as I know the pain of maintaining cluster.