SAP HANA HA and DR Series #4: Storage Replication

[alper_somuncu]

SAP HANA Storage Replication is another disaster recovery solution based on the replication of the data and log disks to a remote storage. In this method, all the data that is written to the persistence layer (data and log volumes) by the primary HANA system is replicated to a secondary (usually) cross-site location. Because the secondary host is in a remote location, this solution requires a reliable, high bandwidth and low latency connection between the primary site and the secondary site.

The HANA instance of the secondary location can be used for other SAP HANA systems (such as Test or QA environment) depending on your hardware solution. In this scenario which the HANA instance of the secondary location is used for other systems, you need to perform below activities for the takeover:

1. Shutdown other HANA databases in the secondary site (this step will interrupt the replication between two sites)


2. Check when the last replication is triggered to secondary site and stop the storage replication between two sites (make sure there is not much gap between data, aim for minimum possible RPO).


3. Mount the replicated storage (mountpoints) to the HANA system in the secondary site


4. Start the HANA instance running on the replicated storage

If you are using the HANA servers of the secondary system for other SAP systems (Test, QA systems), you need to ensure that these servers do not use the hard disk storage system that contains the replicate of the primary system.

Figure 1: Storage Replication with non-Prod systems on the secondary site (credit: help.sap.com)

Storage replication offers both synchronous or asynchronous replication options, but synchronous replication should only be used when the distance between the primary and secondary site is no more than 100 km. Otherwise due to the longer distances between the locations, the latency times for writing the redo log may increase.

Some hardware partners (Lenovo, HP, Hitachi e.g.) also support asynchronous replication of the write requests and ensure the consistency of the data and transactions within HANA database. These asynchronous replication solutions can be used for longer distances between the locations because the latency times are not significantly affected when writing the redo log.

Figure 2: Storage replication as in storage mirroring configuration (credit: help.sap.com)

Even though secondary site is not active and receives the updates from the primary location less frequently (which is why it is named as cold standby), this method is obviously a more attractive approach than regularly sending backups tapes to a secondary location. It can hep you reduce the overall hardware cost compared to System Replication or Host Auto-Failover while providing a better RPO and shorter recover time (RTO) than backup/restore in a remote site.

 

---

Do you have any question about SAP HANA Storage Replication? Leave a comment below, I would love to help you and learn from you too!

Feel free to share.

---

References and further reading:

SAP Note 1755396 - Released DT solutions for SAP HANA with disk replication

SAP HANA Disaster Recovery Support

SAP HANA Disaster Recovery with Asynchronous Storage Replication (Cisco)

---

If you liked this post, you might like these relevant posts:

SAP HANA High Availability and Disaster Recovery Series #1

SAP HANA HA and DR Series #2: Redundancy and Fault Recovery Support

SAP HANA HA and DR Series #3: Host Auto-Failover

Choosing the right HANA Database Architecture

 

[sanjaysahita1]

 

Hi Alper,

Thank you for these excellent blogs for SAP HANA HA and DR Series.
May I ask if its possible for SAP to publish via some SAP Notes / SAP Documents how Storage Replication can be implemented in TDI HANA Implementations ?
In case a customer hasn't bought a storage replication solution as such but needs to implemented in TDI case; Haven't seen any sort of documentation from SAP on this like how to define volumes at storage level and mount those replicated volumes on HANA nodes to test storage failovers, OS Level Linux operations, etc to accomodate this.

Any details on the same would highly appreciate.

Thanks a ton for you time on this.

Best Regards,
Sanjay Sahita

[alper_somuncu]

Hi Sanjay,

If SAP publishes such documents that would be really helpful indeed.

Storage replication is actually a known technology for a long time, it is not SAP or SAP HANA specific. It is basically a storage mirroring solution where you mount this storage to already active HANA system (PreProd, Test etc) and start SAP using that disks.

In terms of defining storage, you should follow the same directory structure as HANA on-premise implementation. I have added my tasks list to publish an article for step-by-step storage replication guide in TDI. Any specific questions, I'm happy to help.

Kind regards,

Alper

[former_member184709]

Hi there,

Are there HANA appliances which offer storage replication? Or is storage replication geared more towards TDI using an enterprise SAN?

I have read a few how-tos, but they seem mostly based on enterprise SAN and not the appliance model.

Also checked the first link but it seems a couple of years old:

1755396 - Released DT solutions for SAP HANA with disk replication

Thanks,

Derek

[alper_somuncu]

Hi Derek,

Exactly, because it is primarily offered by hardware vendors and not a HANA technology, it is geared more towards enterprise SAN.

Following certified and supported SAP HANA® Hardware directory has all the up-to-date hardware details: https://www.sap.com/dmc/exp/2014-09-02-hana-hardware/enEN/index.html

Sorry for my late answer, I usually am more active on LinkedIn.

Kind regards,

Alper Somuncu

[former_member265494]

Hi Alpler.

I have a doubt about this.

In the secondary site, whats is the minimum configuration needed to maintain the storage replication?

 

Thanks.

[former_member199694]

Hello Alper,

Thanks for sharing valuable info on HANA domain.As we are planning for DR storage replication solution(SRDF/A), we understand that DATA and LOG volumes needs to be replicated to DR site. One thing I couldn't find much info is about the /hana/share-NAS file system replication requirements and options available.

As /hana/share has only HANA binary, tools installation and other config files, I assume this needs to be replicated but don't need to be at the same frequency as Data/log volumes.

Would appreciate, if you could share some insight on the options available to maintain the /hana/share file system at DR site.

I agree, as you have mentioned, HANA HW is going towards TDI and the vendor will have the DR solution to work with.

Best Regards,

Raj Sampath

[former_member732740]

Dear Alper, do we have any document that has step-by-step details on this storage replication setup. Please let know. Thanks

Regards

Gabriel

[former_member462360]

Hi Alper,

in my case, at DC we plan to have 2 nodes active-standby with HANA replication. At DR, we plan to replicate HANA at the storage level. may I as you, which system, Active or Stand by, should be selected as a source of storage replicate to DR system?

Regard,

Somchid.

[alper_somuncu]

Active node will be your primary site and the replication will go through active --> standby on the DR site.

[former_member462360]

Hi Alper,

I have total 3 node, 2 nodes at DC  and 1 node at DR. as you mention, why not storage replicate from standby node at DC to node at DR. since I afraid the storage replicate from primary node at DC will effect the performance of the active node. any reason behind that? please give more explanation.

 

Regards,

Somchid S.