Handover for the Next Round – SAP on SUSE Cluster and systemd Native Integration

SAP will enable the SAP Startup Framework for systemd. In short words the updated startup framework will be available for the SAP Host Agent, the SAP NetWeaver application server platform, the SAP S/4HANA ERP platform, and potentially later for the SAP HANA database as well. Here we discuss the benefits and the consequences for the SUSE cluster.

During a Linux workshop of the German SAP user group (DSAG) details of the integration have been shared with the attendees. If you have access to DSAG content you can find the slides at: Online-Session “SAP Software und systemd” am 03.02.2022 (AG Linux & MaxDB).

These changes also have effects on the SUSE cluster for SAP workloads. This blog informs about benefits of the new systemd integration and the changes needed for SUSE clusters. The native systemd integration needs some specific systemd functionality, so SLES 15 is the minimum version. On SLES 12 the native systemd integration is not available due to missing features within the systemd version. This blog focuses on SLES for SAP 15, because for the SUSE cluster solution you need additional packages which are only available on SLES for SAP.

Benefits of Native systemd Integration

Up to now for Linux the systemV init service “sapinit” was starting the SAP Host Agent and all sapstartsrv processes listed in /usr/sap/sapservices. A real systemd integration was not available, but only a compatibility mode using the systemV-to-systemd converter. This was a very loose integration and more used as a backward compatible solution. As systemd was going more and more mature the next step of a native integration was the next obvious move.

Using the native integration SAP Host Agent is started via the saphostagent.service unit. All systemd functionalities like checking the current status, starting, stopping and enablement for the next system boot are now available. Adaptations to the saphostagent.service unit must be done by adding a so called drop-in file.

For any native integrated SAP instance a systemd unit with name schema SAP<SID>_<INO> (e.g. SAPEN1_10) is added. Adaptations should never be done in the automatically generated unit file but in a systemd drop-in file. Also for SAP instances you now have the full functionality of systemctl commands. However it is highly recommended to still use the sapcontrol functions which guarantees also the functionality of cluster integration like the sap-suse-cluster-connector.

SAP has created a special slice named SAP.slice. All SAP related systemd services with the new, native integration are now running in this new slice. This allows better assignment of system resources. It also prevents that during an administrative or cluster action the service would be running in a user slice. This problem is now solved by the SAP.slice.

The former systemV init procedure is still available and “mixed-mode” systems are supported. So you could first roll out the SAP Host Agent native integration into systemd and follow-up with an update of the other SAP workloads.

Details of the SAP systemd integration and supported scenarios will be part of SAP’s documentation and are not part of this blog. The intention is to give you a heads-up about improvements and consequences.

Consequences for the SUSE Cluster

The good news first: The cluster configuration stays unchanged. SUSE updated the resource agents to get the native systemd integration transparent for the cluster administration.

SUSE has tested the native systemd integration of the SAP start framework for compatibility of the plain SLES system as well as for all relevant SUSE cluster scenarios for SAP workloads. In particular we have tested the availability of ASCS and ERS instances with a test list used for the SAP HA certifications and additional tests not covered by the certifications. SAP HANA system replication (SR) has been successfully tested in the following use cases: SAP HANA Scale-Up Performance Optimized, SAP HANA Scale-Up Cost Optimized and SAP HANA Scale-Out Performance Optimized. All improvements found during the test sessions will be available in maintenance updates for the SUSE cluster resource agents. Before you start your new installation or update to the native systemd integration make sure you update the resource agent packages to the newest available versions. The native SAP systemd integration is supported starting with the following package versions for SLES for SAP Applications 15.

For all SAPInstance-based cluster setups it is essential that the SAP<SID>_<INO>.service units are disabled. They must not start during boot before the cluster could control them. This ensures that the service is only running once in a cluster. For this kind of scenario we recommend the simple-mount architecture (First certified simple-mount cluster ever!) and to use the resource agent SAPStartSrv to make sure that each sapstartsrv service is only running once in a cluster. As before the coupling of the cluster with the SAP start framework using the sap-suse-cluster-connector is a must. In our example we have an SAP system EN1 with an ASCS instance using the instance number 00 and the ERS instance with number 10.

The command line tool systemctl provides the sub-commands “list-unit-files” and “status” to check the availability of the units, the disable-status for next system boot and the current status of the service itself:

# systemctl list-unit-files | grep SAP
SAPEN1_00.service disabled
SAPEN1_10.service disabled

# systemctl status SAPEN1_00.service SAPEN1_10.service
* SAPEN1_00.service - SAP Instance SAPEN1_00
Loaded: loaded (/etc/systemd/system/SAPEN1_00.service; disabled; vendor preset: disabled)
Active: inactive (dead)
* SAPEN1_10.service - SAP Instance SAPEN1_10
Loaded: loaded (/etc/systemd/system/SAPEN1_10.service; disabled; vendor preset: disabled)
Active: inactive (dead)

The native systemd integration entries in /usr/sap/sapservices are different from the classic systemV init entries:

# cat /usr/sap/sapservices
systemctl start SAPEN1_00 # sapstartsrv pf=/usr/sap/EN1/SYS/profile/EN1_ASCS00_sapen1as
systemctl start SAPEN1_10 # sapstartsrv pf=/usr/sap/EN1/SYS/profile/EN1_ERS10_sapen1er

For all SAPHanaSR* based cluster setups it is allowed to have SAP<SID>_<INO>.service units enabled, but the start of the SAP HANA database instance during boot must be disabled in the SAP instance profile.

For all SAP workloads in SUSE cluster the saphostagent.service must be enabled. The SAP Host Agent provides the list of SAP instances per SUSE cluster node.

What to Take With

The SUSE cluster is ready for your SAP workload for classic systemV init and modern native systemd services. As always you should follow our setup guides for the SAP workloads available at: SUSE Best Practices: SAP Applications. Our resource agents are shipped in RPM packages which also include helpful man pages (some of them in an extra doc sub-package). The command “apropos sap” will show you a list of very helpful and detailed man pages with a lot of hints, examples and requirements.

Please also read our other blogs about #TowardsZeroDowntime.