红帽全球峰会红帽博客
Red Hat Enterprise Linux (RHEL) has been providing high availability (HA) for business critical workloads at the application and database (DB) level for years, helping maximize uptime and minimize unplanned disruptions of service, making critical environments more resilient.
Thanks to the RHEL High Availability Solutions for SAP, based on the RHEL HA Add-On and included with the Red Hat Enterprise Linux for SAP Solutions subscription, single points of failure like shared file systems, databases, message servers and enqueue servers are extensively mitigated, if not outright eliminated, by clustering these resources.
In the case of SAP HANA, the DB incorporates a mechanism called SAP HANA System Replication (HSR) which replicates the DB to one or more nodes but does not provide automatic failover in case of problems. RHEL HA Solutions for SAP can take care of this automation and help SAP Basis engineers sleep more soundly, knowing that it is much less likely that they’ll have to perform a manual failover of the DB in the middle of the night.
The collaboration between Red Hat and SAP means that new HA scenarios and models incorporated into both DB and application layers are covered by RHEL HA Solutions for SAP so that customers are able to benefit from them. Red Hat performs extensive testing on different releases of RHEL to get them certified by SAP to provide HA for those scenarios and models.
High availability at application level
If we look at the application side, there are two models created by SAP to achieve HA — ENSA1 and ENSA2. The latter is recommended for SAP NetWeaver (starting from version 7.51) and SAP S/4HANA (starting from version 1809), while ENSA1 is used in older versions of SAP NetWeaver based SAP products. In both, the enqueue server (which stores a table of all the locks held by users at all times) is replicated to ensure that, if there is a failure, there will be no data overwriting in the DB so it remains consistent (see Evolution of ENSA2 and ERS2 for details on the differences between ENSA1 and ENSA2).
As in the SAP HANA System Replication case that we mentioned earlier, the failover is not done automatically, so RHEL HA Solutions for SAP adds this layer of automation to clusters of two or more nodes (more than two nodes is only applicable when implementing ENSA2).
Some customers may decide to have the DB and the application on the same server for some of their systems in order to reduce costs (mostly if they are on a cloud service and they need to minimize the expenditure), or they could have the primary application instance (PAS) and other application instances also on one host. These scenarios, so called cost-optimized deployments, are also covered by RHEL HA Solutions for SAP.
See Configuring Cost-Optimized SAP S/4HANA ASCS/ERS/HDB with Standalone Enqueue Server 2 (ENSA 2) in a Pacemaker Cluster - Red Hat Customer Portal for details on how to set up a HA cluster for managing both HANA System Replication and ENSA2 in a single cluster.
High availability at DB level
Regarding the DB layer availability, here we’ll focus on SAP HANA. A SAP HANA instance can be installed on one server, or it can be distributed across multiple servers to have more resources.
The first case is called a “scale-up deployment” because if more resources are needed they may be added to the same server, and the second is called a “scale-out deployment”. High availability can be provided for both implementations. In the first case, an identical instance with the same resources will be installed in another server (also with the same resources and SID), and in the second case, the same configuration will be replicated to the same number of hosts.
As we mentioned earlier, SAP HANA System Replication will provide for the replication and consistency of the data, but requires a cluster solution such as RHEL HA Solutions for SAP to take care of the automatic failover of the resources in case of problems.
In order to achieve even more redundancy, SAP introduced the possibility of Multitier System Replication in SAP HANA 1.0 SP12. With this, a DB is replicated and the replica is in turn replicated to a third tier.
Later on, in SAP HANA 2.0 SP03, Multitarget System Replication was introduced to deliver even more redundancy by replicating the original DB to more than one target simultaneously. This means that if the secondary fails, the third will still be in sync with the primary, while with multi-tier, if the secondary fails, the changes in the primary will no longer be propagated to the third.
Both scenarios are supported with current versions of RHEL HA Solutions for SAP starting as of RHEL 8 for SAP Solutions.
There are additional cost-optimized scenarios described by SAP for SAP HANA database deployments, in which the secondary server not only has a replica of the primary DB but also hosts a DEV or QAS DB that serves queries. Since both DBs have to share resources, the DEV/QAS DB has to be shut down first in order to allow allocation of all the resources to the production database and to allow the primary to fail over to the secondary.
RHEL HA Solutions for SAP supports this solution as of version RHEL 8 for SAP Solutions (and later). See Automating Cost-Optimized SAP HANA Scale-Up System Replication using the RHEL HA Add-On - Red Hat Customer Portal for further details on this solution.
You can find a detailed description of all the supported HA scenarios in this article.
Adding automation to the recipe
Red Hat Ansible Automation Platform can take care of many parts of the IT landscape, including creating and operating clusters. Using automation simplifies the process of configuring Pacemaker clusters and reduces the possibility of human errors. Once a configuration is tested and validated, it can be built into a template that the Ansible roles and playbooks will deploy any number of times. This blog post shows you how to automatically create a SAP HANA Pacemaker cluster with Ansible.
Finally, it is important to note that HA is not only needed to help avoid unplanned outages, but can also be used in combination with automation to minimize the downtime needed for planned maintenance activities as described in this portfolio architecture.
Reliable and cost efficient SAP systems
As we know, SAP workloads are critical because they tend to sit at the core of an organization, so driving towards maximum uptime while minimizing outages (planned and unplanned) is a main concern for IT departments. With the latest scenarios supported by RHEL HA Solutions for SAP, customers can be even more confident that their SAP systems are available and responsive to business needs, providing a smooth user experience while achieving higher levels of data redundancy.
Also, support for SAP HANA cost-optimized solutions can help considerably in reducing expenditure on computing resources, such as organizations with hybrid cloud environments that want to get the most of their systems that are on public cloud, while making sure they are in control of how much they pay for their utilization.
Learn more
关于作者
Ricardo Garcia Cavero joined Red Hat in October 2019 as a Senior Architect focused on SAP. In this role, he developed solutions with Red Hat's portfolio to help customers in their SAP journey. Cavero now works for as a Principal Portfolio Architect for the Portfolio Architecture team.
