Orchestrated nZDM for SAP HANA with a single TakeOver

Using the powerful Custom Process engine, SAP Landscape Management (LaMa) delivers a lot of pre-built processes to automate operations for SAP HANA. One of the best examples is the “near Zero Downtime Maintenance for SAP HANA” operation which helps you perform maintenance or upgrade activities for your SAP HANA setup while taking care of the System Replication, as well as of users and applications.


While the operation’s focus is to help you performing maintenance activities on your Primary and Secondary SAP HANA system (or the OS below it for that matter), its overall definition ensures that after everything is done, the system setup looks the very same way it did before: For instance, the former Primary will be the new Primary and the former Secondary also becomes the new Secondary – with a working SAP HANA System Replication between them, as shown below:

During discussions and feedback sessions, some of you guys told us, that on your SAP HANA setup, a failback to the former Primary would not be necessary. You explained how your very own flavor of orchestrated nZDM for SAP HANA is expected to look like: As the TakeOver can be considered a critical part of the whole activity, it seems essential to some of you to only perform this once during the maintenance procedure (instead of twice and returning to the original state). In this scenario, the new roles would be switched, basically, ending up like this instead:

While the described above is not a fully pre-built process to perform nZDM activities for SAP HANA, however, SAP Landscape Management 3.0 SP03 allows for leveraging other pre-built processes for SAP HANA to achieve exactly this. Let me show you how.

In this example, we will use LaMa to be able to perform maintenance activities on both Primary and Secondary SAP HANA database instance of SAP system “BWP” while also taking care of the SAP application connected to it (in this scenario an SAP NetWeaver BW 7.40).

In the beginning, you start with a standard SAP HANA system replication setup – here with Primary and Secondary. When visualizing this setup with LaMa, it is expected to look something like the situation shown below. As you can see, the Primary is now running on a machine (OS) called “prod-blade-25” (highlighted in blue) while the Secondary runs on “prod-blade-26” (highlighted in grey). This is the situation which we will start from.

To kick off operations for this SAP HANA system, we need to get into the Operations section. The quickest way to do so is clicking “Show in Operations” below the system description in the right hand section of the screen.

Now all the components of SAP system “BWP” are shown together with all possible operations for those – as well as Mass Operations to be performed on multiple entities.

We will now start with the maintenance work on the Secondary. Therefore, we will use LaMa to “free” the Secondary so we can perform our maintenance tasks there. For the Secondary, we select the SAP HANA Process “Near Zero Downtime Maintenance” by navigating Operations > SAP HANA Processes > Near Zero Downtime Maintenance.

The operations in LaMa leveraging the Custom Process engine are always shown to the user before they can be kicked off. Here, we take a look at the Near Zero Downtime Maintenance: The Secondary will be left stopped in order for us to perform maintenance activities. Review the process and click execute…

… and also confirm our action, as we are always pretty sure of what we are doing, aren’t we? Okay, okay. I will try to spare you the “Confirm” stuff for the next ones. Oh, and yes: Don’t get yourself confused because of the notification calling it a “custom process”. These processes really are pre-delivered with LaMa, they are just defined using the Custom Process engine.

Now, the Near Zero Downtime Maintenance process is kicked off. For a more detailed view, you may click on the Details icon next to the progress bar…

… to end up in the Monitoring section with a detailed view on what’s going on.

LaMa will ensure that the Secondary is consistently stopped so we can perform our maintenance activities. Once the operation runs into “Waiting for User input” step, LaMa has told us that now it’s up to us to get our hands dirty.

Alright, then: We now do have the Secondary available to us and can now perform our maintenance activities. As I was able to experience over the past years, this is nothing you need me to educate you about

After the maintenance activities (or you, that is) have concluded, we can tell LaMa to return to the original state by clicking “Continue“. Like this, the Secondary will be started again as the target SAP HANA replication instance.

Yes, I’ve promised not to… however, this one is different: As LaMa is aware of what’s going on, we need to confirm that our Offline Maintenance is finished by clicking “OK“…

… in order to watch the operation succeed until it is fully finished.

Now let’s head back to Operations pane as things are about to get interesting now. As our maintenance activities on the Secondary are already performed successfully, we can now have our one and only Near Zero Downtime Takeover, to make this Secondary the new Primary. To do so, we kick off the corresponding process on the Secondary clicking “Operations > SAP HANA Processes > Near Zero Downtime Takeover“.

Again, the whole process is shown to us and we can kick it off clicking “Execute“. As promised, I will spare you the Confirmation dialogue.

As the Near Zero Downtime Takeover is being performed, we can either stay right here in the Operations section and watch or head over to the Monitoring section, optionally.

Now, our Secondary (running on “prod-blade-26“) has become the new Primary and the former Primary is stopped: A complete Takeover has been performed – handling the application in a near Zero Downtime fashion. Try not to mix this one up with the “hard” Takeover without any near Zero Downtime purpose.

Our goal is now to perform our maintenance activities on the old Primary and to make it the new Secondary afterwards. In order to do so, we first conduct the maintenance tasks as the system is now stopped and available for maintenance.

The old Primary is now expected to become the new Secondary, so that this maintenance activity really can be performed with a single Takeover switching the roles. Therefore, we want to execute the “Register Primary Tier as new Secondary Tier” process on the old Primary clicking “Operations > SAP HANA Processes > Register Primary Tier as new Secondary Tier“.

Now looking at the “Register Primary Tier as new Secondary Tier“, we can review this SAP HANA process before kicking it off clicking “Execute” and confirming again to watch it succeed and finish from either the Operations section of the Monitoring section.

After the last operation has finished successfully, all instances of this SAP system “BWP” are available again. Now let’s see what our final result looks like by visualizing it clicking “Show on > Overview – Visualization” or clicking the corresponding Icon.

As you can see, Primary and Secondary have now basically switched roles:

Well done! We have now performed Near Zero Downtime Maintenance activities on both Secondary and Primary with just a single Takeover, effectively switching the roles of Primary and Secondary.