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. 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.
Since the use of the RKS means application severs of the affected system must operate temporarily with a different kernel version, an important pre-requisite is that the kernel versions in question must be compatible – i.e. the old kernel must be able to operate alongside the new kernel in the same SAP system.
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).
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 work directory beneath the instance directory but can be checked using sapcontrol on the SCS node as follows:
• sapcontrol -nr 00 -function ParameterValue 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 sapcpe 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.
If minimising your SAP downtime is something you’re looking to achieve when upgrading the kernel on your SAP systems and you’d like to learn more, drop us a line with no obligation mailto:firstname.lastname@example.org