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.