Support Policies for RHEL High Availability Clusters - Management of SAP HANA in a Cluster

Updated -

Contents

Overview

Applicable Environments

  • Red Hat Enterprise Linux (RHEL) 6 or 7 with the High Availability Add-On

Useful References and Guides

Introduction

This guide offers Red Hat's policies and requirements around managing an SAP HANA deployment with a RHEL High Availability cluster. Users of RHEL High Availability clusters should adhere to these policies in order to be eligible for support from Red Hat with the appropriate product support subscriptions.

Policies

Scope of Red Hat support with SAP software resources managed by a cluster: Refer to Red Hat's policy on Management of applications that Red Hat does not ship for further details on Red Hat's scope of support applicable to SAP software deployments in a RHEL High Availability cluster.

The focus of Red Hat's assistance may be limited to functionality of the High Availability software and the SAP resource-agent(s). In some cases SAP's input may be necessary to diagnose the nature of a problem - even if the problem originates in the resource-agent Red Hat ships. Solutions to problems with RHEL High Availability + SAP HANA deployments may be dependent upon some input or deliverable from SAP in cases where the issue can not be solved adequately through RHEL High Availability without SAP's assistance.


Red Hat subscriptions for SAP HANA support: Red Hat provides support for RHEL High Availability's resource-agents managing SAP HANA deployments through the following subscriptions:

  • RHEL for SAP Solutions
  • RHEL for SAP HANA

One of these subscriptions for each cluster node is required in order for Red Hat to assist with RHEL High Availability management of SAP HANA.


Supported platforms for SAP HANA on RHEL High Availability: Red Hat support for its software supporting the SAP HANA solution stack - including RHEL High Availability and its resource-agents for SAP software - largely follows the policies laid out for RHEL High Availability and RHEL:

However in public-cloud deployments, Red Hat's support for this SAP HANA solution stack is limited to only the following cloud platforms:

Other cloud provider platforms are not supported by Red Hat for this solution at this time. Please contact Red Hat Support if you are interested in running SAP HANA on another cloud platform.


Supported releases of resource-agents-sap-hana package and versions of SAP HANA: Red Hat provides support for RHEL High Availability management of the following HANA major versions:

Minimal version of resource-agents-sap-hana package supported:

  • RHEL 6.7 (SAP HANA 1.0): resource-agents-sap-hana-3.9.5-24.el6_7.2.x86_64
  • RHEL 7.2 (SAP HANA 1.0, SAP HANA 2.0): resource-agents-sap-hana-3.9.5-54.el7_2.22.x86_64
  • RHEL 7.3 (SAP HANA 1.0, SAP HANA 2.0): resource-agents-sap-hana-3.9.5-82.el7_3.12.x86_64
  • RHEL 7.4 (SAP HANA 1.0, SAP HANA 2.0):
    • resource-agents-sap-hana-3.9.5-105.el7_4.6.x86_64
    • resource-agents-sap-hana-3.9.5-105.el7_4.6.ppc64le
  • RHEL 7.5 (SAP HANA 1.0, SAP HANA 2.0):
    • resource-agents-sap-hana-3.9.5-124.el7.x86_64
    • resource-agents-sap-hana-3.9.5-124.el7.ppc64le

Minimal version of resource-agents-sap-hana package for deployments on Amazon Web Services:

  • RHEL 7.4 (SAP HANA 1.0, SAP HANA 2.0): resource-agents-sap-hana-3.9.5-105.el7_4.6.x86_64

Supported deployment types:

  • Single database deployments,
  • MCOD (Multiple Components One Database)
  • MDC (Multiple Database containers),
  • MCOS (Multiple Components One System) is only supported if all databases running on the hosts are replicated and the replication is always to the same secondary node

Check the SAP Note 2235581 or article Is there a SAP HANA SPS/OS release support matrix ? for certified/supported combinations of RHEL and SAP HANA releases.


Multitier System Replication with 3 SAP HANA databases is possible only when 3rd SAP HANA database is not managed by cluster. 3rd node that runs outside of cluster will require manual registration whenever the takeover of SAP HANA roles in cluster happens. Documentation on setting up the Multitier System Replication can be found in SAP HANA Administration Guide - Set up Multitier System Replication with hdbnsutil


Additional technical requirements for SAP HANA deployments: the following conditions apply for Red Hat to provide support:

  • 2-node clusters only are supported at the moment.
  • SAP HANA scale-up system replication only; SAP HANA scale-out is not supported for a pacemaker cluster scenario on RHEL.
  • Users and groups used by SAP HANA must be identically defined on both nodes (use same UIDs/GIDs, home directories, ...).
  • SAP HANA on both nodes uses the same SID.
  • Using Full Sync Replication is possible, but due to the way Full Sync Replication works some functionality of the cluster will be restricted (for example the automatic start of the HANA instances on both nodes when the cluster is started will not work and the HANA instance on the secondary node will have to be started manually for the cluster to be able to resume operation if Full Sync Replication is enabled.). To check Full Sync Replication state you can run command hdbcons -e hdbindexserver "replication info"|egrep "(ReplicationFullSync|enable_full_sync)" as SAP HANA administrative user.
  • Active/Active (Read Enabled) SAP HANA System Replication setups should be possible with SAP HANA 2.0 using version 0.152.17 or later of the SAPHANA and SAPHanaTopology resource agents. To enable such setups a second IPaddr2 resource and a co-location constraint have to be added to manage the second IP address.
  • If the cluster nodes are installed in different data centers or data center areas, the environment must match both
  • Time on all cluster nodes must be in sync (using NTP or some other time synchronization method) - resource agents require the time to be the same on both nodes for proper operation.
  • Each cluster node must have a local installation of SAPHostAgent and the version of SAPHostAgent across the cluster must be the same

Table of Contents

No