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).

text

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 ScenarioNotes

Performance Optimized

Secondary site is not active for client/application servers

Cost Optimized

Support a QA/Test instance running on the secondary site (Cost-Optimized); QA/Test instance will be shutdown first during the failover of Prod

Active/Active (Read Enabled)

The secondary HANA instance can take read-only inquiries

Multitier System Replication

Multitier System Replication is possible, but the tertiary site cannot be managed by the cluster

Multitarget System Replication

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.

text

2.2.2.1. Configuration Guides

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.

3

2.2.3.1. Configuration Guides

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.

4

2.2.4.1. Configuration Guides

2.2.5. Multitier System Replication

Multitier System Replication is possible, but the tertiary site cannot be managed by the cluster.

5

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.5.1. Configuration Guide

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.

21

2.2.6.1. Configuration Guide

2.3. Supported Scenarios for Automated SAP HANA Scale-Out System Replication

Supported ScenarioDescription

Performance Optimized

Secondary site is not active to client/application servers

Active/Active (Read Enabled)

The secondary HANA instance can take read-only inquiries

Multitarget System Replication

Primary HANA instance is replicated to multiple secondary HANA instances

6

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 Multi Target 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 please refer to: