ocf_suse_SAPStartSrv(7)

πŸ“¦ version 0.9.6+git.1791548114.2a86b96, in opensuse-leap 16.0

✨ SAPStartSrv β€” ocf_suse_SAPStartSrv(7) ✨

πŸŽ€ NAME πŸŽ€

SAPStartSrv β€” manages sapstartsv for a single SAP instance as an HA resource.


🌸 SYNOPSYS 🌸

SAPStartSrv [ start | stop | status | monitor | meta-data | validate-all | usage ]

πŸ¦‹ DESCRIPTION πŸ¦‹

okay so bestie, SAPStartSrv is a resource agent for managing the sapstartsrv process for a single SAP instance as an HA resource. it's giving β€œone instance, one job” energy and honestly? iconic.

One SAP instance is defined by having exactly one instance profile. The instance profiles can usually be found in the directory /sapmnt/$SID/profile/. In an Enqueue Replication setup one (ABAP-) Central Services instance ((A)SCS) and at least one Replicated Enqueue instance (ERS) are configured. A Linux HA cluster can control these instances by using the SAPInstance resource agent. That resource agent depends on the SAP sapstartsrv service for starting, stopping, monitoring and probing the instances. The sapstartsrv needs to read the respective instance profile. By default one system-wide sapstartsrv is started at Linux boot time to provide the needed service for all SAP instances.

For specific Enqueue Replication setups using instance specific sapstartsrv processes might be desireable. So each SAP instance is managed on its own by a pair of one SAPStartSrv and one SAPInstance resource agent. SAPStartSrv starts sapstartsrv for one specific SAP instance. By intention it does not monitor the service. SAPInstance then utilises that service for managing the SAP instance. SAPInstance also is doing in-line recovery of failed sapstartsrv processes. The instance's virtual service IP address is used for contacting the sapstartsrv process. Thus that IP address resource (e.g. IPaddr2, aws-vpc-route53) needs to start before SAPStartSrv. no cap, order matters.

The described setup is benefitial particularly for public cloud and NFS-based environments. Both NFS shares with instance directories can be mounted statically on all nodes. The HA cluster does not need to control that filesystems. The /usr/sap/sapservices file is stored locally on each cluster node. highkey a whole vibe for cloud girlies.


πŸ’– SUPPORTED PARAMETERS πŸ’–

This resource agent supports the following parameters:

  • InstanceName β€” The full qualified SAP instance name. e.g. P01_DVEBMGS00_sapp01ci. Usually this is the name of the SAP instance profile. Unique, required, string, no default.
  • START_PROFILE β€” The name of the SAP START profile. Specify this parameter, if you have changed the name of the SAP START profile after the default SAP installation. Unique, optional, string, no default.

πŸ”₯ SUPPORTED ACTIONS πŸ”₯

This resource agent supports the following actions (operations):

  • start β€” Starts the sapstartsrv resource. Suggested minimum timeout: 60.
  • stop β€” Stops the sapstartsrv resource. Suggested minimum timeout: 60.
  • status β€” Performs a minimal status check of the sapstartsrv resource. Suggested minimum timeout: 60.
  • monitor β€” The SAPStartSrv resource must by intention not define a monitor operation. This is, because the failing sapstartsrv must never force a SAPInstance restart. That would happen because the two resources reside in one resource group.
  • validate-all β€” Performs a validation of the resource configuration. Suggested minimum timeout: 5.
  • meta-data β€” Retrieves resource agent metadata (internal use only). Suggested minimum timeout: 5.

🌈 RETURN CODES 🌈

The return codes are defined by the OCF cluster framework. Please refer to the OCF definition on the website mentioned below.

✨ EXAMPLES ✨

Okay bestie, this is the part where it all clicks πŸ’– These are real, copy-pasteable-ish cluster configs β€” every primitive, every meta attribute, every constraint, all of it. Take your time, this section is long but it's giving main character energy fr fr.


πŸŽ€ Example config for an SAP SCS instance resource group in an ENSA1 setup

So picture this: SAP system name is EN1, the SAP service is SCS, the SAP instance number is 00, and the SAP virtual hostname is sapen1as.

The SAPInstance monitor timeout you see below is a straight-up trade-off between fast recovery of the SCS vs. resilience against sporadic temporary NFS issues. You may slightly increase it to fit your infrastructure. Too short SCS monitor timeouts likely will conflict with the instance's internal recovery. The SAP instance profile needs to be adapted to make this work, no cap.

The also-needed ENSA1 ERS instance group and location constraint is shown in another example (scroll down bestie, it's there). See also manual page SAPStarrSrv_basic_cluster(7) and ocf_heartbeat_SAPInstance(7).

primitive rsc_ip_EN1_SCS00 IPaddr2 \
 params ip=192.168.1.112 \
 op monitor interval=10 timeout=20

primitive rsc_SAPStartSrv_EN1_SCS00 ocf:suse:SAPStartSrv \
 params InstanceName=EN1_SCS00_sapen1as

primitive rsc_sap_EN1_SCS00 SAPInstance \
 op monitor interval=11 timeout=60 on-fail=restart \
 params InstanceName=EN1_SCS00_sapen2as \
 START_PROFILE="/usr/sap/EN1/SYS/profile/EN1_SCS00_sapen1as" \
 AUTOMATIC_RECOVER=false MINIMAL_PROBE=true \
 meta resource-stickiness=5000 failure-timeout=60 \
 migration-threshold=1 priority=10

group grp_EN1_SCS00 \
 rsc_ip_EN1_SCS00 rsc_SAPStartSrv_EN1_SCS00 rsc_sap_EN1_SCS00 \
 meta resource-stickiness=3000

πŸ¦‹ Example config for an SAP ERS instance resource group in an ENSA1 setup

SAP system name is EN1, the SAP service is ERS, the SAP instance number is 10, and the SAP virtual hostname is sapen1er.

An IP address is configured as usual for on-premise use. If possible, the ERS instance should run on a different node than the ASCS (SCS) β€” like, please don't stack them πŸ™ˆ The SAP instance profile needs to be adapted to make this work.

The also-needed ENSA1 ASCS (SCS) instance group is shown in another example. If the ASCS (SCS) failed and is going to be recovered, it needs to move to the ERS node for restoring its lock table β€” that's the whole point, iykyk.

See also manual page SAPStarrSrv_basic_cluster(7) and ocf_heartbeat_SAPInstance(7).

primitive rsc_ip_EN1_ERS10 IPaddr2 \
 params ip=192.168.1.113 \
 op monitor interval=10 timeout=20

primitive rsc_SAPStartSrv_EN1_ERS10 ocf:suse:SAPStartSrv \
 params InstanceName=EN1_ERS10_sapen2er

primitive rsc_sap_EN1_ERS10 SAPInstance \
 op monitor interval=11 timeout=60 on-fail=restart \
 params InstanceName=EN1_ERS10_sapen2er \
 START_PROFILE="/usr/sap/EN2/SYS/profile/EN1_ERS10_sapen1er" \
 AUTOMATIC_RECOVER=false IS_ERS=true MINIMAL_PROBE=true \
 meta priority=1000

group grp_EN1_ERS10 \
 rsc_ip_EN1_ERS10 rsc_SAPStartSrv_EN1_ERS10 rsc_sap_EN1_ERS10

colocation col_sap_EN1_separate -5000: grp_EN1_ERS10 grp_EN1_SCS00

location loc_sap_EN1_failover_to_ers rsc_sap_EN1_SCS00 \
 rule 2000: runs_ers_EN1 eq 1

order ord_sap_EN1_scs_first Optional: rsc_sap_EN1_SCS00:start \
 rsc_sap_EN1_ERS10:stop symmetrical=false

🌸 Example config for an SAP ASCS instance resource group in an ENSA2 setup

SAP system name is EVA, the SAP service is ASCS, the SAP instance number is 00, and the SAP virtual hostname is sapeva.

A loadbalancer is used together with dedicated IP netmask configuration for specific public cloud environments (cloud girlies rise πŸ”₯). The SAPInstance has been given a fencing priority, and a crm property priority-fencing-delay is needed to make this work. See SAPStartSrv_basic_cluster(7).

The SAPInstance monitor timeout shown here is a trade-off between fast recovery of the ASCS vs. resilience against sporadic temporary NFS issues. You may slightly increase it to fit your infrastructure. Too short ASCS monitor timeouts likely will conflict with the instance's internal recovery. The SAP instance profile needs to be adapted to make this work.

The also-needed ERS instance group and location constraint is shown in another example. See also manual page SAPStartSrv_basic_cluster and ocf_heartbeat_SAPInstance(7).

primitive rsc_SAPStartSrv_EVA_ASCS00 ocf:suse:SAPStartSrv \
 params InstanceName=EVA_ASCS00_sapeva

primitive rsc_SAPInstance_EVA_ASCS00 SAPInstance \
 op monitor interval=11 timeout=60 on-fail=restart \
 params InstanceName=EVA_ASCS00_sapeva \
 START_PROFILE=/sapmnt/EVA/profile/EVA_ASCS00_sapeva \
 AUTOMATIC_RECOVER=false \
 MINIMAL_PROBE=true \
 meta resource-stickiness=5000 \
 priority=100

primitive rsc_IPaddr2_EVA_ASCS00 IPaddr2 \
 params ip=192.168.178.188 cidr_netmask=32

primitive rsc_Loadbalancer_EVA_ASCS00 azure-lb \
 params port=85085

group grp_EVA_ASCS00 \
 rsc_Loadbalancer_EVA_ASCS00 \
 rsc_IPaddr2_EVA_ASCS00 \
 rsc_SAPStartSrv_EVA_ASCS00 \
 rsc_SAPInstance_EVA_ASCS00 \
 meta resource-stickiness=3000

πŸ’œ Example config for an SAP ERS instance resource group in an ENSA2 setup

SAP system name is EN2, the SAP service is ERS, the SAP instance number is 10, and the SAP virtual hostname is sapeva.

An IP address is configured as usual for on-premise use. If possible, the ERS instance should run on a different node than the ASCS. The SAP instance profile needs to be adapted to make this work.

The also-needed ASCS instance group is shown in another example. See also manual page SAPStartSrv_basic_cluster and ocf_heartbeat_SAPInstance(7).

primitive rsc_SAPStartSrv_EN2_ERS10 ocf:suse:SAPStartSrv \
 params InstanceName=EN2_ERS10_sapen2er

primitive rsc_SAPInstance_EN2_ERS10 SAPInstance \
 op monitor interval=11s timeout=60s \
 params InstanceName=EN2_ERS10_sapen2er \
 START_PROFILE=/sapmnt/EN2/profile/EN2_ERS10_sapen2er \
 AUTOMATIC_RECOVER=false IS_ERS=true MINIMAL_PROBE=true

primitive rsc_IPaddr2_EN2_ERS10 IPaddr2 \
 params ip=192.168.178.187

group grp_EN2_ERS10 \
 rsc_IPaddr2_EN2_ERS10 \
 rsc_SAPStartSrv_EN2_ERS10 \
 rsc_SAPInstance_EN2_ERS10

colocation col_EN2_ASCS00_separate \
 -5000: grp_EN2_ERS10 grp_EN2_ASCS00

order ord_EN2_ASCS00_first \
 Optional: rsc_SAPInstance_EN2_ASCS00:start \
 rsc_SAPInstance_EN2_ERS10:stop \
 symmetrical=false

🧚 Example SAP ASCS instance profile adapted for an ENSA2 HA setup

SAP SID is EN2, the instance number is 00, the virtual hostname is sapen2er, and the service is _ENQ. Optionally you could limit the number of restarts of services β€” that is not done here tho.

The instance profile /sapmnt/EN2/profile/EN2_ASCS00_sapen2er is adapted like this:

# ... some more above
_ENQ = enq.sap$(SAPSYSTEMNAME)_$(INSTANCE_NAME)
Execute_04 = local rm -f $(_ENQ)
Execute_05 = local ln -s -f $(DIR_EXECUTABLE)/enq_server$(FT_EXE)
$(_ENQ)
Start_Program_01 = local $(_ENQ) pf=$(_PF)
# some more below ...

πŸ“ Example SAP ERS instance profile adapted for an ENSA2 HA setup

SAP SID is EN2, the instance number is 10, the virtual hostname is sapen2er, and the service is _ENQR. See also man page sap_suse_cluster_connector(8).

The instance profile /sapmnt/EN2/profile/EN2_ERS10_sapen2er is adapted like this:

# ... some more above
_ENQR = enqr.sap$(SAPSYSTEMNAME)_$(INSTANCE_NAME)
Execute_02 = local rm -f $(_ENQR)
Execute_03 = local ln -s -f
$(DIR_EXECUTABLE)/enq_replicator$(FT_EXE) $(_ENQR)
Start_Program_00 = local $(_ENQR) pf=$(_PF) NR=$(SCSID)
service/halib_cluster_connector =
/usr/bin/sap_suse_cluster_connector
service/halib = $(DIR_CT_RUN)/saphascriptco.so
# some more below ...

⭐ Handy one-liners (yes these are also examples, slay)

πŸ” Search for log entries of SAPStartSrv, show errors only

This is THE grep for when something smells off:

# grep "SAPStartSrv.*RA.*rc=[1-7,9]" /var/log/messages

πŸ’€ Show failcount for resource rsc_SAPStartSrv_EN2_ERS10

If the failcount exceeds the migration-threshold, the resource will be moved to another node. See SAPStartSrv_basic_cluster(7).

# cibadmin -Ql | grep rsc_SAPStartSrv_EN2_ERS10.*fail-count

πŸ‘‘ Manually trigger a SAPStartSrv probe action for instance ADA_ASCS00_engine

Output goes to the usual logfiles, bestie.

# OCF_ROOT=/usr/lib/ocf/ \
OCF_RESKEY_InstanceName=ADA_ASCS00_engine \
OCF_RESKEY_CRM_meta_interval=0 \
/usr/lib/ocf/resource.d/suse/SAPStartSrv monitor

πŸŽ€ FILES πŸŽ€

Every path you might need, spelled out:

  • /usr/lib/ocf/resource.d/suse/SAPStartSrv β€” the resource agent itself, the star of the show πŸ’…
  • /usr/lib/ocf/resource.d/heartbeat/SAPInstance β€” the also-needed SAP instance resource agent, package resource-agents
  • /usr/sap/$SID/$InstanceName/exe/ β€” default path for the sapstartsrv executable
  • /sapmnt/$SID/profile/ (resp. /usr/sap/$SID/SYS/profile/) β€” default path for DIR_PROFILE
  • /usr/sap/sapservices β€” SAP profiles definition file
  • /etc/sap_suse_cluster_connector β€” sap_suse_cluster_connector configuration, SLE-HA 12

more incoming, don't go anywhere πŸ’–

πŸŽ€ REQUIREMENTS πŸŽ€

okay bestie, before you even think about deploying this, there's a whole checklist and honestly you gotta respect it. Every single one of these is a hard vibe requirement, no cap:

  • Python 3.6 runtime environment or compatible. Yes, 3.6. She's vintage. She's iconic. She works.
  • At least SAP instances NW7.40 for ENSA1. At least NW7.52 or SAP S/4HANA ABAP Platform 1909 for ENSA2. (iykyk which one you're running πŸ’…)
  • SAPInstance resource agent with MINIMAL_PROBE support, November 2020.
  • Needed NFS shares (e.g. /sapmnt/$SID/, /usr/sap/$SID/) mounted statically or by automounter.
  • Directory /usr/sap/ locally read-write mounted on each cluster node.
  • Complete entries in /usr/sap/sapservices file.
  • SAP instance profile Autostart feature is disabled for ASCS (SCS) and ERS. Like, actually off. Not "kinda off".
  • For ENSA2 (ENSA1) HA setups, the ASCS or SCS instance profile entry for the enqueue service _ENQ (_EN), Restart_Program_xx is replaced by Start_Program_xx. Same for the ERS instance profile entry for the enqueue replicator service _ENQR (_ER). Other services stay untouched β€” do not touch them, they're doing fine 🫢
  • The sapinit boot script does not read entries from sapservices file at boot. Thus services sapping and sappong to handle sapservices file at system boot.
  • The sapinit script is not used while the HA cluster is running on any node.
  • SAP instance numbers controlled by the cluster must be unique. No duplicates, bestie, the cluster will simply not cope 😭
  • It is not allowed to block resources from being controlled manually. Thus BLOCK_RESOURCES in /etc/sap_suse_cluster_connector is not allowed anymore.
  • You need SAP hostagent installed and started on your systems. For SystemV style, the sapinit script needs to be enabled. For systemd style, the service saphostagent needs to be enabled and running. Instance services SAP${SID}_${INO} need to be disabled. The systemd enabled saphostagent and sapstartsrv is supported from sapstartsrv-resource-agents 0.9.1 onwards. An appropriate SAPInstance resource agent is needed, newer than November 2021. Please refer to the OS documentation for the systemd version. Please refer to SAP documentation for the SAP software version. Combining systemd style hostagent with SystemV style instance is allowed. However, all nodes in one Linux cluster have to use the same style. Pick one and commit, bestie 🌸
  • The SAPInstance RA regularly checks systemd integration. The SAPInstance monitor interval might be increased to reduce side effects in Multi-SID setups.
  • No firewall rules must block any needed port. πŸ”₯ (block the port and everything just ✨ stops✨)
  • No SELinux rules must block any needed action.
that's a lot, I know. read it twice. then read it again. this is one of those "the details are the whole personality" situations πŸ’€

πŸ’€ BUGS πŸ’€

okay so, honest moment πŸ™ˆ the trace_ra resource tracing feature is not implemented so far. Like, not even a little. So don't go looking for it and then @ me about it.

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 πŸ”—

the reading list, aka the lore, aka the required homework πŸ‘‘ everything here is a real reference, keep them all:


πŸ‘‘ AUTHORS πŸ‘‘

the literal main characters who made this happen, show some respect πŸ’–

X.Arbulu, F.Herschel, L.Pinne


(c) 2020-2026 SUSE LLC

The resource agent SAPStartSrv comes with ABSOLUTELY NO WARRANTY. (dramatic but true, bestie β€” no warranty, like at all πŸ™ˆ)

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


and that's the whole page, you made it to the end πŸŽ‰ slay. This was ocf_suse_SAPStartSrv(7), dated 12 Jun 2026, and honestly? she ate. go configure your cluster, bestie, you've got this πŸ’…βœ¨πŸ¦‹

πŸ“¦ where this page comes from