Supported HA Scenarios for SAP HANA, SAP S/4HANA, and SAP Netweaver

Updated -

Currently the following HA scenarios are supported by Red Hat HA Add-on for SAP HANA, SAP S/4HANA, and SAP Netweaver.

1. HA Solutions for SAP HANA

1.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 HSR, it's possible to copy and continuously synchronize a SAP HANA database to a secondary location in the same or another data center. Data is constantly pre-loaded on the secondary system to minimize recovery time objective (RTO).

HANA System Replication

However, the failover is not automated, therefore it needs a 3rd party cluster solution to monitor the healthiness of the HANA database and trigger failover when failure is detected. The automation is achieved with Red Hat Enterprise Linux HA Add-On. The solution is call Automated SAP HANA System Replication, which is now supported in HANA Scale-Up and Scale-Out.

1.2. Supported Scenarios of Automated SAP HSR in HANA Scale-Up

Supported Scenario Notes
Two node cluster only Only two-node is supported by pacemaker
MDC Supported by resource-agents-sap-hana-3.9.5-54.el7_2.22 and later
Performance Optimized Secondary site is not active to 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 in HANA 2.0 Active-Active Read-Enabled: in HANA 2.0, the secondary instance can take Read-Only inquiries
Replication Chain "Multi-tier System Replication"/"replication chains" are possible, but the tertiary site can not be managed by the cluster


1.2.1. Support Policies

Support Policies for RHEL High Availability Clusters - Management of SAP HANA in a Cluster

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

Performance Optimized

1.2.2.1 Configuration Guide

1.2.3. Cost Optimized

The Cost Optimized scenario supports an additional TEST/QA HANA database on the secondary site, serving client inquiries. Because the resource has 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. The takeover time is therefore longer than Performance Optimized.

Cost Optimized

1.2.4. HANA 2 Active-Active

In HANA 2.0, the secondary instance can take Read-Only inquiries. This setup supports a second virtual IP on the secondary site.

HANA 2 Active-Active

1.2.5. Replication Chain

"Multi-tier System Replication" aka "replication chains" are possible, but the tertiary site can not be managed by the cluster.

HSR Chain

1.3. Supported Scenarios of Automated SAP HSR in HANA Scale-Out

This feature will soon to be supported.

Supported Scenario Description
Performance Optimized Secondary site is not active to client/application servers



HSR Scale-Out

2. HA Solution for S/4HANA based on ABAP Platform 1809

2.1. Standalone Enqueue Server 2 (ENSA2)

Standalone Enqueue Server, a component of Application Server ABAP, is a mechanism to ensure the high availability of the lock table and its entries.

Standalone Enqueue Server has evolved into generation 2 since Netweaver 7.51, known as Standalone Enqueue Server 2, or ENSA2. In ENSA2, if the ASCS failed, it can start on a separate node in the cluster, and copy the lock entries from the enqueue replicator 2.

ENSA2

In ABAP platform 1809, the Standalone Enqueue Server 2 (ENSA2) has become the default installation.

2.2. Supported Scenarios

Supported Scenario Description
Multi-node cluster Because in ENSA2 ASCS doesn't have to “follow” ERS, that makes a multi-node cluster possible
Two-node cluster Upgraded two-node cluster can easily adjust the setup to switch from ENSA1 to ENSA2

Brand new installation can take this chance to design the architecture, choosing between multi-node cluster or two-node cluster. Below is the architecture diagram of a typical 3-node cluster. Of course more nodes can be added upon customer’s datacenter requirements or needs:

ENSA2 HA

2.3. Support Policies

Support Policies for RHEL High Availability Clusters - Management of SAP S/4HANA

2.4. Configuration Guide

3. HA Solution for Netweaver or S/4 Based on ABAP Platform 1709 or older

3.1. Standalone Enqueue Server 1 (ENSA1)

Under the mechanism of the old Standalone Enqueue Server (ENSA1), the ASCS has to fail over to the cluster node where the active ERS is running, because it has to access the shared memory that stores the enqueue replication table. ENSA1 is supported in pacemaker as a two-node cluster configuration, mainly because of the restriction that ASCS must “follow” ERS.

ENSA1

3.2. Supported Scenarios

Supported Scenario Description
Two node cluster Only two-node cluster is supported by pacemaker

Below is the architecture of Netweaver ASCS/ERS ENSA1 running on HANA database. Optionally but highly suggested, HANA can also be configure into a separate pacemaker cluster.

ENSA1 HA

2.3. Support Policies

Support Policies for RHEL High Availability Clusters - Management of SAP Netweaver in a Cluster

2.4. Configuration Guide

Table of Contents

Automatically generate a table of contents