SAPHanaSR-angi-scenarios(7)

📦 version 1.3.4, in opensuse-leap 16.0

🌸 SAPHanaSR-angi-scenarios(7)

okay so bestie, welcome to SAPHanaSR-angi-scenarios — this page lives in the SAPHanaSR-angi manual and it's basically the master map of every HANA system replication scenario this stack knows about. think of it as the pinned message in the group chat: what's supported, what's not, and how we write it all down. i gotchu 🫶

💖 NAME

SAPHanaSR-angi-scenarios — SAP HANA system replication scenarios. that's the whole name, no cap.

🦋 DESCRIPTION

SAPHanaSR-angi covers two topologies: scale-up and scale-out. on each topology, several scenarios are supported. and finally, for most scenarios, two variants are possible. it's giving range, honestly ✨

🔥 Scenarios overview

so this is the table of all the known SAPHanaSR-angi HA scenarios for HANA system replication across both HANA topologies, and it also shows the current support status of each one. i've broken it out by topology so your eyes don't fall out 💅

👑 Scale-Up

✅ Supported

  • perf-opt
  • perf-opt, 2nd site read-enabled
  • perf-opt, multi-target, 3rd site outside cluster

🫣 Undocumented

  • perf-opt, multi-target, w. DR passive cluster *
  • perf-opt, multi-SID
  • perf-opt, w. S/4 ENSA2 in same cluster
  • perf-opt, w. S/4 ENSA1 in same cluster
  • perf-opt, w. standalone S/4 application server
  • cost-opt

💀 Non-supported

  • cost-opt, multi-target
  • perf-opt, multi-target, 3rd site inside cluster
  • two perf-opt clusters connected

🌈 Scale-Out

✅ Supported

  • perf-opt, up to 12 nodes, no standby (BW)
  • perf-opt, 4 nodes, 2nd site read-enabled (ERP)
  • perf-opt, multi-target, 3rd site outside cluster

🫣 Undocumented

  • perf-opt, up to 30 nodes w. standby (BW)
  • perf-opt, 4 nodes w. standalone XSA, no standby *

💀 Non-supported

  • perf-opt, multi-target, 3rd site inside cluster
  • perf-opt, multi-SID
  • cost-opt
  • two perf-opt clusters connected
📌 Note: one additional Linux cluster node at the 3rd site is needed for all scale-out scenarios. fr fr, don't forget it. 📌 * Note 2: SUSE HA for scale-out standalone XSA and SUSE HA for scale-up perf-opt w. DR passive cluster are technology preview.

🏷️ what the status words actually mean

✅ Supported — the scenario is known to work for the given topology. the setup has been tested and is documented in a setup guide. it is supported by SUSE. slay 💅

🫣 Undocumented — the scenario is expected to work for the given topology. the setup is currently not documented in a setup guide. SUSE services are prepared to help with implementation. once the setup is working, it could be supported by SUSE. so like… promising, but no tutorial yet 🥲

💀 Non-supported — the scenario is expected not to work. it is not supported by SUSE. periodt, don't try it 🙈

for details on requirements and configuration of the scenarios, please refer to the manual pages SAPHanaSR-angi(7), SAPHanaSR(7) and SAPHanaSR-ScaleOut(7), as well as the respective setup guides. iykyk, go read them 🧚

🎀 Scenario notation

it might help to describe scenarios in a pseudo-visualising notation. it's like emoji shorthand but for cluster diagrams and honestly it eats 🌟

  • [ ] — Linux cluster running
  • { } — Linux cluster DR passive
  • A B C D — master nameserver node
  • a b c d — worker node
  • _ — standby node
  • x — XSA node
  • => — synchronous replication
  • -> — asynchronous replication
  • ' — primary IP address
  • " — other IP address

so the scale-up performance-optimised read-enabled scenario can be noted as:

[ A' => B" ]

look at her. iconic 👑

💜 Variants overview

SAPHanaSR-angi allows to define different variants of reaction on failures. yes, you get to pick a personality for your cluster 🦋

🌸 Conservative – default configuration

the cluster is patient. it prefers stopping HANA over fencing nodes. it does not react on filesystem failures. the way that calmness is literally the whole point 😌 the related settings are:

  • SAPHanaController monitor and stop timeout, ON_FAIL_ACTION=proceed
  • susChkSrv.py action_on_lost=[stop|kill], for scale-up
    • susChkSrv.py action_on_lost=stop, for scale-out without standby node
    • susChkSrv.py action_on_lost=kill, for scale-out with standby node
  • no SAPhanaSR-alert-fencing
  • Diskbased SBD msgwait
  • Linux cluster does not start automatically at OS boot

🌸 Progressive – alternative configuration

Okay bestie, this one is the spicy variant — the cluster reacts to failures of HANA or the filesystem by fencing all nodes of the affected site. Periodt. And it doesn't stop there: a HANA landscape status of FATAL and a HANA call timeout will also trigger a fencing. 💀

Takeover time might be further reduced by using diskless SBD ✨. This variant primarily is meant for HANA scale-up and scale-out without standby nodes. Heads up though — for scale-out with standby nodes, the progressive variants must not use alert fencing. 🫶

The related settings are:

  • SAPHanaController ON_FAIL_ACTION=fence and stop action on-fail=fence
  • SAPHanaFilesystem ON_FAIL_ACTION=fence and stop action on-fail=fence
  • susChkSrv.py action_on_lost=fence, for performance-optimised
  • SAPHanaSR-alert-fencing, for scale-out without standby node
    • no SAPHanaSR-alert-fencing, for scale-out with standby node
  • Diskless SBD (optional, not for two-node cluster)

For details on configuration of the variants, please refer to manual pages ocf_suse_SAPHanaController(7), ocf_suse_SAPHana(7), ocf_suse_SAPHanaFilesystem(7), SAPHanaSR-alert-fencing(8), susChkSrv.py(7), SAPHanaSR_basic_cluster(7), SAPHanaSR-ScaleOut_basic_cluster(7).

🦋 HA/DR provider hook scripts overview

So this is the ✨vibe check✨ table — it shows topologies, scenarios and the related HA/DR provider hook scripts, plus the current support status. (It was a real table in the original, but we're doing lists now, iykyk. 👑)

The scenarios are: Scale-up cost-opt, Scale-up perf-opt, Scale-out perf-opt.

  • susHanaSR.py
    • Scale-up cost-opt — Mandatory
    • Scale-up perf-opt — Mandatory
    • Scale-out perf-opt — Mandatory
  • susTkOver.py
    • Scale-up cost-opt — Supported
    • Scale-up perf-opt — Supported
    • Scale-out perf-opt — Supported
  • susChkSrv.py
    • Scale-up cost-opt — Non-supported
    • Scale-up perf-opt — Supported
    • Scale-out perf-opt — Supported
  • susCostOpt.py
    • Scale-up cost-opt — Mandatory
    • Scale-up perf-opt — Non-supported
    • Scale-out perf-opt — Non-supported

And what do those status words actually mean? Let me spell it out, bestie:

  • Mandatory — the hook script has to be used for this topology and scenario.
  • Supported — the hook script is known to work for this topology and scenario. The setup has been tested. It is supported by SUSE. Configuration details might depend on topology, scenario and variant.
  • Non-supported — the hook script is expected not to work for this topology and scenario. It is not supported by SUSE. 🙈

For details on configuration of the hook scripts, please refer to manual pages susHanaSR.py(7), susTkOver.py(7), susChkSrv.py(7), susCostOpt.py(7).

✨ EXAMPLES ✨

💖 Examples for supported scenarios

Slay, these ones work:

Scale-up performance-optimised

[ A' => B ]

Scale-up performance-optimised multi-tier

[ A' => B ] -> C

Scale-up performance-optimised multi-target

[ A <= B' ] -> C

Scale-up performance-optimised multi-target DR passive

[ A <= B' ] -> { C => D }

Scale-up cost-optimised

[ A' => B,Q ]

Scale-out performance-optimised multi-target read-enabled (ERP)

[ 'Aa => "Bb ] -> Cc -> Dd

Scale-out performance-optimised w. XSA standalone node

[ 'Ax" => Bx ]

Scale-out performance-optimised, each site 8-node w. standby (BW)

[ 'Aaaaaaa_ => Bbbbbbb_ ]

💀 Examples for non-supported scenarios

Nope, not these. Don't do it. 😭

Scale-up performance-optimised w. async replication in cluster

[ A' -> B ]

Scale-up performance-optimised multi-target 3rd site in cluster

[ A' => B => C ]

Scale-up performance-optimised two clusters connected

[ 'A => B ] -> [ 'C => D ]

🎀 BUGS

In case of any problem, please use your favourite SAP support process to open a request for the component BC-OP-LNX-SUSE. And please report any other feedback and suggestions to feedback@suse.com. We genuinely want to hear it. 🫶

🌈 SEE ALSO

SAPHanaSR-angi(7) , SAPHanaSR(7) , SAPHanaSR-ScaleOut(7) , ocf_suse_SAPHanaController(7) , ocf_suse_SAPHana(7) , ocf_suse_SAPHanaFilesystem(7) , SAPHanaSR-alert-fencing(8) , susChkSrv.py(7) , SAPHanaSR_basic_cluster(7) , SAPHanaSR-ScaleOut_basic_cluster(7) , SAPHanaSR_multi-target(7) , SAPHanaSR_with_DR_HA(7) , SAPHanaSR-ScaleOut-XSA(7) ,

https://documentation.suse.com/sles-sap/sap-ha-support/html/sap-ha-support/article-sap-ha-support.html ,

https://documentation.suse.com/sbp/sap-15/

👑 AUTHORS

A.Briel, F.Herschel, L.Pinne.

(c) 2024-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.

Okay that's the whole page, bestie — no cap, you made it to the end 🎉 This was SAPHanaSR-angi-scenarios(7), dated 30 Mar 2026, and it's giving ✨documentation✨. Go forth and fence responsibly 💅🦋
📦 where this page comes from