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.

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:

---
collections:
  - 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 redhat.satellite.host 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
  redhat.satellite.host:
    username: admin
    password: p4ssw3rd
    server_url: https://satellite.company.lcl
    name: sap-hana-1
    domain: josh.lab.msp.redhat.com
    hostgroup: rhel8.4
    provision_method: bootdisk
    ip: 10.15.121.50
    build: yes
    managed: yes
    activation_keys: ak-hana-rhel8.4-non_production
    compute_attributes:
      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
  hosts:
    - hana
  vars:
    # storage configuration
    storage_pools:
      - name: sap
        disks:
          - sdb
        volumes:
          - 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
    timesync_ntp_servers:
      - hostname: 0.rhel.pool.ntp.org
        iburst: yes
      - hostname: 1.rhel.pool.ntp.org
        iburst: yes
      - hostname: 2.rhel.pool.ntp.org
        iburst: yes
      - hostname: 3.rhel.pool.ntp.org
        iburst: yes
  roles:
    - redhat.rhel_system_roles.storage
    - 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
  hosts:
    - sap
  roles:
    - sap.rhel.preconfigure

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

- name: preconfigure HANA systems
  hosts:
    - hana
  roles:
    - 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:

---
roles:
  - name: redhat_sap.sap_hostagent
    source: https://galaxy.ansible.com
  - name: redhat_sap.sap_hana_deployment
    source: https://galaxy.ansible.com
  - name: redhat_sap.sap_s4hana_deployment
    source: https://galaxy.ansible.com
  - name: sap-hana-hsr
    src: https://github.com/jjaswanson4/sap-hana-hsr/archive/refs/tags/v1.3.0.tar.gz
  - name: sap-hana-ha-pacemaker
    src: https://github.com/jjaswanson4/sap-hana-ha-pacemaker/archive/refs/tags/v2.0.0.tar.gz

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 a Senior Technical Writer for the Red Hat SAP Tech Alliance team.