Near-zero Downtime Maintenance for SAP HANA and SAP Netweaver
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 use case is for maintenances and for SAP maintenance in order to achieve near zero downtime.

So, the best example is when we have an application on SAP Netweaver, be it normal Netweaver, S/4 HANA or whatever connected to a HANA database because this solution is based on HANA in the system replication that is native to HANA. So what we have here is a cluster of HANA databases. So this is a scale-up configuration of HANA normal configuration with one database replicated to another database in real time with the HANA system replication and what we are going to do is to apply the patches operating system patches in one of the servers, then apply the patches on the other server and then they will be at the same level and with the recommendations and patches that we need. In this solution not only Ansible will be used but also satellite Red Hat Satellite we just mentioned, that is the tool Red Hat tool to control the life cycle of the servers and also the high availability add-on of Red Hat the pacemaker will be used.

In order to have this cluster that came failover automatically to one node or another. So, in the first step we will have as we said this HANA system here. The primary replicating to the secondary in real time with the system replication. Ideally we have built our system with Ansible this has been done with an end-to-end solution, one click solution and everything the system replication and the pacemaker cluster has been created automatically that we will see that in a later video. So then what we are going to do is first apply the operating system patches with satellite on the Secondary. Okay! So for that the update I mean the initial state the application the SAP NetWeaver is connecting to the database running on the primary. So, there's a virtual IP of the cluster the database cluster that is pointing the application to this database because it's the primary and the one that the application will be working with. So first of all, here we can see Ansible in satellite. So, all the products or all the solutions that are used here are have been represented with the as you can see the the logos and icons. So, here as we said first of all we are going to perform with satellite the patching of this server. Once it is done we need to patch the primary server. So, we will need to fail over this IP that will be done with the pacemaker. Pacemaker will take care of this virtual IP failover but that change from pacemaker will be triggered with Ansible playbook.

So, you can see this is a takeover, normally the takeover of the of this node as primary takes one or two seconds. So, making the most of a feature called Connectivity Suspend that comes with SAP NetWeaver. What will happen is that this change of IP will be transparent for the users and for the jobs that are running in SAP because for that amount of time that's very very very brief. The transactions that are being performed in the application site won't be committed to the database. So, the application tier will wait till the virtual IP has been moved to the secondary and it has connection again and then it will commit the transactions to the database. Okay! So, as you can see all these steps are performed by means of Ansible playbooks. Okay! and then once we have the virtual IP here pointing to the server, the Primary will be patched with satellite as we did with the Secondary server. When once this one becomes the primary, this direction of the system replication will be changed. So that all the changes, all the transactions are committed while the Prime, the former primary is being patched.

So, all those transactions are being committed in this database are being replicated to the former primary. So that when we fail over again we will have a consistency between the two databases and once this has been done we can either keep this as a primary or revert to the initial situation doing the same failing over the IP with using Ansible tables.

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).