Evolution of ENSA2 and ERS2...

[kundangandhi]

From ABAP Platform 1809, the Standalone Enqueue Server 2 (and Enqueue Replicator 2 for high-availability scenarios) is default installation.

So, lets understand, what is Standalone Enqueue Server 2 (ie. ENSA2)

Overview

On ASCS, message server and Standalone Enqueue Server 2 runs together. The Standalone Enqueue Server 2 prevents multiple users from simultaneously accessing the same data by using the lock table to hold all current user locks in the main memory.

Background -

Before understanding ENSA2, lets have a quick recap and understand BASIC concept
1. How SAP connection works
2. What is SPoF (Single Point of Failure)
3. What is ENSA1 (Standalone Enqueue Server), ERS (Enqueue replication Server) and HA setup

So, lets start -

How SAP connection works -

Basically, SAP consists of following components -

1. ASCS instace consists of - Message Server, Enqueue Server


2. Database


3. ABAP Application server (consists of Dialog, Batch, Update and so on...)

and these components connect each other to make successful connection.

Below diagram shows step-by-step process -

 

What is SPoF (Single Point of Failure) -

A SPoF is a critical application component and if these are not available then this will become service outage for users.

In classical SAP (CI, Central Instance), message server, enqueue server, work process (application server) running on same system. And database running on other application server. (Sometimes, all components also running on one server only). Also, we can have another addition application server known as "Dialog Instance" as shown in below diagram.

 

ASCS (message server and enqueue server) and Database are critical components for business operations and helps for load balancing, licensing, lock management. If these components are not available, then SAP system will not be accessible for end-user and this will become service outage.
So, we need to protect them from SPoF (Single Point of failure).

 

Central Instance

 Out of these,

• the SAP message server can be restarted quickly and easily. While this server is down, the application servers cannot communicate with each other, but no important data is lost.


• The SAP database has to be secured by database failover solutions. (eg. In HANA, you can use HSR solution). Will discuss HANA System replication in another blog.


• And SAP enqueue server holds critical data in the lock table in the main memory. All locks that are currently held by users. If the host fails this data is lost and cannot be restored even when the enqueue server is restarted. All transactions that have held locks must therefore be reset. AND that is reason, you should protect enqueue server from SPoF.

What is ENSA1, ERS and HA setup -

Instead of protecting whole Central Instance, we can split of enqueue server and let it run as a standalone server, called as ENSA1.

And protect the lock table with the help of replication, called as ERS.

Again, we need HA software to redirect connection to ERS host in case of failure. We will see in details, how this will work.

ENSA1 - stands for Standalone Enqueue Server

ERS - Stands for Enqueue Replication Server

HA_Enqueue_server

Lets understand in more details - How this works -

1. If there are any changes in LOCK table ENQUEUE server (ie. new enqueue or dequeue request), this line will be added into replication table.
2. Before you make any changes into lock table, replication table must be updated by full table replication. Delta information can be transfer only when, entire lock table replicated to replication table.
3. Due to n/w issue, if table entry cannot replicated to ERS node, then only those entry will be sent, and NOT entire table.

Connection between Standalone Enqueue Server and Application Server, though port sapdpXX (XX is instance no.).

Connection Between Enqueue Server and Replication Server -
1. Enqueue server opens the port sapgwXX to wait for the connection from replication server.
2. If connection is already there with replication server, enqueue server rejects it and write into log file - dev_enqrepl as "Connect received, but already connected".

Due to multi-threaded architecture of the standalone enqueue serve, enqueue request processing and synchronization of the lock table with the replication server can be carried out in parallel.

 

Now, what if one of the servers (enqueue or replication) fail due to any disaster.

If Enqueue Server fails -

The enqueue server must “obey” the replication server, which means that if there is a failover, the enqueue server MUST be restarted on the host on which the replication server is running.

It works as follows -

• It is started by the HA software on the ERS host on which the replication server is running.


• And It takes over shared memory segment from ERS host and acquire an up-to-date enqueue table. Now replicated enqueue table becomes the new primary enqueue table


• Shut down replication server on ERS host


• Then replication server will start on ASCS host, once it is available.

 

If Replication Server fails -

1. It can be restarted on a different host.

2. It retrieves the replication table from the standalone enqueue server when it restarts

 

 

Some import profile parameters -

Profile Parameters for the Enqueue Clients (AS ABAP) -

If you want to use the standalone enqueue server, you have to set the following parameters in the profile files of the enqueue clients (application server instances):

enque/process_location = REMOTESA

enque/serverhost = <host name of the enqueue server>

enque/serverinst = <instance number of the enqueue server>

enque/deque_wait_answer = TRUE 

 

Establishing Connection to Standalone Enqueue Server

enque/con_timeout = 5000

the parameter specifies the maximum time (in milliseconds) the client can block for when a connection is being set up.

If the connection cannot be established, the client waits for one second and then retries. Parameter enque/con_retries determines how often the attempts are repeated.

 

Recommendation

enque/con_timeout should not be too large, so that the work processes can connect to the enqueue server as soon as it is available again. However, it should not be so small that the network is flooded with connect attempts during the time the enqueue server is not available.

enque/con_retries = 60 

After the specified number of retries, the caller (the application) reports an error.

The entire wait time is therefore between

1s* enque/con_retries and (1s + enque/con_timeout ms)  * enque/con_retries.

 

Profile Parameters for the Standalone Enqueue Server

Profile Parameters for the Enqueue Replication Server

 

 

ENSA1 has some limitations -

1. The enqueue server must “obey” the replication server, in case ASCS (Enqueue/message server) is not started, then we could loose locks.


2. Also, more than 2 node cluster is not possible. This results that - for some time replication was not active. (Time - when ASCS is starting on replication node and shuts down the ERS, after handing over shared memory locks and then it will start on different node)..

 

ENSA2 and ERP2...

The Standalone Enqueue Server 2 is the successor to the standalone enqueue server. It is a component of the SAP lock concept and manages the lock table. This principle ensures the consistency of data in an ABAP system.

ENSA 2 - How it works -

1. Each work process (WP) in an ABAP application server instance functions as an enqueue client.


2. It opens a network connection to Standalone-Enqueue-Server 2 using TCP

Backup file: Standalone Enqueue Server 2 holds critical data in the lock table in the main memory: Locks that were passed to the update system are stored both in the lock table and in a backup file. When Standalone Enqueue Server 2 is restarted, the locks are read from the backup file and entered in the lock table. This ensure that update locks do not get lost if the enqueue server is shut down.

 

ERS 2 - How it works -

1. Each work process (WP) of an ABAP instance (enqueue client) has a separate connection to the Standalone Enqueue Server 2.


2. The Standalone Enqueue Server 2 uses several connections to the Enqueue Replicator 2.


3. When enqueue clients set (enqueue) or release (dequeue) locks, they make changes to the lock table of the Standalone Enqueue Server 2


4. Each change made to the lock table is automatically replicated to the replication table of the Enqueue Replicator 2.


5. The Standalone Enqueue Server 2 sends the response to the client only when the Enqueue Replicator 2 has acknowledged a successful replication.

 

 

HA setup in ENSA 2 -

 

Standalone Enqueue Server 2 and Enqueue Replicator 2 run on different hosts.

1. The Standalone Enqueue Server 2 is running on the physical host HOST1. It can be addressed by the virtual host name ASCS_HA.


2. The Enqueue Replicator 2 is running on the physical host HOST2 and can be addressed by the virtual host name ERS_HA.


3. At one given point in time, the virtual host ASCS_HA is assigned to one of the physical hosts (HOST1, HOST2, HOST3, or HOST4). The same applies for the virtual host ERS_HA.

 

Source - SAP

If Standalone Enqueue Server 2 that is running on HOST1 fails,

1. the HA software starts the ASCS instance (including Standalone Enqueue Server 2 and Message Server) on another host (for example, on HOST3).

The old Standalone Enqueue Server was required to "follow" the Enqueue Replication Server. That is, the HA software had to start the ASCS instance on the host where the ERS instance is currently running.

2. The newly started Standalone Enqueue Server 2 then retrieves the replication table from the Enqueue Replicator 2 over the network and uses it as the lock table.

 

3. The HA software ensures that connection attempts from clients are automatically directed to the ASCS instance that is running on HOST3.

 

Source - SAP

If the Enqueue Replicator 2 that is running on HOST2 fails,

1. The HA software starts ERS on another host (for example, on HOST4).


2. The newly started Enqueue Replicator 2 waits until the Standalone Enqueue Server 2 starts an initial transfer of the lock table.


3. The HA software ensures that connection attempts from the Standalone Enqueue Server 2 are automatically directed to the ERS instance that is running on HOST4.

 

Source - SAP

 

Conclusion -

1. The standalone enqueue server is the future.


2. It is already the standard for all new installations (S/4HANA -1809 ENSA2...) and mandatory for high availability setups.


3. In future releases, it will become mandatory for all systems. From ABAP Platform 2020, the Standalone Enqueue Server 2 (and Enqueue Replicator 2 for high-availability scenarios) is the only available option.

So, plan to "Split Off ASCS Instance From Existing Primary Application Server instance" if you have still Central Instance setup.