Skip to Content
Author's profile photo Yongkang Ng

Enterprise Readiness with SAP HANA – Host Auto-failover, System Replication, Storage Replication

Continuing on from the earlier blog on Backup & Recovery that we covered last year, we will focus on the Building phase for data centers as we continue this topic in 2017. This segment will focus on what happens inside the data center, and specificically the high availability capabilities and options by SAP HANA, which can be deployed according to the IT managers’ landscape requirements. Of particular focus would be the System Replication feature, which will be explained in detail.

High Availability within Data Centers
SAP HANA comes with three different high availability and disaster recovery deployment modes that can be used:

  • Host auto-failover
  • System replication
  • Storage replication

Host auto-failover
This method is appropriate for systems within a single data center. Host auto-failover focuses on replacing failed parts of a system, such as hosts or nodes, with a standby server. In this method, the main memory of the standby system is not preloaded with data from SAP HANA. When failure occurs, this configuration option selects one or more hosts, which are currently running as a standby, for immediate takeover (see Figure 3). This configuration can also scale out to a larger configuration with multiple hosts.

This feature will be managed by the name service in SAP HANA within a scale-out cluster, and multiple standbys can be executed with this feature. A regular check is run by the name service on each cluster member to determine if each node is still active. When a failure is detected, SAP HANA initiates a fully automated takeover by the standby hardware. Multiple takeovers can also be executed using multiple standby servers.

Figure 1. Host auto-failover


System Replication
For enterprises with multiple data centers, system replication could be another recommended approach to ensure fast takeovers and minimum performance ramp-up in the event of system failure. With system replication, both data and log content are transferred using the SAP HANA database kernel. SAP HANA is also responsible for the replication process of data and logs, replication the information immediately after executed transactions. In the case of a transaction, both sites (primary and secondary) must acknowledge the commit to finish the transaction.

The below shows an example of system replication which is optimized for performance. An initial data load is performed first on the secondary system, to ensure both systems reflect the same data with one another. From there, two setup options can be used: the continous log replay setup, which is available since the SPS11 release of SAP HANA, or the delta data shipping setup option.

To maximize throughput efficiency and takeover performance, a “hot standby” continuous log replay setup can be used. Upon the initial data load on the secondary system, the log is then transferred in a steady stream from the primary to the secondary server, where it is further replayed (redo) in the secondary SAP HANA system. This feature reduces takeover times as well as network traffic.

Figure 2. System Replication

Difference of footprint between Delta Data shipping and continuous log replay
In the delta data shipping setup, the operation on the secondary server is only active as a shadow of the primary server. Data and log streams in this case are only taken for local storage.

In the continuous log-replay setup, the operation on the secondary server has a higher footprint. This is because additional resources are needed on the shadow production instance to run a continuous replay of the logs from the primary server. As a result, the non-production instance in this case is smaller as compared to the delta-data shipping setup.

Multiple options for System Replication
To put it all together, the table below shows the four options available with SAP HANA system replication as well as their differences. It also shows the different configurations that can be modified to run nonproduction workloads, and further optimize the use of hardware assets.

Table 1. system replication options

Storage Replication
Storage replication lastly, is useful for single or multiple data centers. This feature provisions a whole system on a replaced or alternative set of disks or storage system. Because of the remote management of this replication mode, it does not support preloading of data into the main memory of SAP HANA. More will be covered on storage replication in the next chapter in running our data center.

Balancing between the HA/DR Options
The above three options should be balanced according to requirements between the need for cost and performance. The two key metrics that can help guide decision making are the recovery-point objectives as well as recovery-time objective. To provide a rough guide, the table below helps compare product options according to these priorities.

Table 2. Balancing High Availability and Disaster Recovery Options

Moving forward to System Replication Active/Active
SAP also offers high availability solutions in which transactions run on the primary server and analytics can run on the standby server. This feature helps maximize hardware assets and processing performance, and is one of the latest releases from SAP in 2016. For more about this feature, see the other blog on, “Active/Active System Replication.”

More on this topic
The build phase is an important phase for IT managers, in considering the balance between managing costs and maintaining SLAs. Aside from the build phase, we will explain more on the Run phase in the next blog. For the moment, you can explore more on the other topics will be explained in the other blogs below.

(More to come)

  • Feb 17: Running Your Data Center – Storage & System Replication between data centers
  • Mar 17: Optimizing for Cost, Optimizing for Performance
  • Apr 17: Addressing Latency in replication, difference between delta shipping & log replay
  • May 17: Making use of new features in Active/Active read-enabled, log encryption etc. (Sapphire)

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 Former Member
      Former Member

      Hi Yongkang,

      Good article.

      I want to understand the HA scenario whereby within the same site I have 2 physical HANA DB servers and both are active-active such that when 1 fails, the other is still running and accepting all requests.

      Is this possible? If yes, can you please describe how this is made possible technically. The OS on both servers will be SUSE Linux and data will be on SAN storage.






      Author's profile photo Yongkang Ng
      Yongkang Ng
      Blog Post Author

      Hi Suraj, sorry for the late reply. I have checked with product management for deeper details, and this can be possible. Do refer to this blog on Active-Active for more details.

      Operating System in this case are recommended to be identical for the Active-Active operation. Without Active-Active, with pure system replication, more combinations are possible, even replicating between Intel and Power architecture, as long as they have the same little endianess with SAP HANA 2.0. Every site has its own set of disks, usually on separate SANs because of distance between locations.


      Best regards,

      Yongkang Ng

      Author's profile photo Sanjay Sahita
      Sanjay Sahita

      Hi Yongkang,


      Thank you for the nice article.

      I had a query about how Storage Replication can be technically implemented. Can your upcoming blog showcase some sort of details around the phenomena ? Till now, We have just heard the word but underlying technique has never been elaborated in much details by SAP.

      In case of TDI HANA Implementations on-premise; Storage Replication may not always be offered by underlying Storage so we need to know better technique such as mounting storage replication volumes to bring HANA DBs up in case of HA/DR scenarios.

      So if you can please elaborate to best on the same.


      Sanjay Sahita

      Author's profile photo Yongkang Ng
      Yongkang Ng
      Blog Post Author

      Hi Sanjay,

      sorry for the late reply. Just to answer, storage replication is driven mainly by SAP’s hardware partners. As such, SAP may not have too much details  how our partners/vendors implement their solutions at the customer. If you want to know more on this, please get in contact with our storage partners for example, EMC, HPE, Hitachi, NetApp, IBM etc. List may be incomplete, so do get in contact with your storage vendor of choice. The ones we named here, we know that they are currently investing in existing storage replicating solutions.

      Storage replication needs strong support by hardware and storage partners, because of the complexity and supportability. Generally, we wouldn’t recommend customers to build solutions completely by themselves. Our preference instead, is to work closely with the named partners/vendors on their pre-developed concepts.

      Best regards,

      Yongkang Ng

      Author's profile photo Sanjay Sahita
      Sanjay Sahita

      Hi Yongkang,


      You are correct in your response. But our case is HANA-TDI which means do it by yourself.

      I wonder if SAP gives some sort of guidelines for System replication; why not generic commands, etc for Storage replication. As underneath its only SLES / RHEL Linux as OS.


      Sanjay Sahita

      Author's profile photo Former Member
      Former Member

      Hi Yongkang:

      For the data shipping part, what is the interval? How often does it occur? Is there a parameter for this? What's the default value?



      Author's profile photo Peter Wegner
      Peter Wegner


      default interval für delta data shipping is 10 Minutes