[Part IV] Leveraging Ansible Collections and Upstream Roles

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 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 server_url: name: sap-hana-1 domain: hostgroup: rhel8.4 provision_method: bootdisk ip: 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: iburst: yes - hostname: iburst: yes - hostname: iburst: yes - hostname: iburst: yes roles: - - 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: - name: redhat_sap.sap_hana_deployment source: - name: redhat_sap.sap_s4hana_deployment source: - name: sap-hana-hsr src: - name: sap-hana-ha-pacemaker src:

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.