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:
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.
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.
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.
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:
- Shutdown other HANA databases in the secondary site (this step will interrupt the replication between two sites)
- 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).
- Mount the replicated storage (mountpoints) to the HANA system in the secondary site
- 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
- SAP Managed Tags:
10 Comments
