Dieser Inhalt ist in der von Ihnen ausgewählten Sprache nicht verfügbar.
Chapter 4. Upgrading SAP NetWeaver System
4.1. Upgrading an SAP NetWeaver Non-Cloud or BYOS Cloud RHEL system
Follow the Upgrading from RHEL 7 to RHEL 8 guide to upgrade your SAP NetWeaver non-cloud or BYOS cloud RHEL 7.9 system to RHEL 8 minor versions, with the following additional steps:
-
At the end of chapter 3.1. Preparing a RHEL 7 system for the upgrade, remove the line containing
kernel.sem
from file/etc/sysctl.d/sap.conf
. At the end of chapter 6. Verifying the post-upgrade state of the RHEL 8 system, verify that the value of
kernel.pid_max
is 4194304 according to SAP note 2772999:# sysctl kernel.pid_max
If this is not the case, add the following line to file
/etc/sysctl.d/sap.conf: kernel.pid_max = 4194304
and then reload the file with:# sysctl -p /etc/sysctl.d/sap.conf
You can run the
sap_general_preconfigure
andsap_netweaver_preconfigure
roles in assert mode to verify if your system is compliant with the SAP notes requirements. These roles are part of the RHEL packageRHEL System Roles for SAP
or the Ansible collectionredhat.sap_install
.
4.2. Upgrading an SAP NetWeaver Cloud PAYG RHEL system
The upgrade of SAP NetWeaver or other SAP application systems hosted on cloud provider PAYG instances is very similar to the upgrade of SAP HANA systems hosted on cloud provider PAYG instances. All non-HANA specific steps listed earlier in the SAP HANA systems upgrade on cloud provider PAYG instances procedure should be applied to complete the upgrade of SAP NetWeaver or other SAP application systems hosted on cloud provider PAYG instances.
The only differences are:
The upgrade paths, as the Supported In-place Upgrade Paths section states.
The desired target release version is defined by the
--target
option. For SAP HANA systems, it is either 8.8 or 8.10. For SAP applications, there are two latestEUS/E4S
RHEL 8.x minor versions (even numbers usually), which are supported by Leapp for non-HANA systems as per the Upgrading from RHEL 7 to RHEL 8 document. Please use the--target
option according to your preferences. For more information, please seeleapp --help
.The repo channel for standalone SAP NetWeaver hosts on Microsoft Azure PAYG instances.
When upgrading RHEL for SAP Applications virtual machine on Microsoft Azure PAYG instances, use
--channel eus
instead of--channel e4s
. In other cases,--channel e4s
is always used. After the upgrade with--channel eus
, the system will have the following Red Hat repositories:$ yum repolist rhel-8-for-x86_64-appstream-eus-rhui-rpms rhel-8-for-x86_64-baseos-eus-rhui-rpms rhel-8-for-x86_64-sap-netweaver-eus-rhui-rpms
The repolist may contain other non-Red Hat repositories, namely custom repositories of cloud providers for RHUI configuration.
NoteDo not use
--channel
option if you upgrade to RHEL 8.10, as it is the final minor release of RHEL 8, it is not E4S release, and its support cycle differs. For more information, see Red Hat Enterprise Linux Life Cycle.Please keep in mind that the
rhel-8-for-x86_64-sap-solutions-eus-rhui-rpms
repository should not be present on RHEL for SAP Applications instances, as per Red Hat Enterprise Linux for SAP Offerings on Microsoft Azure FAQ. At some point, it will be removed by Microsoft Azure via the RHUI client rpm automatic update and does not require any action from users. If the automatic RHUI client rpm update has been disabled on your system, for example, by removing the corresponding cron job, the RHUI client rpm can be updated byyum update <package_name>
.The in-place upgrade of RHEL 7 with SAP NetWeaver or other SAP applications hosted on cloud providers and using the Red Hat Enterprise Linux for SAP Solutions or Red Hat Enterprise Linux for SAP Applications subscription can be performed only from RHEL 7.9 with normal (non-e4s/eus/…) repos. RHEL 7.7 or earlier must be updated to RHEL 7.9 first. For special instructions on how to upgrade from RHEL 7.7 or earlier to RHEL 7.9 on cloud providers, refer to How to Perform Update of RHEL for SAP with HA from 7.* to 7.9 on Cloud Providers.
As always, run all the upgrade steps, including the preparation and pre-upgrade steps, on a test system first until you have verified that the upgrade can be performed successfully in your production environment.