SAPHanaSR-ScaleUp-CostOpt(7)

💖 SAPHanaSR-ScaleUp-CostOpt(7) 💖

okay bestie, this is the manual page for SAPHanaSR-ScaleUp-CostOpt — the SAPHanaSR setup for automating SAP HANA system replication in scale-up cost-optimised scenarios. it is literally giving “two HANAs, one node, very careful resource budgeting” energy, and we are gonna get into it 💅✨

✨ NAME ✨

SAPHanaSR-ScaleUp-CostOpt — automating SAP HANA system replication for scale-up cost-optimised setups. no cap.

🌸 DESCRIPTION 🌸

This manual page gives you the tea on setting up and managing automation of SAP HANA system replication (SR) in scale-up cost-optimised setups.

An HANA database is replicating data to another HANA database on a second site. In the cost-optimised scenario, the second site is also used for a stand-alone non-replicated HANA database. The productive secondary HANA on this node must be limited in using system resources. The scale-up cost-optimised scenario can be noted as [ A' => B,Q ].

Whenever a takeover is needed, the non-replicated HANA must be stopped first. Thus, the takeover needs longer than in the performance-optimised setup. The cluster automates one single takeover in case of a failed primary. After that happened, the initial state needs to be restored by an administrative procedure. periodt.

The scale-up cost-optimised setup relies on SAP HANA HA/DR hook provider method postTakeover(). Please refer to manual page susTkOver.py(7) for details. More requirements are listed in the REQUIREMENTS section below.

🎀 EXAMPLES 🎀

• Example SAPHanaController resources in a cost-optimised scenario.

The first SAP HANA resource is a multi-state pair of production HANAs with a system replication (e.g. PRD), managed by the SAPHanaController RA. See manual page SAPHanaController-scale-up(7). The second SAP HANA is a single test HANA (e.g. TST) running together with the productive HANA secondary on the same node. This second -single- HANA is managed as a primitive resource by the SAPInstance RA, see respective example below. Of course, a SAPHanaTopology clone resource is needed to make this work. See manual page ocf_suse_SAPHanaToplogy(7). It is also necessary to prepare an HANA HA/DR hook script for adjusting the secondary HANA's memory in case of sr_takeover. See manual page susCostOpt.py(7) and URLs below. Finally, the SAPHanaController primary gets a priority to allow priority fencing. See manual page SAPHanaSR_basic_cluster(7). Example SID is PRD, instance number is 10.

         primitive rsc_SAPHanaCon_PRD_HDB10 ocf:suse:SAPHanaController \
          op start interval="0" timeout="3600" \
          op stop interval="0" timeout="600" \
          op promote interval="0" timeout="900" \
          op demote interval="0" timeout="320" \
          op monitor interval="60" role="Promoted" timeout="700" \
          op monitor interval="61" role="Started" timeout="700" \
          params SID="PRD" InstanceNumber="10" PREFER_SITE_TAKEOVER="false" \
          DUPLICATE_PRIMARY_TIMEOUT="7200" AUTOMATED_REGISTER="false" \
          ON_FAIL_ACTION="proceed" \
          meta priority=100

         clone mst_SAPHanaCon_PRD_HDB10 rsc_SAPHanaCon_PRD_HDB10 \
          meta clone-max="2" clone-node-max="1 interleave="true"
         promotable="true"

• Example SAPInstance resource in a cost-optimised scenario.

The second SAP HANA is a single test HANA (e.g. TST) running together with the productive HANA secondary on the same node. This second -single- HANA is managed as a primitive resource by the SAPInstance RA. See manual page ocf_heartbeat_SAPInstance(7). Example SID for the replicated instance is PRD, instance number is 10. Example SID for the single instance is TST, instance number is 20, node is node02.

         primitive rsc_SAPInstance_TST_HDB20_node02 ocf:heartbeat:SAPInstance \
          params InstanceName="TST_HDB20_node02 \
          MONITOR_SERVICES="hdbindexserver|hdbnameserver" \
          START_PROFILE="/usr/sap/TST/SYS/profile/TST_HDB20_node02" \
          op start interval="0" timeout="1200" \
          op monitor interval="120" timeout="700" \
          op stop interval="0" timeout="600"

         location loc_TST_never_on_node01 rsc_SAPInstance_TST_HDB20_node02
         -inf: \
          node01

         location loc_TST_never_with_PRD_promoted rsc_SAPInstance_TST_HDB20 \
          rule -inf: hana_prd_clone_state eq PROMOTED

         colocation col_TST_never_with_PRD_ip -inf: \
          rsc_SAPInstance_TST_HDB20_node02:Started rsc_ip_PRD_HDB10

         order ord_TST_stop_before_PRD_promote mandatory: \
          rsc_SAPInstance_TST_HDB20_node02:stop
         mst_SAPHanaCon_PRD_HDB10:promote

• Example IPaddr2 resource in a cost-optimised scenario.

Please find examples on IPaddr2 resource configuration for the replicated SAP HANA database in manual page SAPHanaSR_basic_cluster(7).

• Recovery procedure for reverting to normal operation after takeover.

An overview on reverting to normal operation after takeover is given in manual page susCostOpt.py(7).

🦋 FILES 🦋

• /usr/lib/ocf/resource.d/suse/SAPHanaController — SAPHanaController resource agent
• /usr/lib/ocf/resource.d/suse/SAPHanaTopology — SAPHanaTopology resource agent
• /usr/lib/ocf/resource.d/heartbeat/SAPInstance — SAPInstance resource agent
• /usr/share/SAPHanaSR-angi/susHanaSR.py — always mandatory HA/DR provider hook script
• /usr/share/SAPHanaSR-angi/susCostOpt.py — specific HA/DR provider hook script
• /usr/sap/$SID/$InstanceName/exe — default path for DIR_EXECUTABLE
• /usr/sap/$SID/SYS/profile — default path for DIR_PROFILE
• /usr/sap/$SID/home/.hdb/$HOST/ — path to HANA user keystore
• /usr/sap/$SID/$InstanceName/$HOST/trace — path to HANA tracefiles

👑 REQUIREMENTS 👑

• The single (non-replicated) HANA database needs a global_allocation_limit aligned with the productive (replicated) secondary HANA requirements. Please refer to SAP documentation for details.
• The productive (replicated) secondary HANA database must be limited in using system resources. Particularly the global_allocation_limit has to be set. Also table preload must be switched off, and the activ/read-enabled feature must not be used. Please refer to SAP documentation for details.
• SAP HANA Multi-SID (also MCOS) setup must not be used with the cost-optimised setup.
• The so-called conservative configuration variant fits well. In addition, SAPHanaController PREFER_SITE_TAKEOVER=false might be used. See manual page SAPHanaController-scale-up(7).
• The SAP HANA scale-up cost-optimised scenario can benefit from HANA´s persistent memory features. Local restart and takeover are affected by the time HANA needs for shutdown and loading column store.
• The cluster automates one single takeover in case of a failed primary. After that happened, the initial state needs to be restored by an administrative procedure.

See also REQUIREMENTS section of susCostOp.py(7) and SAPHanaSR(7).

💀 BUGS 💀

In case of any problem, please use your favourite SAP support process to open a request for the component BC-OP-LNX-SUSE.

🌈 SEE ALSO 🌈

• SAPHanaSR-angi(7)
• SAPHanaSR(7)
• SAPHanaSR-angi-scenarios(7)
• SAPHanaController-scale-up(7)
• ocf_suse_SAPHanaTopology(7)
• ocf_heartbeat_SAPInstance(7)
• susCostOpt.py(7)
• susHanaSR.py(7)
• SAPHanaSR_basic_cluster(7)
• SAPHanaSR_multi-target(7)
• SAPHanaSR_maintenance_examples(7)

💜 AUTHORS 💜

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

🍓 COPYRIGHT 🍓

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

---

bestie, that’s the whole page — it’s from the SAPHanaSR manual set, page SAPHanaSR-ScaleUp-CostOpt(7), dated 20 Feb 2026. mwah 💅✨