[Updated 01/2022]
A lot of customers asking for the optimal operation strategy regarding Linux/HANA and how it will change their current operational processes. So, we talk about lifecycle management – patching of the different components of a system.
- Reasons for staging
- Staging process
- Small businesses
- Big businesses
- Frequency of stage updates
- Right time for staging tests
- HANA maintenance
- Linux lifecycle
- Combining HANA and OS lifecycle
But when is the right time to patch components like Linux, Hypervisor, SAP Kernel, HANA Client, HANA DB? We have a lot of dependencies:
In this blog we will focus on the timing and the best staging in the SAP and Linux context, because we have to take a attention on the different lifecycles and maintenance strategies.
Reasons for Staging
Issue 1:
You want to install a 3-system-landscape: DEV – QAS – PRD
Week 1: installation of DEV Linux server with latest repository software versions (repository: week 1)
Week 6: installation QAS Linux server with latest repository software versions (repository: week 6)
Week 10: installation PRD Linux server with latest repository software versions (repository: week 10)
Issue 2:
You want to change a Linux Kernel in cause of a HANA dependency.
Week 1: installation of latest Linux Kernel on DEV
Week 6: After a successful test on the DEV system you want to update your QAS system, but the kernel is not available anymore and you have to use the another one. You have to update the DEV system to the same level as QAS.
Week 10: After a successful test on the QAS system you want to update your PRD system, but the kernel is not available anymore and you have to update all systems again. In the meanwhile, you don’t restart and activate the new kernel in PRD until the tests are over.
Result: You have different Linux kernels and other software component like glibc, libgcc etc. in every week.
Effect: Side effects of the system behavior like memory allocation or security gaps. It’s like a big zoo.
Recommendation: For harmonization and homogeneity there should be only one image or repository for all HANA / SAP servers.
Q: But how we can achieve this?
Small businesses
Low cost variants:
- Update all servers in week 10 to one repository version
- Order all servers in week 1 and install them with one repository version
- Create one image and use it for every installation (old software versions)
Staging with a repository manager/server (2-stage concept)
You can create your own repository server, but this requires experience and time to manage.
Stage 1: Sandbox / DEV / QAS systems
Stage 2: PRD
- This means you update your stage 1 in one point in time in your project or normal business operation.
- Update and Test your sandbox or development and quality assurance system
- After successful tests you will update stage 2 = PRD
- Update and Test your PRD system in a maintenance window
Note: Updating the repository does not mean that all system in the stage are updated and restarted. It just means that they are able to see the new packages in the repository. The point in time when you update the system and plan the restart to activate the new versions is in your hand and complete independent from the staging process. |
Big businesses
Depending on which Linux distribution (SLES / RHEL) you are using, you can use different repository manager / orchestration tools.
SLES
SUMA (SUSE Manager): Can manage RHEL and SLES (also Ubuntu and Debian).
RHEL
- SUMA
- Satellite
- Ansible
Such repositories should be frozen in different project phases to ensure the stability.
Staging (3-stage concept)
Stage 1: Sandbox / Dev systems
Stage 2: QAS
Stage 3: PRD
- This means you update you stage 1 in one point in time in your project or normal business operation.
- Update and Test your sandbox or development system
- Afterwards update QAS stage 2
- Update and Test your QAS system
- After successful tests you will update stage 3 = PRD
- Update and Test your PRD system in a maintenance window
Some customers are switching the DEV to stage 2 and updating stage 1 more often. Other possibility is to use a 4th stage.
Frequency of stage updates
What about the right time in normal business operations without influence from projects?
It depends on your security guidelines. For the most companies it is sufficient to update the kernel and software packages once per year but for systems which are in a special function or areas like DMZ you have to update them more frequently. For other non-SAP Linux systems like webserver or proxies which you have not so strict specification and dependencies you have an own staging. I recommend creating a staging for SAP products (application servers and HANA DB).
Since Live Patching is now fully included in your SLES4SAP subscription since 07/2021 you are able to update security patches online (please be aware that there are some dependencies for a restart within a certain time)
You can update your stages daily or weekly, but you have to take care when your systems are using those packages and actively using them.
Right time for new OS and HANA releases
Therefor we have to take a closer look at the maintenance strategy and lifecycles.
HANA maintenance
2021789 - SAP HANA 1.0 Revision and Maintenance Strategy
2378962 - SAP HANA 2.0 Revision and Maintenance Strategy
HANA maintenance strategy
HANA 1.0
HANA 2.0
You have one new SPS (Support Package Stack) per year. SAP is providing bug fixes and security patches for every SPS for 2 years after RTC (=Release-to-Customer).
Summary:
This means that you have to update your HANA at least once in two years. This new release should be planned and tested carefully and properly. I recommend combining the OS update(kernel/packages) / upgrade (minor/major step) with such HANA lifecycle to avoid additional tests and downtimes.
Update: SPS05 was released end of June 2020 and SAP is providing 5 years of support after RTC (=long term support release).
- SPS3 will run out of maintenance in
04/2020update: end of 06/2020
- SPS4 is also out of maintenance since 07/2021
- We are searching for an OS which supports at least SPS5
My personal recommendation for normal releases (2-years support): Wait 6 months after RTC of a SPS to evaluate such a HANA revision. Why? Every SPS is coming with new features. In the past this new features made some trouble. This may not be the case in the future, but with these 6 months you are on the safe side. |
SLES
If you want to go for a new SLES release I can recommend SLES15 SP3 because for S/4HANA2020 and S/4HANA2021 you need a SLES15 release (at least SLES15 SP1 due to HANA SPS06 support). You should plan to upgrade your SLES12 systems in the next 2 years.
RHEL
https://access.redhat.com/support/policy/updates/errata
support for RHEL 8.0 was extended by 6 months
This is valid for the Update Services for SAP Solutions Add-on. In the meanwhile RHEL 7.7 + 8.1 has been certified.
Due the short support of RHEL 8.0 I can’t recommend going for it. I would recommend HANA 2.0 SPS5 RHEL8.4 for new projects, because currently there is an issue with the old GCC libs the HANA 2.0 SPS04 was compiled with. This libs are not available out of the box in the RHEL 8.1 channels (status quo 07/2020). Please skip the short releases like 8.0 and 8.3 because they won't be certified for SAP HANA at all.
Combining HANA and OS lifecycle
Start validating your OS in April 2020. (exception: SPS 05 will be released end of June 2020; support of 5 years!)
Start validating the latest HANA revision of SPS5 in November/December 2020.
This validation can be combined with Capture & Replay and SQL Plan Stability feature. This phase takes about 4-10 weeks depending on the used features, the different workloads (different days / system types) and the findings.
Example: Internal test results by SAP
At the end you will start your productive update with your final setup in 02/2021 which means you have only 14 months of maintenance left for it. Of course, you can use this SPS longer than April 2022, but you won’t receive any code fixes of bugs after this period. I don’t recommend doing this for a long time. With SLES12 SP4 or SLES15 SP1 you will get support till mid/end of 2023. With RHEL 7.6 you will get support till 10/2023. This means the next OS evaluation of the next minor/major update should take place in April of 2022.
Tip Combine a system copy with your QAS test phase for your Capture & Replay. |
Summary
- HANA Release-to-Customer: April of each year
- Start OS testing phase: April of each year (new packages or minor/major step)
- HANA testing: 6-months after RTC in November
- Finalizing HANA/OS package: 4-6 weeks after November => February of upcoming year
- Frequency of updating stages: 1-4 times per month (security reasons), depending on the number stages and your updating process or per need
- Update packages within a supported OS release: at least 1-2 times per year (depending on security policy and planned downtime windows)
##############
Edit:
V1.1 2020-07-26 Update HANA 2.0 SPS5 , RHEL 8.1 + SLES15 SP1
V1.2 2020-07-27 Update RHEL 7.7 now supported for SAP HANA
V1.3 2022-01-21 Live Patching and updated release details
##############
- SAP Managed Tags:
2 Comments
