Edit

Deploy SAP ASCS/ERS with SAP HANA high-availability VMs on RHEL

  • Article

This article describes how to install and configure SAP HANA along with ABAP SAP Central Services (ASCS)/SAP Central Services (SCS) and Enqueue Replication Server (ERS) instances on the same high-availability cluster running on Red Hat Enterprise Linux (RHEL).

References

Overview

This article describes the cost-optimization scenario where you deploy SAP HANA, SAP ASCS/SCS, and SAP ERS instances in the same high-availability setup. To minimize the number of VMs for a single SAP system, you want to install SAP ASCS/SCS and SAP ERS on the same hosts where SAP HANA is running. With SAP HANA being configured in a high-availability cluster setup, you want SAP ASCS/SCS and SAP ERS also to be managed by cluster. The configuration is basically an addition to an already configured SAP HANA cluster setup. In this setup, SAP ASCS/SCS and SAP ERS are installed on a virtual host name, and its instance directory is managed by the cluster.

The presented architecture showcases NFS on Azure Files or Azure NetApp Files for a highly available instance directory for the setup.

The example shown in this article to describe deployment uses the following system information:

Instance name Instance number Virtual host name Virtual IP (Probe port)
SAP HANA DB 03 saphana 10.66.0.13 (62503)
ABAP SAP Central Services (ASCS) 00 sapascs 10.66.0.20 (62000)
Enqueue Replication Server (ERS) 01 sapers 10.66.0.30 (62101)
SAP HANA system identifier HN1 --- ---
SAP system identifier NW1 --- ---

Note

Install SAP dialog instances (PAS and AAS) on separate VMs.

Diagram that shows the architecture of an SAP HANA, SAP ASCS/SCS, and ERS installation within the same cluster.

Important considerations for the cost-optimization solution

  • SAP dialog instances (PAS and AAS) (like sapa01 and sapa02) should be installed on separate VMs. Install SAP ASCS and ERS with virtual host names. To learn more about how to assign a virtual host name to a VM, see the blog Use SAP Virtual Host Names with Linux in Azure.
  • With an HANA DB, ASCS/SCS, and ERS deployment in the same cluster setup, the instance number of HANA DB, ASCS/SCS, and ERS must be different.
  • Consider sizing your VM SKUs appropriately based on the sizing guidelines. You must factor in the cluster behavior where multiple SAP instances (HANA DB, ASCS/SCS, and ERS) might run on a single VM when another VM in the cluster is unavailable.
  • You can use different storage (for example, Azure NetApp Files or NFS on Azure Files) to install the SAP ASCS and ERS instances.

    Note

    For SAP J2EE systems, it's not supported to place /usr/sap/<SID>/J<nr> on NFS on Azure Files. Database file systems like /hana/data and /hana/log aren't supported on NFS on Azure Files.

  • To install more application servers on separate VMs, you can either use NFS shares or a local managed disk for an instance directory file system. If you're installing more application servers for SAP J2EE system, /usr/sap/<SID>/J<nr> on NFS on Azure Files isn't supported.
  • See NFS on Azure Files considerations and Azure NetApp Files considerations because the same considerations apply to this setup.

Prerequisites

The configuration described in this article is an addition to your already-configured SAP HANA cluster setup. In this configuration, an SAP ASCS/SCS and ERS instance are installed on a virtual host name. The instance directory is managed by the cluster.

Install a HANA database and set up a HANA system replication (HSR) and Pacemaker cluster by following the steps in High availability of SAP HANA on Azure VMs on Red Hat Enterprise Linux or High availability of SAP HANA Scale-up with Azure NetApp Files on Red Hat Enterprise Linux depending on what storage option you're using.

After you install, configure, and set up the HANA Cluster, follow the next steps to install ASCS and ERS instances.

Configure Azure Load Balancer for ASCS and ERS

This article assumes that you already configured the load balancer for a HANA cluster setup as described in Configure Azure Load Balancer. In the same Azure Load Balancer instance, follow these steps to create more front-end IPs and load-balancing rules for ASCS and ERS.

  1. Open the internal load balancer that was created for SAP HANA cluster setup.
  2. Frontend IP Configuration: Create two front-end IPs, one for ASCS and another for ERS (for example, 10.66.0.20 and 10.66.0.30).
  3. Backend Pool: This pool remains the same because we're deploying ASCS and ERS on the same back-end pool.
  4. Inbound rules: Create two load-balancing rules, one for ASCS and another for ERS. Follow the same steps for both load-balancing rules.
  5. Frontend IP address: Select the front-end IP.
    1. Backend pool: Select the back-end pool.
    2. High availability ports: Select this option.
    3. Protocol: Select TCP.
    4. Health Probe: Create a health probe with the following details (applies for both ASCS and ERS):
      1. Protocol: Select TCP.
      2. Port: For example, 620<Instance-no.> for ASCS and 621<Instance-no.> for ERS.
      3. Interval: Enter 5.
      4. Probe Threshold: Enter 2.
    5. Idle timeout (minutes): Enter 30.
    6. Enable Floating IP: Select this option.

The health probe configuration property numberOfProbes, otherwise known as Unhealthy threshold in the Azure portal, isn't respected. To control the number of successful or failed consecutive probes, set the property probeThreshold to 2. It's currently not possible to set this property by using the Azure portal. Use either the Azure CLI or the PowerShell command.

Important

Floating IP isn't supported on a NIC secondary IP configuration in load-balancing scenarios. For more information, see Azure Load Balancer limitations. If you need more IP addresses for the VMs, deploy a second NIC.

When VMs without public IP addresses are placed in the back-end pool of an internal (no public IP address) Standard Azure Load Balancer instance, there's no outbound internet connectivity unless more configuration is performed to allow routing to public endpoints. For steps on how to achieve outbound connectivity, see Public endpoint connectivity for virtual machines using Azure Standard Load Balancer in SAP high-availability scenarios.

Important

Don't enable TCP timestamps on Azure VMs placed behind Azure Load Balancer. Enabling TCP timestamps causes the health probes to fail. Set the parameter net.ipv4.tcp_timestamps to 0. For more information, see Load Balancer health probes.

SAP ASCS/SCS and ERS setup

Based on your storage, follow the steps described in the following articles to configure a SAPInstance resource for the SAP ASCS/SCS and SAP ERS instance in the cluster.

Test the cluster setup

Thoroughly test your Pacemaker cluster: