Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
Showing results for 
Search instead for 
Did you mean: 
This is Part 4 of a blog series on Deploying SAP S/4HANA Systems Using The Red Hat Portfolio. Read Part III: Setting up Provisioning via Red Hat Satellite here.

Read the other chapters here:

[Part I – Overview] Deploying SAP S/4HANA Systems Using The Red Hat Portfolio
[Part II] Curating Content with Red Hat Satellite
[Part III] Setting up Provisioning via Red Hat Satellite
[Part V] Building an Execution Environment for Ansible Automation Platform
[Part VI] Setting Up an Inventory in Ansible Automation Platform
[Part VII] Setting Up Components for Ansible Automation Platform
[Part VIII] Provisioning a new SID with Ansible Automation Platform


Now that our lifecycle and content management platform is ready, we can switch gears over to Ansible Automation Platform and start building our automated process. First, let’s take a deep dive into the existing automation available today for provisioning and managing SAP systems, starting with the supported ansible collections we’ll want to leverage:
- redhat.satellite
- redhat.rhel_system_roles
- sap.rhel

This snippet of code should look familiar: it’s an example of a requirements file containing collections we’ll be consuming. First, the redhat.satellite collection allows us to use Ansible to integrate with Satellite, and contains 60+ modules we can use for satellite configuration, host management, content management, and much more. The module will allow us to describe to Satellite the system we want, and Satellite will go and provision the system. For example:
- name: provision system
username: admin
password: p4ssw3rd
name: sap-hana-1
hostgroup: rhel8.4
provision_method: bootdisk
build: yes
managed: yes
activation_keys: ak-hana-rhel8.4-non_production
start: ‘1’
cpus: 8
memory_mb: 73728
organization: red-hat-blog
location: red-hat-blog
delegate_to: localhost

This task takes our definition of a HANA system, complete with the system name, ip address, resources, etc, and provisions a new system via Satellite to match what we’ve defined. In this example I’ve hard-coded the values to match what we configured in Satellite previously, however these could also be variables we define elsewhere, say, in our Ansible Inventory in Ansible Controller...more on this later.

Next, the redhat.rhel_system_roles collection provides a stable and consistent way to configure systems according to variables we define. Instead of needing to understand timesync or storage configuration across various RHEL versions, this collection abstracts the individual tasks and allows us to simply define what we want. Let’s consider our HANA system from above: in addition to provisioning the system, we’ll also want to configure some storage for HANA, as well as configure a time source. By leveraging this collection, we can simply define what we want and let Ansible do the heavy lifting:
- name: configure HANA systems
- hana
# storage configuration
- name: sap
- sdb
- name: data
size: "128 GiB"
mount_point: "/hana/data"
state: present
- name: log
size: "100 GiB"
mount_point: "/hana/log"
state: present
- name: shared
size: "256 GiB"
mount_point: "/hana/shared"
state: present
- name: sap
size: "50 GiB"
mount_point: "/usr/sap"
state: present
# timesync information
- hostname:
iburst: yes
- hostname:
iburst: yes
- hostname:
iburst: yes
- hostname:
iburst: yes
- redhat.rhel_system_roles.timesync

This playbook demonstrates us defining what we want in the vars section, and then handing off the actual configuration tasks to the RHEL System Roles. I’ve fed in some common mount points used for HANA deployments.

Finally, we have the sap.rhel collection, which configures our systems according to the appropriate SAP Notes and Red Hat best practices. Instead of having to individually go through the SAP Notes and manually configure the systems, this collection handles all of the appropriate steps for us. This collection consists of three roles: preconfigure, netweaver_preconfigure, and hana_preconfigure. Consider the following playbook:
- name: preconfigure all SAP systems
- sap
- sap.rhel.preconfigure

- name: preconfigure netweaver systems
- netweaver
- sap.rhel.preconfigure

- name: preconfigure HANA systems
- hana
- sap.rhel.hana_preconfigure

While this playbook is short, it is extremely powerful: in these few lines of Ansible we’ve set up our systems according to all applicable SAP Notes and Red Hat best practices so our SAP systems will be as stable and performant as possible.

These collections get our systems ready to run SAP workloads, however we’re going to step further by consuming some additional roles that will allow us to install the various SAP components. These roles are not supported by Red Hat, but are supported by vibrant communities interested in the automation of SAP workloads using Ansible. Let’s take a look at our roles/requirements.yml file:
- name: redhat_sap.sap_hostagent
- name: redhat_sap.sap_hana_deployment
- name: redhat_sap.sap_s4hana_deployment
- name: sap-hana-hsr
- name: sap-hana-ha-pacemaker

For the installation side of our process, we’ll install the SAP Host Agent, run the HANA installation, configure HANA system replication, wrap HANA system with pacemaker, and finally install an S4 application server. These roles all take input variables that define what we want to install, as well as various configuration options provided during the installation processes, which we’ll define in a later section of this blog post series.

Stay tuned for Part 5: Building an Execution Environment for Ansible Automation Platform.


Josh Swanson is currently a Solution Architect for Red Hat.
Ted Jones is currently a SAP Architect for the Red Hat SAP Tech Alliance team.
Vivien Wang is currently an Ecosystem Partner Manager for the Red Hat Partner Engineering Ecosystem.