- SAP Managed Tags:
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
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)
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.
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.”
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.
- Nov 16: SAP HANA active/active read-enabled option
- Dec 16: Overview – Data Center Readiness
- Dec 16: Planning Your Data Center – Installation, Scalability & Persistence / Backup & Recovery
- Jan 17: Building Your Data Center – Host Auto-failover, Sys. Replication, Storage Replication (current)
(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.
7 Comments
