Chapter 2. Requirements 2.1. Subscription and repositories It's important to keep the subscription, kernel, and patch level identical on all cluster nodes. For more information on how to enable the correct subscription and repositories, check RHEL for SAP Subscriptions and Repositories . 2.2. Pacemaker Resource Agents For a pacemaker-based HA cluster to manage both SAP HANA System Replication and also ENSA2 the following resource agents are required. 2.2.1. SAPInstance The SAPInstance resource agent will be used for managing the ASCS and ERS resources in this example. All operations of the SAPInstance resource agent are done by using the SAP start-up service framework sapstartsrv . 2.2.2. SAPHanaTopology (Cloned Resource) This resource agent is is gathering status and configuration of SAP HANA System Replication on each cluster node. It is essential to have the data from this agent present in cluster node attributes for SAPHana resource agent to work properly. 2.2.3. SAPHana (Promotable Cloned resource) This resource is responsible for starting, stopping, and relocating (failover) of SAP HANA database. This resource agent takes information gathered by SAPHanaTopology and based on that it is interacting with SAP HANA database to do things. It also adds additional information to cluster node attributes about SAP HANA status on cluster nodes. 2.2.4. filesystem Pacemaker cluster resource-agent for Filesystem. It manages a Filesystem on a shared storage medium exported by NFS or iSCSI etc. 2.2.5. IPaddr2 (or other RAs for managing VIPs on CCSPs) Manages virtual IPv4 and IPv6 addresses and aliases. 2.3. SAP S/4HANA High-Availability Architecture A typical Cost-Optimized setup for SAP S/4HANA High-Availability consists of 2 distinct components: SAP S/4HANA ASCS/ERS cluster resources Database: SAP HANA with System Replication Please refer to Automating SAP HANA Scale-Up System Replication using the RHEL HA Add-On , for more details. This article focuses on the setup of SAP S/4HANA HA environment where both SAP HANA System Replication and the ASCS and ERS instances are managed by a single cluster. This is done using the RHEL HA add-on and the corresponding HA solutions for SAP, available as part of RHEL for SAP Solutions. 2.4. Two node cluster environment Since this is a Cost-Optimized scenario, we will focus only on a 2-node cluster environment. ENSA1 can only be configured in a 2-node cluster where the ASCS can failover to the other node where the ERS is running. ENSA2, on the other hand, supports running more than 2 nodes in a cluster; however, SAP HANA scale-up instances are limited to 2-node clusters only, therefore, this Cost-Optimized document keeps everything simple by using only 2 nodes in the cluster. Note : Below is the architecture diagram of the example installation of a 2-node cluster setup which this article focuses on, with a separate section on the design and configuration of the additional SAP HANA instances with System Replication. Note that ASCS or SAP HANA primary instances can failover to the other node independently of each other. 2.5. Storage requirements Directories created for S/4HANA installation should be put on shared storage, following the below-mentioned rules: 2.5.1. Instance Specific Directory There must be a separate SAN LUN or NFS export for the ASCS and ERS instances that can be mounted by the cluster on each node. For example, as shown below, 'ASCS' and 'ERS' instances, respectively, the instance specific directory must be present on the corresponding node. ASCS node: /usr/sap/SID/ASCS<Ins#> ERS node: /usr/sap/SID/ERS<Ins#> Both nodes: /hana/ Note : As there will be System Replication, the /hana/ directory is local that is non-shared on each node. Note : For the Application Servers, the following directory must be made available on the nodes where the Application Server instances will run: App Server Node(s) (D<Ins#>): /usr/sap/SID/D<Ins#> When using SAN LUNs for the instance directories, customers must use HA-LVM to ensure that the instance directories can only be mounted on one node at a time. When using NFS exports, if the directories are created on the same directory tree on an NFS file server, such as Azure NetApp Files or Amazon EFS, the option force_unmount=safe must be used when configuring the Filesystem resource. This option will ensure that the cluster only stops the processes running on the specific NFS export instead of stopping all processes running on the directory tree where the exports are created. 2.5.2. Shared Directories The following mount points must be available on ASCS, ERS, HANA, and Application Servers nodes. /sapmnt /usr/sap/trans /usr/sap/SID/SYS Shared storage can be achieved by: using the external NFS server (NFS server cannot run on any of the nodes inside the cluster in which the shares would be mounted. More details about this limitation can be found in the article Hangs occur if a Red Hat Enterprise Linux system is used as both NFS server and NFS client for the same mount ) using the GFS2 filesystem (this requires all nodes to have Resilient Storage Add-on ) using the glusterfs filesystem (check the additional notes in the article Can glusterfs be used for the SAP NetWeaver shared filesystems? ) These mount points must be either managed by the cluster or mounted before the cluster is started.

Commands: