Quorum\/Witness node<\/strong> \u2014 breaks ties in split-brain scenarios. In a two-node setup without a witness, you risk both nodes thinking they’re primary simultaneously \u2014 and that’s when your data diverges silently.<\/li>\n<\/ul>\nThe quorum node can be a lightweight VM \u2014 it doesn’t run HANA itself. It participates only in the Corosync voting ring. If you’re running on Azure or AWS, place the witness in a different availability zone from your HANA nodes. Think of it like a referee on the sidelines who can see both players \u2014 if the two players start arguing about who’s in charge, the referee makes the call.<\/p>\n
Pacemaker itself has two major components you need to understand: Corosync<\/strong> handles cluster communication and membership (who’s alive), while Pacemaker<\/strong> manages resources (what runs where and in what order). When someone says “Pacemaker failed over,” what actually happened is Corosync detected the node was gone, and Pacemaker’s policy engine decided to relocate the HANA resource agent to the secondary.<\/p>\n<\/span>HSR Replication Modes: Choosing the Right One<\/span><\/h2>\nSAP HANA supports three HSR replication modes, and choosing correctly is the single most important design decision you’ll make. Each mode represents a different tradeoff between zero data loss and performance impact \u2014 there’s no universal “best” option.<\/p>\n
<\/span>Mode 1: Synchronous (sync)<\/span><\/h3>\nSynchronous replication means every transaction on the primary waits for confirmation that it was written to the secondary’s log buffer before committing. This guarantees zero data loss (RPO = 0) but adds latency to every write operation \u2014 typically 1-5 milliseconds over a direct network link.<\/p>\n
Use synchronous when:<\/strong> Your RPO is zero (no data loss acceptable), your network latency between nodes is under 2ms, and your workload can tolerate the additional commit delay. This is the default recommendation for most production SAP landscapes.<\/p>\n<\/span>Mode 2: Synchronous in Memory (syncmem)<\/span><\/h3>\nSyncmem is a middle ground. The secondary confirms receipt of log pages to the primary before they’re persisted to disk on the secondary. Transactions commit faster than pure sync because the secondary doesn’t wait for disk I\/O \u2014 it only waited for the log to land in memory.<\/p>\n
The catch? If the secondary crashes before flushing those log pages to disk, you lose whatever was still in memory. In practice, the window is tiny (milliseconds), and SAP rates syncmem as near-zero data loss. I recommend this mode when synchronous adds more than 5ms of latency to your workload but you still need near-zero RPO.<\/p>\n
<\/span>Mode 3: Asynchronous (async)<\/span><\/h3>\nAsynchronous replication fires and forgets. The primary doesn’t wait for any acknowledgment from the secondary. This gives you the lowest latency on the primary side, but during a failover, you lose whatever transactions were in transit \u2014 potentially minutes of data.<\/p>\n
Use async when:<\/strong> The replication link spans long distances (inter-region DR), network latency exceeds 10ms, or you have a tolerance for some data loss in exchange for performance. It’s common to see sync for intra-data-center HA paired with async for cross-region DR \u2014 a tiered approach.<\/p>\n<\/span>Pacemaker Cluster Components<\/span><\/h2>\nNow let’s talk about what makes the cluster actually work. Understanding these components will save you hours of “why didn’t it failover?” debugging later.<\/p>\n
<\/span>Corosync \u2014 The Membership Layer<\/span><\/h3>\nCorosync is the cluster communication layer. It manages node membership, message passing, and quorum decisions. In an HANA HA setup, Corosync runs on all nodes (including the witness) over a dedicated network interface \u2014 and yes, you should use a separate NIC for Corosync traffic.<\/p>\n
Key corosync.conf<\/code> settings you’ll configure:<\/p>\n\ntotem.version: 2<\/code> \u2014 Ring protocol version<\/li>\nsecauth: on<\/code> \u2014 Encrypt cluster communication (enable this in production)<\/li>\ninterface ring0_addr<\/code> \u2014 Bind to your dedicated cluster network<\/li>\ntwo_node: 1<\/code> \u2014 Required when using a two-node setup<\/li>\nquorum_votes<\/code> \u2014 Set the witness to 0 votes (non-voting) or adjust for expected failures<\/li>\n<\/ul>\n<\/span>Fencing \u2014 STONITH and Why It Matters<\/span><\/h3>\nFencing is the mechanism that guarantees only one node can access shared resources at any time. Without proper fencing, you get a split-brain scenario where both nodes think they’re the primary \u2014 and each starts accepting writes independently. This corrupts your data silently and is significantly worse than downtime.<\/p>\n
Pacemaker uses STONITH (Shoot The Other Node In The Head) fencing agents. Common agents include:<\/p>\n
\n- fence_aws \/ fence_azure<\/strong> \u2014 Cloud API-based fencing for virtualized environments<\/li>\n
- fence_ipmilan<\/strong> \u2014 IPMI\/BMC-based physical server fencing<\/li>\n
- fence_sbd<\/strong> \u2014 SBD (STOTH Block Device) for shared-disk fencing<\/li>\n<\/ul>\n
Critical rule:<\/strong> Never disable STONITH in production because “it’s causing problems.” STONITH triggering is a symptom, not the cause. If STONITH fires unexpectedly, fix the root cause (network flapping, resource starvation) rather than disabling the guard rail.<\/p>\n<\/span>Resource Agents and Constraints<\/span><\/h3>\nResource agents are scripts that know how to start, stop, and monitor a specific service \u2014 in our case, the SAP HANA instance. The sfence_saphana<\/code> and sfence_sapnode<\/code> resource agents handle HANA-specific operations including takeover, replication status checks, and version validation.<\/p>\nThe key constraint properties you’ll configure:<\/p>\n
\n- colocation<\/strong> \u2014 HANA primary IP must run on the same node as the HANA primary role<\/li>\n
- ordering<\/strong> \u2014 Bring up the IP address before starting HANA, and reverse on shutdown<\/li>\n
- promotable resources<\/strong> \u2014 Define the master\/slave relationship managed by HSR<\/li>\n<\/ul>\n
<\/span>Step-by-Step Cluster Configuration<\/span><\/h2>\nHere’s the practical sequence I follow when standing up a new HANA HSR + Pacemaker cluster from scratch. Adjust for your specific OS (SLES or RHEL) and HANA version.<\/p>\n
<\/span>Step 1: Prerequisites Checklist<\/span><\/h3>\n\n- Both HANA nodes installed with identical version, patch level, and parameter files<\/li>\n
- Network: at least two network paths between nodes (production + replication)<\/li>\n
- Time synchronized \u2014 NTP drift breaks Corosync. I’ve seen 60-second drift cause false fencing events.<\/li>\n
- SSH key-based authentication between nodes (for HSR replication)<\/li>\n
- SAP Host Agent installed and running on all nodes<\/li>\n
- Log mounts accessible from both nodes (for shared log access during failover)<\/li>\n<\/ul>\n
<\/span>Step 2: Enable HANA System Replication<\/span><\/h3>\nOn the primary node, enable HSR:<\/p>\n
hdbsql -u SYSTEM -p <password> -i 90 \"ALTER SYSTEM ALTER CONFIGURATION ('global.ini', 'system') SET ('replication', 'mode') = 'logreplay' WITH RECONFIGURE\"<\/code><\/pre>\nFor synchronous mode:<\/p>\n
hdbsql -u SYSTEM -p <password> -i 90 \"ALTER SYSTEM ALTER CONFIGURATION ('global.ini', 'system') SET ('replication', 'mode') = 'logreplay_sync' WITH RECONFIGURE\"<\/code><\/pre>\nRegister the secondary on the primary:<\/p>\n
hdbnsutil -sr_enable --name=NODE01<\/code><\/pre>\nOn the secondary node, register for replication from the primary:<\/p>\n
hdbnsutil -sr_register --remoteHost=hananode01 --remoteInstance=00 --mode=sync --operationMode=logreplay<\/code><\/pre>\n<\/span>Step 3: Configure the Cluster Infrastructure<\/span><\/h3>\nInstall cluster packages (SLES example):<\/p>\n
zypper install -y pacemaker pcs corosync fence-agents-saphana saphana-ha<\/code><\/pre>\nInitialize the cluster on the primary:<\/p>\n
pcs cluster auth hananode01 hananode02 -u hacluster -p <password>\r\npcs cluster setup --name hana-ha --start hananode01 hananode02 --enable<\/code><\/pre>\nConfigure Corosync for two-node operation:<\/p>\n
pcs property set no-quorum-policy=freeze\r\npcs property set stonith-enabled=true<\/code><\/pre>\nThe freeze<\/code> policy for two-node clusters prevents a single remaining node from continuing without quorum (which would violate cluster consistency unless the witness confirms).<\/p>\n