High availability and disaster recovery solutions for SAP are essential. Tier 1 application outages are costly and disruptive to the business. Even short periods of planned downtime for maintenance events like software updates or hardware upgrades can negatively impact end-user and IT productivity as well as critical business processes. Larger unplanned outages can be devastating, with significant business disruption, missed revenue, and lost reputation. By nature, SAP® workloads are often business critical, making downtime increasingly unacceptable. For example, losing the ability to process high-volume transactions or perform real-time analytics can have substantial negative business impacts.
Included with Red Hat® Enterprise Linux® for SAP Solutions, Red Hat Enterprise Linux High Availability Add-On is an automated high-availability solution that reduces unplanned downtime in scale-up and scale-out SAP HANA®, SAP S/4HANA, and SAP NetWeaver deployments. Using SAP HANA’s native replication capabilities, the add-on offers a standards-based approach for ensuring SAP application reliability in on-premise and cloud environments.
Red Hat tools for managing SAP solutions
With more than 20 years of joint innovation, Red Hat and SAP tailor solutions for the needs of business-critical applications. More than just a stable platform, Red Hat Enterprise Linux offers distinct benefits for SAP installations, including:
- Continuous availability of SAP applications. A Red Hat Enterprise Linux for SAP Solutions subscription provides high-availability SAP solutions as well as SAP HANA tested in-place upgrades and live patching capabilities for critical and important Common Vulnerabilities and Exposures (CVEs).
- A focus on SAP application life cycle. Red Hat Enterprise Linux for SAP Solutions includes update services, providing a stable foundation and support for certain minor releases for up to four years.
- Proactive monitoring and remote management of SAP landscapes. Red Hat Insights and Red Hat Smart Management provide real-time assessment of risks related to performance, availability, stability, and security.
- Readiness to run. Red Hat Enterprise Linux for SAP Solutions provides high-performance profiles, runtime libraries, and file system add-ons that increase SAP performance and reliability on Red Hat Enterprise Linux.
Managing SAP installations with Red Hat technologies
Successful nonstop operation relies on more than a single product or feature. It depends on having a robust enterprise-grade platform, a high-availability feature set in support of SAP applications, and IT automation technology that removes human error from complex and repetitive configuration tasks. Red Hat provides technologies that can be used to minimize downtime for SAP deployments. They include:
- Red Hat Ansible® Automation Platform, which automates IT processes and deployments with a simple and powerful language that requires no agents to install.
- Red Hat Satellite, which helps you build a trusted Red Hat environment and manage the Red Hat life cycle—standardizing your environment while provisioning and configuring at scale.
- Red Hat Insights, which helps put SAP on a firm foundation by preventing critical issues before they occur with continuous insights, verified knowledge, and proactive resolutions.1
Use case: Fast patching of SAP landscapes
Rapid routine configuration and patching of SAP landscapes are critical to minimizing downtime. Figure 1 shows how an Ansible Playbook can be used to provide patching of an SAP landscape on a quality assurance (QA)/test server, with eventual promotion to production. As shown in Figure 1, the playbook is broken down into roles for each of the component technologies, with distinct functionality:2
- Red Hat Virtualization roles are used to apply production server and boot profiles.
- Red Hat Satellite roles install the operating system (OS) on the QA server.
- Red Hat Enterprise Linux roles apply the production OS configuration on the QA server.
- Red Hat Ansible Automation Platform roles for SAP are used to provision and configure the application.
- Finally, storage roles load test data.
Once the tests are vetted on the QA server, the patch can be promoted to production and deployed by Red Hat Satellite.
SAP automation with Red Hat Ansible Automation Platform
Red Hat Ansible Automation Platform provides a number of specific roles for SAP automation (Figure 2). Ansible Roles are the primary mechanism for breaking Ansible Playbooks into smaller reusable components. Roles provide a framework for fully independent tasks, or independent collections of variables, files, templates, and modules. Each role is limited to a particular set of functionality or desired output, with all of the necessary steps to provide that result either defined within the role, or in other roles that are listed as dependencies.
As pictured, Ansible Roles for SAP environments include the following:
- sap-hana-preconfigure performs additional configurations for SAP HANA that have not been done by sap-preconfigure.
- sap-netweaver-preconfigure prepares the system for NetWeaver installation.
- sap-preconfigure configures system locale and host name and checks the Domain Name Service (DNS) according to basic SAP Notes for a generic operating setup for SAP.
- sap-hana-mediacheck checks for SAP installation media availability and returns version information that can be used by the sap-hana-hostagent and sap-hana-deploy roles.
- sap-hana-hostagent installs/updates the SAP Host Agent (if applicable).
- sap-hana-deploy creates SAP HANA-specific users and launches an SAP HANA unattended installation for all supported scenarios.
- sap-hana-hsr creates an initial backup for SAP HANA System Replication (HSR) and configures system replication between two SAP HANA instances.
High availability and disaster recovery options for SAP HANA
There are multiple ways to configure SAP HANA for high availability and disaster recovery. Choosing the right option depends on performance and cost sensitivity, and what problems you are trying to solve with a high-availability solution. Configuration options include:
- Host auto-failover. Host auto-failover is a cluster-like solution that uses a single data pool. It includes an internal cluster manager for micro cosmos auto-failover. Storage connector APIs communicate with storage area network (SAN) storage. Host auto-failover covers hardware problems by providing additional hosts. Technically, this approach represents a “scale-out” multimode solution.
- System replication. SAP HSR is similar to classical shadow database solutions and is suitable for high availability and disaster recovery scenarios. Failover is not automated by default, though automation is possible with a cluster manager, like Pacemaker, and Red Hat Ansible Automation Platform. System replication covers hardware and data integrity problems by providing an additional set of individually driven data pools.
- Storage replication. Storage replication is typically used for multisite disaster recovery. Automation is possible with an external cluster manager (macro cosmos). Storage replication covers datacenter-level failures on a broader scale.
Choosing a strategy for high availability and disaster recovery depends on priorities for performance, cost, recovery point objectives (RPO), and recovery time objectives (RTO). Table 1 compares host auto-failover with SAP HSR.
Table 1. Host auto-failover vs. SAP HANA System Replication
|Host auto-failover||SAP HSR|
|Least expensive option||Fully redundant|
|Provides zero RPO but high RTO||Allows zero RPO and low RTO|
|Only covers the failure of compute nodes. Storage is shared through a SAN.||Nothing is shared. High availability and disaster recovery instances are fully provisioned SAP HANA scale-up or scale-out deployments.|
Automating SAP HANA System Replication with Red Hat
With standard SAP HSR, all data is replicated to a secondary SAP HANA system (Figure 3). Data is constantly preloaded on the secondary system to minimize RTO in the event of a failure event. Failover is not automated by default and requires a third-party cluster solution. SAP HANA scale-up and scale-out configurations are supported.
SAP HSR takeover can be automated using Red Hat Enterprise Linux High Availability Add-On. In addition, Red Hat Ansible Automation Platform can automate many SAP tasks, including the setup and configuration of the SAP HSR running in Red Hat Enterprise Linux High Availability Add-On, and on the Pacemaker cluster.
SAP HANA scale-up configurations
For scale-up configurations, automated SAP HSR assumes a two-node cluster as shown in Figure 3. SAP HSR supports different modes of operation, which can be configured depending on the needs of the organization:
- Cost-optimized configurations support a QA/test instance running on the secondary site. The QA/test instance is shut down during failover events. SAP HANA 2.0 supports active/active configurations where the secondary instance can take read-only inquiries.
- Performance-optimized configurations feature a secondary site that is dedicated to failover, and is not active to client/application servers.
- Multi-tier system replication (aka “replication chains”) is also possible; however, the tertiary site cannot be managed by the cluster. Resource agents are available to aid with the system replication process.3
Use case: Near-zero downtime maintenance for SAP HANA
Ansible Playbooks and Red Hat Satellite provisioning can allow SAP HANA software updates or hardware maintenance with zero downtime. For example, in a scale-up scenario, a virtual IP address is assigned to the primary node, with synchronous data replication to a secondary node. The secondary node might be supported by updated hardware, or it might run a more recent software version.
Using the SAP NetWeaver suspend connection API, the Ansible Playbook suspends the connectivity of the appropriate node. Once database connectivity is suspended, Red Hat Ansible Playbooks instruct the cluster manager to take over the secondary node as a prefered site. After the primary node is down, system replication is interrupted, and the Pacemaker cluster fences the primary node. The secondary node then becomes the new primary node, and the virtual IP address binds to the new primary node. As the dual-primary state times out, the former primary registers as the new secondary node. System replication then restarts in the opposite direction, replicating from the new primary node to the new secondary node.
Prerequisites for this use case include the following:
- SAP NetWeaver 7.40 Support Package 5 or higher
- SAP Kernel 7.41 or higher
- SAP Note 1913302 - SAP HANA: Suspend DB connections for short maintenance tasks
- An SAP HANA system landscape with SAP HSR
SAP HANA scale-out configurations
For SAP HANA scale-out configurations, automated SAP HSR is supported between two scale-out sites (Figure 4), starting with Red Hat Enterprise Linux 7.6 or later.
The combination of SAP HSR and Red Hat subscriptions for Red Hat Enterprise Linux for SAP Solutions enhances the ability to operate SAP HANA landscapes with less downtime. Long-term collaboration between Red Hat and SAP makes Red Hat Enterprise Linux for SAP Solutions an ideal platform for hosting enterprise-critical SAP HANA deployments. Red Hat Ansible Automation Platform provides a wealth of SAP-specific roles for automating SAP HANA landscapes. The combination of Red Hat Ansible Automation Platform with Red Hat Enterprise Linux for SAP Solutions make it possible to automate critical transitions like system and software upgrades, with near-zero downtime.
Red Hat Insights is included as part of your Red Hat Enterprise Linux subscription, so you can start proactively identifying and remediating risks across your Red Hat infrastructure from the moment the operating system is deployed.
Find additional ready-to-use Ansible roles at the following links: https://access.redhat.com/articles/3050101, https://galaxy.ansible.com/linux-system-roles, https://galaxy.ansible.com/mk-ansible-roles
Available in the resource-agents-sap-hana RPM.