Red Hat HA Solutions for SAP HANA, S/4HANA and NetWeaver based SAP Applications
Making open source more inclusive
Red Hat is committed to replacing problematic language in our code and documentation. We are beginning with these four terms: master, slave, blacklist, and whitelist. Due to the enormity of this endeavor, these changes will be gradually implemented over upcoming releases. For more details on making our language more inclusive, see our CTO Chris Wright’s message.
Providing feedback on Red Hat documentation
We appreciate your feedback on our documentation. Let us know how we can improve it.
Submitting comments on specific passages
- View the documentation in the Multi-page HTML format and ensure that you see the Feedback button in the upper right corner after the page fully loads.
- Use your cursor to highlight the part of the text that you want to comment on.
- Click the Add Feedback button that appears near the highlighted text.
- Add your feedback and click Submit.
Chapter 1. Introduction
For organisations running SAP production applications, it is essential to ensure the highest possible uptime for their mission critical applications by deploying them in a highly available configuration. With Red Hat HA Solutions for SAP HANA, S/4HANA and NetWeaver based SAP Applications, Red Hat provides such customers with a set of solutions to set up highly available SAP environments on top of the industry leading Red Hat Enterprise Linux High Availability cluster framework.
The Red Hat Enterprise Linux High Availability Add-On provides all the necessary packages for configuring a pacemaker-based cluster that provides reliability, scalability, and availability to critical production services. On top of this, the Red Hat HA Solutions for SAP HANA, S/4HANA and NetWeaver based SAP Applications also allow for setup and configuration of highly available SAP HANA, S/4HANA and NetWeaver based SAP Applications, providing a standard-based approach to reducing planned and unplanned downtime in the corresponding SAP environment.
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
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
2.2.2. Performance Optimized
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.
126.96.36.199. 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
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.
188.8.131.52. Configuration Guides
- On-Premise: Automating Cost-Optimized SAP HANA Scale-Up System Replication using the RHEL HA Add-On
- IBM Power System Virtual Server: Configuring SAP HANA Cost-Optimized Scale-Up System Replication in a RHEL HA Add-On cluster
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.
184.108.40.206. Configuration Guides
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.
220.127.116.11. Configuration Guide
- IBM Power System Virtual Server: Configuring SAP HANA multitier system replication in a RHEL HA Add-On cluster
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.
18.104.22.168. Configuration Guide
2.3. Supported Scenarios for Automated SAP HANA Scale-Out System Replication
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
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:
Chapter 3. HA Solution for S/4HANA based on ABAP Platform 1809 or newer
3.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 fails, it can start on a separate node in the cluster, and copy the lock entries from the enqueue replicator 2.
In ABAP platform 1809 or newer, the Standalone Enqueue Server 2 (ENSA2) has become the default installation.
3.2. Supported Scenarios
Because in ENSA2 ASCS doesn’t have to “follow” ERS, that makes a multi-node cluster possible
Upgraded two-node cluster can easily adjust the setup to switch from ENSA1 to ENSA2
Brand new installations 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.
3.3. Support Policies
3.4. Configuration Guides
- On-Premise: Configuring SAP S/4HANA ASCS/ERS with Standalone Enqueue Server 2 (ENSA2) in Pacemaker
- AWS: Configure SAP S/4HANA ASCS/ERS ENSA2 on Amazon Web Services (AWS)
- Azure with GlusterFS: Azure Virtual Machines high availability for SAP NetWeaver on Red Hat Enterprise Linux with GlusterFS
- Azure with NetApp: Azure Virtual Machines high availability for SAP NetWeaver on Red Hat Enterprise Linux with Azure NetApp Files for SAP applications
- Azure with NFS: High availability for SAP NetWeaver on Azure VMs on Red Hat Enterprise Linux with NFS on Azure Files
- GCP: HA cluster configuration guide for SAP NetWeaver on RHEL
- IBM Power System Virtual Server: Configuring high availability for SAP S/4HANA (ASCS and ERS) in a RHEL HA Add-On cluster
3.5. Cost-Optimized SAP S/4HANA HA setup (HANA System Replication and ENSA2 combined)
With current versions of S/4HANA, it is also possible to run HANA and ABAP Application Server instances on the same system. This makes it possible to have a "cost-optimized" S/4HANA setup where both HANA System Replication and ENSA2 are managed by a single cluster running on the same cluster nodes.
For more information, please refer to Configuring a Cost-Optimized SAP S/4HANA HA cluster (HANA System Replication + ENSA2) using the RHEL HA Add-On.
Chapter 4. HA Solution for NetWeaver or S/4 Based on ABAP Platform 1709 or older
4.1. Standalone Enqueue Server 1 (ENSA1)
When using the old Standalone Enqueue Server (ENSA1), the ASCS instance has to fail over the cluster node where the active ERS instance is running and it must be ensured that the ERS instance is shut down and moved to the node where the ASCS instance was running when it was online. This is because the ASCS instance has to access the shared memory where the ERS instance maintains a copy of the enqueue lock table to continue to keep track of the enqueue locks of active transactions. ENSA1 is supported in pacemaker as a two-node cluster configuration, mainly because of the restriction that the ASCS instance must “follow” the ERS instance.
4.2. Supported Scenarios
Two node cluster
For ENSA1 the ASCS instance must always move to the node where the ERS instance is running
Supported by Master/Slave Resources in all RHEL 7.x releases
4.2.1. ABAP/Java Dual-Stack
ABAP/JAVA Dual-Stack is supported using the Master/Slave methodology, that’s supported in all RHEL 7.x minor releases. Please follow the configuration guide: Configure (A)SCS/ERS SAPInstance cluster resource.
However, since SAP no longer recommends dual-stack setups where both ABAP and JAVA instances share the same SID, it would be better to consider doing a Dual-Stack Split, so that the ABAP and JAVA stack will use separate SIDs. With such a setup you then could use the Standalone approach for managing the ASCS/ERS instances for the ABAP stack and the SCS/ERS instances for the JAVA stack. You need to configure separate resource groups for each instance and set up appropriate constraints based on the separate SIDs for each part of the environment. Please follow configuration guide: Configuring SAP NetWeaver ASCS/ERS ENSA1 with Standalone Resources in RHEL 7.5+ and RHEL 8.
4.3. Support Policies
4.4. Configuration Guides
- On-Premise: Configuring SAP NetWeaver ASCS/ERS ENSA1 with Standalone Resources in RHEL 7.5+ and RHEL 8
- AWS: Configure SAP NetWeaver ASCS/ERS ENSA1 on Amazon Web Services (AWS)
- Azure: Azure Virtual Machines high availability for SAP NetWeaver on Red Hat Enterprise Linux with GlusterFS
- Azure: Azure Virtual Machines high availability for SAP NetWeaver on Red Hat Enterprise Linux with Azure NetApp Files for SAP applications
- Azure: High availability for SAP NetWeaver on Azure VMs on Red Hat Enterprise Linux with NFS on Azure Files
- GCP: HA cluster configuration guide for SAP NetWeaver on RHEL