Introduction

A two-node SAP HANA cluster with SAP HANA System Replication (HSR) and Pacemaker protects SAP HANA from failures inside an Azure region. It doesn't protect against the loss of the whole region. For that, many customers add a disaster recovery (DR) copy of SAP HANA in a second Azure region.

Some customers require the DR environment to provide the same high-availability protection as the primary environment. In the event of a regional failover, the DR site should be ready to run production with local SAP HANA HA from the start. A 2+2 topology addresses this requirement: a two-node HA cluster in the production region and a two-node passive HA cluster in the DR region, connected through asynchronous HSR.

SUSE supports this pattern as the "Performance-optimized, multi-Target SR, third site in passive cluster" scenario (currently a technology preview) in the SUSE support matrix for SAPHanaSR-angi. This blog walks through an implementation of that scenario on Azure.

IMPORTANT: A technology preview lets customers evaluate an upcoming capability in their own environment before it's generally available. If you want to take part in the technology preview, contact your SUSE representative or your Microsoft account team; SUSE welcomes feedback on your use cases and test results.

This blog post complements the official SUSE documentation; it doesn't replace it. The steps here are a working example from a test environment. The SUSE man pages installed with the SAPHanaSR-angi package contain everything you need to configure this setup and always take precedence. Review them on your nodes before you follow the steps in this blog:

man SAPHanaSR_with_DR_HA # scenario description, requirements, DR procedures 
man SAPHanaSR_with_DR_HA_setup # setup procedure 
man SAPHanaSR_maintenance_examples 
man ocf_suse_SAPHanaController # PREFER_SITE_TAKEOVER=DR and DR mode 
man SAPHanaSR-showAttr # attribute meanings

1. Architecture overview

The environment has two SAP HANA HSR pairs, one per Azure region, each managed by its own two-node pacemaker cluster. The production cluster runs the SAPHanaSR-angi scale-up performance optimized scenario. The DR cluster is a passive cluster, where it runs the same software but in DR mode, so it never promotes a primary on its own. This is neither a stretched four-node cluster nor two active cluster coupled together. 

Figure 1: A production SAPHanaSR-angi cluster in Region 1 and a passive cluster in DR mode in Region 2. Asynchronous HSR replicates from the production primary (site1) to the first DR site (site3).

In SUSE notation, the topology is [site2 <= site1] -> {site3 => site4}.

This is a multi-target HSR configuration, where the production primary replicates to both its local secondary and the first DR site. The DR region is cascading, site3 receives from site1 and forwards to site4.

Production region cluster behaves like any SAPHanaSR-angi scale-up performance-optimized cluster. It monitors SAP HANA, performs local takeover between site1 and site2, and moves the virtual IP with the primary. Through the srHook, it also sees the replication status of the DR site (site3).

DR region cluster runs in DR mode, enabled by setting the SAPHanaController parameter PREFER_SITE_TAKEOVER=DR. In DR mode:

• The cluster starts, stops, and monitors SAP HANA on both DR nodes.
• There is no local primary. Scoring prevents promotion, so both nodes remain demoted and the IP resource stays stopped.
• The cluster doesn't perform a takeover between the two DR nodes. It can recover some failures by restarting resources locally.
• The cluster never performs a takeover from production to DR. Regional takeover is a manual decision and a manual procedure.

2. Prerequisites and requirements

NOTE: This procedure works only with SAPHanaSR-angi package. 

Review the REQUIREMENTS section of SAPHanaSR_with_DR_HA(7) for the full, current list. Key items include:

• SAPHanaSR-angi version: the man page lists the minimum version. 
• Both regions are configured as SAPHanaSR-angi scale-up performance-optimized clusters (see SAPHanaSR-angi-scenarios(7)). No multi-SID.
• Replication inside each cluster is 'sync' or 'syncmem'. Replication from production to DR is 'async'.
• 'register_secondaries_on_takeover = true' in 'global.ini' on all SAP HANA sites in both regions.
• The SAP HANA secure keystore (SSFS) content is identical on all sites.
• Enough disk space for log volumes and log backups on every potential replication source.
• Once a site name is known to the cluster, always use exactly that site name (case sensitive) when you register the site manually.
• After a failed former production region recovers, its cluster must not start SAP HANA resources before DR mode is set. SUSE recommends disabling automatic cluster start at boot. If automatic start stays enabled, you must take additional measures (for example, booting nodes one at a time). 
• Maintenance activities in both regions must be coordinated. Never change the replication topology from both regions at the same time.
• Takeover decisions and procedures are the customer's responsibility. Every procedure must be tested, documented, and trained before use in production.

Azure-specific considerations

• Build each region's cluster by following High availability for SAP HANA on Azure VMs on SLES (SAPHanaSR-angi tab).
• Provide network connectivity between the regions for HSR traffic (for example, global VNet peering) and allow the SAP HANA replication ports between all four nodes.
• Each region uses its own Azure Load Balancer frontend IP for the SAP HANA virtual IP. An Azure Load Balancer frontend can't move between regions, so client redirection after a regional takeover needs DNS or application connection changes.

3. Set up the passive DR cluster

SUSE recommends building and testing the cluster in each region separately first, then switching the DR region to a passive cluster and attaching it to production through HSR. This is the procedure in SAPHanaSR_with_DR_HA_setup(7).

Starting state: Two healthy SAPHanaSR-angi clusters, each tested on its own. Region 1 runs production. Region 2 temporarily runs as its own primary/secondary pair (site3 → site4) for testing.

Target state: Cluster B runs as a passive cluster in DR mode, site3 is an async secondary of site1, and site4 is a secondary of site3.

The example environment used in this blog:

1. [B1] Register site3 as an async secondary of the production primary (site1):
   

   sm3adm> hdbnsutil -sr_register --remoteHost=sm3hdb1 --remoteInstance=00 --replicationMode=async --operationMode=logreplay --force_full_replica --name=site3

2. [B1] Start SAP HANA on site3, then enable it as a replication source:
   

   sm3adm> HDB start sm3adm> hdbnsutil -sr_enable

3. [B2] Register site4 as a secondary of site3, then start SAP HANA:

   sm3adm> hdbnsutil -sr_register --remoteHost=sm3hdb1-wus3 --remoteInstance=00 --replicationMode=sync --operationMode=logreplay --force_full_replica --name=site4 
   sm3adm> HDB start

3.5 Return region 2 to cluster control

1. [B1] Refresh the SAPHanaController resource so the cluster detects the new state:
   

   crm resource refresh mst_SAPHanaController_SM3_HDB00

2. [B1] Set the srHook attribute of the first DR site (site3) to SWAIT:
   

   crm_attribute -n hana_sm3_site_srHook_site3 -v SWAIT -t crm_config -s SAPHanaSR

3. [B1] End maintenance:
   

   crm resource maintenance mst_SAPHanaController_SM3_HDB00 off

3.6 Validate

On Region 2, both nodes are demoted and the IP group is stopped:

Clone Set: mst_SAPHanaController_SM3_HDB00 [rsc_SAPHanaController_SM3_HDB00] (promotable):
  Slaves: [ sm3hdb1-wus3 sm3hdb2-wus3 ]

SAPHanaSR-showAttr on Region 2:

Sites    lpt  lss  mns           opMode     srHook  srMode  srPoll  srr
site3    30   4    sm3hdb1-wus3  logreplay  SWAIT   async   DR      S
site4    30   4    sm3hdb2-wus3  logreplay  SOK     sync    DR      S

On the production primary, systemReplicationStatus.py shows all three links as ACTIVE. Check the complete landscape with 'hdbnsutil -sr_state' as 'sm3adm'.

4 Planned takeover: switch production to the DR region

Use this procedure for a planned region switch. For example, a DR drill or maintenance in the production region. This follows the SUSE procedure "switch HANA production and DR region, keep HANA running" in SAPHanaSR_with_DR_HA(7), where we perform takeover by suspending primary. 

Note: Because DR replication is asynchronous, confirm that site3 is fully in sync before the takeover. SAP HANA service is interrupted during the switch, plan a maintenance window and client reconnection. Suspend primary shortens the wait for the old primary to stop, but it doesn't make the switch transparent to applications.

4.1 Confirm readiness in both regions

1. [A1] Check replication from the production primary:
   

   sm3adm> cdpy; python systemReplicationStatus.py

   All links must be ACTIVE and fully synced:

   site1 (sm3hdb1)      -> site3 (sm3hdb1-wus3)  ASYNC  ACTIVE  Fully Synced: True
   site1 (sm3hdb1)      -> site2 (sm3hdb2)       SYNC   ACTIVE  Fully Synced: True
   site3 (sm3hdb1-wus3) -> site4 (sm3hdb2-wus3)  SYNC   ACTIVE  Fully Synced: True
   overall system replication status: ACTIVE

2. [A1, B1] Check 'crm_mon -1Ar' and 'SAPHanaSR-showAttr' in both regions:
   

   Region 1 (production)	Region 2 (DR)
   Masters: sm3hdb1, Slaves: sm3hdb2	Slaves: sm3hdb1-wus3, sm3hdb2-wus3
   g_ip_SM3_HDB00 started on sm3hdb1	g_ip_SM3_HDB00 stopped
   site1 PRIM/P (score 150), site2 SOK/S (score 100), site3 SOK	site3 SWAIT async (score -1234), site4 SOK (score -1234), site1 PRIM

4.2 Prepare the current production region

1. [A1] Put the SAPHanaController resource in Region 1 into maintenance:
   

   crm resource maintenance mst_SAPHanaController_SM3_HDB00

2. [A1] Switch Region 1 to DR mode and refresh:
   

   crm configure set rsc_SAPHanaController_SM3_HDB00.PREFER_SITE_TAKEOVER DR 
   crm configure show rsc_SAPHanaController_SM3_HDB00 | grep PREFER_SITE_TAKEOVER 
   crm resource refresh mst_SAPHanaController_SM3_HDB00

3. [A2] Stop SAP HANA on the production secondary (site2):
   

   su - sm3adm -c "HDB stop"

4.3 Take over on the first DR site

Warning: The takeover step invalidates the SAP HANA data on the current production sites (site1, site2).

1. [B1] Put the SAPHanaController resource in Region 2 into maintenance:
   

   crm resource maintenance mst_SAPHanaController_SM3_HDB00

2. [B1] Take over on site3 with suspend primary, then check replication:
   

   su - sm3adm -c "hdbnsutil -sr_takeover --suspendPrimary" 
   su - sm3adm -c "cdpy; python systemReplicationStatus.py"

4.4 Activate HA in the new production region

1. [B1] Switch Region 2 from DR mode to regular mode, refresh, and end maintenance:
   

   crm configure set rsc_SAPHanaController_SM3_HDB00.PREFER_SITE_TAKEOVER true 
   crm configure show rsc_SAPHanaController_SM3_HDB00 | grep PREFER_SITE_TAKEOVER 
   crm resource refresh mst_SAPHanaController_SM3_HDB00 
   crm resource maintenance mst_SAPHanaController_SM3_HDB00 off

2. [B1] Confirm that site3 is promoted and the IP group is running in Region 2:
   

   Masters: [ sm3hdb1-wus3 ]   
   Slaves: [ sm3hdb2-wus3 ]
   g_ip_SM3_HDB00:  
       rsc_ip_SM3_HDB00 Started sm3hdb1-wus3   
       rsc_nc_SM3_HDB00 Started sm3hdb1-wus3
   
   global  prim=site3  sec=site4  topology=ScaleUp
   site3  srHook=PRIM  srr=P  (score 150)
   site4  srHook=SOK   srr=S  (score 100)
   site1  srHook=PRIM   <-- orphaned attribute from the former primary

Production now runs in Region 2. Redirect clients to the Region 2 endpoint.

4.5 Re-register the former production region as DR

Warning: The next steps overwrite all SAP HANA data on the former production sites (site1, site2).

1. [A1] Register site1 as an async secondary of the new primary (site3):
   

   sm3adm> hdbnsutil -sr_register --remoteHost=sm3hdb1-wus3 --remoteInstance=00 --replicationMode=async --operationMode=logreplay --force_full_replica --name=site1 --online

   '--online' is used here because SAP HANA on site1 was suspended, not stopped, at the time of takeover.

2. [B1] Confirm site1 appears as an async target of site3 (site3 -> site1 ASYNC ACTIVE).
   

   su - sm3adm -c "cdpy; python systemReplicationStatus.py"

3. [A1] Enable site1 as a replication source:
   

   su - sm3adm -c "hdbnsutil -sr_enable"

4. [A2] Register site2 as a secondary of site1, then start SAP HANA:
   

   sm3adm> hdbnsutil -sr_register --remoteHost=sm3hdb1 --remoteInstance=00 --replicationMode=sync --operationMode=logreplay --force_full_replica --name=site2 
   su - sm3adm -c "HDB start"

    

5. [A1] Refresh the resource, end maintenance, and set the srHook attribute of the new first DR site to 'SWAIT':

   crm resource refresh mst_SAPHanaController_SM3_HDB00 
   crm resource maintenance mst_SAPHanaController_SM3_HDB00 off 
   crm_attribute -n hana_sm3_site_srHook_site1 -v SWAIT -t crm_config -s SAPHanaSR

4.6 Validate the final topology

[B1] From the new primary (site3) the status of system replication:

site3 (sm3hdb1-wus3) -> site4 (sm3hdb2-wus3)  SYNC     ACTIVE  Fully Synced: True
site3 (sm3hdb1-wus3) -> site1 (sm3hdb1)       ASYNC    ACTIVE  Fully Synced: True
site1 (sm3hdb1)      -> site2 (sm3hdb2)       SYNC     ACTIVE  Fully Synced: True
overall system replication status: ACTIVE

Region 1 (now DR): both nodes are Slaves, IP group stopped, and:

site1  srHook=SWAIT  srMode=async    srr=S
site2  srHook=SOK    srMode=sync     srr=S
site3  srHook=PRIM

The roles are now mirrored: [site4 <= site3] -> [site1 => site2].

5 Unplanned takeover: the production region is down

Use this procedure when both production nodes are unavailable and aren't expected to recover within your recovery time objective. It follows the SUSE procedures "take-over HANA to DR region in case of disaster" and "register former production HANA as new DR" in SAPHanaSR_with_DR_HA(7).

This example starts from the layout built in Section 3

Data loss: Replication to the DR region is asynchronous. Transactions committed on the failed primary but not yet shipped to the DR region are lost. Factor this into the takeover decision.

5.1 Phase 1 - Restore production service in the DR region

Warning: The takeover step invalidates all SAP HANA data on the former production sites (site1, site2).

1. [A] Make sure both production sites (site1, site2) aren't running. A takeover while the old primary is still active creates a duplicate-primary (split-brain) situation. Confirm through Azure (VM state) and, if reachable, SAP HANA itself.

2. [B] Make the formal decision to take over to site3.

3. [B1] Put the SAPHanaController resource in Region 2 into maintenance:

   crm resource maintenance mst_SAPHanaController_SM3_HDB00

4. [B1] Take over on site3:

   su - sm3adm -c "hdbnsutil -sr_takeover"
   su - sm3adm -c "cdpy; python systemReplicationStatus.py"

   site3 (sm3hdb1-wus3) -> site4 (sm3hdb2-wus3)  SYNC  ACTIVE  Fully Synced: True
   overall system replication status: ACTIVE
   mode: PRIMARY   site id: 3   site name: site3

5. [B1] Switch Region 2 from DR mode to regular mode, refresh, and end maintenance:

   crm configure set rsc_SAPHanaController_SM3_HDB00.PREFER_SITE_TAKEOVER true
   
   crm configure show rsc_SAPHanaController_SM3_HDB00 | grep PREFER_SITE_TAKEOVER
   # params SID=SM3 InstanceNumber=00 PREFER_SITE_TAKEOVER=true DUPLICATE_PRIMARY_TIMEOUT=7200 AUTOMATED_REGISTER=true
   
   crm resource refresh mst_SAPHanaController_SM3_HDB00
   crm resource maintenance mst_SAPHanaController_SM3_HDB00 off

6. [B1] Confirm site3 is promoted and the IP group is running in Region 2:
   

   Masters: [ sm3hdb1-wus3 ]   
   Slaves: [ sm3hdb2-wus3 ]
   g_ip_SM3_HDB00:  
       rsc_ip_SM3_HDB00 Started sm3hdb1-wus3   
       rsc_nc_SM3_HDB00 Started sm3hdb1-wus3
   
   global  prim=site3  sec=site4  topology=ScaleUp
   site3  srHook=PRIM  srMode=sync  srr=P  (score 150)
   site4  srHook=SOK   srMode=sync  srr=S  (score 100)
   site1  srHook=PRIM   <-- orphaned attribute of the failed former primary

Production is restored in Region 2, with local HA. Redirect clients to the Region 2 endpoint.

At this point you have HA but no DR. The next phase re-establishes DR protection once Region 1 is healthy again.

5.2 Phase 2 - Re-protect: recover the former production region as DR

Only continue once the root cause of the Region 1 outage is resolved.

Critical: prevent a second primary

The former production cluster in region 1 still has PREFER_SITE_TAKEOVER=true and still treats site1 as primary. If both nodes boot together, the cluster can start SAP HANA on site1 as a second primary. If automatic cluster start at boot is enabled, make sure you start the nodes one at a time, as shown below. 

1. [A1] Start only the sm3hdb1 VM. The cluster service starts automatically, but the cluster doesn't start SAP HANA:
   

   Current DC: sm3hdb1 ... partition WITHOUT quorum
   Node sm3hdb2: UNCLEAN (offline)
   Online: [ sm3hdb1 ]
     mst_SAPHanaController_SM3_HDB00: Stopped: [ sm3hdb1 sm3hdb2 ]

   This is expected. A two-node corosync configuration (two_node: 1) implicitly enables 'wait_for_all', so after a cold start the cluster doesn't gain quorum until both nodes have been seen. Without quorum, Pacemaker doesn't start or promote resources. This gives you the window to reconfigure safely.

2. [A1] While only one node is up, put the resource into maintenance and switch Region 1 to DR mode:
   

   crm resource maintenance mst_SAPHanaController_SM3_HDB00
   crm configure set rsc_SAPHanaController_SM3_HDB00.PREFER_SITE_TAKEOVER DR
   crm configure show rsc_SAPHanaController_SM3_HDB00 | grep PREFER_SITE_TAKEOVER
   # params SID=SM3 InstanceNumber=00 PREFER_SITE_TAKEOVER=DR DUPLICATE_PRIMARY_TIMEOUT=7200 AUTOMATED_REGISTER=true

   A warning such as 'Fencing and resource management disabled due to lack of quorum' is expected here.'

3. [A2] Start the sm3hdb2 VM. With both nodes online, the cluster has quorum, but because the resource is in maintenance and in DR mode, SAP HANA stays stopped:

   partition with quorum
   Online: [ sm3hdb1 sm3hdb2 ]
     mst_SAPHanaController_SM3_HDB00 (maintenance): Stopped: [ sm3hdb1 sm3hdb2 ]

4. [A1] Register site1 as an async secondary of the new primary (site3), start SAP HANA, and enable it as a replication source:

   sm3adm> hdbnsutil -sr_register --remoteHost=sm3hdb1-wus3 --remoteInstance=00 --replicationMode=async --operationMode=logreplay --force_full_replica --name=site1
   su - sm3adm -c "HDB start"
   su - sm3adm -c "hdbnsutil -sr_enable"

5. [A2] Register site2 as a secondary of site1 and start SAP HANA:
   

   sm3adm> hdbnsutil -sr_register --remoteHost=sm3hdb1 --remoteInstance=00 --replicationMode=sync --operationMode=logreplay --force_full_replica --name=site2
   su - sm3adm -c "HDB start"

6. [A1] Refresh, end maintenance, and set site1's srHook attribute to SWAIT:
   

   crm resource refresh mst_SAPHanaController_SM3_HDB00
   crm resource maintenance mst_SAPHanaController_SM3_HDB00 off
   crm_attribute -n hana_sm3_site_srHook_site1 -v SWAIT -t crm_config -s SAPHanaSR

5.3 Validate

[B1] From the new primary (site3):

site3 (sm3hdb1-wus3) -> site1 (sm3hdb1)       ASYNC    ACTIVE  Fully Synced: True
site3 (sm3hdb1-wus3) -> site4 (sm3hdb2-wus3)  SYNC     ACTIVE  Fully Synced: True
site1 (sm3hdb1)      -> site2 (sm3hdb2)       SYNC     ACTIVE  Fully Synced: True
overall system replication status: ACTIVE

Region 1 (now DR): both nodes' Slaves, the IP group stopped, and:

site1  srHook=SWAIT  srMode=async    srr=S
site2  srHook=SOK    srMode=sync     srr=S
site3  srHook=PRIM

Region 2 (now production): the orphaned site1 = PRIM entry is replaced by site1 = SOK once site1 replicates from site3.

Full HA and DR protection is restored, with the roles reversed: [ site4 <= site3' ] -> { site1 => site2 }.

To return production to Region 1 later, use the planned procedure in Section 4 with the regions swapped.

6. Summary

The SAPHanaSR-angi "Performance-optimized, Multi-Target SR, third site in passive cluster" scenario gives SAP HANA on Azure local high availability in both regions, with asynchronous replication between them:

• The production cluster is a standard SAPHanaSR-angi scale-up performance-optimized cluster.
• The DR cluster runs in DR mode (PREFER_SITE_TAKEOVER=DR): it monitors SAP HANA, keeps the IP resource stopped, and never takes over by itself.
• Regional takeover is a deliberate, manual decision, followed by a short, repeatable command sequence.
• After takeover, the former production region is re-registered as the new DR region, restoring full HA + DR protection.

Before you use any step from this blog, read the SUSE man pages installed with your SAPHanaSR-angi package. They are the authoritative and up-to-date source for requirements and procedures.

References

SUSE manual pages (installed with SAPHanaSR-angi)

• SAPHanaSR_with_DR_HA(7) - scenario, requirements, DR procedures
• SAPHanaSR_with_DR_HA_setup(7) - setup procedure
• SAPHanaSR_maintenance_examples(7) - general maintenance procedures
• ocf_suse_SAPHanaController(7) - PREFER_SITE_TAKEOVER, DR mode
• SAPHanaSR-showAttr(8), SAPHanaSR-angi-scenarios(7), SAPHanaSR_multi-target(7), ocf_heartbeat_dnsupdate(7)

SUSE

• HA Solutions for SAP HANA using SAPHanaSR-angi
• SAP HANA System Replication Scale-Up - Performance Optimized Scenario
• SUSE Best Practices for SAP
• SUSE #towardszerodowntime blog series

Microsoft

• High availability for SAP HANA on Azure VMs on SLES
• Disaster Recovery overview and infrastructure guidelines for SAP workload

SAP

• SAP HANA System Replication
• SAP Note 2517805: How-to check if SAP HANA System Replication is in Sync or not