Red Hat High Availability Clustering for SAP Solutions

SAP HANA System Replication (HSR) is a built-in high availability and disaster recovery feature to support business continuity. With HSR, you can copy and continuously synchronize a SAP HANA database to a secondary site in the same or another data center.

Data is constantly preloaded on the secondary system to minimize the recovery time objective (RTO).

Figure 1.8: General SAP HSR architecture

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

Red Hat Support Policies for Managing SAP HANA in a Cluster

In general, RHEL High Availability is packaged with agents to manage applications and resources of different types, and users can also deploy their own scripts or agents. Red Hat might have specific policies for individual resources or for applications that a cluster manages. For more details, refer to the Support Policies for RHEL High Availability Clusters Knowledge Base article, https://access.redhat.com/articles/2912891#cluster_resources. In the context of SAP HANA on RHEL 8 and later versions, users must adhere to additional requirements to be eligible for support from Red Hat with the appropriate product support subscriptions.

For example, the following supported releases of resource-agents-sap-hana and versions of SAP HANA for Scale-Up systems are required when managed by RHEL HA Pacemaker clusters on RHEL 8:

Red Hat subscriptions for SAP HANA support: Red Hat provides support for RHEL High Availability resource agents that manage SAP HANA deployments through the RHEL for SAP Solutions subscription. One of these subscriptions for each cluster node is required for Red Hat to assist with RHEL High Availability management of SAP HANA.

Supported platforms for SAP HANA on RHEL High Availability:

Red Hat support for its software, for the SAP HANA solution stack for Scale-Up/Scale-Out System Replication environments, including RHEL High Availability and its resource agents for SAP software, largely follows the policies for RHEL High Availability and RHEL.

For the list of x86_64 and IBM POWER servers, storage systems, and cloud instance types that are certified for running SAP HANA Scale-Up and Scale-Out installations, see the Certified and Supported SAP HANA Hardware Directory at https://www.sap.com/dmc/exp/2014-09-02-hana-hardware/enEN/index.html.

In public-cloud deployments, Red Hat support for this SAP HANA solution stack is limited to only the following cloud platforms:

Red Hat does not yet officially support other cloud provider platforms. However, those platforms might already have been tested.

To run SAP HANA on another cloud platform, contact Red Hat Support for more information. For general information about using SAP on RHEL in cloud environments, see SAP Offerings on Certified Cloud Providers at https://access.redhat.com/articles/3751271. The entire environment stack must be supported for proper functioning of SAP environments.

Supported SAP HANA Deployment Types

MCOS is supported only if all running databases on the hosts are replicated, and if the replication is always to the same secondary node (for Scale-Up only).

Active/Active (Read Enabled): https://help.sap.com/viewer/6b94445c94ae495c83a19646e7c3fd56/2.0.03/en-US/fe5fc53706a34048bf4a3a93a5d7c866.html

SAP HANA System Replication setups are possible with SAP HANA 2.0 by using version 0.152.17 or later of the SAPHana, SAPHanaTopology, and SAPHanaController resource agents. To enable these setups, the additional secondary IPs and the appropriate colocation constraints must be added to manage the other IP addresses for the requirement (Scale-Up or Scale-Out).

Multitier System Replication, https://help.sap.com/viewer/6b94445c94ae495c83a19646e7c3fd56/2.0.02/en-US/f730f308fede4040bcb5ccea6751e74d.html, is supported for SAP HANA Scale-Up and SAP HANA Scale-Out System Replication HA setups. This replication is possible only if additional SAP HANA instances are not managed by an HA cluster. The HANA instances that run outside the cluster must be registered manually and be re-registered after each takeover.

Multi-Target System Replication, https://help.sap.com/viewer/6b94445c94ae495c83a19646e7c3fd56/2.0.03/en-US/ba457510958241889a459e606bbcf3d3.html, is supported for SAP HANA Scale-Out System Replication HA setups. For SAP HANA Scale-Up System Replication HA setups, this replication is possible only if additional SAP HANA instances are not managed by an HA cluster. Then, the HANA instances that run outside the cluster must be registered manually and be re-registered after each takeover.

Additional Technical Requirements for SAP HANA System Replication HA Deployments

The following conditions apply for Red Hat to provide support:

*hdbcons -e hdbindexserver "replication info"|egrep "(ReplicationFullSync|enable_full_sync)"*

If it is not already installed, then SAPHostAgent is installed with the HANA installation.

The following conditions also apply for Red Hat to provide support for Cost-Optimized SAP HANA environments:

The environment must also match the RHEL HA add-on stretch cluster requirements (see Support for Red Hat Enterprise Linux High Availability Cluster Stretch and Multi-Site Architectures), specifically the network latencies between the nodes and the recommended maximum distance. * Access to the SAP Service Marketplace is needed to download SAP installation media, installation guides, and so on. * The current set of SAP HANA installation media is needed. See the SAP HANA Installation Guides for the correct list of installation media. * The latest and the same version of SAP HOSTAGENT must be installed on all nodes.

If you are installing SAP software, then the current version of SAPHOSTAGENT is installed or updated.

Performance Optimized

In the Performance Optimized scenario, the secondary HANA database is configured to preload the tables into memory. The takeover time is normally fast. However, because the secondary HANA database is dedicated to system replication and is not used for client requests, this setup is expensive in terms of hardware costs.

Figure 1.9: SAP HSR Performance Optimized

Configuration Guides

Cost Optimized

The Cost Optimized scenario supports an additional TEST/QA HANA database on the secondary site, to serve client inquiries. Because the resource must be allocated to the TEST/QA instance, the Production HANA database cannot be preloaded. Before takeover, the TEST/QA instance must be shut down first. The takeover time is therefore longer than for Performance Optimized . See also Configuring Cost-Optimized SAP S/4HANA ASCS/ERS/HDB with Standalone Enqueue Server 2 (ENSA 2) in a Pacemaker Cluster: https://access.redhat.com/articles/6896831

Figure 1.10: SAP HSR Cost Optimized

HANA 2 Active-Active (Read-Enabled)

In HANA 2.0, the secondary instance can take Read-Only inquiries. For this purpose, a second virtual IP is used on the secondary site.

Figure 1.11: SAP HSR Active/Active (read-enabled)

Replication Chain

Multi-tier system replication is possible, and is also known as a replication chain, but the cluster cannot manage the tertiary site.

Figure 1.12: SAP HSR multi-tier system replication

Figure 1.13: SAP HSR components managed by Pacemaker resource agents

Configuration Guides for Multi Target Replication with Active/Active (Read-Enabled)

Scale-Out HANA 2 with Active/Active (Read-Enabled)

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, see the "Adding a Secondary Virtual IP Address Resource for Active/Active (Read-Enabled) Setup" chapter in Red Hat Enterprise Linux HA Solution for SAP HANA Scale-Out and System Replication.

For information, see Active/Active (Read-Enabled): https://help.sap.com/viewer/6b94445c94ae495c83a19646e7c3fd56/2.0.03/en-US/fe5fc53706a34048bf4a3a93a5d7c866.html.

Scale-Out Multi Target Replication

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 to a third site to meet other availability requirements. In terms of failure, this additional third site is automatically registered to the new primary site, which is the former secondary site. For more details, see Automating SAP HANA Multi Target System Replication in a Pacemaker-based Cluster on Red Hat Enterprise Linux (RHEL): https://access.redhat.com/articles/6113261 and Multi Target Replication: https://help.sap.com/viewer/6b94445c94ae495c83a19646e7c3fd56/2.0.03/en-US/ba457510958241889a459e606bbcf3d3.html.

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, and is known as Standalone Enqueue Server 2, or ENSA2. In ENSA2, if the ASCS failed, then it can start on a separate node in the cluster, and can copy the lock entries from the enqueue replicator 2.

Figure 1.14: General SAP S4/HANA (ENSA 2) architecture

Since ABAP platform 1809, the Standalone Enqueue Server 2 (ENSA2) is the default standard.

A new installation can take this opportunity to design the architecture, with a choice between a multi-node cluster or a two-node cluster. The following diagram shows the architecture diagram of a typical 3-node cluster. More nodes can be added, based on a customer's data center needs.

Figure 1.15: SAP S4/HANA (ENSA 2) Multi-node architecture

Under the mechanism of the old Standalone Enqueue Server (ENSA1), the ASCS must fail over to the cluster node where the active ERS is running, because it must 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.

Figure 1.16: SAP S4/HANA (ENSA 1) Two-node only architecture

Both ENSA 1 and ENSA 2 are supported, but only 2-node clusters in this scenario.

The following figure shows the architecture of NetWeaver ASCS/ERS ENSA1 or S/4 HANA ENSA 2 on a HANA database. It is also optionally recommended to configure HANA into a separate Pacemaker cluster.

Figure 1.17: SAP S4/HANA (ENSA 1/2) Two-node only Cost-Optimized architecture

ABAP/Java Dual-Stack

ABAP/JAVA Dual-Stack is supported with the Primary/Secondary methodology, which is supported in all RHEL 7.x minor releases.

Follow the configuration guide: SAP NetWeaver ASCS/ERS ENSA1 in Pacemaker Cluster Using Master/Slave Resources, at https://access.redhat.com/articles/3150081#configure-ascs-ers-sapinstance-cluster-resource. However, because SAP no longer recommends dual-stack setups where both ABAP and Java instances use the same SID, it is better to consider a Dual-Stack Split (see https://wiki.scn.sap.com/wiki/display/SL/Dual+Stack+Split+Tool), so that the ABAP and the Java stack use separate SIDs. With such a setup, you might then use the Standalone approach for managing the ASCS/ERS instances for the ABAP stack and the SCS/ERS instances for the Java stack. You must configure separate resource groups for each instance and set up appropriate constraints based on the separate SIDs for each part of the environment. Follow the configuration guide: Configure SAP NetWeaver ASCS/ERS ENSA1 with Standalone Resources in RHEL 7.5 and Later: https://access.redhat.com/articles/3569681