High availability for SAP on AWS: HANA System Replication with Pacemaker and ENSA2

High availability for SAP on AWS is really two HA problems wearing one trench coat. The database layer and the SAP central-services layer fail independently, need different mechanisms, and — on AWS — both have to survive the loss of an entire Availability Zone. This walks through the design that most productive S/4HANA and NetWeaver estates on AWS converge on: HANA System Replication for the database, ENSA2 for the ASCS, a Pacemaker cluster automating takeover, and the AWS-specific plumbing that makes a virtual IP behave the way it would on-premises.

Two failure domains

Before choosing tools, be clear about what you are protecting. An SAP system has two components whose loss stops the whole system, and they are protected differently.

• The HANA database. A single point of failure by default. Protected with HANA System Replication (HSR) — a second HANA instance kept continuously in step with the primary.
• The SAP central services (ASCS). Home of the enqueue lock table and the message server. If it dies mid-transaction and the locks are gone, in-flight business processes break. Protected with ENSA2 and an Enqueue Replication Server.

On AWS the accepted pattern places each layer's two nodes in two different Availability Zones inside one region. That gives you resilience to an AZ-level failure — a power, network or hardware fault confined to one data-center campus. Keep that scope in mind: two-AZ HSR is high availability. Surviving the loss of a whole region is a separate disaster-recovery problem, addressed at the end.

HANA System Replication

HSR runs a primary and a secondary HANA instance. The primary ships its redo log to the secondary continuously; the secondary applies it so it can take over. Two independent choices govern the behaviour: the replication mode (how much the primary waits for the secondary before acknowledging a commit) and the operation mode (what the secondary does with the log it receives).

Replication mode is the durability-versus-latency dial. Because your two nodes sit in different AZs, the round-trip between them is small but not zero, and every synchronous commit pays it.

For HA between two AZs, SYNC or SYNCMEM are the realistic choices because they give you a zero (or near-zero) recovery point. ASYNC belongs in the DR story, where the two sites are too far apart to make anyone wait for a synchronous acknowledgement.

Operation mode decides how fast a takeover is:

• delta_datashipping periodically ships data deltas in addition to the log. The secondary is not continuously replaying, so a takeover has more work to do before the database is fully available.
• logreplay continuously replays the received log into the secondary and keeps its column store preloaded in memory. Takeover is fast because the secondary is already warm. This is the standard choice for an automated HA cluster and the one the resource agents assume.

Automating takeover with Pacemaker

HSR by itself does not fail over. Left alone, a dead primary means an administrator logs in, runs a manual hdbnsutil takeover, and re-points the application — minutes to tens of minutes of downtime, and only if someone is awake. A Pacemaker cluster (the SUSE HA Extension or the Red Hat HA add-on) removes the human from the critical path.

Two resource agents do the SAP-specific work:

• SAPHanaTopology runs on every node and reports the replication state of the local HANA instance to the cluster, so Pacemaker always knows which node is primary, which is secondary, and whether the secondary is in sync.
• SAPHana is the master/slave (promotable) resource that actually promotes the secondary to primary on failure and demotes the old primary when it returns.

When Pacemaker detects the primary is gone, it promotes the in-sync secondary and moves the service address to the new primary. Because logreplay kept the secondary preloaded, the promoted instance is serving quickly rather than warming a cold cache.

Fencing is not optional. If the two nodes lose sight of each other but both are actually alive — a network partition — each may conclude the other is dead and try to become primary. Two primaries writing independently is split-brain, and it corrupts data. STONITH ("shoot the other node in the head") prevents it: before promoting, the cluster forcibly powers off or reboots the node it can no longer talk to, guaranteeing only one primary survives. A cluster without working fencing is not an HA cluster; it is a data-loss incident waiting for a bad network day.

The AWS-specific pieces

A Pacemaker cluster designed on-premises assumes it can move a gratuitous-ARP virtual IP around a flat L2 subnet and shoot a node via IPMI or a PDU. Neither assumption holds in a VPC. AWS provides purpose-built resource and fencing agents to bridge the gap.

The overlay IP is the piece that most surprises teams new to AWS. On-premises a virtual IP is just an address the cluster ARPs for on the local segment. In a VPC there is no such segment, so the "move" is really a route-table update: aws-vpc-move-ip rewrites the route for the overlay address to send traffic to the ENI of whichever instance is currently primary. That is why the address must sit outside the VPC CIDR — it is a routed target, not a subnet host. The IAM role attached to the cluster instances therefore needs permission to modify the relevant route tables and to describe, start, stop and reboot the cluster instances (the fencing agent's job). Scope it to those actions and those resources; grant it through an instance profile, never a static user. (Describe the policy to your security reviewers by intent — route-table plus instance lifecycle on the tagged cluster nodes — rather than pasting a broad wildcard.)

ENSA2 for the central services

The database is only half the system. The ASCS holds the enqueue lock table — the record of which business objects are currently locked by in-flight transactions. Lose it uncleanly and those transactions fail. The Enqueue Replication Server (ERS) exists to keep a second copy of that lock table so a failover preserves the locks.

The relevant modern piece is ENSA2 — Standalone Enqueue Server 2, the default for S/4HANA. Its practical advantage over the older ENSA1 is placement freedom:

• ENSA1 required the ASCS to fail over onto the same node that was running the ERS, so it could read the replicated lock table locally. That co-location constraint forces awkward cluster topologies.
• ENSA2 lets the ASCS fail over to any node in the cluster; it retrieves the lock table from the ERS over the network. On a two-node AWS cluster spanning two AZs, that flexibility is exactly what you want — the ASCS can land on the surviving node regardless of where the ERS was.

Pacemaker manages the ASCS and ERS as clustered resources, keeps them on separate nodes in normal operation, and moves the ASCS to the survivor on failure — with the lock table intact, so users do not see broken updates.

What actually bites in a failover

The mechanisms above are well understood. The incidents come from the gaps around them.

• No (or misconfigured) fencing. The single most damaging mistake. Without STONITH a network partition becomes split-brain, and split-brain in HANA means diverged data you have to reconcile by hand. Test that fencing actually powers off the peer, not just that the config parses.
• An untested cluster. A cluster proven only at build time is a guess. OS patches, HANA upgrades, agent versions and IAM changes all drift. Rehearse takeover on a schedule.
• Confusing automatic and manual takeover. An automatic Pacemaker takeover and a manual hdbnsutil takeover reach different end states and have different fallback behaviour. Know which one your runbook describes, and make sure the cluster is in the mode you think it is — a cluster left in maintenance mode will not fail over at all.
• Mistaking HA for DR. Two-AZ synchronous HSR protects against an AZ failure. It does not protect against a region-level event or a logical corruption that replicates. That is a separate posture — asynchronous HSR to a second region, or Backint restore from S3 — chosen by your recovery objectives, and drilled independently.

Validate it

An HA design is a claim until you have proven each moving part. A minimum rehearsal:

• Rehearse a takeover on a schedule. Force the primary down and confirm the secondary is promoted and serving within your target — then fail back.
• Confirm the overlay IP moves. After takeover, verify the Route 53 name resolves to the overlay IP and that traffic reaches the new primary without touching an application config.
• Confirm ENSA2 preserves locks. Hold locks, fail the ASCS over, and check that the lock table survived via the ERS and in-flight work continued.
• Confirm fencing actually fences. Simulate a partition and verify the losing node is really powered off through the AWS API — not merely marked unclean in the cluster.

How Farrenio fits

A cluster's correctness is a runtime property, not a build-time one, so it needs continuous observation. Farrenio watches the pieces that quietly decay between drills: the HSR replication state itself — whether the secondary is ACTIVE and genuinely in sync rather than merely connected — and the instance health of every node in the landscape, so a degraded secondary is visible before the primary needs it. It reads the same SAP- and HANA-side signals across every system and customer and attributes every privileged action to a person.

See AWS for SAP for how we run SAP-on-AWS landscapes, HANA monitoring for the database-layer detail, and the SAP-on-AWS landing zone checklist for the foundational account, network and HA/DR decisions this design sits on top of. If you want a second pair of eyes on a two-AZ HANA cluster — or help proving the takeover you have never actually tested — write to contact@farrenio.com.