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.