Prep your RHEL systems for SAP installations using RHEL system roles

Red Hat Enterprise Linux (RHEL) has always distinguished itself with features that make supporting the Linux platform easier and more efficient for administrators. Freeing up system administrator time so they can focus on other work is a win-win for both Red Hat and our customers. One of these features that we spend a lot of time on is Red Hat Enterprise Linux system roles.

RHEL is more than just a platform on which to deploy your SAP applications. With Red Hat Enterprise Linux for SAP Solutions customers receive access to SAP workload-specific RHEL system roles, which simplify and help speed up the setup of SAP environments, such as SAP HANA on RHEL within a RHEL high availability (HA) cluster. And, let’s face it, planning for and deploying critical workloads like SAP HANA and Netweaver can otherwise be a daunting task. Like other important applications, these need a reliable operating system and usually have a lot of fine-tuning and performance requirements that need to be deployed on that operating system.

Luckily, in the case of SAP’s products, some of the work is done for you. RHEL is one of the few certified platforms for both HANA and Netweaver. SAP also does a great job of publishing those tunings and recommendations in their Notes knowledgebase. Deploying them can still feel overwhelming though and RHEL system roles can help with that.

If you’re like me, any time you can hand that sort of repeatable work off to automation, it's a real win. You can save yourself (or your administration staff) time and effort, while making sure that all of your SAP systems are getting the same configuration changes applied to them in the same manner. That’s not only saving time, it's turning your fleet of systems into something a bit more predictable and reducing technical debt at the same time. Believe me, that’s the sort of thing that reduces unplanned downtime and lets everyone sleep better at night.

Automation is great, but in many cases it just means that instead of having to learn how to deploy your applications, you’re learning how to tell your automation tools how to deploy applications. Now, we’ve all heard those arguments, and that the time invested in building automation can repay you in time saved later. But what if you had a head start building out that automation?

RHEL system roles, a collection of Ansible roles included with RHEL, are that head start. And with your RHEL for SAP Solutions entitlement, you have access to a small set of SAP-specific roles that can help you prep your systems for, and even install, SAP’s applications. If you are looking to take your automation to the next level, you might also consider Red Hat Ansible Automation Platform, our enterprise automation suite.

In this article, I will show you how the general sap pre-configuration role can help lay the groundwork for your SAP Netweaver or HANA deployments with just a few lines in an Ansible Playbook. Keep in mind, however, that there are other roles in the collection.

• sap_general_preconfigure - Installs base packages, sets up repositories and applies general groundwork for a SAP deployment.
• sap_hana_preconfigure - Similar to the general_preconfigure role, but for HANA specific packages and configuration.
• sap_netweaver_preconfigure - Similar to the general_preconfigure role, but for Netweaver specific packages and configuration.
• sap_hana_install - A role for SAP HANA installation.
• sap_ha_pacemaker_cluster - Uses the ha_cluster role to configure a HA cluster for your SAP needs.
• sap_ha_install_hana_hsr - A role for SAP HANA System Replication Setup on 2 nodes.
• sap_swpm - A role for SAP software installation using SWPM.

So, let’s see how this works. I am going to show you an example of how the general pre-configuration role is used to prep a RHEL 9 system for a SAP deployment using a relatively simple inventory and Ansible Playbook. Bear in mind that I am intentionally keeping things simple here. You can leverage RHEL system roles via broader platforms such as Ansible Automation Platform, but that is not the focus of this article. This is also not an exhaustive how-to document, it is simply meant to be an example.

First, we need to make sure that we have the right repositories enabled, and then install the system role. You need the RHEL for SAP Solutions entitlement, and you’ll also have to enable the repository.

# subscription-manager repos --enable rhel-9-for-x86_64-sap-solutions-rpms 
# dnf install rhel-system-roles-sap

I will be running these playbooks against the system I am running them from, so my Ansible inventory just points to localhost.

# cat inventory
[servers]
127.0.0.1

 Your playbook tells your system role what options you’d like configured, enabled or disabled using Ansible variables. You can find the full documentation included with the system roles themselves in /usr/share/ansible/roles/<roleName>/README.md. The pre-configure role’s documentation is in /usr/share/ansible/roles/sap_general_preconfigure/README.md, and it outlines all of the various configuration variables at your disposal. Here are a few I’d like to call out.

• sap_domain - This is, of course, the SAP domain. This is required.
• sap_general_preconfigure_config_all - This tells the role whether it should just do all of its tasks (the default) or if you’d like to manually specify them. If you set this to no, the role doesn’t do much, so you’ll have to then look at the docs to find the tasks you do want the role to perform. There are two major tasks that the role performs if you set config_all to no:
  • sap_general_preconfigure_installation - This limits the scope to just installation tasks.
  • sap_general_preconfigure_configuration - This limits the scope to just configuration tasks.
  • There are also tasks that you can specifically call related to various SAP notes, like sap_general_preconfigure_1391070. You should look at the readme for more examples.
• sap_general_preconfigure_assert - This variable tells the role whether or not to run in assessment mode. This is a great way to see if your system is already ready for the next phase of deployment.
• sap_general_preconfigure_assert_ignore_errors - A related variable is the ignore_errors variable.  This tells the role not to fail if the assertions in the assessment fail.  With this set to yes, the role will finish its assessment even if items fail, giving you an entire report of the tasks that ran, not just up to the first error.

One last note. SAP runs with SELinux in permissive mode, and one of the tasks that the role will perform is to make that so. However, I’ve also found some cases where the role fails if SELinux is not permissive, so I have set my system to permissive already. Oh, and this role is best run on a new system, not one already running a workload. We also do not recommend running this against a system that is already running a production workload.

First, let’s run a playbook that just runs the assessment.

# cat sap-pre.yml
---
- hosts: all
  roles:
  - role: sap_general_preconfigure
	vars:
  	sap_domain: example.com
  	sap_general_preconfigure_assert: yes
  	sap_general_preconfigure_assert_ignore_errors: yes

 And let’s run it with our inventory from earlier.

# ansible-playbook -i ./inventory ./sap-pre.yml

The output from this is quite long, so here are some examples.

Here you can see it’s testing for required packages. 

TASK [sap_general_preconfigure : Assert that all required packages are installed]
*****************************************
failed: [127.0.0.1] (item=uuidd) => {
	"ansible_loop_var": "line_item",
	"assertion": "'uuidd' in ansible_facts.packages",
	"changed": false,
	"evaluated_to": false,
	"line_item": "uuidd",
	"msg": "FAIL: Package 'uuidd' is not installed!"
}

 Here it’s checking for SAP Notes that may apply to my system.

TASK [sap_general_preconfigure : Assert - List required SAP Notes]
********************************************************
ok: [127.0.0.1] => {
	"__sap_general_preconfigure_sapnotes_versions | difference([''])": [
    	{
        	"number": "3108316",
        	"version": "2"
    	},
    	{
        	"number": "1771258",
        	"version": "6"
    	}
	]
}

TASK [sap_general_preconfigure : Assert - Include configuration actions for required sapnotes] 
****************************
included: /usr/share/ansible/roles/sap_general_preconfigure/tasks/sapnote/assert-3108316.yml for 127.0.0.1 => (item={'number': '3108316', 'version': '2'})
included: /usr/share/ansible/roles/sap_general_preconfigure/tasks/sapnote/assert-1771258.yml for 127.0.0.1 => (item={'number': '1771258', 'version': '6'})

And of course at the end you get a play recap, you can see that this role performs a number of checks.

PLAY RECAP 
*******************************************************************************************************************
127.0.0.1              	: ok=86   changed=0	unreachable=0	failed=0	skipped=59   rescued=0	ignored=21

Now, we can run it for real just by removing that assert variable from the playbook.

# cat sap-pre.yml
---
- hosts: all
  roles:
  - role: sap_general_preconfigure
	vars:
  	sap_domain: example.com
  	#sap_general_preconfigure_assert: yes
  	#sap_general_preconfigure_assert_ignore_errors: yes
# ansible-playbook -i ./inventory ./sap-pre.yml

 Now the role will run through and actually perform the tasks it’s designed to do. Here are some examples:

Package installations:

TASK [sap_general_preconfigure : Ensure that the required package groups are installed, RHEL 7] 
******************************
skipping: [127.0.0.1]

TASK [sap_general_preconfigure : Ensure that the required package groups are installed, RHEL 8 and RHEL 9] 
*******************
changed: [127.0.0.1]

TASK [sap_general_preconfigure : Ensure that the required packages are installed] 
********************************************
changed: [127.0.0.1]

SAP Note being applied:

TASK [sap_general_preconfigure : Configure 3108316-8] 
************************************************************************
ok: [127.0.0.1] => {
	"msg": "SAP note 3108316 Step 8: Configure Linux Kernel Parameters"
}

TASK [sap_general_preconfigure : Set kernel parameters] 
**********************************************************************
changed: [127.0.0.1] => (item={'name': 'vm.max_map_count', 'value': '2147483647'})

TASK [sap_general_preconfigure : Reload kernel parameters from file '/etc/sysctl.d/sap.conf'] 
********************************
changed: [127.0.0.1]

TASK [sap_general_preconfigure : Display kernel parameters after setting kernel.pid_max] 
*************************************
ok: [127.0.0.1] => {
	"__sap_general_preconfigure_register_sap_conf_sysctl_p_output.stdout_lines": [
    	"vm.max_map_count = 2147483647"
	]
}

TASK [sap_general_preconfigure : Configure 3108316-9] 
************************************************************************
ok: [127.0.0.1] => {
	"msg": "SAP note 3108316 Step 9: Configure Process Resource Limits"
}

Basic filesystem structures:

TASK [sap_general_preconfigure : Configure - Create directory '/usr/sap'] 
****************************************************
changed: [127.0.0.1]

You can see how this system role can help you save time in standardizing and preparing your fleet for SAP workloads. You can learn more about RHEL system roles on the Introduction to RHEL System Roles page. If you would like more information on the RHEL For SAP solutions offering, you can read more in our documentation. Finally,  if you would like training for configuring and deploying SAP on RHEL using Ansible, the following courses are offered by Red Hat:

• Red Hat Ansible Automation for SAP
• Red Hat High Availability for SAP Solutions