Skip to Content

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

 

To report this post you need to login first.

4 Comments

You must be Logged on to comment or reply to a post.

  1. Sanjay Sahita

     

    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

    (1) 
    1. Alper Somuncu Post author

      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

      (0) 
  2. Derek Barrett

    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

     

    (0) 

Leave a Reply