What are SAPHanaSR-angi configuration variants?

SAPHanaSR-angi is the SAPHanaSR Advanced Next Generation Interface. It aimes to ensure SUSE HA for SAP HANA over the next decade.

Picture: Variants

I this blog article you learn about SAPHanaSR-angi configuration variants. You will learn which variants are available, what they do and how to choose the right one.

Which variants are available and what do they do?

SAPHanaSR-angi allows to define different variants of reaction on failures. In theory several measures could be chosen in arbitrary combinations. In practice two defined sets of measure give two useful configuration variants.

Conservative variant

The cluster is patient, it prefers stopping HANA over fencing nodes. It does not react on filesystem failures. Prominent examples are the stop/start reaction on HANA call timeout and the lengthy timeout period in case of a failed /hana/shared/ filesystem.

The conservative configuration variant was introduced with classical on-premise deployments in mind. It works well in environments where failures usually are causing long duration outage, but are expected to happen really seldom.

The conservative variant is quite similar to the old-style SAPHanaSR configuration and behavior. So it obviously is the configuration after an upgrade from SAPHanaSR to SAPHanaSR-angi. It also is the default described in the very first SAPHanaSR-angi scale-up performance-optimized setup guide.

This configuration does not fit well for environments where short time outage are happening often. It also is sub-optimal for SAPHanaSR-angi scale-out performance-optimized deployments without HANA  host auto-failover (aka ERP style).

Progressive variant

The cluster reacts on failures of HANA or filesystem with fencing all nodes of the affected site. Also HANA landscape status FATAL and HANA call timeout will trigger a fencing. Further for scale-out the impact of nodes rejoining the cluster on HANA takeover is reduced.

The progressive configuration variant was introduced based on requirements from current cloud deployments. It primarily is meant for HANA scale-up performance-optimized and scale-out performance-optimized without standby nodes. This configuration variant gives short takeover time in case of filesystem failures and HANA call timeouts. That means it makes node fencing and HANA takeover more likely.

The progressive variant might become standard in the near future. Most new scenarios will be supported in the progressive configuration only, f.e. the SAPHanaSR-angi scale-out XSA standalone scenario.

This configuration does not fit well where HANA system replication to the secondary site runs out of sync often. This configuration does not fit for SAPHanaSR-angi scale-up cost-optimized setup and needs to be adapted for the SAPHanaSR-angi scale-out performance-optimized deployments with HANA host auto-failover (aka BW style).

What are the relevant components?

Resource agents, HA/DR provider hook scripts, an alert agent and SBD are combined and configured. The respective components are:

• SAPHanaController
  • resource agent monitors a HANA database with system replication and manages the takeover. See manual page ocf_suse_SAPHanaController(7).
• SAPHanaFilesystem
  • resource agent monitors mounted HANA filesystems. It neither mounts nor umounts any filesystem. See manual page ocf_suse_SAPHanaFilesystem(7).
• susChkSrv.py
  • HA/DR provider hook script detects failing HANA indexserver processes and triggers the takeover. See manual page susChkSrv.py(7).
• SAPHanaSR-alert-fencing
  • alert agent checks whether an node belongs to the same HANA site as a fenced node. If so, it reboots the local node as well. See manual page SAPHanaSR-alert-fencing(8).
• SBD
  • fencing daemon performs node fencing. See manual page sbd(8).

How to configure the variants?

In practice two defined sets of measure give two useful configuration variants. Each set contains certain parameters for resource agents, HA/DR provider hook scripts and other settings.

Conservative configuration

The cluster is patient, it prefers stopping HANA over fencing nodes. The related settings are:

• SAPHanaController monitor and stop timeout, ON_FAIL_ACTION=proceed
• susChkSrv.py action_on_lost=[stop|kill], for scale-up
  susChkSrv.py action_on_lost=stop, for scale-out without standby node
  susChkSrv.py action_on_lost=kill, for scale-out with standby node
• no SAPHanaSR-alert-fencing
• Diskbased SBD msgwait
• Linux cluster does not start automatically at OS boot

Progressive configuration

The cluster reacts on failures of HANA or filesystem with fencing all nodes of the affected site. The related settings are:

• SAPHanaController ON_FAIL_ACTION=fence and stop action on-fail=fence
• SAPHanaFilesystem ON_FAIL_ACTION=fence and stop action on-fail=fence
• susChkSrv.py action_on_lost=fence, for performance-optimised
• SAPHanaSR-alert-fencing, for scale-out without standby node
  no SAPHanaSR-alert-fencing, for scale-out with standby node
• Diskless SBD (optional, not for two-node cluster)

Where to find more information?

You can find details on configuration of the variants in manual pages ocf_suse_SAPHanaController(7), ocf_suse_SAPHanaFilesystem(7), SAPHanaSR-alert-fencing(8), susChkSrv.py(7), SAPHanaSR_basic_cluster(7), SAPHanaSRScaleOut_basic_cluster(7).

Find more information on SAPHanaSR-angi at blog article https://www.suse.com/c/what-is-saphanasr-angi/

Related SUSE support article is: HA for SAP HANA: Resource agents are running into HANA_CALL timeout lssRc=124 (000022345)