Application-Level Disaster Recovery: An Efficient Alternative for SAPinsiders

In the first part of this series, we tuned in to the webinar hosted by the leader in HA and DR services provider SIOS and explored how disaster recovery (DR) is often overlooked compared to high availability (HA) in SAP environments and how it is crucial to give thorough attention to DR because it ensures the continuity of operation and minimizes downside in the event of disasters.

One other aspect that was touched on in the webinar included the implementation of a site-wide DR recovery – and how it may not be the best option for cloud users due to its ‘all-or-nothing’ approach.

So, what options are available to SAPinsiders? As argued by Harry Aujla, SIOS partner alliances director, the alternative approach to a site-wide strategy is to think about DR at an application or database level.

Key differences and benefits

According to Aujla, because application-level DR is customizable compared to a site-wide DR, it offers flexibility that allows organizations to prioritize critical applications and allocate resources accordingly. Specifically, it gives you a guarantee that the most essential applications are recovered with the highest priority, reducing potential downtime and minimizing the impact on business operations. Considering the criticality of applications and data in systems like SAP S/4HANA, this kind of flexibility is crucial for its sustainability.

Additionally, application-level DR can be more scalable, Aujla explained: “[It] allows organizations to tailor their recovery strategies based on specific application requirements. So, again, it enables organizations to allocate their resources based on the criticality of each application, optimizing the overall recovery process.

“Focusing on application recovery can also simplify the recovery process by narrowing down the scope of the effort, allowing organizations to design specific recovery plans and procedures for each application, making the testing of those DR plans more manageable as well.”

Compared to the site-wide strategy which offers a comprehensive approach to protect all applications and systems at once, therefore bringing additional complexity and high initial investment with it, application-level DR provides more ‘granular and controlled scalability,’ in Aujla’s words.

He added that the best fit, however, will be largely dependent on the SLAs that you’ve set in your business, so “SAP users need to carefully evaluate their requirements, budget and tolerance for downtime to determine the most suitable approach for their needs.”

SIOS HANA Multitarget – an example of an application-level DR solution

To explain how an application-level DR would work in practice, Aujla shared insights on SIOS’s own DR recovery clustering solution, SIOS LifeKeeper, which is designed to monitor and failover HANA databases. A part of the solution includes a feature called HANA Multitarget which allows SIOS to integrate HA and DR clusters in a more granular approach into the HANA database.

Simply put, imagine a traditional two-node failover cluster in which node A is the primary HANA database and node B is the secondary. With SIOS LifeKeeper, in the event that node B detects that node A failed for whatever reason, node B automatically registers itself as the new primary HANA database, maintaining both the HANA system replication mode and operation mode throughout that failover process. However, what happens when node B is also at risk of failing and DR must be invoked?

This is where the HANA Multitarget feature comes into play. Apart from the existing nodes A and B, in HANA Multitarget there is an additional node C which is based in a different ‘geography’. So, while nodes A and B maintain a synchronous system replication function, nodes A and C follow asynchronous replication. What this means is that there is one primary source and two targets and databases are synchronized across all three nodes, allowing HANA failovers from node to node.

When node B also fails and the DR process must be invoked, the software allows you to activate node C. Considering the risks, it is programmed to be done manually with a switch, so that you have full control over when and how it happens. Once the switch is flipped, node C registers itself as the new primary and starts other database services, asynchronously resuming the HANA System Replication back to nodes A and B.

Aujla added that, while this insight described how HANA Multitarget would operate in a cloud environment, it can also work the same way in a physical or virtualized environment.

All in all, as the example of SIOS Lifekeeper and its HANA Multitarget feature has shown, application-level DR strategy allows organizations to approach the process in a more flexible and controlled manner. It is, however, crucial to assess your critical systems and establish clear objectives regarding what you’d like your DR process to achieve. Carefully crafted DR strategy alongside software that offers clear visibility and control over your databases is the key match that will ensure the stability and security of your SAP environment.