Skip to Content
Author's profile photo Yongkang Ng

Enterprise Readiness with SAP HANA – Storage & System Replication between data centers

(Note: my apologies for the long pause in between due to my fellowship.)

Having covered the Build phase in our last blog on system replication within the data center, we will now cover in this blog the phase on running the data center. The run phase focuses on helping IT managers to operate and execute the data center readiness stages of disaster recovery, monitoring and administration, as well as security and auditing. In this blog, we will focus specifically on the storage and system replication technologies currently available for the IT manager.

Storage & System Replication
For large enterprises running multiple data centers, SAP HANA has two disaster recovery features: storage replication and system replication. These are based on the current offerings SAP HANA already has at the node level, which we covered in the previous blog. The table below provides a brief overview between the two offerings and their implications.

Table 1: Disaster recovery options between data centers, with distance in perspective

Storage Replication
To start off, there are currently different storage replication solutions provided by several SAP partners, which mirrors data between data centers. Customers can proactively engage their dedicated hardware partners responsible for these storage replication solutions, to find out more about the existing options available that can be leveraged in their data centers. Storage data is mirrored between the persistent storage of the first and second data centers. The replicated data includes both data and log volumes.

The below example provides a closeup of how the configuration works in a data center setting. In data center 2, the production instance of SAP HANA is inactive. The mirroring in this case would occur one level below. This type of configuration would help increase the efficient use of hardware assets, by using the hardware infrastructure to also support quality assurance and development activities. To ensure that there is no impact on the mirroring process, the nonproduction usage in this case would use an area of persistent storage that is separate from the actively used production disk.

Figure 1. Storage Replication between Data Centers

System Replication – Optimized for Cost
Aside from the storage replication option above, system replication is another option that can be leveraged and configured for disaster recovery scenarios. It can also be further optimized for cost or performance, depending on the needs of the business department. In the below closeup example, this configuration could be setup to help lower the TCO by maximizing the usage of hardware assets in the secondary data center for quality assurance and development.

In this configuration, production is active on the secondary cluster, but only at a minimal to take both data and log streams into local storage. Data is not preloaded. As such, the active non-production instances used by Development and Quality-Assurance will have “more room” to run in memory. The disk arrays of the instances in this setup would be separated from each other, so as not to impact performance.

Figure 2. System Replication optimized for costs

System Replication – Optimized for Performance
For the Performance optimized setup, the IT assets are used solely only for a takeover to ensure as minimum impact to the performance as possible. This can be a preferred option for enterprises with mission critical workloads and extremely short recovery time objectives. Data is also preloaded in this case.

In this configuration, the secondary instance will manage the replication process. As the instance appears active only from a database-kernel point of view, from the client view the secondary server cannot be actively accessed. The introduction of the continuous log replay feature in SAP HANA SPS11 takes the system replication feature a step further by removing the need to transfer the delta data. Only the log information is transferred via the SAP HANA database kernel, and this feature helps to minimize traffic on the connecting network, while further reducing takeover times.

Figure 3. System Replication optimized for Performance

System Replication – Summary
To put it all together, the table below provides a summary of the differences between the available disaster recovery options, which are based on the system replication methods focusing on the node level, as highlighted in the previous blog.

Table 2. Comparison between different system replication options

Monitoring and Administration in the Data Centers
Aside from choosing the replication methods, there are also various options and tools available for IT managers to specifically manage their SAP HANA landscape within the data center. Below are some of the tools that an IT manager can consider to manage their SAP HANA data center landscape:

  • SAP HANA cockpit: To monitor and administer the SAP HANA, the SAP HANA cockpit is a platform-independent tool to help administer, monitor and manage the SAP HANA implementation. With this application, IT managers can monitor databases, navigate between different actions and handle central configuration tasks.
  • SAP Solution Manager: The SAP Solution Manager offers a holistic monitoring option for SAP HANA and its environments. This tool is also used by SAP support personnel to assist in early problem analysis.
  • SAP Landscape Management: The SAP Landscape Management software allows IT managers to orchestrate SAP HANA. It interacts with SAP Solution Manager and also incorporates SAP HANA cockpit tiles. This integration supports enhanced orchestration and automated functions. SAP Landscape Management offers features from basic operation to larger and more complex SAP solution landscapes, such as database and application system copies or automated zero downtime updates on shadow systems with SAP HANA replication features.

More on this topic
The run phase covers the critical day to day operations within the data center, and IT managers should always consider the need to balance between performance, delivering to SLAs, as well as cost. However the initial Plan & Build phases should be well thought through, and below are the earlier blogs which they can refer to for more information.

(More to come)

  • May 17: Optimizing for Cost, Optimizing for Performance
  • Jun 17: Addressing Latency in replication, difference between delta shipping & log replay
  • Jul 17: Making use of new features in Active/Active read-enabled, log encryption etc.

Find out more on the topic of SAP HANA High Availability and Disaster Recovery at our SAP website here.

To go deeper in detail, check out also the Open SAP courses on the general topic of “High Availability and Disaster Recovery with the SAP HANA Platform“.

You can also check out our existing playlist on SAP HANA System Replication at the SAP HANA Academy here.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Rajagopal Sampath
      Rajagopal Sampath

      Hello Yongkang Ng,

      Thanks for the detailed info on DR solution based on storage/system replication. We are planning for  storage level replication (SRDF/A) at DR site. This means replicating Data and Log volumes to DR site in async method.

      Regarding /hana/shared file system (NAS), we are thinking about replicating every few hours. Wondering, if there is any guidelines for NAS replication options and maintaining it at DR site?This has only Hana binaries and config files.

      I couldn't find much info from SAP docs on maintaining /hana/shared (NAS) file systems at DR site. Any info on this, would be helpful for DR planning.


      Raj Sampath

      Author's profile photo Alan Maskey
      Alan Maskey

      Thank you for the explanation.  I have a question regarding the “Table 2 Comparison Between Different System Replication” Diagram. On the last option “Continues Log Replay Optimized for Cost, could you please elaborate “Only data relevant for the log replay is reloaded into the memory of secondary"?  Is it for both main and delta? We are using operation mode log replay and we keep seeing memory increase in secondary and does not de-allocate. We are also running Dev and QA on the same cluster where we are running secondary.