HA Solutions for SAP HANA using SAPHanaSR-angi #

The infrastructure can be on-premises, physical, virtual or in public cloud. The infrastructure must be supported by both SAP and SUSE Linux Enterprise High Availability so that important functions like fencing and virtual IP are supported.

Public cloud deployment usually needs additional documentation focusing on the cloud-specific implementation details. Check the documentation provided by the respective public cloud vendor.

The support details for SUSE's High Availability solutions for SAP and the support process for each public cloud vendor are defined in the following SAP Notes:

For more details, see the SUSE knowledgebase article SLES for SAP - How To Engage SAP and SUSE to address Product Issues.

Note

If necessary, all documented SUSE Linux Enterprise High Availability scenarios can run the SAP workload while the High Availability cluster is temporarily disabled.

This document applies to SUSE Linux Enterprise Server for SAP applications 16 and 15.

The general SUSE software lifecycle applies for the described scenarios. See the SUSE lifecycle page for details:

https://www.suse.com/lifecycle/#suse-linux-enterprise-server-for-sap-applications-16

https://www.suse.com/lifecycle/#suse-linux-enterprise-server-for-sap-applications-15

SAP HANA system replication (HSR) provides the ability to copy and continuously synchronize an SAP HANA database to a secondary location in the same or another data center. SAP HANA system replication is implemented between two different SAP HANA systems with the same number of active nodes. After system replication is set up between the two systems, it replicates all the data from the primary SAP HANA system to the secondary SAP HANA system (initial copy). After this, any logged changes in the primary system are also sent to the secondary system.

Figure 1: Overview of system replication with single nodes #

  

If the primary SAP HANA system fails, the system administrator must perform a manual takeover. Takeover can be performed using SAP HANA Cockpit or the command line. Manual failover requires continuous monitoring and could lead to higher recovery time. To automate the failover process, SUSE Linux Enterprise High Availability can be used. Using High Availability for the takeover process helps customers achieve service-level agreements for SAP HANA downtime by enabling faster recovery without any manual intervention.

Multiple SAP HANA High Availability scenarios are supported based on SAP HANA system replication. For variations, contact SUSE to discuss defining a PoC for a scenario that is not mentioned in the documentation.

You can use SAP HANA Fast Restart on RAM-tmpfs and SAP HANA on persistent memory if they are transparent to the High Availability cluster. On SLES for SAP 16, virtual persistent memory (vPMEM) is still supported, but Physical PMEM (Intel Optane) is not supported.

SAP HANA Native Storage Extension (NSE) is supported in High Availability solutions for automated SAP HANA system replication in both Scale-up and Scale-out. This feature does not change the SAP HANA topology or interfaces to the High Availability cluster. However, unlike SAP HANA NSE, the HANA Extension Nodes do change the topology and are therefore not currently supported by SUSE Linux Enterprise High Availability. Refer to the SAP documentation for details of SAP HANA NSE and its functional restrictions.

To provide a streamlined High Availability solution, SUSE is evolving its SAP HANA clustering infrastructure away from legacy, decade-old code bases. The traditional framework required administrators to manage two distinct resource agents: SAPHanaSR for scale-up topologies and SAPHanaSR-ScaleOut for scale-out topologies. This architectural division is being consolidated into SAPHanaSR-angi (Advanced Next Generation Interface), a unified, single code base engineered to sustain reliable High Availability for SAP HANA over the next decade.

This evolution drastically reduces operational complexity by introducing an identical software package and highly similar configuration models regardless of the underlying scale-up or scale-out environment. Although the classic resource agents will remain supported for the entire lifetime of SLES for SAP 15, SAPHanaSR-angi is also available in SLES for SAP 15 SP4+. This is the recommended choice for all new deployments, and will completely replace the classic resource agents as the default standard in SLES for SAP 16.

Along with optimizations like faster takeover capabilities, SAPHanaSR-angi also supports a live, in-place upgrade from the classic resource agents, without requiring any SAP HANA downtime.

This table shows the notation formula used in the following sections to describe the different configurations for SAP HANA system replication.

Below is a summary of the most common and newly supported configurations for SAPHanaSR-angi. For the complete support matrix for all supported topologies, see Section 3, “Support matrix for automated SAP HANA system replication”.

Tip: SAPHanaSR-angi configuration variants

SAPHanaSR-angi introduces two configuration variants that allow administrators to choose the failover behavior that best aligns with their operational and availability requirements. While both variants provide High Availability for SAP HANA, they differ in how they respond to failures and balance recovery speed against service stability.

• Progressive variant: Optimized for rapid recovery by proactively fencing the affected site when critical SAP HANA or file system failures are detected, enabling fast and reliable failover. This is the recommended option for most new deployments, particularly in cloud and performance-optimized environments.

• Conservative variant: Prioritizes service stability by attempting to recover SAP HANA locally before fencing cluster nodes, reducing the likelihood of unnecessary fencing. This variant is best suited for traditional on-premises environments where maximizing local recovery is preferred over the fastest possible failover.