SAPHanaSR_with_DR_HA_setup(7)

📦 version 1.3.4, in opensuse-leap 16.0

🌸 SAPHanaSR_with_DR_HA_setup(7) — the SAPHanaSR-angi era, bestie edition 💅

okay so this is the SAPHanaSR_with_DR_HA_setup page from the SAPHanaSR-angi fam, and it's literally the glow-up guide for running SAPHanaSR with an HA cluster chilling in the DR region. bucket-list level important, no cap 🫶

✨ NAME ✨

SAPHanaSR_with_DR_HA_setup — SAPHanaSR with an HA cluster at the DR region, setup procedure. it's giving "here's how we build the whole thing" energy 🌈

🦋 DESCRIPTION 🦋

okay so picture this: two HANA system replication pairs, connected by a third HANA system replication. each pair is configured as a Linux cluster for the scale-up performance-optimised scenario. iconic setup honestly 👑

  • the first pair is running regularly as the production region — that's site1, site2 💖
  • the second pair is running in DR mode — that's site3, site4 🩵

see manual page SAPHanaSR_with_DR_HA(7) for the deets, iykyk.

The two clusters could be set up and connected by different procedures:

a. Set up HANA and Linux clusters in both regions separately. Test both regions in production mode before connecting them. Test takeover, register and DR mode once both regions are connected. This procedure is outlined as an example below. This is the recommended setup procedure. ✨ main character energy, fr fr.

b. Set up HANA and Linux clusters in production region. Connect HANA DR site (or region) without Linux cluster there. Test production region. Install cluster at DR region in DR mode. Test takeover. Test register and DR mode. This procedure is possible, but not recommended. 🙈 See manual pages SAPHanaSR(7), SAPHanaController-scale-up(7), susHanaSR.py(7), SAPHanaSR_basic_cluster(7), SAPHanaSR_multi-target(7), SAPHanaSR_with_DR_HA(7), et al.

🎀 EXAMPLES 🎀

The examples are outlining highlevel procedures as well as describing basic tasks. Detailled runbooks can be created by using the appropriate tasks for adding details to the procedures. build-your-own-adventure but make it cluster ops 💀

⭐ Procedure to set up HANA and Linux clusters in both regions ⭐

Set up HANA and Linux clusters in both regions separately. Test both regions in production role before connecting them. Test takeover and DR role after both are connected. SID is HA1, instance number is 00. slay 🍓

site1, node1: production primary
site2, node2: production secondary
site3, node3: current temporary primary, to become first DR
replication target
site4, node4: current temporary secondary, to second DR replication
target

Please see also the REQUIREMENTS section in manual page SAPHanaSR_with_DR_HA(7). 👀

  1. Collect information and prepare parameter sheet. 📝
  2. Install SAPHanaSR-angi scale-up performance-optimised scenario at production region (site1, site2).
  3. Check that everything works fine at production region (site1, site2). ✅
  4. Install SAPHanaSR-angi scale-up performance-optimised scenario at DR region (site3, site4).
  5. Check that everything works fine at DR region (site3, site4). ✅
  6. Copy HANA secure keystore from production primary (site1) to DR nodes (site3, site4).
    • See example "Copying HANA secure keystore from production primary to nodes at DR region."
  7. Add entry in global.ini to register secondaries on takeover.
    • See example "Entry in global.ini to register secondaries on takeover."
  8. Add DR specific colocation constraint for IPaddr2 to both clusters.
    • See example "Preventing IPaddr2 from starting at DR sites."
  9. Set SAPHanaController multi-state resource into maintenance at DR region (node3, node4).
node3 # crm resource maintenance mst_SAPHanaCon_HA1_HDB00
  1. Stop HANA at DR region (node3, node4). Stop primary first. 🛑
node3 # su - ha1adm -c "HDB stop"
node4 # su - ha1adm -c "HDB stop"
  1. Change SAPHanaController to "PREFER_SITE_TAKEOVER=DR" at DR region.
node3 # crm configure set rsc_SAPHanaCon_HA1_HDB00.PREFER_SITE_TAKEOVER DR
node3 # crm configure show rsc_SAPHanaCon_HA1_HDB00 | grep PREFER_SITE_TAKEOVER
⚠️ The next steps will overwrite all HANA data at DR sites (site3, site4). like, all of it. please read that twice, bestie. 😭💀
  1. Register first DR site (node3) as secondary to production primary (site1).
node3 # su - ha1adm
node3 ~> hdbnsutil -sr_register --remoteHost=node1 --remoteInstance=00 \
 --replicationMode=async --operationMode=logreplay \
 --force_full_replica --name=site3
node3 ~> exit
  1. Start HANA at first DR site (node3).
node3 # su - ha1adm -c "HDB start"
  1. Enable system replication at first DR site (site3).
node3 # su - ha1adm -c "hdbnsutil -sr_enable"
  1. Register second DR site (site4) as secondary to first DR site (site3).
node4 # su - ha1adm
node4 ~> hdbnsutil -sr_register --remoteHost=node3 --remoteInstance=00 \
 --replicationMode=syncmem --operationMode=logreplay \
 --force_full_replica --name=site4
node4 ~> exit
  1. Start second DR site (site4).
node4 # su - ha1adm -c "HDB start"
  1. Refresh SAPHanaController multi-state resource.
node4 # crm resource refresh mst_SAPHanaCon_HA1_HDB00
  1. Change srHook attribute of first DR site (site3) to SWAIT.
node4 # crm_attribute -n hana_ha1_site_srHook_site3 -v SWAIT -t crm_config -s SAPHanaSR
  1. Get SAPHanaController multi-state resource out of maintenance.
node4 # crm resource maintenance mst_SAPHanaCon_HA1_HDB00 off
  1. Change IP address at DR region (site3, site4) to match production (optional).
    • See example "Changing IPaddr2 at DR sites to match production."
  2. Check that everything works fine. 🎉 you did it, bestie.

🧚 Entry in global.ini to register secondaries on takeover 🧚

This entry is needed at all HANA nodes. The HANA has to be stopped before the file can be edited. Do not copy the file global.ini between nodes. Please check SAP HANA documentation for details. 🫶

[system_replication]
 ...
register_secondaries_on_takeover = true
 ...

🔐 Copying HANA secure keystore from production primary to nodes at DR region 🔐

Needs to be done at production primary before registering the DR secondaries. Production primary is node2. DR secondary nodes are node3 and node4, SID is HA1. 💖

node1 # cd /usr/sap/HA1/SYS/global/security/rsecssfs
node1 # md5sum */*
node1 # rsync -va * node3:$PWD/
node1 # rsync -va * node4:$PWD/
node1 # ssh node3 "md5sum $PWD/*/*"
node1 # ssh node4 "md5sum $PWD/*/*"

🚫 Preventing IPaddr2 from starting at DR sites 🚫

The production HANA database might be accessed by the same IP address at both regions. In that case the IP address must not run on the current DR sites. Two location contstraints are preventing from starting the IPaddr2 resource at any DR site. This constraint is needed at both regions. SID is HA1, instance number is 00. ✨

location loc_ip_not_dr_1 rsc_ip_HA1_HDB00 rule -inf: \
 master-rsc_SAPHanaCon_HA1_HDB00 lt 145
location loc_ip_not_dr_2 rsc_ip_HA1_HDB00 rule -inf: \
 not_defined master-rsc_SAPHanaCon_HA1_HDB00

🌈 Changing IPaddr2 at DR sites to match production 🌈

The production HANA database might be accessed by the same IP address at both regions. However, during installation and testing phase both regions should use different IP addresses. Once one of the clusters is running in DR mode, in that cluster the IP address can be changed to match the production. SID is HA1, instance number is 00, IP address is 192.168.22.22. 🔥

# crm configure set rsc_ip_HA1_HDB00.ip 192.168.22.22

🦋 Using Dynamic DNS for moving the HANA IP address between regions 🦋

It might be that the same IP address should be used at both regions. Usually the IP address is managed by the IPaddr2 RA, sometimes together with a loadbalancer. If this is not possible across regions, Dynamic DNS might be an option. For details please refer to manual page ocf_heartbeat_dnsupdate(7). 👑

💜 Backing up first DR node and enabling system replication 💜

Needs to be done at first DR node, before registering another node. First DR site is site3, SID is HA1, instance number is 00. 💫

# su - ha1adm
~> hdbsql -i 00 -u SYSTEM -d SYSTEMDB \
 "BACKUP DATA FOR FULL SYSTEM USING FILE ('backup')"
~> hdbnsutil -sr_enable --name=site3
~> hdbnsutil -sr_state

💅 FILES 💅

  • /hana/shared/$SID/global/hdb/custom/config/global.ini — on-disk representation of HANA global system configuration. the file itself, bestie 🌸
  • /usr/sap/$SID/SYS/global/security/rsecssfs/ — HANA database secure keystore directory. keep it safe, keep it secret 🔐

⭐ REQUIREMENTS ⭐

See the REQUIREMENTS section in manual page SAPHanaSR_with_DR_HA(7) and SAPHanaSR-angi(7). do your homework first, i'm begging 🙏

💀 BUGS 💀

In case of any problem, please use your favourite SAP support process to open a request for the component BC-OP-LNX-SUSE. they'll sort you out, no cap 🫶

🌟 SEE ALSO 🌟

SAPHanaSR-angi(7) , SAPHanaSR-angi-scenarios(7) , SAPHanaSR(7) , SAPHanaSR_multi-target(7) , SAPHanaSR_with_DR_HA(7) , SAPHanaSR_basic_cluster(7) , ocf_suse_SAPHanaController(7) , susHanaSR.py(7) , SAPHanaSR_maintenance_examples(7) , https://documentation.suse.com/sbp/sap/ — the whole reading list, go off 📚✨

👑 AUTHORS 👑

A.Briel, F.Herschel, L.Pinne. legends, honestly 🎀

(c) 2026 SUSE LLC

The package SAPHanaSR-angi comes with ABSOLUTELY NO WARRANTY. For details see the GNU General Public License at http://www.gnu.org/licenses/gpl.html — like, absolutely none, we said what we said 💀

💖 that's the whole page, bestie! brought to you by SAPHanaSR-angi, dated 27 May 2026 — catch you on SAPHanaSR_with_DR_HA_setup(7) next time! mwah 💋✨

📦 where this page comes from