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?