This is Part 3 of a blog series on Deploying SAP S/4HANA Systems Using The Red Hat Portfolio. Read Part II: Curating Content with 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 IV] Leveraging Ansible Collections and Upstream Roles
[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
--
For full lifecycle management of our SAP systems, we’re going to use Satellite to provision our new SAP systems. This will give us a common management plane across different compute landscapes, meaning we can easily manage our SAP systems regardless of if they run on premise or in a cloud provider.
For this blog post I’m going to use a VMware environment as my compute provider, and have set up the compute resource in Satellite:
I’ve also set up a general compute profile tied to the compute resource:
Note: 4 cores and 4gb of memory are insufficient for most SAP systems, however our compute profile serves as a base. We’ll override these settings later on when we tell Satellite to provision our new systems.
We’ll also want to set up a domain and subnet for provisioning our systems. First, our domain:
A quote note here: I’ve left the DNS Capsule option blank as I’m using an external DNS provider (in this case: Red Hat IDM). If you’re using DNS through Satellite, be sure to populate that dropdown.
Now, our subnet can be configured:
Another quick note here: for our Primary DNS Server I’ve entered the IP address of my Satellite server so our systems can locate Satellite as they’re kickstarting. After provisioning, this can safely be changed to other DNS servers.
Now that we have our provisioning pieces, we can tie them together in a hostgroup. On the first screen, we set our deployment and content sources:
As a best practice, I’ve set my lifecycle environment to production so my systems kickstart off the content my production systems are running. However, the activation key we specify can change this upon registration, meaning a system provisioned with a “non-production” activation key would kickstart off the production content, but then update to the content in non-production. I’ve also selected my compute resource and compute profile on this screen, and filled in my satellite as the content source.
On the network tab I’ve selected the domain and subnet we configured earlier:
And on the operating system tab I’ve selected the appropriate settings for building a RHEL8.4 system:
Remember: even though our systems will start out their existence as a generic RHEL8.4 system, our application servers will be registered and pointed at the latest RHEL8 content and NetWeaver packages while our HANA systems will be pointed at the RHEL8.4 E4S content by their activation key.
With these provisioning components configured, along with the curated content from part 2, we’ve now set Satellite up as our de-facto lifecycle and content-management platform for our SAP systems. Note that I’m running my SAP systems all on RHEL8, however this procedure is directly translatable to RHEL7 SAP systems, and will be applicable as newer versions of Red Hat Enterprise Linux become available.
Stay tuned for Part 4: Leveraging Ansible Collections and Upstream Roles.
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 IV] Leveraging Ansible Collections and Upstream Roles
[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
--
For full lifecycle management of our SAP systems, we’re going to use Satellite to provision our new SAP systems. This will give us a common management plane across different compute landscapes, meaning we can easily manage our SAP systems regardless of if they run on premise or in a cloud provider.
For this blog post I’m going to use a VMware environment as my compute provider, and have set up the compute resource in Satellite:
I’ve also set up a general compute profile tied to the compute resource:
Note: 4 cores and 4gb of memory are insufficient for most SAP systems, however our compute profile serves as a base. We’ll override these settings later on when we tell Satellite to provision our new systems.
We’ll also want to set up a domain and subnet for provisioning our systems. First, our domain:
A quote note here: I’ve left the DNS Capsule option blank as I’m using an external DNS provider (in this case: Red Hat IDM). If you’re using DNS through Satellite, be sure to populate that dropdown.
Now, our subnet can be configured:
Another quick note here: for our Primary DNS Server I’ve entered the IP address of my Satellite server so our systems can locate Satellite as they’re kickstarting. After provisioning, this can safely be changed to other DNS servers.
Now that we have our provisioning pieces, we can tie them together in a hostgroup. On the first screen, we set our deployment and content sources:
As a best practice, I’ve set my lifecycle environment to production so my systems kickstart off the content my production systems are running. However, the activation key we specify can change this upon registration, meaning a system provisioned with a “non-production” activation key would kickstart off the production content, but then update to the content in non-production. I’ve also selected my compute resource and compute profile on this screen, and filled in my satellite as the content source.
On the network tab I’ve selected the domain and subnet we configured earlier:
And on the operating system tab I’ve selected the appropriate settings for building a RHEL8.4 system:
Remember: even though our systems will start out their existence as a generic RHEL8.4 system, our application servers will be registered and pointed at the latest RHEL8 content and NetWeaver packages while our HANA systems will be pointed at the RHEL8.4 E4S content by their activation key.
With these provisioning components configured, along with the curated content from part 2, we’ve now set Satellite up as our de-facto lifecycle and content-management platform for our SAP systems. Note that I’m running my SAP systems all on RHEL8, however this procedure is directly translatable to RHEL7 SAP systems, and will be applicable as newer versions of Red Hat Enterprise Linux become available.
Stay tuned for Part 4: Leveraging Ansible Collections and Upstream Roles.
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.
- SAP Managed Tags:
