Chapter 2. Planning the HA cluster setup

The solutions for SAP HANA in a Pacemaker cluster for High Availability (HA) are provided in dedicated repositories. The RHEL for SAP Solutions subscription is required to access all relevant content. In addition to the standard RHEL repos the subscription provides access to the following repos, which are required to set up the SAP HANA HA solution:

The <arch> denotes the specific hardware architecture:

Example list of repositories enabled as part of the RHEL for SAP Solutions subscription:

[root]# dnf repolist
Updating Subscription Management repositories.
repo id                                     repo name
rhel-9-for-x86_64-appstream-e4s-rpms        Red Hat Enterprise Linux 9 for x86_64 - AppStream - Update Services for SAP Solutions (RPMs)
rhel-9-for-x86_64-baseos-e4s-rpms           Red Hat Enterprise Linux 9 for x86_64 - BaseOS - Update Services for SAP Solutions (RPMs)
rhel-9-for-x86_64-highavailability-e4s-rpms Red Hat Enterprise Linux 9 for x86_64 - High Availability - Update Services for SAP Solutions (RPMs)
rhel-9-for-x86_64-sap-netweaver-e4s-rpms    Red Hat Enterprise Linux 9 for x86_64 - SAP NetWeaver - Update Services for SAP Solutions (RPMs)
rhel-9-for-x86_64-sap-solutions-e4s-rpms    Red Hat Enterprise Linux 9 for x86_64 - SAP Solutions - Update Services for SAP Solutions (RPMs)

Deploy your host operating system as described in Installing RHEL 9 for SAP Solutions.

Follow SAP Note 3108302 - SAP HANA DB: Recommended OS Settings for RHEL 9 to configure architecture specific settings, kernel parameters and check the minimum required Linux kernel and HANA versions.

Apply the operating system post-installation configuration for SAP HANA hosts as described in SAP Note 3108316 - Red Hat Enterprise Linux 9.x: Installation and Configuration.

Root privileges

For the HANA installation and the cluster HA setup the root user or a privileged user that can run any sudo commands is required.

You can find information about Sizing SAP HANA in the SAP HANA Master Guide.

There is no communication between both scale-out environments on the storage level. As a result, you must complete the storage configuration on each scale-out environment before installing the HANA instances.

For the setup of a scale-out SAP HANA environment with HANA system replication between two HANA sites you can configure the storage as shared or non-shared.

Shared storage

Configure 3 NFS shares for the mountpoints /hana/data, /hana/log, /hana/shared. For each HANA site you must create a dedicated set of the shares.

Example NFS storage details for the HANA instance in datacenter 1:

Example NFS storage details for the HANA instance in datacenter 2:

Non-shared storage

A non-shared storage configuration requires the integration of the storage connector. The storage connector manages access to the LUNs or LVM devices over SCSI or LVM locking mechanisms. You can only use this method for /hana/data and /hana/log.

Use the SAP HANA Fiber Channel Storage Connector Admin Guide for the setup of non-shared storage.

For /hana/shared you must configure an NFS share for each instance, even if you use non-shared storage for /hana/data and /hana/log.

You can find information about SAP HANA network architecture considerations in the SAP HANA Administration Guide.

For the SAP HANA system replication setup in a HA cluster we recommend that you configure dedicated networks and connections for the cluster communication traffic, which is separate from any HANA network traffic.

Fencing

For a supported HA cluster setup using the RHEL HA Add-on you must configure a fencing or STONITH device on each cluster node. Which fencing or STONITH device you can use depends on the platform the cluster is running on. Check the Support Policies for RHEL High Availability Clusters - Fencing/STONITH for recommendations on fencing agents or consult your hardware or cloud provider to find out which fence device is supported on their platform.

Quorum

HANA environments with HANA system replication managed by a Pacemaker cluster in a performance-optimized setup always consist of an even number of HANA nodes. Each cluster member automatically counts as one vote in the quorum calculations, which the cluster uses to decide which nodes can continue running when there is a communication disruption between the nodes. An even number of cluster nodes can lead to a 50/50 split and there is a risk of a split-brain situation, where both partitions continue running and cause conflicts or data corruption in the running services.

We highly recommend that you configure an additional quorum vote in the cluster to have an odd number of votes and improve the availability of the service even during multiple cluster interconnect failures. See Exploring Concepts of RHEL High Availability Clusters - Quorum for more details about the concept and its benefits.

You can use a qdevice or an additional cluster node to add a quorum vote to your cluster. Both methods require a separate host and have different advantages and limitations that you must consider.

See Configuring a quorum device in the cluster for the configuration steps of the following quorum device methods:

The sap-hana-ha package provides the combined resource agents which support setups with SAP HANA 2.0 SPS05 rev 59.04 or newer.

To prepare the HANA setup you can define a list of parameters that you require for the installation and configuration of the planned environment.

Example SAP HANA configuration parameters are show below: