Reduce SAP Downtime with the Rolling Kernel Switch (RKS)

What is SAP RKS?

The rolling kernel switch (RKS) is an automated procedure that enables the kernel in an ABAP system to be exchanged without any system downtime. RKS can also be used to make parameter changes while the system is running.

?

The Rolling Kernel Switch (RKS) can be used to minimize the planned downtime in high availability systems in order to implement a new kernel patch level. ?

Important SAP notes to review in relation to SAP Rolling Kernel Switch (RKS) are:

??953653??Rolling Kernel Switch??https://launchpad.support.sap.com/#/notes/953653

??2254173?Linux: Rolling Kernel Switch in Pacemaker-based NetWeaver HA environments https://launchpad.support.sap.com/#/notes/2254173?

SAP note 953653 Rolling Kernel Switch and SAP help page Rolling Kernel Switch (RKS) can be used in conjunction with this blog.

The RKS is available for the following kernel releases with the associated method:?

·????????Manual RKS Procedure for 7.2x Releases

·????????Automated RKS Procedure for 7.4x Releases?

This blog focuses on the manual procedure at present but will be extended later to include the automated procedure.?

Pre-Requisites

Before the RKS process can be executed there are pre-requisite checks that must be carried out beforehand. Some of these are manual and must be performed by the system administrator. Other are automatic checks that are executed by the RKS process itself.

Another major pre-requisite to using the RKS is the ability to stop each application server without the overall availability of the system being affected – i.e. the system is a high availability system with clustered central services (SCS) and associated replicated enqueue managed by an enqueue replication server (ERS).

?

Preparations

·????????As of 7.4x version, RKS procedure does not support any DUAL stack or JAVA stack systems.

·????????Avoid long-running background jobs when RKS is scheduled.

·????????Use a logical spool server instead of an application server which can be defined in SPAD to avoid any print failure during this activity.

·????????Use local IGS services as this service might get stopped/restarted.

·????????If we are using update server groups, we should check if each group is RKS compatible.

·????????We can verify this by checking if the UPD work process exists for all/ at least 2 application servers in the group.

·????????VMC must be active in at least two AS ABAP instances or in none.

·????????RFC’s must be configured with load balancing, if a single host is used, chances are to get they failed.

·????????Backup DIR_CT_RUN in we want to import new kernel patch.

·????????Download relevant SAPEXE.SAR and SAPEXE<DB>.SAR archives and extract them in DIR_CT_RUN (central executable directory) using SAPCAR.

·????????Source and target versions kernels must be RKS compatible.

After downloading and preparing the new kernel and before starting the RKS, you need to prepare the central services (SCS).?Copy the file “StoC.xml” located in the newly prepared kernel location to the directory of the SCS instance denoted by system parameter $DIR_HOME.

The home directory of the SCS will generally be the working directory beneath the instance directory but can be checked using sap control on the SCS node as follows:

????sapcontrol -nr 00 -function Parameter Value DIR_HOME | tail -1

Once the SCS is prepared, physically switch in the new kernel by copying the newly prepared kernel into the /sapmnt/<SID> file system.?

Rolling Kernel Switch

The Rolling Kernel Switch for the SAP instances comprises the following steps:

????Prepare the Instance

????Restart the Instance

????Run saproot.sh

????Activate the Instance?

These steps should be performed for all instances of the SAP system being patched. In the preparation of the instance for RKS, we need to isolate the chosen instance. Isolating the instance means preventing all access to the instance – e.g. direct logon, transport system communication etc. Once isolated, the instance can be restarted to introduce the new kernel as space will detect the new version in /sapmnt and initiate a copy of the new version into the instance-specific executable directory.

When the instance has started successfully, it can be made active by reversing the isolation activities. When all application instances have been restarted, the dormant ERS should be restarted, the SCS cluster failed over and the remaining dormant ERS restarted.

?