What's changed: Created AZ-120 Chapter 3 (Domain 3: high availability (SLA, availability set vs availability zones, Azure Load Balancer, HANA/SCS clustering, Pacemaker and STONITH, Azure fence agent vs SBD, HANA System Replication, restart config); disaster recovery (Azure Site Recovery, region DR, DR networking, RPO/RTO backup strategy, Azure Backup/Recovery Services vault, HANA snapshots/DB-consistent backup, DR testing)).
3.1High availability (HA)
Understand SLA considerations, availability sets vs availability zones, load balancing, clustering for HANA/SAP Central Services, and Pacemaker with STONITH (Azure fence agent / SBD).
SAP requires designs that eliminate single points of failure (SPOF) to achieve a high SLA. Redundant placement and clustering are the pillars.
3.1.1Redundant placement and load balancing
Two redundant placements: an availability set spreads across fault/update domains within one datacenter (higher VM SLA, low latency); availability zones distribute across physically separate zones in a region (tolerate datacenter failure, top SLA but possible inter-zone latency). In HA, an Azure Load Balancer (internal) distributes traffic to redundant app/SCS/DB. For "tolerate a zone failure," use availability zones; for "simple redundancy in one DC with low latency," use an availability set.
3.1.2Clustering and STONITH
SAP HANA and SAP Central Services (SCS/ASCS) are SPOFs, so make them redundant with clustering (Pacemaker on Linux, WSFC on Windows/SQL). The cluster uses fencing (STONITH) to reliably stop an unresponsive node and prevent split-brain. On Azure, implement STONITH via an Azure fence agent (stop nodes via Azure API, no shared disk) or a STONITH Block Device (SBD) (shared block device / iSCSI-based). HANA replicates data at the storage/DB level (HANA System Replication), and you configure restart of SAP systems/instances/HANA DBs on failover.
Cues: "tolerate datacenter failure, top SLA" = availability zones. "fault/update domains in one DC, low latency" = availability set. "make HANA/SCS SPOFs redundant" = clustering (Linux = Pacemaker). "reliably stop an unresponsive node / prevent split-brain" = STONITH (Azure fence agent or SBD).
Watch the mix-ups: (1) Availability set (one DC) vs availability zones (separate zones)—different DC-failure tolerance. (2) STONITH is required—a cluster without fencing risks split-brain. (3) Azure fence agent (API, no shared disk) vs SBD (shared block device). (4) A load balancer distributes; it does not decide failover or fence.
3.1.3Section summary
- Redundant placement = availability set (one DC, low latency) / availability zones (DC-failure tolerance, top SLA)
- Make HANA/SCS redundant with a Pacemaker cluster + STONITH (Azure fence agent or SBD)
- Azure Load Balancer distributes to redundant nodes; HANA replicates data
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. You want to place the SAP app tier redundantly to tolerate a datacenter failure within a region. Best?
Q2. You want to make the SPOFs of SAP HANA and SCS on Linux redundant. Best?
Q3. In a Pacemaker cluster, you want to reliably stop an unresponsive node to prevent split-brain. Best?
Q4. You want fencing that stops cluster nodes via the Azure API without a shared disk. Best?
Q5. Which correctly distinguishes an availability set from availability zones?
Keep track of your progress
The full study guide is free to read. Sign up free to practice with the question bank, track what you have read, review your mistakes, and highlight passages.