SAPStartSrv_u...lesystem_disk(7)

📦 version 0.9.6+git.1791548114.2a86b96, in opensuse-leap 16.0

💅 SAPStartSrv_upgrade_from_Filesystem_disk(7) — the SAPStartSrv glow-up, part 1 🦋

okay so bestie, buckle up — this is a manual page (section 7) for the `SAPStartSrv_upgrade_from_Filesystem_disk procedure, and it's literally the story of how you take an HA cluster for SAP central service instances from a Filesystem resource based setup with a shared disk and slide it over to the simple-mount setup. ✨

🌸 NAME 🌸

SAPStartSrv_upgrade_from_Filesystem_disk — upgrade from Filesystem on shared disk to SAPStartSrv 💫

🎀 DESCRIPTION 🎀

💖 What is the upgrade about?

So like, the whole thing is about upgrading an HA cluster for SAP central service instances from the Filesystem resource based setup with shared disk to the simple-mount setup. That's it. That's the vibe. 🫶

The upgrade is done in two phases:

1st: Changing the Filesystem based setup from shared disks to NFS shares — and that's exactly what this manual page is about, bestie, you're in the right place. 📍
2nd: Upgrading from the Filesystem based setup to the simple-mount setup — that one lives in SAPStartSrv_upgrade_from_Filesystem(7). 🦋

🔥 What will be changed?

Here's what gets changed during the 1st phase:

1.a SAP instance directories will be copied from shared disk to NFS shares. 1.b Filesystem resources and resource groups will be changed from shared disk to NFS shares.

And here's what gets changed during the 2nd phase (just so you know what's coming, no cap):

2.a Two systemd services sapping and sappong will be enabled. 2.b The SAP instance working directories for the enqueue service (ASCS) and the enqueue replicator (ERS) will be added to fstab on both cluster nodes, and mounted statically. 2.c The Filesystem resources for ASCS and ERS will be removed from the CIB. 2.d Instead, SAPStartSrv resources for ASCS and ERS will be added to the CIB.

⭐ How does the 1st phase look like at a glance?

The 1st phase consists of these steps, in this exact order, don't skip, don't shuffle 👑

1.1 Backing up the SAP instance directories.
1.2 Checking for clean state, collecting information.
1.3 Preparing shares on the central NFS server.
1.4 Setting the cluster into maintenance and saving the old CIB.
2.1 Stopping the ERS instance, not the resource group.
2.2 Copying the ERS instance directory to the NFS share on the other node.
2.3 Unmounting the disk-based ERS instance directory.
2.4 Adapting the Filesystem resource for ERS.
2.5 Removing non-needed storage stack resources for ERS.
2.6 Starting the ERS instance on the other node.

⚠️ heads up bestie — the next step will bring SAP central services DOWN. like, actually down. 😭

3.1 Stopping the ASCS instance, not the resource group.
3.2 Copying the ASCS instance directory to the NFS share on the other node.
3.3 Unmounting the disk-based ASCS instance directory.
3.4 Adapting the Filesystem resource for ASCS.
3.5 Removing non-needed storage stack resources for ASCS.
3.6 Starting the ASCS instance on the other node.
4.1 Getting the cluster out of maintenance and saving the new CIB.
4.2 Checking for clean state.
4.3 Testing the ERS instance (optional).

💀 a downtime is needed for both instances — the ASCS as well as the ERS. both. no way around it. plan for it, tell your people, put it in the calendar.

🌈 How does the 2nd phase look like at a glance?

Please refer to manual page SAPStartSrv_upgrade_from_Filesystem(7). That's a whole other vibe, go read it. 📖

🧚 What needs to be prepared upfront?

First things first: refresh your knowledge of the Filesystem resource based HA scenario. like, genuinely, go reread it before you touch anything. 🫡

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

Names of cluster nodes
Names of SAP instance directories
Names of shared disks, MD-Raid mirrors, VGs, LVs for the SAP instance directories
Names of NFS server and shares for the SAP instance directories, mount options
Names of Filesystem resources and resource groups
Deviation of configuration from setup guide, if existing
Matching with the REQUIREMENTS section below

Finally — prepare config templates with the correct values for the given cluster. Ideally you also have all the needed commands prepared in detail. yes, all of them. write them out. future you will be so grateful 💖

✨ EXAMPLES ✨

💅 Checking for clean state, collecting information

This information should be collected before starting the upgrade. See also SAPStartSrv_maintenance_examples(7).

To be done on one node for the whole cluster:

node1:~ # cs_show_ensa_status

node1:~ # crm configure show type:node

node1:~ # crm configure show type:primitive |\
 grep -e "primitive.*Filesystem" -e "primitive.*lvm" -e "primitive.*Raid1" \
      -e "primitive.*LVM-activate"

node1:~ # crm configure show type:group | grep group

To be done on each cluster node:

node1:~ # ls -l /usr/sap/EN2/SYS/ | awk '{print $9,$11}'
node1:~ # mount | awk 'TODO'
node1:~ # df -h /usr/sap/*

(yes, that awk 'TODO' is literally in here. work in progress energy, we love to see it 🙈)

🎀 Setting cluster in maintenance and saving old CIB

To be done on one node for the whole cluster.

node1:~ # crm maintenance on
node1:~ # crm_mon -1r | grep "Resource management"
node1:~ # crm configure show > /root/crm.filesystem-disk.backup
node1:~ # echo "property cib-bootstrap-options: stop-orphan-resources=false" |\
 crm configure load update -
node1:~ # crm configure show cib-bootstrap-options |\
 grep stop-orphan-resources

🦋 Stopping SAP instance, not resource group

To be done on the node where the SAP instance is running. ERS or ASCS instance.

Example is node node2, sidadm en2adm, instance number 10.

node2:~ # cs_show_ensa_status
node2:~ # su - en2adm -c 'sapcontrol -nr 10 -function Stop'
node2:~ # su - en2adm -c 'sapcontrol -nr 10 -function WaitforStopped'
node2:~ # crm resource refresh

💡 reminder: stop the instance, not the resource group. the resource group stays put. iykyk

To be done on the other node. ERS or ASCS instance.

Example is node node2, other node node1, SID EN2, instance ERS10, NFS server 192.168.1.1, NFS share /export/EN2/usr-sap/ERS10, mount options defaults.

node2:~ # ssh node1
node2:~ # cs_show_ensa_status
node1:~ # mount -t nfs 192.168.1.1:/export/EN2/usr-sap/ERS10 /usr/sap/EN2/ERS10/
node1:~ # mount | grep /usr/sap/EN2/ERS10/
node1:~ # rsync -va node2:/usr/sap/EN2/ERS10/* /usr/sap/EN2/ERS10/
node1:~ # find /usr/sap/EN2/ERS10/
node1:~ # exit

🔥 Unmounting disk-based SAP instance directory

To be done on the node where the SAP instance has been stopped manually. ERS or ASCS instance.

Example node node2, SID EN2, instance ERS10, VG TODO, MD-Raid array TODO.

node2:~ # cs_show_ensa_status
node2:~ # umount /usr/sap/EN2/ERS10/
node2:~ # mount | grep /usr/sap/EN2/ERS10/
node2:~ # find /usr/sap/EN2/ERS10/
node2:~ # vgchange -an TODO
node2:~ # lvs TODO
node2:~ # mdadm TODO
node2:~ # mdadm TODO

👑 Adapting Filesystem resource

To be done on one node for the whole cluster. ERS or ASCS instance.

Example resource is rsc_fs_EN2_ERS10, group grp_EN2_ERS10.

node1:~ # crm configure show type:group | grep group
node1:~ # TODO

⭐ Removing non-needed storage stack resources

To be done on one node for the whole cluster. ERS or ASCS instance.

Usual resources are Raid1 and lvm, also possible LVM-activate.

Example resources rsc_Raid1_EN2_ERS10 and rsc_lvm_EN2_ERS10, group grp_EN2_ERS10.

node1:~ # crm configure show type:Raid1
node1:~ # crm configure show type:lvm

node1:~ # crm configure show type:group
node1:~ # crm configure show type:group > /root/crm.grp_EN2_ERS10
node1:~ # sed -e s/rsc_Raid1_EN2_ERS10//g -e s/rsc_lvm_EN2_ERS10//g \
 -i /root/crm.grp_EN2_ERS10
node1:~ # crm configure load update /root/crm.grp_EN2_ERS10
node1:~ # crm configure show type:group

node1:~ # cibadmin --delete --xpath "//resource[@id='rsc_Raid1_EN2_ERS10']"
node1:~ # cibadmin --delete --xpath "//resource[@id='rsc_lvm_EN2_ERS10']"
node1:~ # crm configure show type:primitive |\
 grep -e "primitive.*Raid1" -e "primitive.*lvm"

⚠️ that cibadmin --delete is for real deleting things out of the CIB. double-check you backed up first, bestie. 🙏

💜 Starting SAP instance on other node

The instance will be started on the node where it has not been running before the stop, because the NFS share with the new SAP instance directory has been mounted there. ERS or ASCS instance.

Example node is node1, sidadm en2adm, instance number 10.

node2:~ # ssh node1
node1:~ # su - en2adm -c 'sapcontrol -nr 10 -function Start'
node1:~ # su - en2adm -c 'sapcontrol -nr 10 -function WaitforStarted'
node1:~ # crm resource refresh
node1:~ # exit

🍓 Getting cluster out of maintenance and saving new CIB

To be done on one node for the whole cluster.

node1:~ # echo "property cib-bootstrap-options: stop-orphan-resources=true" |\
 crm configure load update -
node1:~ # crm configure show cib-bootstrap-options |\
 grep stop-orphan-resources
node1:~ # crm resource refresh
node1:~ # crm configure show > /root/crm.filesystem.backup
node1:~ # crm maintenance off
node1:~ # cs_show_ensa_status

(notice we flipped stop-orphan-resources=false back to stop-orphan-resources=true there — iconic bookending, honestly 💅)

🧚 Testing the ERS instance (optional)

See manual page SAPStartSrv_upgrade_from_Filesystem(7).

🎀 FILES 🎀

/usr/sap/$SID/$Instance/ — SAP instance directories, f.e. /usr/sap/EN2/ASCS00/
/usr/sap/$SID/SYS/ — SAP system central local directory
/sapmnt/$SID/ — SAP system central shared NFS directory
/etc/lvm/lvm.conf — LVM configuration, if LVM-activate resources are used
/etc/mdadm.conf, /etc/mdadm.conf.localdevices, /clusterconf/$SID/mdadm.conf — MD-Raid configuration, if Raid1 resources are used
/etc/multipath/multipath.conf, /etc/multipath/bindings — multipath configuration, if MPIO is used

✨ REQUIREMENTS ✨

okay these are the non-negotiables, bestie, read them all 👇

Downtime for the SAP central services is needed for this procedure. like, mandatory. 🕐
OS, Linux cluster and SAP instances are matching requirements for the Filesystem resource based setup. No cluster volume manager (f.e. cLVM), no cluster filesystem (f.e. OCFS2) and no distributed lock manager (f.e. DLM) is used. none. zero. 🚫
The whole upgrade procedure is tested carefully and documented in detail before being applied on production. (yes. actually. no sending it in prod blind 🙈)
Linux cluster, SAP instances and enqueue replication are in sane state before the upgrade. All cluster nodes are online.
The SAP instances are idle during the upgrade. No other changes on OS, cluster, SAP instances or infrastructure are done in parallel to the upgrade. one thing at a time, periodt 💅
Password-less login for user root between cluster nodes. An upgrade is possible without, but would need adapted commands.
Only one SAP system (SID) per cluster. Only the ASCS and ERS instances. No dialog, diagnostic agent, webdispatcher, or other instances on the cluster nodes. An upgrade is possible with multiple SIDs or additional instances, but would need adapted commands.
Two nodes per cluster. An upgrade is possible with three nodes, but would need additional commands.
Linux cluster, SAP instances and enqueue replication are checked and in sane state before being set back into production. ✅
OS configuration for MPIO, MD-Raid and LVM is not changed. This is out of scope for the procedure at hand. hands off 🫶
See also the REQUIREMENTS section in SAPStartSrv_upgrade_from_Filesystem(7).

💀 BUGS 💀

This manual page is work in progress. 🚧

(it's giving "we'll finish it later" and honestly? relatable. part 2 of this page is right behind this one, so keep scrolling bestie 🦋)

👀 SEE ALSO 👀

okay bestie, here's the whole friend group — go say hi to all of them:

ocf_suse_SAPStartSrv(7)
ocf_heartbeat_Filesystem(7)
SAPStartSrv_basic_cluster(7)
SAPStartSrv_upgrade_from_Filesystem(7)
crm(8)
cibadmin(8)
crm_mon(8)
cs_show_ensa_status(8)
fstab(5)
mount(8)
vgchange(8)
mdadm(8)
awk(1)
sed(1)

and the reading list, i.e. the docs that actually explain the lore 💅:

seriously, if you're about to touch disks on a cluster node, go read those first. they ate, fr fr 🔥

💖 AUTHORS 💖

the icons who wrote this masterpiece:

F.Herschel, L.Pinne

give them their flowers, they earned them 🌸

⚖️ COPYRIGHT ⚖️

⚠️ real talk: SAPStartSrv comes with ABSOLUTELY NO WARRANTY. like, none. zero. the vibes are immaculate but the warranty is not included 😭

for the details, the full GNU General Public License is right here:

http://www.gnu.org/licenses/gpl.html

read it, bestie. it's giving responsible adult energy and honestly it's kind of iconic 👑

aaaand that's the whole page, you made it to the end!! 🎀🦋 go forth, mount those filesystems, and may your crm_mon always look cute 🌈

this was SAPStartSrv_u...lesystem_disk(7), dated 01 Oct 2026 — periodt, signing off 💅✨

📦 where this page comes from

opensuse-leap 16.0: sapstartsrv-resource-agents 0.9.6+git.1791548114.2a86b96-160000.1.1 · GPL-2.0
💖 girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on 2026-11-04: a language model's rewrite of the original, under its terms