High Availability for ASCS/SCS | Guided by A Guide to Cloud

Protecting the heart of SAP

🛡️ Lars pulls up the architecture diagram. “ASCS is the single most important thing to protect. If the enqueue server goes down and we lose the lock table, every user’s unsaved transaction is at risk. Dr. Schmidt will not accept that for GlobalPharma.”

☁️ Mei agrees. “The good news is that SAP designed a replication mechanism specifically for this. The Enqueue Replication Server — ERS — keeps a copy of the lock table on a second node. If the primary ASCS fails, the secondary picks up the lock table and users do not lose their work.”

Simple explanation

Think of it like a backup cashier at a busy store.

The main cashier (ASCS) tracks every open transaction. A backup cashier (ERS) writes down everything the main cashier does in real time. If the main cashier suddenly has to leave, the backup already knows every open transaction and takes over instantly. No customer loses their purchase. With the old system (ENSA1), the backup maintained a copy, but the handoff process had race conditions where some entries could be lost. With the new system (ENSA2), the backup’s list is always reliably up to date.

📐 Architecture diagram: Open the ASCS/SCS HA Cluster diagram in Excalidraw to see the clustering layout with ERS, shared storage, Azure LB, and STONITH fencing.

ENSA1 vs ENSA2

ENSA1 vs ENSA2 enqueue replication
Feature	ENSA1 (Legacy)	ENSA2 (Current)
Lock table replication	ERS maintains a replicated lock table, but failover has race conditions where some locks can be lost in edge cases	Active — ERS maintains an independent copy with improved failover reliability
Lock preservation on failover	Possible lock loss in edge cases	All locks preserved — seamless failover
SAP version	SAP NetWeaver older releases	S/4HANA default, NetWeaver 7.52+
ERS behavior	ERS restarts on the same node as ASCS after failover	ERS stays on its own node — ASCS moves to the ERS node
Complexity	Simpler but less reliable	Slightly more complex but robust
Exam focus	Know it exists and its limitations	Primary focus — this is the modern standard

🛡️ Lars checks the SAP version. “GlobalPharma runs S/4HANA, so we use ENSA2 by default?”

☁️ Mei confirms. “Yes. ENSA2 is the default for S/4HANA. ENSA1 is only relevant if you are running older NetWeaver systems that have not been updated.”

Exam tip: ENSA2 is the modern answer

When the exam asks about enqueue replication for S/4HANA or modern SAP systems, ENSA2 is always correct. ENSA1 questions typically describe legacy NetWeaver systems. The key difference to remember: ENSA2 maintains an independent copy with reliable failover (no lock loss), ENSA1 maintained a replicated lock table but had race conditions during failover (potential lock loss in edge cases).

⚠️ Recently changed — exam alert

ENSA2 (Enqueue Server 2) is the current standard and is mandatory for S/4HANA. The older ENSA1 is only relevant for legacy ECC systems. If an exam question asks about the recommended enqueue replication approach for a new S/4HANA deployment, ENSA2 with standalone ERS is always the correct answer. ENSA1 may appear as a distractor.

Linux HA: Pacemaker for ASCS

On Linux (SUSE SLES or Red Hat RHEL), ASCS HA uses Pacemaker — an open-source cluster resource manager:

Cluster components:

Two VMs — one runs ASCS, the other runs ERS
Pacemaker — manages which node runs which service
Corosync — provides cluster communication and membership
STONITH — fencing mechanism (SBD or Azure Fence Agent)
Azure Load Balancer — routes traffic to the active ASCS node

How failover works:

The active ASCS node fails (VM crash, OS issue, or ASCS process dies)
Pacemaker detects the failure via the cluster health check
STONITH fences the failed node (Azure Fence Agent restarts it, or SBD blocks it)
Pacemaker moves ASCS to the surviving node (which was running ERS)
ERS moves to the recovered node
Azure Load Balancer health probe detects the move and redirects traffic

SUSE vs RHEL differences

Both SUSE and RHEL support Pacemaker for SAP, but they have different cluster agent names, configuration syntax, and supported fencing approaches:

SUSE uses the sapstartsrv and SAPInstance resource agents
RHEL uses the SAPInstance resource agent with sap_redhat_cluster_connector
Both require the distribution’s HA extension for SAP (SLES for SAP, RHEL for SAP)
Configuration guides are distribution-specific — Microsoft publishes separate guides for each

Windows HA: WSFC for ASCS

On Windows, ASCS HA uses Windows Server Failover Clustering (WSFC):

Azure Shared Disk or SOFS (Scale-Out File Server) for shared storage
Cluster role for ASCS with a virtual network name
Azure Load Balancer with health probe (same concept as Linux)
No STONITH needed — WSFC handles fencing differently through cluster arbitration

Windows vs Linux ASCS HA

The exam focuses more on Linux (Pacemaker) than Windows (WSFC) for ASCS HA because most SAP HANA deployments use Linux. However, know that WSFC is the Windows equivalent and uses Azure Shared Disk for shared storage instead of NFS.

SBD vs Azure Fence Agent

STONITH fencing options for SAP on Azure
Feature	SBD (STONITH Block Device)	Azure Fence Agent
How it works	Uses a shared disk for fencing messages — nodes write 'poison pills'	Calls Azure REST API to deallocate or restart the failed VM
Storage required	Azure Shared Disk (small, dedicated for SBD)	No additional storage needed
Network dependency	Works even if network is partitioned (uses shared disk)	Requires network access to Azure API endpoints
Setup complexity	Moderate — configure SBD device and iSCSI/shared disk	Simpler — configure managed identity and permissions
SUSE support	Yes	Yes
RHEL support	Yes	Yes
Exam tip	Know that SBD uses shared storage for fencing	Know that it uses Azure API and needs network

🛡️ Lars evaluates. “Azure Fence Agent is simpler, but SBD works even if the network is down. For GlobalPharma’s compliance requirements, I prefer SBD — belt and suspenders.”

☁️ Mei agrees. “SBD is more robust in network-partition scenarios. But Azure Fence Agent is easier to set up and works well for most deployments. The exam may test both.”

Azure Load Balancer for ASCS

The Load Balancer configuration for ASCS HA:

Standard SKU, internal — SAP cluster IPs are always private
Floating IP enabled — mandatory for the virtual cluster IP to work
Health probe on port 620xx — where xx is the ASCS instance number (e.g., 62000 for instance 00)
Health probe on port 621xx — for ERS instance
HA ports rule — forwards all ports to the active node
Idle timeout — set to 30 minutes for SAP long-running connections

Exam tip: Health probe ports

The exam loves testing ASCS Load Balancer health probe ports. The pattern is 620xx for ASCS and 621xx for ERS, where xx is the SAP instance number. For a multi-SID setup, each SID needs its own frontend IP and health probe on distinct ports.

Question

What is the key difference between ENSA1 and ENSA2?