Automating the Migration of SAP Workloads from SUSE Linux Enterprise Server to Red Hat Enterprise Linux
Start course
2h 10m

This course covers Ansible automation for SAP. We'll start off with introductions to both SAP and Ansible and then we'll present the use cases of automation with Ansible that we have built for SAP. You'll then be guided through a demonstration of an end-to-end deployment of SAP HANA and SAP applications like NetWeaver and S4/HANA.

Learning Objectives

  • Learn the fundamentals of what SAP and Ansible are and how they work
  • Learn how to patch SAP landscapes
  • Understand SAP HANA and SAP Netweaver maintenance
  • Automate the deployment of SAP S/4HANA databases with Ansible Tower
  • Automate the creation of SAP HANA and SAP S/4HANA Pacemaker Clusters
  • Automate the migration of SAP workloads from SUSE Linux Enterprise Server to Red Hat Enterprise Linux
  • Learn how to carry out SAP Application Server Autoscaling

Intended Audience

This course is intended for anyone who wants to learn how to learn how Ansible automation can be used with their SAP workloads.


To get the most from this course, you should have basic knowledge of Ansible and SAP.


Another very interesting use case for SAP with Ansible that's generating a lot of interest in customers, mostly in customers that are migrating and re-platforming their SAP environments to the cloud is the solution around the migration of SAP workloads with Ansible.

So, this solution is about migrating SAP workloads, so HANA and S/4HANA or Netweaver in general from SUSE Linux to Red Hat Linux. Okay! So, there's a solution that we have worked on to automate all this and to be able to achieve near zero downtime as well for the migrations. We're going to look at the strategy and the architecture and how we've managed to do this.

So, the foundations of the strategy are the SAP HANA system replication because we are going to create the new system with this feature of our native SAP HANA feature and the Ansible that's going to orchestrate all the process.

So here we have some more details about the HANA system replication, is based on having two nodes. If we have to scale up SAP HANA installation and then the primary node will be replicating all the changes, all the logs will be sent across to the secondary side to the other node that is running HANA. It's for those of you who know Oracle data card is similar to that or a SQL server log shipping. So it's a similar mechanism to that.

It has different modes so the replication can be asynchronous. So that means that the primary database will send across the logs and it won't wait for a confirmation of the secondary to keep performing transactions then we have synchronous. So the primary will wait till the secondary has not only received the logs but persistent them to the disks because we need to remember that SAP HANA is in memory database. So as soon as the logs are sent across and received in memory we can say that both databases are in sync but in this whole synchronous mode, this primary will wait till the secondary has persisted as the logs or the changes to the to the disks and then we have synchronous in memory. So, the replication will be deemed as successful as soon as the locks are received in memory and not persisted. Okay! so that being said this is the architecture that we have used for this solution. So we have a source SAP system with an SAP HANA database and an S/4HANA or SAP Netweaver in general application server. So, what we are going to do is to build the same structure but on RHEL and we are going to use Ansible Tower as well. So, we will need two servers, the two source servers and three target servers. So, two for the actual migration and one for the installation of tower. This is optional because we can run this from the command line from the bootstrap server and do it, I mean launch the playbooks manually but the best solution and the way to control it at its best is used by using Ansible Tower.

So, here we can see the steps one by one. At this point we have installed provision. The machines and install the RHEL operating system on this side. So, we just registered with subscription manager as we've said those two servers, so to the right channels for SAP.

Then we are creating the file systems for the installation of the HANA database here. So, we can see as we saw in the previous videos the HANA is shared with the server will be installed and all the binaries will reside the HANA data for all the data files all the database and the HANA logs for all the transaction logs and then in the application server we will just create the user's app for the installation. Now we will apply the SAP nodes. So that means sap-preconfigure and sap-hana-preconfigure on the database server and  sap-preconfigure and sap-netweaver-preconfigure on the application server. Now we will install the SAP Host Agent just on the database as we said.

We will install the HANA database in the RHEL server. At this moment it would be an empty database, right? We will install the application on the RHEL server for S/4HANA. It's just the same workflows that we've done in the other videos and now we will enable the system replication from the source database on SUSE Linux onto the database on RHEL. So, the database will be copied and will have exactly the same data, same database schemas and everything as in the SUSE Linux source. Once it is done, we will failover and then and make this node be the same the primary of the system replication and once this is synchronized as well we will just disable the replication and then we will just have our target system up and running with the same data and same configuration as we had on SUSE Linux. As we said all this is performed with Ansible playbooks and roles. So, nothing is done manually and as you can see this, we are able to achieve near zero downtime with this because at any moment we aren't interrupting the connection between the source and the target. So, all the time during all this migration this the users will be connected to the source to the SUSE Linux and once we have synchronized the databases we will just failover the virtual IPs and move the redirection to here or yes so the users will be able to continue working.

As usual these are the Ansible roles used that are the same that we have used in the other videos to deploy HANA and S/4HANA to configure the System Replication and to create well here we're not using the pacemaker cluster but just installing and the database and the application and enabling the HANA System Replication.

So those are the links to the Github repositories where you can find all the code and you can download them and customize them to your to use them in your systems and here is a white paper that we have we have written explaining all the details of this solution.

So, yes I hope that this provides all the information that you need to try this yourself.

About the Author
Learning Paths

Jeremy is a Content Lead Architect and DevOps SME here at Cloud Academy where he specializes in developing DevOps technical training documentation.

He has a strong background in software engineering, and has been coding with various languages, frameworks, and systems for the past 25+ years. In recent times, Jeremy has been focused on DevOps, Cloud (AWS, Azure, GCP), Security, Kubernetes, and Machine Learning.

Jeremy holds professional certifications for AWS, Azure, GCP, Terraform, Kubernetes (CKA, CKAD, CKS).