SAP Central Services

Edit online

The SAP Central Services concept is applicable to both ABAP and Java™ systems. By implementing high availability for SAP Central services, you can ensure that vital services in an SAP system (enqueue and message service) are accessible at all times.

Note: SAP has designated SAP Central Services for ABAP as ASCS (ABAP SAP Central Services) and now applies the abbreviation SCS to the Java-based variant. This is attributable to the use of these abbreviations as directory names. However, this publication continues to use the abbreviation SCS as a conceptual term and to refer to an SCS instance in general terms. It employs ASCS and Java SCS to distinguish the environment-dependent instances.

Earlier SAP releases were based solely on the central instance concept. This concept provided the following functionality:

  • It hosted the enqueue work process
  • It usually served as location of the message server and the syslog collector
  • It hosted an SAP gateway process and serves as primary destination for RFC connections

Generally, the SAP file systems physically reside on the same system where the central instance is running. The file systems are made available to other application servers by means of NFS.

To remove the central instances as a single point of failure and thereby enable high availability solutions, the central instance has been disassembled and redesigned into stand-alone components that operate as SAP Central Services (SCS). The current SAP releases now offer an HA option in their installation procedure, which installs the SCS instead of the traditional central instance.

If you have an SAP system with the old central instance (CI) concept that you want to enable for high availability, then you must split the CI into a Central Services (ASCS) instance and a remaining primary application server (PAS). For an overview and rationale for this procedure, refer to this article: Why splitting off the ASCS from PAS?

The following SAP notes contain instructions how to split the central services using SAP tool support:

With SCS the independence of the components allows for a more efficient recovery should a component become unavailable, and provides better performance of the enqueue services.

For the sake of simplicity, the following stand-alone components have been grouped together as SCS:

  • Enqueue server
  • Message server
  • SAP gateway server

As members of SCS, the components share an instance directory and an instance profile. Nevertheless, the components can be started, stopped and recovered independently. None of them requires access to the database.

Furthermore, the components of SCS share one virtual IP address (VIPA). With this approach, the setup of TCP/IP and the SAP profiles is kept as small as needed. All the components benefit from an IP takeover simultaneously and in the same manner.

Stand-alone enqueue server and enqueue replication server

The availability of the enqueue server is extremely critical for an SAP system; if the enqueue server cannot be reached, the SAP system is basically not operational, since most transactions fail to run.

Within the SAP Central Services, the enqueue server is a stand-alone component. The enqueue server does not require access to the database.

An application server instance connects directly to the enqueue server by using a virtual IP address (VIPA). See Figure 1.

To allow continuous availability and transparent failover, the enqueue replication server has been introduced. It is a stand-alone component as well. It connects to the enqueue server. When connected, the enqueue server transmits replication data to the replication server. The replication server stores it in a shadow enqueue table, which resides in shared memory. In case of a failure of the enqueue server, it is used to rebuild the tables and data structures for the enqueue server so it can be restarted.

If the enqueue replication server is unavailable, the SAP system continues to be up and running. However, there is no longer a backup for the enqueue server.

The enqueue replication server is not considered a member of SCS. It is an own SAP instance, named ERS<xx> and must be installed with its own VIPA.

The multithreaded architecture of the stand-alone enqueue servers allows parallel processing and replication. The I/O processing for the TCP/IP communication, which caused the throughput limitations in the old design, is now distributed over several I/O threads. This, together with the elimination of the message server in the enqueue communication path, makes possible a significantly higher throughput.

With SAP kernel 7.21 or higher, an alternative enqueue replication mechanism is available for SAP on IBM Z®. This mechanism does no longer require an enqueue replication server instance, the backup of replication data is written to the z/OS® coupling facility instead. For details see Enqueue replication into a IBM Z coupling facility.

Failover and recovery of SAP Central Services

Figure 1 shows the principal TCP/IP communication paths between the application server instances and the enqueue and message servers. The VIPA used for ERS is not shown because it is of minor relevance for the failover scenario.

Figure 1. Initial startup of SCS
Graphic shows the initial startup of SCS

If LPAR1 fails, LPAR2 takes over the role of LPAR1, as shown in Figure 2:

  1. The IP address (VIPA) is taken over.
  2. Enqueue and message servers are restarted.
  3. The enqueue table is rebuilt from the shadow table.
  4. The application servers reconnect to the enqueue server and the message server.

The failover is fully transparent to the application. The enqueue locks are preserved and transactions continue to run.

Figure 2. Failure of SCS and recovery of the enqueue table
Graphic shows failure of SCS and recovery of the enqueue table

After a successful failover of the enqueue server, the replication server is no longer needed on LPAR2 and therefore can be stopped. If another LPAR is available or becomes available, the replication server is started on that LPAR and a new shadow enqueue table is established. This is shown in Figure 3.

Figure 3. Movement of the enqueue replication server
Graphic shows movement of the enqueue replication server

Failover and recovery of SAP Central Services using EnqCF replication

This topic outlines the failover and recovery scenario when using the alternative enqueue replication mechanism that uses the IBM Z coupling facility (also referred to as EnqCF replication).

Figure 4 shows the principal TCP/IP communication paths between the application server instances and the enqueue and message servers. It also shows the links that exist between each LPAR in the sysplex and the coupling facility.

Figure 4. Startup of SCS during failover and recovery using EnqCF replication
Graphic shows the startup of SCS during failover and recovery using EnqCF replication

If LPAR1 fails, LPAR2 takes over its role, as shown in Figure 5.

  1. The IP address (VIPA) is taken over.
  2. Enqueue and message servers are restarted.
  3. The enqueue table is rebuilt from the shadow table in the coupling facility.
  4. The application servers reconnect to the enqueue server and the message server.

The failover is fully transparent to the application. The enqueue locks are preserved and transactions continue to run.

Figure 5. Failure of SCS and recovery of the enqueue table using EnqCF replication
Graphic shows the failure of SCS and recovery of the enqueue table using EnqCF replication