Enterprise Resource Planning Blogs by Members
Gain new perspectives and knowledge about enterprise resource planning in blog posts from community members. Share your own comments and ERP insights today!
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 

Setting Up S4/HANA Application for High Availability

rachit1507
Explorer
‎2023 Jun 01 3:14 PM
9,357

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.

 


  • 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

 
9 Comments
Labels in this area
Popular Blog Posts