The Need for High Available Solutions
Modern day business demands 24x7 operations which in turn requires a highly available application infrastructure. I often see SAP Consultants asking questions about how to prepare their SAP system or landscape for a highly available infrastructure. This question becomes even more important as more and more customer are now moving to S/4HANA solutions.
This blog is intended for SAP administrators and consultants who want to understand and know basic fundamentals and required configuration for setting up a Highly Available SAP system.
In this blog I will be describing how to set up a two-node cluster solution for a SAP S/4HANA System. and will be using below use case:
- SAP Application - S/4HANA 2020
- Operating System - RHEL 8
- Resource Manager - Pacemaker
Let's Plan It Out
Before planning the installation and configuration, version specific Release Information Notes for S/4HANA should always be considered. Belo table shares a mapping between S/4HANA versions and their associated Release Information Notes:
| S/4HANA Version | Release Information Note |
| S/4HANA 2022 | 3145277 |
| S/4HANA 2021 | 3015539 |
| S/4HANA 2020 | 2884313 |
| S/4HANA 1909 | 2769531 |
The entire process for configuring a high available SAP solution can be broadly divided into three phase:
Phase #1: Preparing SAP S/4HANA application for clustering
Phase #2: Installing all instances of High Available SAP S/4HANA application on cluster
Phase #3: Configuring SAP Clustering via Pacemaker (RHEL) for fail overs
The concept of High Availability in S/4HANA or any new SAP Product is based on Standalone Enqueue Server 2 (ENSA2). It is to be noted starting with ABAP Platform 1809, ENSA2 is installed by default and from ABAP Platform 2020 onwards, Standalone Enqueue Server 2 (and Enqueue Replicator 2 for high-availability scenarios) is the only available option.
To understand all necessary details regarding the concept, implementation considerations, configuration, administration and monitoring of ENSA2, it is highly recommended to check SAP's standard documentation Standalone Enqueue Server 2.
Additionally, SAP Note 2711036 provides the list of all HA solutions currently available in market.
Before starting detailed journey to understand and execute above phases, let me take a minute to help you understand the components for a High Available SAP system.
SAP S/4HANA High-Availability Architecture
This blog focuses on the configuration of SAP S/4 ASCS and ERS in a RHEL-Pacemaker Cluster. Considering this, a typical setup for a High-Available SAP system will consist of 3 major components:
- SAP ASCS and ERS application instances and cluster resources.
- SAP application servers - Primary Application Server (PAS) and Additional Application Servers (AAS)
- Database: SAP HANA 2.0 SP05+
High Available SAP S/4HANA System
Phase #1: Preparing SAP S/4HANA application for clustering
In this phase, you have to carry out below activities:
- Understanding the Directory Structure for Clustering
- Understanding the Configuration
Understanding the directory structure for clustering
The directory structuring can be grouped into two categories for a highly available solution:
- Instance Specific Directories
- Shared Directories
Instance Specific Directory
For clustering it is important to understand that the directories should be based only on SAN LUN or NFS or else moving resource from one cluster to another will require a lot of manual tasks and workaround. An opinion from your System Admin or Linux Administrator will also help understanding if you need SAN LUN or NFS.
- /usr/sap/SID/ASCS<nn> : to be mounted on ASCS instance
- /usr/sap/SID/ERS<nn> : to be mounted on ERS instance
Above two directories will later be added to Pacemaker resources groups and will play a key role for fail-overs.
Similarly for SAP Application Servers, the instance directory should be made available on corresponding node designated for the Application Server instance:
- App Server D<nn>: /usr/sap/SID/D<nn>
As shown in the architecture diagram, i am building 2 application instances - D10 and D20
Shared Directories
The following mount points must be available on all instances/nodes - ASCS instance, ERS instance and Application Servers instance.
- /sapmnt
- /usr/sap/trans
- /usr/sap/SID/SYS
Nomenclature for SAP Instances used in this blog
Below are nomenclature that will be used for instances in this blog:
Two nodes will be running the ASCS and ERS instances in pacemaker. I will be using nomenclature as shared in below table:
- SID: S4H
- Node A hostname: sapnode1
- Node B hostname: sapnode2
- ASCS Instance number: 01
- ASCS virtual hostname: sapascs
- Virtual IP tagged to virtual host sapascs
- ERS Instance number: 02
- ERS virtual hostname: sapers
- Virtual IP tagged to virtual host sapers
SAP Application Instances will be configured outside the two-node cluster:
- PAS Instance number: 10
- AAS Instance number: 20
Phase #2: Installing all instances of High Available SAP S/4HANA application on cluster
Before you start installation of SAP instances, make sure below prerequisites are already met:
- Installation of HANA Database: The S/4HANA application will run on top of HANA Database. So as a basic prerequisite, installation of HANA Database should be completed before starting the application installation.
- Maintenance Planner: You should have generated stack file for intended S/4HANA version and downloaded the media.
Installation of ASCS Instance
As already covered in Phase #1, following file systems should be mounted on sapnode1 where ASCS will be installed:
- /usr/sap/S4H/ASCS01
- /usr/sap/S4H/SYS
- /usr/sap/trans
- /sapmnt
Virtual IP for sapascs should be enabled on sapnode1.
Run the SAP Installer (SWPM) and select High Availability System. Make sure you are passing virtual host for ASCS as a parameter to sapinst:
./sapinst SAPINST_REMOTE_ACCESS_USER=<sid>adm SAPINST_STACK_XML=<Path_to_Stack.xml> SAPINST_USE_HOSTNAME=sapascs
SWPM Run for ASCS Instance
Follow subsequent SWPM screens to install ASCS instance
Installation of ERS Instance
Just like you did for ASCS, following file systems should be mounted on sapnode2 where ERS will be installed:
- /usr/sap/S4H/ERS02
- /usr/sap/S4H/SYS
- /usr/sap/trans
- /sapmnt
Virtual IP for sapers should be enabled on sapnode2.
Run the SAP Installer (SWPM) and select High Availability System. Make sure you are passing virtual host for ERS as a parameter to sapinst:
./sapinst SAPINST_REMOTE_ACCESS_USER=<sid>adm SAPINST_STACK_XML=<Path_to_Stack.xml> SAPINST_USE_HOSTNAME=sapers
SWPM Run for ERS Instance
Follow subsequent SWPM screens to install ERS instance
Installation of Database Instance
This is an important run for installing S/4 Application and I have seen many consultants skipping this step and later face issues with application to database communication. Even if you have already installed Hana Database, the SWPM run for Database Instance is equally important. This run will create required S/4HANA schemas and users in the database and place the core components as well.
SWPM Run for DB Instance
Installation of Primary Application Server Instance
Next run of SWPM will be installing Primary Application Server Instance on Node A (sapnpde1)
SWPM Run for PAS
Installation of Additional Application Server Instance
the last run for SWPM will be for installing Additional Application Server Instance on Node B (sapnode2).
Phase #3: Configuring SAP Clustering - Utilizing Pacemaker for Fail Overs
This is the final phase where I will be setting up SAP clustering by utilizing Pacemaker on Linux environment (RHEL).
This phase can be further divided into two sub-phases:
Phase #3.a: Post Installation modifications on SAP services.
Phase #3.b: Adapting Pacemaker for Fail Overs. This phase should be carried by a System Admin or RHEL Administrator.
Phase #3.a: Post Installation modifications on SAP services
ASCS Profile Modification
Modify ASCS instance profile to prevent automatic restart of enqueue server as it will be managed by cluster. To do this, run the following command at your ASCS profile present in profile directory:
sed -i -e 's/Restart_Program_<NN>/Start_Program_01/' /sapmnt/S4H/profile/<ASCS_Profile>
ERS Profile Modification
Modify ERS profile to prevent automatic restart as it will be managed by cluster. To do this, run the following command at your ERS profile present in profile directory:
[sed -i -e 's/Restart_Program_NN/Start_Program_00/' /sapmnt/S4H/profile/<ERS_Profile>
Update the /usr/sap/sapservices file
On both sapnode1 and sapnode2, make sure following two lines are commented out in /usr/sap/sapservices file:
#LD_LIBRARY_PATH=/usr/sap/S4H/ERS02/exe:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH; /usr/sap/S4H/ERS02/exe/sapstartsrv pf=/usr/sap/S4H/SYS/profile/S4H_ERS02_sapers -D -u s4hadm
#LD_LIBRARY_PATH=/usr/sap/S4H/ASCS01/exe:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH; /usr/sap/S4H/ASCS01/exe/sapstartsrv pf=/usr/sap/S4H/SYS/profile/S4H_ASCS01_sapascs -D -u s4hadm
Phase #3.b: Adapting Pacemaker for Fail Overs
This phase should be carried by a System Admin or RHEL Administrator and is the last phase to enable to fail overs. I am listing out the steps in order of sequence they have to be followed.
Installing Pacemaker
- To understand how Pacemaker utilizes resource groups and constraints, its installation and configuration on RHEL, a detailed guide can be accessed here: Configuring and managing high availability clusters on RHEL
Install "Resource Agent SAP" on both cluster nodes
Setting Up Resource Groups
- Create resource for virtual IP address for ASCS instance
- Create resource for ASCS filesystem
- Create resource for ASCS instance
- Create resource for virtual IP address for ERS instance
- Create resource for ERS filesystem
- Create resource for ERS instance
Setting Up Constraints
- It is always advisable to use colocation and order constraints for high available solutions. Both of these constraints comply simple login and will help you troubleshoot unsuccessful fail overs.
- It is important to understand that for smooth fail overs, ASCS and ERS must avoid running on same host. That is why colocation constraint for ASCS and ERS resource groups are needed.
- As ASCS should be start prior to ERS, I will suggest to create an order constraint as well for ASCS and ERS Resource Groups.
(Optional)
If you intend to achieve high-availability for SAP Application Servers as well, simply proceed and Create Virtual IP address for PAS instance followed by creation of resource for PAS and AAS filesystem
Once you complete above configuration, you are ready to test fail over scenarios.
I hope this blog helped you understand and execute a high available project for S/4HANA.
Thankyou
- SAP Managed Tags:
8 Comments
