India’s Leading Domain & Web Hosting Provider
Support
Domain & Login
Blog
SAP High Availability with Pacemaker, HSR and ENSA2 Across Zones
SAP high availability on cloud is the design that keeps an SAP system running through the loss of a host or an availability zone, using Pacemaker clusters for HANA system replication and ASCS/ERS, cloud-native fencing and virtual IPs. NTSPL builds and tests these clusters across zones in Indian regions so a single failure causes minutes of disruption, not hours.
Delivered on
In scope
Where an S/4HANA System Can Fail and What Each Cluster Protects
Cloud VMs fail less often than on-prem hosts, but they do fail, and providers also schedule maintenance. Without HA, an S/4HANA production system has three single points of failure: the HANA database, the ASCS with its message server and enqueue lock table, and any shared file system. A host event at 7 pm on the last working day of the month can stop invoicing and goods issue across every plant. Many teams have a cluster on paper, but fencing has never been triggered and the virtual IP has never actually moved.
NTSPL builds SAP HA as two Pacemaker clusters per SID: one for HANA system replication between zones, one for ASCS and ERS on ENSA2. Fencing uses the provider's own agent or SBD, virtual IPs follow the provider pattern, and SAP's HA interface ties the clusters to Basis tools. Before go-live we execute a written test catalogue of 14 to 18 failure cases, measure every takeover and record the evidence for auditors.
Signs Your SAP Production Needs a Real HA Design
Signals you need SAP High Availability
- Production S/4HANA or ECC runs on a single HANA host and a single ASCS host in one zone.
- The business has asked for 99.9 percent or higher monthly availability for SAP, excluding planned maintenance.
- A cluster exists but fencing has never been tested or takeover has never been measured.
- Plants, warehouses or dispatch run three shifts and an SAP outage of over 30 minutes stops trucks leaving the gate.
- Auditors or a parent company require documented failover evidence for core ERP each year.
When to choose something else
- The requirement is recovery from a region-wide outage or ransomware; that is SAP disaster recovery and backup, not zonal HA.
- The system is non-production or a small ECC with business hours use only; a quick restore from snapshots may be enough.
- SAP runs under RISE with SAP, where SAP designs and operates HA as part of the service tier you purchased.
Components of a Zone-Redundant SAP HA Build
HANA HSR cluster
Primary and secondary HANA hosts in different zones with syncmem or sync replication, managed by SAPHanaSR resource agents and a Pacemaker cluster.
ASCS and ERS cluster
ASCS and ERS on ENSA2 in separate zones, with the SAPInstance agent, a virtual hostname for each and the SAP HA connector enabled.
Fencing and quorum
Provider fence agent or SBD devices, cluster timeouts tuned for cloud API behaviour, and a quorum design that avoids split-brain.
Shared file services
Zone-redundant NFS for /sapmnt and transport directories, so a zone loss does not remove shared files.
Failure test catalogue
Scripted tests for node crash, network isolation, HANA process kill, ASCS kill, zone simulation and planned maintenance, with timings recorded.
Two-Cluster HA Pattern for HANA and Central Services
Two-Cluster Zonal HA for HANA System Replication and ASCS/ERS
HANA replicates synchronously from a primary in zone 1 to a secondary in zone 2 under a Pacemaker cluster, while ASCS and ERS run in a separate cluster across the same zones. Virtual IPs follow the active nodes, and application servers in both zones reconnect after takeover.
Select any component
Two-Cluster Zonal HA for HANA System Replication and ASCS/ERS: click any of its 8 components to see its role and the design choice NTSPL makes for it, or trace the 7-step primary path.
Fencing, Virtual IP and Cluster Agents by Hyperscaler
On AWS, the cluster moves an overlay IP outside the VPC CIDR by updating route tables, and fencing stops the failed EC2 instance through the API; Mumbai and Hyderabad each offer three zones.
On Azure, the virtual IP is a Standard Load Balancer frontend with health probes, and fencing uses the Azure fence agent with a managed identity or SBD devices; Central India supports zonal deployment.
On Google Cloud, NTSPL uses an internal passthrough load balancer with health checks for virtual IPs and fence_gce for fencing; Workload Manager validates cluster settings against Google's SAP guides.
HA Settings That Decide Takeover Time and Data Loss
Sync or syncmem replication
Use syncmem for most zonal HA: the primary commits once the secondary has the log in memory, which protects against single-host loss at lower commit latency than sync. Use sync when RPO must be zero even for simultaneous loss of both nodes. Measure inter-zone round-trip; if commit latency rises above about 1 ms at peak, review zone choice before tightening the mode.
Automated re-registration
Keep AUTOMATED_REGISTER disabled initially, so a failed primary must be checked by Basis before it rejoins as secondary. This avoids replicating a damaged database. Enable it after six months of stable operation if the team wants fully automatic recovery, and document the decision in the cluster design record.
Fencing method
Prefer the provider fence agent with least-privilege identity rights to stop and start only the cluster VMs. Add SBD as a secondary method where shared disks are available, or where the cloud API path could be unreachable during a network partition. Set fencing timeouts above the provider's typical stop time, usually 300 seconds or more.
Application server placement
Spread application servers across both zones so a zone loss leaves at least half of dialog capacity. Size each zone's servers to carry 60 to 70 percent of peak load. Logon groups should include servers from both zones so users are not stranded.
Build and Failure-Test Sequence for SAP Clusters
HA design and SLA agreement
Agree availability target, RPO for zonal failure and takeover time target with the business owner.
Second-zone build
Build the secondary HANA host, ERS host and zone-redundant shared files from code.
Replication and cluster configuration
Establish HSR, configure Pacemaker, fencing and virtual IPs, and enable the SAP HA interface.
Failure test execution
Run the test catalogue in quality and then production during an approved window, measuring every takeover.
Runbook and handover
Document maintenance procedures, cluster commands and alert responses for operations teams.
What you receive
Measured HA Outcomes After Failure Testing
| KPI | Typical target |
|---|---|
| HANA takeover time from failure detection to open for SQL | Under 5 minutes for most databases |
| ASCS failover time with locks preserved | Under 2 minutes, zero lost enqueue locks |
| Data loss on zonal failure | Zero committed transactions with syncmem or sync |
| Failure test cases passed before go-live | 100 percent of catalogue |
Cluster Behaviours That Cause Longer Outages Than No Cluster
| Risk | How NTSPL prevents it |
|---|---|
| Fencing fails during a network partition and both nodes believe they are primary | NTSPL tests network isolation explicitly and configures a secondary fencing method or quorum device where the primary method depends on the same network path. |
| OS patching restarts a cluster node without maintenance mode and triggers an unplanned takeover | Patching runbooks require cluster maintenance mode, and the patching tool is configured to skip cluster nodes unless approved. |
| Application servers keep stale database connections after takeover | Connections use the virtual hostname, and reconnect behaviour is verified in the test catalogue with live user sessions. |
SAP HANA system replication with Pacemaker or HANA host auto-failover with a standby node?
On cloud, HSR with Pacemaker is the standard for scale-up HANA. The secondary has its own storage, already has data loaded with preload, and sits in another zone, so takeover is fast and survives a zone loss. Host auto-failover uses a standby node sharing storage with the active nodes; it is mainly relevant to scale-out systems and does not protect against storage or zone failure by itself. NTSPL uses host auto-failover only where scale-out BW is unavoidable, and even then usually combines it with HSR to a second zone.
Key facts: SAP High Availability
SAP High Availability in Practice
2 SAP High Availability scenarios, from Edible oil refiner and Glass bottles, plus related platform case studies.
Edible oil refiner cuts SAP outage from a host fault to 4 minutes with zonal HSR
Glass bottle maker proves SAP failover in 18 tests before its furnace relining shutdown
Auto-ancillary maker converts ECC to S/4HANA on AWS inside a 48-hour downtime window
API manufacturer moves a GxP-validated SAP landscape to Azure without re-validation delays
SAP High Availability: Frequently Asked Questions
What does SAP HA on cloud cost?
The main cost is the secondary HANA host, which roughly doubles database compute, plus an ERS host and zone-redundant storage. Build and testing effort is typically 20 to 30 consultant-days per production SID. Some teams use a smaller secondary with the cost-optimized pattern, but takeover then takes longer.
Can SAP HA stay inside one Indian region?
Yes. AWS Mumbai and Hyderabad, Azure Central India and Google Cloud Mumbai and Delhi all offer multiple zones, so zonal HA stays in-region. A second region is added only for disaster recovery.
Is a Pacemaker cluster supported by SAP and the OS vendors?
Yes. SUSE and Red Hat publish cluster setup guides for SAP HANA and NetWeaver on each major cloud, and the cloud providers publish matching reference designs. NTSPL builds to those guides so support cases are not rejected for unsupported configuration.
How often should failover be tested?
Run the full catalogue before go-live, after major OS, cluster or HANA upgrades, and at least once a year. A planned takeover during a quarterly maintenance window is a simple way to keep the team practised.
Do users notice a failover?
Users on the affected application server or in the middle of a transaction may see an error and need to log on again. With ENSA2, enqueue locks are preserved, so open locks do not have to be reset. Most users see a short pause.
How does HA support CERT-In incident reporting?
Cluster events and takeovers are logged and forwarded to the central log store, which is kept for at least 180 days as CERT-In directs. If an outage is caused by a cyber incident, the timeline helps meet the 6-hour reporting requirement.