SAP on AZURE/ SAP on AWS : Cost Optimized DR Solutions for HANA : Lean/Skinny DR

—-

It has been a long time since I wrote a technical blog post. I was busy reading wonderful blog posts written by all fellow SAP professionals. Thank you all, here is my share 😊

—-

Running SAP on the HANA database is not only having multiple advantages, but also few cons as well. The hardware cost to run the HANA database is one of them. Since HANA is an in-memory database, customers must provision higher-size RAM and CPU to run their SAP on HANA. Even in hyper scaler environments like AZURE/AWS, HANA VM (M-Series) cost is huge comparatively and concern for most of the customers.

Keeping this in mind, designing a disaster recovery solution for HANA is a very challenging one.&To address this design challenge, we can consider multiple cost-optimized options like

1. Lean/Skinny DR
2. Backup/Restore
3. Azure/AWS native solutions

Each option has its own pros & cons. In this blog post, we are going to talk about lean DR setup. The Lean DR option has a little more cost factor but has a lesser RTO/RPO compared to the other options.

In general, to set up DR for HANA, there will be one Primary HANA running on the primary region and a Secondary HANA instance, running on the DR region with identical VM size. As per SAP recommendation, DR for HANA will be set up using HANA system replication (HSR).

For example:

In Lean DR Setup, we can reduce the VM size by 50% OR row store size + 20 GiB ( This is as per my experience, there are no standard guidelines or not that I am aware of). In this case, we can provision M64s VM for DR HANA, which is 64 CPU’s and 1 TB RAM

By default, SAP HANA loads the columns into the memory of the secondary system of a system replication scenario during normal uptime. This has the advantage that a reload is not required at failover time. In lean DR Setup, since only limited memory is available, we should disable this feature. Set the preload_column_tables parameter to ‘false’.

How it works?

Need to configure Replication between Primary and Secondary HANA using System Replication (HSR) with no preload option. With no preload option, data will not be loaded in the memory while replication in progress. In this case, we don’t need the DR system to match the primary instance size.

During the actual DR, the DR VM needs a quick restart to upsize the VM Size to match the actual primary VM size by leveraging the cloud scalability options. Just Upsize the VM and perform the takeover.

Update: 

As ‘Darryl Griffiths MBCS’ right said in my Linkedin post, “In a real DR where the primary region/site is down, all other customers will be failing over at the same time. You may not be able to upscale your DR VM. You may not get your original VM back once you stop it to try and upscale it. You could end up with no DR at all.”. Please make sure that you have quota allocated with the right size VM on the DR site to avoid this situation.

————————————————————-

DISCLAIMER: This blog post is based on due diligence performed at the time of writing. As options and paths can change over time, readers are advised to check the latest official information before making business decisions. The author accepts no responsibility for the current validity, accuracy, completeness, or quality of the information provided.