Rolling Kernel Switch - Updating the SAP Kernel Without System Downtime
The SAP Kernel
The SAP Kernel is a set of executables and libraries that provide the runtime environment for an SAP NetWeaver system (ABAP mainly but to a lower degree also for Java).
The SAP Kernel has its own release- and patch schedules, and can be updated independently from the rest of the SAP system. For each kernel version, corrections are provided by so called kernel patches, which are delivered on a weekly basis on the SAP Service Marketplace. A major milestone in SAP kernel delivery was reached with kernel version 720, which can be used as a downward compatible kernel (DCK) for all NW7.X based systems up to NW 7.31. Starting with SAP Kernel 720, kernel patches come in two flavors:
- The so called SP stack kernels that are published approximately 2 times a year. These can be distinguished by their patch number being divisible by 100 (more precisely the last two digits of the patch number form a number that is smaller than 9) and they have passed a very long and extensive verification and validation phase at SAP including usage in production environments.
- Kernel patches delivered on a weekly basis (distinguished by the last two digits of their patch number being 10 or larger). They contain the most recent corrections and shall be applied if there is an urgent need for a kernel correction that is not yet contained in the most recent SP stack kernel.
In order to meet the highest quality standards, kernel patches for SAP Kernel 720 may only contain bugfixes and security fixes. Consequently, in order to provide innovations and new features for systems with the DCK, a new version of the SAP Kernel, kernel 721, has been provided in parallel. SAP Kernel versions 720 and 721 are completely interchangeable with the one exception that new features are delivered with SAP Kernel 721 only.
Typically, the SAP Kernel is updated along the maintenance procedure of the SAP system itself. In some cases however, patching the SAP Kernel separately is required. Prior to the Rolling Kernel Switch all application server instances within one SAP system had to be running with the same kernel patch level. Consequently updating the kernel patch in an SAP system required a downtime of the system because all application servers had to be shutdown and restarted afterwards with the new kernel patch.
With SAP Kernel 720, SAP introduced the possibility to run an SAP system with different, but compatible kernel patch levels. Leveraging this capability, it is possible to update the SAP system by updating the application servers step-by-step in a rolling fashion without a business downtime from end-user perspective.
The Rolling Kernel Switch Procedure
Updating the kernel of each application server instance in turn has been termed Rolling Kernel Switch (or RKS for short) for obvious reasons. If none of the application server instances offers a service that is not as well offered by any other instance, the kernel update for the whole system takes place without a business downtime. This is why you need an ASCS (ABAP SAP Central Instance) with a replicated enqueue server if you want to use the RKS to update the kernel in a high-availability scenario because otherwise the enqueue lock service is such a single point of failure. The soft-shutdown feature of an application server instance may be used in order to keep the impact on end-users and overall system functionality to a minimum. Here are the concrete steps to implement the RKS in your system:
Kernel updates for three different SAP application servers
- check note 953653 whether the new kernel patch is RKS compatible to your currently running kernel
- download the new kernel from the SAP service market place
- make a backup of your current central kernel directory
- extract the new kernel archive to the central kernel directory
- restart the ASCS
- restart each SAP application server instance by the aid of the soft-shutdown feature
- Although SAP makes no general commitment about the RKS compatibility of kernel patches, there were hardly any incompatible changes in the past. The latest incompatible change as of Sep 2013 has been in Jan 2011 (with kernel 720 PL#78)
- The compatibility of different kernel patches is checked at runtime by the message server through a file called StoC.xml (StoC for Statement of Compatibility). Starting with kernel 720 PL#417 the StoC file is distributed together with the kernel package. So there is no need to download the StoC file from SMP. All that remains to do is either copy the StoC.xml to the home directory of the ASCS (message server) or set the parameter ms/stoc_file_location to the directory where the StoC file is located. We recommend setting the parameter.
- It is sufficient to extract the kernel archives to the central executable directory. The sapcpe based copy mechanism will update the local application server executable directories automatically at instance startup time
- Restarting the ASCS may either be done by the aid of high availability tools (i.e. a HA switchover) or manually. Since the message server operates stateless and its restart takes several seconds only, the restart will result in a unavailability which in most cases from any practical point of view can be neglected.
- It is obviously recommended to execute the RKS during times of lower usage and load on the system. Since fading out of the application server instances may take considerable time and thus restarting the whole system may take several days, this is not always possible. What is however possible is to schedule the ASCS restart to a time with very low system load (e.g. during the weekend). It is also possible to skip the restart of the ASCS all together if there is no business reason to do so (e.g. fixing a critical bug in the enqueue or messages server)
Elaborating a little bit further on the last remark, it is possible to use the RKS not only as a means for updating the kernel without downtime, but also as a means for verifying/validating new kernel patches in a production environment without the necessity and risk of introducing the kernel with a "big bang" change. This has indeed been done successfully by a number of customers. In this context you simply make use of the fact that the system will allow to run application server instances with different kernel patches at the same time. Of course we strongly recommend to update all application servers in a system in a timely fashion.
The description above holds true for kernel releases 720 and 721. The Rolling Kernel Switch in upcoming kernel releases is currently being reworked completely. This will allow many features that have not been possible with the current implementation:
- Automation of the RKS procedure
- Integration of the procedure into SAP Start Service and SAP MMC
- ASCS update without the necessity for a cluster failover
- Improved server soft-shutdown
- Improved adaption and integration of services like Spool and Batch
- Supports updating to a new (DCK) kernel release
- Changes to the ABAP load format will not spoil RKS compatibility
- Improved monitoring in SAP MMC and SM51
These features will be part of kernel 741. For more details watch out for future announcements concerning the Rolling Kernel Switch.
If you want to learn more about the RKS in kernel release 720 and 721 you may consult the following documents:
SAP note 953653 general information about the Rolling Kernel Switch
SAP note 1787163 saving logon groups during message server restart