sapconf – A way to prepare a SLES system for SAP workload – Part 3

This is the third article about sapconf and it will cover the update from a previous (not reworked) version to a reworked one.

NOTE: For further documentation check SAP note 1275776 and the man pages shipped with sapconf.

sapconf 4 → sapconf 5

This is the only comment about sapconf 5 I have added to this post.

The original post describes the update to the reworked version we released over 2 years ago. I have to assume that everybody who uses sapconf runs the reworked version 4 by now. An update from version 3 to 5 should work, but we haven’t tested it.

Therefore let me go a bit deeper into the update from 4 to 5:

An update on SLES 12:

# zypper update sapconf
...
Updating /etc/sysconfig/sapnote-1680803...
Updating /etc/sysconfig/sapnote-bobj...
Updating /etc/sysconfig/sapconf...
Updating /etc/security/limits.conf...
File '/etc/systemd/logind.conf.d/sap.conf' already exists, nothing to do.

The first two messages are about updates for the ‘ase’ and ‘bobj’ profiles. Both files contain now everything that was handled by tuned which is not used anymore.
The third line is about the main configuration file /etc/sysconfig/sapconf. Also everything that has been in the tuned configuration before has been moved to this file now.
The next one is about removing the nofile block in /etc/security/limits.conf. With sapconf 5 a drop-in /etc/security/limits.d/sapconf-nofile.conf will be created on start and removed on stop. This is much cleaner.
And finally the last one is about the infamous drop-in to set UserTasksMax to infinity.

If you look at update on SLES 15, you will see much less:

Updating /etc/sysconfig/sapconf ...
Updating /etc/security/limits.conf...

Profiles does not exist anymore, therefore only one configuration file /etc/sysconfig/sapconf exists.
Also the limits entry became dynamic on SLES 15 as well.
With the latest systemd packages the drop-in to set UserTasksMax is not necessary anymore. TasksMax and UserTasksMax are infinity already.

If you have a customized tuned config for sapconf, additional messages will appear:

...
Updating /etc/sysconfig/sapconf line 'GOVERNOR=' with line 'GOVERNOR=performance' from /etc/tuned/sapconf/tuned.conf...
Updating /etc/sysconfig/sapconf line 'PERF_BIAS=' with line 'PERF_BIAS=performance' from /etc/tuned/sapconf/tuned.conf...
Updating /etc/sysconfig/sapconf line 'MIN_PERF_PCT=' with line 'MIN_PERF_PCT=100' from /etc/tuned/sapconf/tuned.conf...
Updating /etc/sysconfig/sapconf line 'FORCE_LATENCY=70' with line 'FORCE_LATENCY=20' from /etc/tuned/sapconf/tuned.conf...
Updating /etc/sysconfig/sapconf line 'IO_SCHEDULER="noop none"' with line 'IO_SCHEDULER=deadline' from /etc/tuned/sapconf/tuned.conf...
...

You can see, that all your changes are transferred from tuned to sapconf and are preserved!
The tuned configuration is removed completely, but you can find a copy in /var/lib/sapconf/saved_configs/.

Let me summarize the important facts here:

• Everything that was configured in tuned has now moved to sapconf configuration files.
• If you had a customized sapconf tuned profile, the changes have been moved too!
  Any additional entries sapconf can’t handle! Please create a custom tuned profile for them.

Updating

Normally updating a package is quiet simple. Non-configuration files are exchanged silently, configuration files only if you haven’t made any changes. If you did, the new version is saved with the suffix ‘.rpmnew’ and rpm outputs a comment to check the file.

Due to some major changes, it is not that easy with sapconf. Let me guide you thru an update and show you the bumps on the road.

I have put my virtual machine back into the state, where no sapconf was installed and now I will install the latest ‘old-fashioned’ version.

...
(reset vm...)
...
sles12-sp3:~ # zypper in sapconf-4.1.11-40.40.24
...
Updating /etc/sysconfig/sapconf...
Updating /etc/sysconfig/sapnote-1557506...
Updating /etc/sysconfig/sapnote-1680803...
...

There is one configuration file that we haven’t seen before: /etc/sysconfig/sapnote-1557506. It contains variables for the pagecache limit, which have been moved to /etc/sysconfig/sapconf. This is the reason that the file is not part of sapconf anymore.

For my first test I will leave the configuration unchanged and just update sapconf after a reboot.

sles12-sp3:~ # reboot
...
sles12-sp3:~ # zypper update sapconf
...
(1/1) Install: sapconf-4.1.12-40.47.1.noarch
...
Updating /etc/sysconfig/sapnote-1680803...
Updating /etc/sysconfig/sapconf...
Removing obsolete /etc/sysconfig/sapnote-1557506...
...
sles12-sp3:~ # grep sapconf /var/log/messages
...
2018-05-15T11:52:02.355283+02:00 sles12-sp3 systemd[1]: Reloading sapconf.
...

File /etc/sysconfig/sapnote-1557506 has been removed. The other ones have been updated.
Also the new configuration is applied immediately since sapconf has been restarted.

NOTE: If you have an unchanged sapconf configuration, updating to the re-worked version will install the new configuration and apply it immediately.

Let me try this again, but have something changed in the configuration files first. (Again I will leave out /etc/sysconfig/sapnote-1680803 because it belongs to the ASE profile that shouldn’t be used any longer.)

...
(reset vm and install the 'old' sapconf)
...
sles12-sp3:~ # vi /etc/sysconfig/sapconf
...
SHMALL_MIN=8000000
...
sles12-sp3:~ # vi /etc/sysconfig/sapnote-1557506
...
ENABLE_PAGECACHE_LIMIT="yes"
...
OVERRIDE_PAGECACHE_LIMIT_MB="500"
...

Now I update sapconf:

sles12-sp3:~ # zypper update sapconf
...
(1/1) Install: sapconf-4.1.12-40.47.1.noarch
...
Updating /etc/sysconfig/sapnote-1680803...
Updating /etc/sysconfig/sapconf...
Updating /etc/sysconfig/sapconf with line 'ENABLE_PAGECACHE_LIMIT="yes"' from /etc/sysconfig/sapnote-1557506...
Updating /etc/sysconfig/sapconf with line 'PAGECACHE_LIMIT_IGNORE_DIRTY="1"' from /etc/sysconfig/sapnote-1557506...
Updating /etc/sysconfig/sapconf with line 'PAGECACHE_LIMIT_MB="500"' from /etc/sysconfig/sapnote-1557506...
Removing obsolete /etc/sysconfig/sapnote-1557506...
...

The settings from /etc/sysconfig/sapnote-1557506 have been transferred to /etc/sysconfig/sapconf before the file was deleted.

WARNING: Due to a bug in sapconf-4.1.12-40.47.1 the configuration from /etc/sysconfig/sapnote-1557506 cannot be transferred to /etc/sysconfig/sapconf if you have commented-out variables in it (like: #ENABLE_PAGECACHE_LIMIT).
Remove them first!

What is about the SHMALL_MIN setting?

sles12-sp3:~ # grep SHMALL_MIN /etc/sysconfig/sapconf
sles12-sp3:~ # grep SHMALL /etc/sysconfig/sapconf
...
SHMALL=1152921504606846720

The value has not been transferred! The variable does not even exist anymore!
The rework of sapconf included a renaming of most of its variables.
Earlier versions never lowered a value, if the current one was higher than the configured one. This has been changed to give the admin full control about the settings in one place. Therefore variable names have been altered e.g. by removing the _MIN suffix.

Here an overview:

But the old configuration is not lost. The file has been moved away to /etc/sysconfig/sapconf.rpmsave. You should go thru that file and take the one you really need.

sles12-sp3:~ # ls /etc/sysconfig/sapconf*
/etc/sysconfig/sapconf  /etc/sysconfig/sapconf.rpmsave

Don’t forget a manually changed tuned.conf!
The profiles beneath /usr/lib/tuned/ will be overridden, but not the configuration in /etc/tuned/. Copy your old tuned.conf away, copy the new profile shipped with the updated sapconf and alter it to your needs!

By the way, if you have copied script.sh together wit the tuned.conf to /etc/tuned/ instead of altering the path in the past (something I told in the last article is a very bad idea), you will run into bigger trouble.
The old script can not handle the new variable names in /etc/sysconfig/sapconf and mostly nothing will work.
This shows how important it is to alter the path instead of simply copying the file. Sometimes the easiest way is not the best way to do something!

IMPORTANT: You have to transfer settings from your old configuration (/etc/sysconfig/sapconf.rpmsave) to the new one (/etc/sysconfig/sapconf) manually after an update to the re-worked sapconf version!
Use this opportunity to question old decisions.
If you have a manually altered tuned.conf please copy the new tuned.conf from the profile directory and change that one to your needs!

If you are verifying your configuration anyway, please use the chance to check that you set a system parameter on one place and one place only!
What do I mean by this? Sometimes there is more than one way to configure a system parameter. The performance behavior of a cpu can be set by some commandline parameters or with tuned. The MAX_MAP_COUNT can be set by an entry in /etc/sysctl.conf or a config file in /etc/sysctl.d/ or by sapconf.
If you choose sapconf as central your configuration tool, remove the other settings. Anything else will cause trouble, inconsistent system behavior and confusion.

NOTE: Avoid “multi-configuration” here. For some parameters handled by sapconf, other ways of configuration exist. Some can be configured by sysctl, others by boot parameters. Choose one way and stay consistent, else debugging can become difficult.

For a change this was a short article.
The next one will cover the unlikely possibility of a sapconf deinstallation. 😉

previous article: sapconf – A way to prepare a SLES system for SAP workload – Part 2

next article: sapconf – A way to prepare a SLES system for SAP workload – Part 4