- SAP Managed Tags:
This is Part 6 of a blog series on Deploying SAP S/4HANA Systems Using The Red Hat Portfolio. Read Part V: Building an Execution Environment for Ansible Automation Platform 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 IV] Leveraging Ansible Collections and Upstream Roles
[Part V] Building an Execution Environment for Ansible Automation Platform
[Part VII] Setting Up Components for Ansible Automation Platform
[Part VIII] Provisioning a new SID with Ansible Automation Platform
--
Arguably, one of the most powerful pieces of Ansible is the inventory. What may seem like just a list of systems can actually be an incredibly powerful source of information for our automation, where systems can be grouped in parent-child relationships, variables can be defined in multiple places and are automatically merged, and aliases can be assigned. Entries in an inventory can be members of one to many groups, so we have some real flexibility around grouping our systems and defining our variables.
In a very real sense, we’re going to leverage Infrastructure as Code methodologies to provision and manage our SAP systems. We’re going to use our inventory to define what we want our SAP landscape to look like, and then have Ansible provision our systems and deploy our application.
Let’s consider our architecture: we’re going to provision two SAP HANA systems and an SAP S4 application server. There’s already a few groupings we can see: first, all these systems are Red Hat Enterprise Linux based. Next, these systems are all SAP systems, and we can break them down further into HANA systems and netweaver systems. Under the HANA grouping we can further define what will be our primary system in HANA system replication, and what will be our secondary. Finally, these systems will all belong to one SID, which is another grouping. For today, we’ll be deploying just one SID, however a typical SAP landscape is comprised of many SIDs across many versions, and may span different instances, locations, and more. Setting up appropriate groups in an inventory can be very powerful when it comes to managing our SAP systems.
Let’s first set up an inventory for our SAP systems:
Within that inventory, let’s set up some groups:
Here we can see groups that mirror how we naturally group systems in an SAP landscape: there’s a group for netweaver systems, hana systems, production systems, etc. Some of these groups will be nested under other groups, whereas others won’t be. Let’s take a look at this differently, via yaml:
Here we can see how we nested our groups, and can start to visualize where our systems will fit in. Let’s consider a production HANA system that’s the secondary site in system replication:
We’ve defined the system as a member of two groups: secondary and production, stating explicitly that this system is a production system and a secondary system in system replication. If there are variables defined for those groups, they’ll be automatically applied. Implicitly, we’ve also defined it as an SAP system and a HANA system, which means we’ll inherit the variables from those groups as well. Should there be overlapping variables, the child group’s variables would override the parent group’s variables, allowing us to define our variables with general values, and then override later in children groups.
Now let’s put these groups to work: earlier we took a brief look at the roles and collections we’ll be using to do the provisioning, configuration, and application installation of our new SAP systems, however almost all of them require us to define some variables describing how we want our systems configured. For our sap group, which spans all of our SAP systems, let’s define the following variables:
Since we’ll want the SAP host agent installed on all systems and we run the sap_preconfigure role on all systems, we’ll define the required variables at a group level that encompasses all of our SAP systems.
Now, let’s continue defining variables, moving to the hana group:
Here we’ve defined a ton of information, let’s break down where these values get used:
What we’ve really done is built a definition of our hana systems: we want systems with 8 cores and 72GB of memory, with HANA installed, system replication set up, and a pacemaker cluster configured to manage HANA and system replication. A few more variables for system replication get defined in the child groups of hana: primary and secondary:
Now we’ve defined what our HANA system replication topology should look like, and are ready to deploy our new HANA instances. Let’s do the same for our application server:
These variables look similar to the ones we defined for HANA: what compute resources we’d like and some additional storage, however now we’ve defined what our S4HANA deployment should look like.
Once we’ve loaded our variables into Ansible Controller, we have a source of truth for our new SAP systems.
Stay tuned for Part 7: Setting Up Components of 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.
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 IV] Leveraging Ansible Collections and Upstream Roles
[Part V] Building an Execution Environment for Ansible Automation Platform
[Part VII] Setting Up Components for Ansible Automation Platform
[Part VIII] Provisioning a new SID with Ansible Automation Platform
--
Arguably, one of the most powerful pieces of Ansible is the inventory. What may seem like just a list of systems can actually be an incredibly powerful source of information for our automation, where systems can be grouped in parent-child relationships, variables can be defined in multiple places and are automatically merged, and aliases can be assigned. Entries in an inventory can be members of one to many groups, so we have some real flexibility around grouping our systems and defining our variables.
In a very real sense, we’re going to leverage Infrastructure as Code methodologies to provision and manage our SAP systems. We’re going to use our inventory to define what we want our SAP landscape to look like, and then have Ansible provision our systems and deploy our application.
Let’s consider our architecture: we’re going to provision two SAP HANA systems and an SAP S4 application server. There’s already a few groupings we can see: first, all these systems are Red Hat Enterprise Linux based. Next, these systems are all SAP systems, and we can break them down further into HANA systems and netweaver systems. Under the HANA grouping we can further define what will be our primary system in HANA system replication, and what will be our secondary. Finally, these systems will all belong to one SID, which is another grouping. For today, we’ll be deploying just one SID, however a typical SAP landscape is comprised of many SIDs across many versions, and may span different instances, locations, and more. Setting up appropriate groups in an inventory can be very powerful when it comes to managing our SAP systems.
Let’s first set up an inventory for our SAP systems:
Within that inventory, let’s set up some groups:
Here we can see groups that mirror how we naturally group systems in an SAP landscape: there’s a group for netweaver systems, hana systems, production systems, etc. Some of these groups will be nested under other groups, whereas others won’t be. Let’s take a look at this differently, via yaml:
---
all:
children:
production:
sap:
children:
hana:
children:
primary:
secondary:
netweaver:
Here we can see how we nested our groups, and can start to visualize where our systems will fit in. Let’s consider a production HANA system that’s the secondary site in system replication:
---
all:
children:
production:
hosts:
sapddhdb2.josh.lab.msp.redhat.com:
sap:
children:
hana:
children:
secondary:
hosts:
sapddhdb2.josh.lab.msp.redhat.com:
We’ve defined the system as a member of two groups: secondary and production, stating explicitly that this system is a production system and a secondary system in system replication. If there are variables defined for those groups, they’ll be automatically applied. Implicitly, we’ve also defined it as an SAP system and a HANA system, which means we’ll inherit the variables from those groups as well. Should there be overlapping variables, the child group’s variables would override the parent group’s variables, allowing us to define our variables with general values, and then override later in children groups.
Now let’s put these groups to work: earlier we took a brief look at the roles and collections we’ll be using to do the provisioning, configuration, and application installation of our new SAP systems, however almost all of them require us to define some variables describing how we want our systems configured. For our sap group, which spans all of our SAP systems, let’s define the following variables:
---
sap_preconfigure_modify_etc_hosts: true
sap_domain: josh.lab.msp.redhat.com
sap_hostagent_installation_type: rpm
sap_hostagent_rpm_remote_path: /software/SAPHOSTAGENT
sap_hostagent_rpm_file_name: saphostagentrpm_44-20009394.rpm
sap_preconfigure_fail_if_reboot_required: false
sap_preconfigure_selinux_state: permissive
Since we’ll want the SAP host agent installed on all systems and we run the sap_preconfigure role on all systems, we’ll define the required variables at a group level that encompasses all of our SAP systems.
Now, let’s continue defining variables, moving to the hana group:
---
cpus: 8
memory_mb: 73728
application: hana
os: rhel8.4
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
sap_hana_deployment_bundle_path: /software/HANA_installation
sap_hana_deployment_bundle_sar_file_name: IMDB_SERVER20_046_0-80002031.SAR
sap_hana_deployment_sapcar_path: /software/SAPCAR
sap_hana_deployment_sapcar_file_name: SAPCAR_1010-70006178.EXE
sap_hana_deployment_root_password: '{{ ansible_password }}'
sap_hana_deployment_sapadm_password: '{{ ansible_password }}'
sap_hana_deployment_hana_instance_number: '00'
sap_hana_deployment_hana_env_type: development
sap_hana_deployment_hana_mem_restrict: 'n'
sap_hana_deployment_common_master_password: '{{ ansible_password }}'
sap_hana_deployment_sidadm_password: '{{ ansible_password }}'
sap_hana_deployment_hana_db_system_password: '{{ ansible_password }}'
sap_hana_deployment_ase_user_password: '{{ ansible_password }}'
sap_hana_deployment_apply_license: false
sap_hana_hsr_hana_instance_number: '00'
sap_hana_hsr_hana_db_system_password: '{{ ansible_password }}'
sap_hana_preconfigure_fail_if_reboot_required: false
sap_hana_deployment_hana_sid: DS4
sap_hana_hsr_hana_sid: DS4
sap_hana_hsr_hana_primary_hostname: sapddhdb1
sap_hana_hsr_full_primary_hostname: sapddhdb1.josh.lab.msp.redhat.com
sap_hana_hsr_full_secondary_hostname: sapddhdb2.josh.lab.msp.redhat.com
sap_hana_ha_pacemaker_hana_sid: DS4
sap_hana_ha_pacemaker_hana_instance_number: '00'
sap_hana_ha_pacemaker_vip: 10.15.121.43
sap_hana_ha_pacemaker_hacluster_password: '{{ ansible_password }}'
sap_hana_ha_pacemaker_node1_fqdn: sapddhdb1.josh.lab.msp.redhat.com
sap_hana_ha_pacemaker_node2_fqdn: sapddhdb2.josh.lab.msp.redhat.com
sap_hana_ha_pacemaker_node1_ip: 10.15.121.41
sap_hana_ha_pacemaker_node2_ip: 10.15.121.42
sap_s4hana_deployment_db_host: sapddhdb.josh.lab.msp.redhat.com
Here we’ve defined a ton of information, let’s break down where these values get used:
- cpu/memory: Used when we tell Satellite to provision our new instance
- storage_pools: Used by the RHEL system role to configure local storage
- sap_hana_deployment: Used by the sap-hana-deployment role to install HANA
- sap_hana_hsr: Used by the sap-hana-hsr role to configure system replication
- sap_hana_ha_pacemaker: Used by the sap-hana-ha-pacemaker role to configure pacemaker with system replication
What we’ve really done is built a definition of our hana systems: we want systems with 8 cores and 72GB of memory, with HANA installed, system replication set up, and a pacemaker cluster configured to manage HANA and system replication. A few more variables for system replication get defined in the child groups of hana: primary and secondary:
---
sap_hana_hsr_role: primary
sap_hana_hsr_alias: DC1
Now we’ve defined what our HANA system replication topology should look like, and are ready to deploy our new HANA instances. Let’s do the same for our application server:
---
os: rhel8
cpus: 4
memory_mb: 16384
additional_storage:
- size: 100Gb
type: thin
scsi_controller: 0
unit_number: 1
storage_pools:
- name: sap
disks:
- sdb
volumes:
- name: sap
size: 50 GiB
mount_point: /usr/sap
state: present
- name: sapmnt
size: 20 GiB
mount_point: /usr/sapmnt
state: present
- name: swap
size: 20 GiB
state: present
sap_s4hana_deployment_sid: DS4
sap_s4hana_deployment_db_host: sapddhdb.josh.lab.msp.redhat.com
sap_s4hana_deployment_db_sid: DS4
sap_netweaver_preconfigure_fail_if_not_enough_swap_space_configured: false
sap_s4hana_deployment_product_id: 'NW_ABAP_OneHost:S4HANA1909.CORE.HDB.ABAP'
sap_s4hana_deployment_sapcar_path: '/software/{{ sap_s4hana_deployment_sid }}'
sap_s4hana_deployment_sapcar_file_name: SAPCAR_1010-70006178.EXE
sap_s4hana_deployment_swpm_path: /software/S4HANA_installation
sap_s4hana_deployment_swpm_sar_file_name: SWPM20SP04_6-80003424.SAR
sap_s4hana_deployment_db_schema_password: '{{ ansible_password }}'
sap_s4hana_deployment_db_schema_abap_password: '{{ ansible_password }}'
sap_s4hana_deployment_master_password: '{{ ansible_password }}'
sap_s4hana_deployment_hana_systemdb_password: '{{ ansible_password }}'
sap_s4hana_deployment_hana_instance_nr: '00'
sap_s4hana_deployment_hana_system_password: '{{ ansible_password }}'
sap_s4hana_deployment_parallel_jobs_nr: '30'
sap_s4hana_deployment_db_sidadm_password: '{{ ansible_password }}'
sap_s4hana_deployment_igs_path: /software/S4HANA_installation
sap_s4hana_deployment_igs_file_name: igsexe_9-80003187.sar
sap_s4hana_deployment_igs_helper_path: /software/S4HANA_installation
sap_s4hana_deployment_igs_helper_file_name: igshelper_17-10010245.sar
sap_s4hana_deployment_kernel_dependent_path: /software/S4HANA_installation
sap_s4hana_deployment_kernel_dependent_file_name: SAPEXEDB_201-80003385.SAR
sap_s4hana_deployment_kernel_independent_path: /software/S4HANA_installation
sap_s4hana_deployment_kernel_independent_file_name: SAPEXE_201-80003386.SAR
sap_s4hana_deployment_software_path: /software/S4HANA_installation
sap_s4hana_deployment_sapadm_password: '{{ ansible_password }}'
sap_s4hana_deployment_sap_sidadm_password: '{{ ansible_password }}'
These variables look similar to the ones we defined for HANA: what compute resources we’d like and some additional storage, however now we’ve defined what our S4HANA deployment should look like.
Once we’ve loaded our variables into Ansible Controller, we have a source of truth for our new SAP systems.
Stay tuned for Part 7: Setting Up Components of 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.
