Chapter 2. HA Solutions for SAP HANA
2.1. Automated SAP HANA System Replication
SAP HANA System Replication (HSR) is a built-in high availability and disaster recovery feature to support business continuity. With HANA System Replication, it’s possible to copy and continuously synchronize a SAP HANA database to one or more locations. Data is constantly pre-loaded on the secondary system to minimize recovery time objective (RTO).
However, SAP HANA does not contain any mechanism to automatically trigger a failover in case an issue occurs with any components that are part of a HANA System Replication setup. But 3rd party cluster solutions can be used to monitor the healthiness of the HANA System Replication environment and trigger failover when a failure is detected.
On RHEL the Red Hat Enterprise Linux HA Add-On can be used to automate the failover. Red Hat provides HA solutions for both single system SAP HANA setups (Scale-up) or scaleable multi-system SAP HANA setups ( Scale-out).
2.2. Supported Scenarios for Automated SAP HANA Scale-Up System Replication
| Supported Scenario | Notes |
|---|---|
| Secondary site is not active for client/application servers | |
| Support a QA/Test instance running on the secondary site (Cost-Optimized); QA/Test instance will be shutdown first during the failover of Prod | |
| The secondary HANA instance can take read-only inquiries | |
| Multitier System Replication is possible, but the tertiary site cannot be managed by the cluster | |
| In addition to the standard HANA System Replication the data is replicated to additional secondary HANA instances that are not managed by the cluster |
2.2.1. Support Policies
Please refer to Support Policies for RHEL High Availability Clusters - Management of SAP HANA in a Cluster.
2.2.2. Performance Optimized
In the Performance Optimized scenario, the secondary HANA database is configured to preload the tables into memory, thus the takeover time is normally very fast. However, as the secondary HANA database is dedicated to System Replication and doesn’t accept client inquiries, this setup is expensive in terms of hardware cost.
2.2.2.1. Configuration Guides
- On-Premise: Automating SAP HANA Scale-Up System Replication using the RHEL HA Add-On
- AWS: Configuring SAP HANA Scale-Up System Replication with the RHEL HA Add-On on Amazon Web Services (AWS)
- Azure: High availability of SAP HANA on Azure VMs on Red Hat Enterprise Linux
- Google Cloud Platform (GCP): HA cluster configuration guide for SAP HANA on RHEL
- IBM Power System Virtual Server: Configure SAP HANA Scale-Up System Replication in a RHEL HA Add-On cluster
2.2.3. Cost Optimized
The Cost Optimized scenario supports an additional TEST/QA HANA database on the secondary site, serving client inquiries. Because hardware resources have to be allocated to the TEST/QA instance, the Production HANA database can not be preloaded. Before takeover, the TEST/QA instance has to be shutdown first to free up the hardware resources assigned to it and reassign them to the secondary HANA instance that will be promoted to become the primary instance. The takeover time is therefore longer than for Performance Optimized setups.
See also Automating Cost-Optimized SAP HANA Scale-Up System Replication using the RHEL HA Add-On.
2.2.4. Active/Active(Read Enabled)
The secondary HANA instance can take read-only inquiries. This setup supports a second virtual IP on the secondary site.
For more information, please refer to Adding a secondary virtual IP address for an Active/Active (Read-Enabled) HANA System Replication setup.
2.2.5. Multitier System Replication
Multitier System Replication is possible, but the tertiary site cannot be managed by the cluster.
A takeover to the tertiary site will have to be triggered manually, and if the environment should be brought back to the previous state after a manual takeover to the tertiary site, all steps to reconfigure the HANA System Replication setup will have to be carried out manually as well while the cluster is disabled. After it has been verified that the HANA System Replication setup is working correctly again on the HANA instances that should be managed by the cluster, the cluster can be reactivated.
2.2.6. Multitarget System Replication
When using HANA 2.0 SPS 04 or newer and a RHEL release that provides version 0.162.1 or newer of the resource-agents-sap-hana RPM package, Multitarget System Replication is supported for HANA Scale-Up System Replication setups managed by the RHEL HA Add-On.
In a Scale-Up Multitarget System Replication HA cluster setup, the primary HANA instance is replicated to a secondary HANA instance managed by the HA cluster and to additional secondary HANA instances not managed by the cluster to meet additional availability requirements.
2.2.6.1. Configuration Guide
2.3. Supported Scenarios for Automated SAP HANA Scale-Out System Replication
| Supported Scenario | Description |
|---|---|
| Secondary site is not active to client/application servers | |
| The secondary HANA instance can take read-only inquiries | |
| Primary HANA instance is replicated to multiple secondary HANA instances |
2.3.1. Support Policies
Please refer to Support Policies for RHEL High Availability Clusters - Management of SAP HANA in a Cluster.
2.3.2. Configuration Guides for Performance Optimized HANA Scale-Out System Replication HA setups
2.3.3. Active/Active (Read Enabled) HANA Scale-Out System Replication
In HANA 2.0, the secondary instance can take Read-Only inquiries. This setup supports a second virtual IP on the secondary site. For more details please check chapter "Adding a secondary virtual IP address resource for Active/Active (Read-Enabled) setup" in Red Hat Enterprise Linux HA Solution for SAP HANA Scale Out and System Replication.
For more information see Active/Active(Read-Enabled).
2.3.4. Multitarget System Replication (Scale-Out)
Starting with HANA 2.0 SPS 04 Multitarget System Replication is supported in a cluster environment. The primary site is replicated to a secondary site and also replicated to an additional secondary site to meet additional availability requirements. In terms of failure this additional third site will be automatically registered to the new primary site, which was the former secondary.
For more details, refer to Multitarget System Replication.
