SAPHanaSR_upgrade_to_angi(7)

📦 version 1.3.4, in opensuse-leap 16.0

💅 SAPHanaSR_upgrade_to_angi — the glow-up guide (SAPHanaSR, section 7)

okay so bestie, this is from the SAPHanaSR manual, section 7, and it's literally the whole roadmap for upgrading from SAPHanaSR or SAPHanaSR-ScaleOut to SAPHanaSR-angi. no gatekeeping here 🫶

✨ NAME ✨

SAPHanaSR_upgrade_to_angi — How to upgrade from SAPHanaSR or SAPHanaSR-ScaleOut to SAPHanaSR-angi.

🦋 DESCRIPTION 🦋

💖 What is the upgrade about?

SAPHanaSR-angi can be used to replace SAPHanaSR and SAPHanaSR-ScaleOut. she's quite similar to SAPHanaSR and SAPHanaSR-ScaleOut, but not fully backward compatible — so do not just yolo it, mkay? upgrading existing clusters is totally possible, but you have to follow a defined procedure. do it right and the upgrade lands you on the exact same configuration you'd get from an installation from scratch. main character energy, no leftover chaos 💅

the upgrade procedure depends on an initial setup as described in setup guides and manual pages. see REQUIREMENTS below and in manual pages SAPHanaSR(7) or SAPHanaSR-ScaleOut(7). the procedure does not necessarily need downtime for HANA, if planned and executed carefully. that said — still do it under friendly conditions, please. no upgrading during a crisis ✨

🌈 What will be changed for SAP HANA scale-up scenarios?

SAPHanaSR-angi unifies HA for HANA scale-up and scale-out. so basically it handles scale-up as a subset of scale-out, which changes the structure of attributes. the most significant changes are listed below 👇

a. The SAPHana RA and its multi-state config will be replaced by the new SAPHanaController and its clone promotable config. b. The SAPHanaSR.py HADR provider hook script will be replaced by the new susHanaSR.py. c. Tools are placed in /usr/bin/ instead of /usr/sbin/. d. Node attributes will be removed:

hana_<sid>_site
hana_<sid>_remoteHost
lpa_<sid>_lpt
hana_<sid>_op_mode
hana_<sid>_srmode
hana_<sid>_sync_state

also the first and second field of hana_<sid>_roles go bye-bye 💀

e. Site and global attributes will be added to property SAPHanaSR:

hana_<sid>_glob_topology
hana_<sid>_glob_prim
hana_<sid>_glob_sec
hana_<sid>_site_lpt_<site>
hana_<sid>_site_lss_<site>
hana_<sid>_site_mns_<site>
hana_<sid>_site_srr_<site>
hana_<sid>_site_opMode_<site>
hana_<sid>_site_srMode_<site>
hana_<sid>_site_srPoll_<site>

🎀 What will be changed for SAP HANA scale-out scenarios?

again: SAPHanaSR-angi unifies HA for HANA scale-up and scale-out. but here's the tea — for scale-out, the structure of attributes stays unchanged 🫶 the most significant changes are listed below:

a. The SAPHanaController RA and its multi-state config will be replaced by the new SAPHanaController and its clone promotable config. b. The SAPHanaSrMultiTarget.py HADR provider hook script will be replaced by the new susHanaSR.py. c. Tools are placed in /usr/bin/ instead of /usr/sbin/. d. Node attributes will be removed:

hana_<sid>_gra
hana_<sid>_gsh

e. Site and global attributes will be removed from property SAPHanaSR:

hana_<sid>_glob_mts
hana_<sid>_glob_upd
hana_<sid>_glob_sync_state
hana_<sid>_glob_srmode
hana_<sid>_glob_srHook (in case of obsolete scale-out SAPHanaSR.py)

f. Site and global attributes will be added to property SAPHanaSR:

hana_<sid>_glob_topology
hana_<sid>_site_lpt_<site>
hana_<sid>_site_lss_<site>
hana_<sid>_site_mns_<site>
hana_<sid>_site_srr_<site>
hana_<sid>_site_srMode_<site>
hana_<sid>_site_srPoll_<site>

👑 How does the upgrade procedure look like at a glance?

four phases, bestie: preparing, removing, adding, finalising. the Linux cluster and HANA are kept running the whole time 😌 however — resource management is disabled and the system goes thru fragile states during the upgrade. so like, she's awake but she's not okay. be gentle 🙈

  • 1.1 Check for sane state of cluster, HANA and system replication
  • 1.2 Collect information, needed for upgrade
  • 1.3 Make backup of CIB, sudoers and global.ini
  • 2.1 Set SAPHana or SAPHanaController resource to maintenance
  • 2.2 Remove SAPHanaSR.py or SAPHanaSrMultiTarget.py from global.ini, HANA and sudoers
  • 2.3 Remove SAPHana or SAPHanaController resource config from CIB
  • 2.4 Remove SAPHanaSR property attributes from CIB
  • 2.5 Remove SAPHanaSR node attributes from CIB
  • 2.6 Remove SAPHanaSR or SAPHanaSR-ScaleOut RPM
  • 3.1 Install SAPHanaSR-angi RPM
  • 3.2 Add susHanaSR.py to sudoers, global.ini, HANA
  • 3.3 Add angi SAPHanaController resource config to CIB
  • 3.4 Refresh SAPHanaController resource and set it out of maintenance
  • 3.5 Add SAPHanaFilesystem resource (optional)
  • 3.6 Add SAPHanaSR-alert-fencing agent (optional, scale-out)
  • 4.1 Check for sane state of cluster, HANA and system replication
  • 4.2 Test RA on secondary and trigger susHanaSR.py (optional)
  • 4.3 Remove ad-hoc backup from local directories

🌸 What needs to be prepared upfront?

first things first — make yourself familiar with the concepts, components and configuration of SAPHanaSR-angi. and refresh your knowledge of SAPHanaSR or SAPHanaSR-ScaleOut. never skip the reading era 📚

next, the following information needs to be collected and documented before upgrading a cluster:

  • 1.1 Path to config backup directory at both sites
  • 1.2 Name of both cluster nodes, respectively both HANA master nameservers, see SAPHanaSR-showAttr(8)
  • 1.3 HANA SID and instance number, name of <sid>adm
  • 1.4 HANA virtual hostname, in case it is used
  • 1.5 Name and config of existing SAPHana, or SAPHanaController, resources and related constraints in CIB, see ocf_suse_SAPHana(7) or ocf_suse_SAPHanaController(7)
  • 1.6 Path to sudoers permission config file and its content, e.g. /etc/sudoers.d/SAPHanaSR
  • 1.7 Name of existing SAPHanaSR.py, or SAPHanaSrMultiTarget.py, section in global.ini and its content, see SAPHanaSR.py(7), SAPHanaSrMultiTarget.py(7) and SAPHanaSR-manageProvider(8)
  • 2.1 Name and config for new SAPHanaController resources and related constraints, path to config template, see ocf_suse_SAPHanaController(7)
  • 2.2 Path to config template for new sudoers permission and its content, see susHanaSR.py(7)
  • 2.3 Path to config template for new susHanaSR.py section, e.g. /usr/share/SAPHanaSR-angi/global.ini_susHanaSR, see susHanaSR.py(7)
  • 2.4 Name and config for new SAPHanaFilesystem resources, path to config template, see ocf_suse_SAPHanaFilesystem(7) (optional)

finally — prepare the config templates with the correct values for the given cluster. ideally also have the needed commands prepared in detail. like, fully written out. future you will be so grateful, i promise 🧚💜

🎀 EXAMPLES 🎀

okay bestie, this is the part where we actually do stuff. every single one of these is a real-world move, so read carefully, don't skip, and definitely don't freestyle the commands. 💅

✨ Example for checking sane state of cluster, HANA and system replication ✨

this is your little health-check ritual. do it before you touch anything in the cluster, and again after you've done the thing. usually it's done per Linux cluster. also peep manual pages SAPHanaSR_maintenance_examples(7), cs_show_saphanasr_status(8) and section REQUIREMENTS down below (yes, it's coming). for scale-out, SAPHanaSR-manageAttr(8) might be helpful too. 🫶

# cs_clusterstate -i
# crm_mon -1r
# crm configure show | grep cli-
# SAPHanaSR-showAttr
# cs_clusterstate -i

💜 Example for showing SID and instance number of SAP HANA 💜

this shows you the installed SAP HANA instance (there should be only one) with its SID and instance number. if your HANA is systemd-enabled you can pull the exact same info from systemd instead. needs to be done at least once per Linux cluster. see also manual page SAPHanaSR_basic_cluster(7).

# /usr/sap/hostctrl/exe/saphostctrl -function ListInstances
# systemd-cgls -u SAP.slice

🦋 Example for collecting information on SAPHana resource config 🦋

here we're figuring out the names of the SAPHana primitive and multi-state resource, plus the related order and (co-)location constraints. then it dumps the SAPHana primitive config so you can eyeball whether anything looks ✨special✨. needs to be done once per Linux cluster.

# crm_mon -1r
# crm configure show |\
  grep -e "[primitive|master|order|location].*SAPHana_"
# crm configure show rsc_SAPHana_HA1_HDB00

🌸 Example for making a backup of CIB, sudo config and global.ini 🌸

backups are the moment, no cap. SID here is HA1, and the sudo config lives at /etc/sudoers.d/SAPHanaSR.

# export BAKDIR=SAPHanaSR.$(date +%s)
# mkdir ~/$BAKDIR
# cp -a /hana/shared/HA1/global/hdb/custom/config/global.ini
~/$BAKDIR/
# cp -a /etc/sudoers.d/SAPHanaSR ~/$BAKDIR/SAPHanaSR.sudo
# crm configure show >~/$BAKDIR/crm_configure.txt
# ls -l ~/$BAKDIR/*

🔥 Example for removing SAPHana resource config from CIB, scale-up 🔥

okay so the order of operations here is lowkey important. first the CIB gets written to a file as a backup. next the cluster is told to not stop orphaned resources, and the SAPHana multi-state resource gets put into maintenance. then the order and colocation constraints get removed, the SAPHana multi-state resource gets removed, and the orphaned primitive gets refreshed. after that the cluster is told to stop orphaned resources again. finally the resulting cluster state gets shown. and obviously check the CIB too to confirm the removal actually worked, bestie. needs to be done once per Linux cluster. SID is HA1, Instance Number is 00. the resource names were figured out like in the example above. 👑

# crm configure show > SAPHanaSR-crm-backup
# echo "property cib-bootstrap-options: stop-orphan-resources=false"|\
  crm configure load update -
# crm resource maintenance msl_SAPHana_HA1_HDB00 on
# cibadmin --delete --xpath \
  "//rsc_order[@id='ord_SAPHana_HA1_HDB00']"
# cibadmin --delete --xpath \
  "//rsc_colocation[@id='col_saphana_ip_HA1_HDB00']"
# cibadmin --delete --xpath \
  "//master[@id='msl_SAPHana_HA1_HDB00']"
# crm resource refresh rsc_SAPHana_HA1_HDB00
# echo "property cib-bootstrap-options: stop-orphan-resources=true"|\
  crm configure load update -
# crm_mon -1r

🌈 Example for removing location constraints from CIB, scale-out 🌈

first you do the exact same steps as for scale-up (see the example right above, bestie). then, on top of that, the (anti-)location constraints for the majority maker node also gotta go. the resource names were determined like in the example above.

# cibadmin --delete --xpath \
  "//rsc_location[@id='SAPHanaCon_not_on_majority_maker']"
# cibadmin --delete --xpath \
  "//rsc_location[@id='SAPHanaTop_not_on_majority_maker']"

⭐ Example for removing all reboot-safe node attributes from CIB ⭐

this nukes all the reboot-safe node attributes. the attributes that are actually needed are expected to get re-added by the RAs later, so don't panic. ofc check the CIB to see if the removal worked. needs to be done for both nodes, or both master nameservers. Node is node1. see also crm_attribute(8).

# crm configure show node1
# crm configure show node1 | tr " " "\n" |\
  awk -F "=" 'NR>5 {print $1}' | while read; do \
  crm_attribute --node node1 --name $REPLY --delete; done

🍓 Example for removing non-reboot-safe node attribute from CIB, scale-up 🍓

the attribute hana_<sid>_sync_state is the one getting removed here. ofc check the CIB to confirm it actually left. needs to be done for both nodes. scale-up only. Node is node1, SID is HA1. see also crm_attribute(8).

# crm_attribute --node node1 --name hana_ha1_sync_state \
  --lifetime reboot --query
# crm_attribute --node node1 --name hana_ha1_sync_state \
  --lifetime reboot --delete

🧚 Example for removing all SAPHanaSR property attributes from CIB, scale-out 🧚

every attribute of property SAPHanaSR gets removed. the needed ones are expected to get re-added by the RAs later. heads up: the attribute for srHook gets added by the susHanaSR.py HADR provider script, so it might be missing until the HANA system replication status changes — that's normal, don't spiral. ofc check the CIB to see if the removal was successful. needs to be done once per Linux cluster. scale-out only. see also SAPHanaSR-showAttr(8) and SAPHanaSR.py(7) or SAPHanaSrMultiTarget.py(7) respectively.

# crm configure show SAPHanaSR
# crm configure show SAPHanaSR |\
  awk -F"=" '$1~/hana_/ {print $1}' | while read; do \
  crm_attribute --delete --type crm_config --name $REPLY; done

💀 Example for removing the SAPHanaSR.py hook script from global.ini and HANA 💀

global.ini gets copied for backup first. next the exact name (upper/lower case matters, bestie) of the section gets determined from global.ini. then the current HADR provider section gets shown. if that section is identical to the shipped template, it can be removed from the config super easily. finally the HADR provider hook script gets removed from the running HANA. needs to be done for each HANA site. SID is HA1, and the case-sensitive HADR provider name is SAPHanaSR. this example is given for scale-up SAPHanaSR.py — for scale-out, SAPHanaSrMultiTarget.py might get removed instead. the path /usr/sbin/ is used because this step happens while the old RPM is still installed. see manual page SAPHanaSR.py(7) or SAPHanaSrMultiTarget.py(7) for the details on checking the hook script integration.

# su - ha1adm
~> cdcoc
~> cp global.ini global.ini.SAPHanaSR-backup
~> grep -i ha_dr_provider_saphanasr global.ini
~> /usr/sbin/SAPHanaSR-manageProvider --sid=HA1 --show \
  --provider=SAPHanaSR
~> /usr/sbin/SAPHanaSR-manageProvider --sid=HA1 --reconfigure \
  --remove /usr/share/SAPHanaSR/samples/global.ini
~> hdbnsutil -reloadHADRProviders

🎀 Example for removing the SAPHanaSR.py hook script from sudoers 🎀

needs to be done on each node. this example is given for scale-up SAPHanaSR.py — for scale-out, SAPHanaSrMultiTarget.py might get removed instead. see manual page SAPHanaSR.py(7) for the deets on checking the hook script integration.

# cp $SUDOER "$SUDOER".angi-bak
# grep -v "$sidadm.*ALL..NOPASSWD.*crm_attribute.*$sid" \
  "$SUDOER".angi-bak >$SUDOER

💖 Example for removing old SAPHanaSR-hookHelper from sudoers 💖

needs to be done on each node. see manual page SAPHanaSR-hookHelper(8) for the deets on checking the integration.

# cp $SUDOER "$SUDOER".angi-bak
# grep -v "$sidadm.*ALL..NOPASSWD.*SAPHanaSR-hookHelper" \
  "$SUDOER".angi-bak >$SUDOER

🦋 Example for removing the SAPHanaSR and SAPHanaSR-doc package 🦋

the packages SAPHanaSR and SAPHanaSR-doc get removed from all cluster nodes. related packages defined by patterns and dependencies are not touched, so don't worry about collateral damage. needs to be done once per Linux cluster. all nodes get checked to make sure the packages aren't installed anymore. this example is given for scale-up SAPHanaSR — for scale-out, SAPHanaSR-ScaleOut might get removed instead.

# crm cluster run "rpm -e --nodeps SAPHanaSR-doc"
# crm cluster run "rpm -e --nodeps SAPHanaSR"
# crm cluster run "hostname; rpm -q SAPHanaSR-doc --queryformat
%{NAME}"
# crm cluster run "hostname; rpm -q SAPHanaSR --queryformat %{NAME}"

✨ Example for installing the SAPHanaSR-angi package ✨

the package SAPHanaSR gets installed on all cluster nodes. all nodes get checked afterward for the package. needs to be done once per Linux cluster. slay. 👑

# crm cluster run \
  "zypper --non-interactive in -l -f -y SAPHanaSR-angi"
# crm cluster run \
  "hostname; rpm -q SAPHanaSR-angi --queryformat %{NAME}"

🌸 Example for adding susHanaSR.py to sudoers 🌸

needs to be done on each node. see manual page susHanaSR.py(7) and SAPHanaSR-hookHelper(8).

🌈 Example for adding new SAPHanaSR-hookHelper to sudoers 🌈

needs to be done on each node. see the example for sudo permissions in manual page SAPHanaSR-hookHelper(8).

🍓 Example for adding susHanaSR.py to global.ini and HANA 🍓

needs to be done for each HANA site. see manual page susHanaSR.py(7) and SAPHanaSR-manageProvider(8).

⭐ Example for adding angi SAPHanaController resource config to CIB ⭐

needs to be done once per Linux cluster. see manual page ocf_suse_SAPHanaController(7), SAPHanaSR_basic_cluster(7) and the SUSE setup guides.

🔥 Example for setting SAPHanaController resource out of maintenance 🔥

first the SAPHanaController multi-state resource gets refreshed, then it gets set out of maintenance. name of the resource is mst_SAPHanaController_HA1_HDB00. ofc the status of the cluster, HANA and system replication needs to be checked before and after this action — see the example further up. needs to be done once per Linux cluster. see also manual page SAPHanaSR_maintenance_examples(7).

note: the srHook status for the HANA secondary site might be empty. that's a thing that happens, it's not you.
# crm resource refresh mst_SAPHanaController_HA1_HDB00
# crm resource maintenance mst_SAPHanaController_HA1_HDB00 off

💜 Example for testing RA on secondary site and trigger susHanaSR.py 💜

this step is optional. the secondary node gets determined from SAPHanaSR-showAttr. on that node, hdbnameserver gets killed. the cluster will recover the secondary HANA and set the CIB attribute srHook. and ofc the status of the cluster, HANA and system replication needs to be checked.

# SECNOD=$(SAPHanaSR-showAttr --format script |\
  awk -F"/" '$1=="0 Host"&&$3=="score=\"100\"" {print $2}')
# echo $SECNOD
# ssh root@$SECNOD "hostname; killall -9 hdbnameserver"

📁 FILES 💖

okay bestie, here's where all the important little files live — memorize the paths, not me having to tell you twice ✨

  • /etc/sudoers.d/SAPHanaSR — the recommended spot for sudo permissions for the HADR provider hook scripts. put it there, thank me later 💅
  • /usr/sbin/, /usr/bin/ — path to tools before the upgrade, and after the upgrade. yes, both. the glow-up moves things around 🦋
  • /hana/shared/$SID/global/hdb/custom/config/global.ini — the on-disk representation of the HANA global system configuration. this is the main character file fr fr 👑
  • /usr/share/SAPHanaSR/samples/global.ini — template for the classical scale-up SAPHanaSR.py entry in global.ini 🌸
  • /usr/share/SAPHanaSR-ScalOut/samples/global.ini — template for the classical scale-out SAPHanaSrMultiTarget.py entry in global.ini 💜
  • /usr/share/SAPHanaSR-angi/samples/global.ini_susHanaSR — template for the susHanaSR.py entry in global.ini. the new-era template, iconic ✨
  • /usr/share/SAPHanaSR-angi/samples/SAPHanaSR-upgrade-to-angi-demo — an unsupported script for demonstrating the procedure on a test cluster. test cluster only, bestie — do not bring this to production 😭

✅ REQUIREMENTS 🎀

before you even think about starting, vibe-check all of these:

  • OS, Linux cluster and HANA are matching requirements for SAPHanaSR, or SAPHanaSR-ScaleOut respectively, and SAPHanaSR-angi. all of them. matching. no mix-and-match chaos 🙈
  • The resource configuration matches a documented setup. Even if the general upgrade procedure is expected to work for customised configuration, details might need special treatment. so like… custom is fine, but pay attention 🔥
  • The whole upgrade procedure is tested carefully and documented in detail before being applied on production. test it, write it down, then do it for real. periodt 💅
  • Linux cluster, HANA and system replication are in sane state before the upgrade. All cluster nodes are online. sane state is the whole vibe check 🫶
  • The HANA database is idle during the upgrade. No other changes on OS, cluster, database or infrastructure are done in parallel to the upgrade. one thing at a time, bestie — multitasking is not the move here 💀
  • Linux cluster, HANA and system replication are checked and in sane state before set back into production. check again before you let it back out into the world 🌈

🐛 BUGS 🍓

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

like, if something's broken fr, open that request — and if you just have thoughts, the feedback inbox is right there 💌

👀 SEE ALSO 🦋

go read these too, no cap:

iykyk — that last one is literally the towards zero downtime tag, obsessed 🔥

✍️ AUTHORS 💜

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

(c) 2024-2026 SUSE LLC

This maintenance examples are coming with ABSOLUTELY NO WARRANTY.

For details see the GNU General Public License at http://www.gnu.org/licenses/gpl.html

and that's the whole page, bestie 🎀 this was SAPHanaSR_upgrade_to_angi(7), dated 05 Jan 2026 — go forth and upgrade responsibly, mwah 💋✨

📦 where this page comes from