Migrating SAP workloads to Red Hat Enterprise Linux

Real-time analytics on live data and the ability to analyze data at scale are crucial for businesses to succeed. The data platforms that power these businesses should offer the scale and flexibility to meet current and future data processing needs—with options to run on-premise, in the cloud, or hybrid environments.

Increasing numbers of enterprises are betting on technologies like SAP HANA® and SAP S/4HANA to help them meet growing demands, remain competitive, and prepare for the future. However, powering a data-intensive real-time workload on SAP HANA requires a solid foundation that can deliver stability, performance, security, and availability at scale. Standardizing to run SAP workloads on Red Hat’s integrated portfolio can help you optimize your environment and operations while helping you adopt digital technologies to advance your business.

Moving SAP workloads to another operating system can seem quite complex, and many organizations might not know where to begin. However, a well-thought-out and well-executed migration plan can help you eliminate many of the unknowns and simplify your data migration efforts.

This detail covers a step-by-step migration path for SAP HANA and SAP S/4HANA workloads from SUSE Linux® Enterprise Server (SLES) to Red Hat® Enterprise Linux, providing best practices for rapid and successful migration. Red Hat Enterprise Linux 8.0 x86_64 is used for this scenario, but the guidance in this detail applies to other microprocessor architectures as long as they are certified by SAP, including new minor releases for Red Hat Enterprise Linux 8.

Costs, reliability, and scalability

When it comes to selecting a new platform to migrate to, cost, reliability, and scalability typically show up as top selection criteria attributes. Recently, IDC interviewed more than 600 line-of-business and IT executives across organizations that have largely standardized their Linux environments on Red Hat Enterprise Linux.²  These organizations reported that their investment in Red Hat enables them to maintain efficient, reliable, and scalable Linux environments for their most important business operations at a lower cost.

IDC projects that the use of Red Hat Enterprise Linux will provide economic benefits of more than US$1 trillion a year to customers. Additionally, the Red Hat Enterprise Linux ecosystem will employ nearly 900,000 workers this year and will grow to US$119 billion in 2023. Among customers, the IT professionals who work with the software, hardware, and services stacked on Red Hat Enterprise Linux will number more than 1.7 million. These results show that interviewed organizations are achieving strong benefits at a significant cost savings from investing in standardized infrastructure with management tools, showing the substantial value of investing in Red Hat Enterprise Linux.

Red Hat and SAP strategic relationship

The SAP and Red Hat partnership brings together business applications and IT infrastructure, with built-in openness and flexibility, giving customers the tools to modernize their business models. As companies try to speed up development, optimize resources, and adapt to changes in market dynamics, IT operations bears the extra burden. The SAP and Red Hat partnership helps companies meet current and future challenges by reducing IT infrastructure complexity, generating insights for real-time business, and equipping organizations to embrace continuous innovation. 

As a Preferred Partner of SAP, Red Hat collaborates closely with SAP engineering and SAP Linux Lab to help our joint customers and partners succeed with the Red Hat portfolio. This innovative partnership is based on a long history of collaboration that has benefited from Red Hat’s leadership in open source and SAP’s world-class business software solutions.

Migrating workloads does not have to be a one-time trip. Red Hat believes the process of migrating data infrastructure should be carried out in an agile, flexible, and iterative way. Migration is a journey, and a typical starting step is defining a baseline and an ongoing plan that is focused on delivering the necessary business outcomes. 

Here are 4 steps that can help your company navigate this transition successfully: 

1. Evaluate and assess your environment to decide which applications would most benefit from being migrated, and create a migration plan. We recommend starting with your dev/test environments, followed by the QA and production environments.
2. With support from subject matter experts (SMEs), including Red Hat services and support, perform the migration. More details on how to perform the migration appear in the next sections of this detail.
3. Prove that your migration is successful by confirming that the desired results are being achieved. You might want to check that your service-level agreements (SLAs) of your application are still within acceptable limits or better.
4. Develop adoption knowledge to carry out future migrations and scale out the process to the remaining set of applications that need to be migrated. From architecture through adoption and training, our teams and resources can help you get the most out of your technology investments. 

Nearly every sizable organization has stacks deployed across multiple environments. This architecture allows enterprises to reliably implement environmental changes at all stages from development to production. It also permits validation that includes unit testing, integration testing, functional testing, nonfunctional testing, and more.

It is advisable to perform this migration starting with your dev/test environments, followed by the QA and production environments.

High-level migration architecture

Migrating a database from one environment is a two-step process in our architecture:

1. Migrate the data within the database.
2. Update the applications to connect to the new database host.

Before we illustrate the high-level migration architecture, it is important to understand the core strategies for carrying out the migration: 

1. In the replication strategy, you can replicate the database running on a SLES server (source) to a Red Hat Enterprise Linux server (target), in an online fashion, without incurring any database or application downtime on the source. To allow for this, the same versions of SAP HANA and SAP S/4HANA or higher that are present in the SLES servers must be installed in the Red Hat Enterprise Linux servers that will be targeted for the migration. Once database replication is completed and disabled, the SAP S/4HANA system will successfully run on Red Hat Enterprise Linux. No changes are necessary for the application server itself aside from restarting it (on the target).
2. In the backup/restore strategy, you can take a full backup of the SAP HANA on SLES (source) and then restore it in the newly installed SAP HANA database on Red Hat Enterprise Linux (target). During the backup process, the SAP S/4HANA application running on the source will need to be taken offline. After the backup is restored on the target database, the SAP S/4HANA application server can be started on the target.

The high-level architecture outlined in Figure 2 will consist of 2 SLES instances for the source and 2 Red Hat Enterprise Linux 8.0 instances for the target. SLES 15 is used for the procedure validation, but these systems are agnostic as the emphasis is on the workloads themselves. An additional Red Hat Enterprise Linux instance, an Ansible® host where execution of the automation is controlled, is used to support the migration. This last instance controls and automatically executes the whole process using Ansible. The instances with the suffix of “01” in their names will run the application servers, and the instances with the suffix of “02” in their names will run the database servers.

The starting point of the architecture has SAP S/4HANA component running in one of the SLES instances and SAP HANA component in the other SLES instance. The procedure will take both workloads and migrate those to the Red Hat Enterprise Linux instances driven by Ansible from the supporting Ansible host.

While SLES has a specific release for running SAP workloads, Red Hat Enterprise Linux is consistent across the datacenter. This facilitates the work for operations teams where only one base system image needs to be maintained and patched throughout its life cycle.

For future references and understanding, here are the host names and role for each system:

• sles-01: source SLES server running SAP S/4HANA
• sles-02: source SLES server running SAP HANA
• rhel-01: target Red Hat Enterprise Linux 8 server running SAP S/4HANA
• rhel-02: target Red Hat Enterprise Linux 8 server running SAP HANA
• ansible-01: supporting server to run Ansible automation playbooks

Considerations before migrating between SLES and Red Hat Enterprise Linux

There are several key considerations that you should evaluate and validate before starting the process. To ensure that the workloads will run smoothly on the target systems, hardware specifications must be equivalent to those in the source systems. These specifications include common attributes such as CPU, memory, network, and disk input/output (I/O). In addition, the hardware and operating system releases must be supported and certified by SAP (SAP Note 2235581). Finally, it is also critical to validate that required traffic for SAP HANA replication is open between source and target systems, as well as any required traffic for postmigration validation, data integrity, and performance testing.

The following software was used in the exercise for this detail:

• SLES 15 in servers sles-01 and sles-02
• Red Hat Enterprise Linux 8 in servers rhel-01 and rhel-02
• SAP HANA 2.0 SP SP03 rev 33
• SAP S/4HANA 1809
• SAP kernel 7.73 64-bit Unicode
• SAP HANA Client Version 2.4

Step-by-step procedure

As explained previously, the whole process is done automatically using Ansible automation technology. Ansible automation will not only increase the reliability of the process by removing any unintended human errors, but it also provides the means to reproduce the process as needed in different environments. Thus, the process can be completed uniformly and accurately across different environments, such as Dev, QA, and production.

During this process, Ansible executes the following steps as part of the broader workflow:

1. Register rhel-01 and rhel-02 systems, add required repos, register to Red Hat Insights and install base required packages using the following role.
2. Configure rhel-01 and rhel-02 systems with the required file systems for SAP HANA and SAP S/4HANA using the following role. (/usr/sap/trans and /sapmnt shared filesystems will be mounted in rhel-01 after step 9, as the way they are exported is dependent on the architecture. This will not be covered in this whitepaper.)
3. Configure rhel-01 and rhel-02 systems according to applicable SAP notes so that any SAP software can be installed using the following role.
4. Install SAP Host Agent for life-cycle management on rhel-02 systems using the following role.
5. Configure rhel-02 as per the relevant SAP notes using the following role.
6. Install SAP HANA in the rhel-02 using the following role. (It needs to be installed with the same configuration as the SAP HANA database in sles-02. Worker groups, etc., must be identical, as well as the SID and instance number that must be the same as in the source system.)
7. Install SAP HANA permanent license in the rhel-02 using the following role.
8. Configure rhel-01 as per the relevant SAP notes using the following role.
9. Install SAP S/4HANA on rhel-01 using the following role.
10. Configure SAP HANA System Replication between the sle-02 (primary) and the rhel-02 (secondary) using the following role. During this step, the SAP HANA database in rhel-02 needs to be stopped and started, but users will not notice the change because they will still be connected to the environment on SLES.
11. Trigger the takeover process of SAP HANA on rhel-02 as primary once the SAP HANA on sle-02 has been replicated to it using the following role.
12. Disable the SAP HANA replication using the following role. During this step, the SAP HANA database in rhel-02 needs to be stopped and started again, but once more this will be transparent to users since they keep connected to the environment on SLES.
13. In rhel-02, change the password of the database user with which SAP S/4HANA in rhel-01 connects to the SAP HANA database in rhel-02, (If a password different from the one in the source system was specified in steps 6 or 9, SAP S/4 HANA will not be able to connect to the database now that the database has been replicated from sles-02 to rhel-02. In the SAP HANA Client Secure User Store, SAP S/4 HANA will have the password we specified during the new installation. We will have to set this password for the database user in rhel-02. If in steps 6 and 9 we specified the same password as in the source system, this step will not be needed).
14. Restart SAP S/4HANA on rhel-01 using the following role to clean up the connections to the SAP HANA database on rhel-02 that were established prior to the enablement of SAP HANA System Replication.

By following these steps, users can connect to SAP HANA and SAP S/4HANA on the new Red Hat Enterprise Linux servers.

Migrating an operating system requires confidence in the new platform. Red Hat offers a comprehensive set of products and services, including:

• Red Hat Enterprise Linux for SAP Solutions, which includes Red Hat Enterprise Linux High Availability Add-On for increased uptime, Red Hat Smart Management, Red Hat Insights, update services for SAP Solutions for up to 4 years, and in-place upgrades and live patching for Critical and Important security issues.
• Access to our award-winning knowledge-centered support system, which features reference architectures, documentation, videos, and collaborative discussions with Red Hat experts. Above and beyond providing support and best practices, the Red Hat Customer Portal delivers information about ongoing security vulnerabilities and critical steps to mitigate their impact.
• Red Hat Consulting, which helps organizations quickly and strategically achieve value while improving capabilities across the enterprise. During a Red Hat Consulting engagement, teams receive mentoring on technology and the methods and skills needed to sustain success when the engagement is complete.
• Red Hat Training. Through open enrollment, virtual classrooms, or Red Hat Learning Subscription, Red Hat Training provides a current approach and practical application skills to optimize use of modern technologies and maximize your technology investment.

When it comes to mission-critical SAP deployments, Red Hat believes it is important to pick the right operating system. From saving your organization money and resources, to reducing complexity and creating more time for innovation, Red Hat Enterprise Linux can provide a solid foundation to move your SAP workloads with confidence and ease. Red Hat Enterprise Linux also powers our other portfolio solutions, including:

Red Hat Ansible Automation Platform, which helps you automate the entire migration process so that it is repeatable and reliable. 

Red Hat Smart Management, which combines Red Hat Satellite with cloud management services for Red Hat Enterprise Linux, allowing you to provision, patch, configure, and control your development, test, and production systems based on Red Hat Enterprise Linux. You can also ensure that all systems have the latest security patches and quickly remediate configuration drift. Complete auditing capabilities record and report the historical state of your systems at any point in time.

Red Hat Insights, which delivers predictive operating system analytics so that you can rapidly identify and remediate threats to availability, security, stability, and performance. Proactive, automated, targeted issue resolution helps you keep your environment operating optimally to avoid problems and unplanned downtime. Red Hat Insights includes more than 1,000 rules, including many specific to SAP system configuration requirements and best practices, to identify vulnerabilities before they impact critical operations.

Additionally, with the planned strategy from SAP to move to containers, you can prepare for the future by extending your IT footprint to hybrid cloud and with Red Hat OpenShift®, an enterprise-grade Kubernetes platform. There is growing industry pressure to move to SAP S/4HANA by 2027, and the time to migrate your SAP workloads to Red Hat Enterprise Linux is now.