HANA – Linux staging

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.

1. Reasons for staging
2. Staging process
i. Small businesses
ii. Big businesses
3. Frequency of stage updates
4. Right time for staging tests
i. HANA maintenance
ii. Linux lifecycle
iii. 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.

1. 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:

1. Update all servers in week 10 to one repository version

2. Order all servers in week 1 and install them with one repository version

3. 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

1. This means you update your stage 1 in one point in time in your project or normal business operation.

2. Update and Test your sandbox or development and quality assurance system

3. After successful tests you will update stage 2 = PRD

4. 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

1. This means you update you stage 1 in one point in time in your project or normal business operation.

2. Update and Test your sandbox or development system

3. Afterwards update QAS stage 2

4. Update and Test your QAS system

5. After successful tests you will update stage 3 = PRD

6. 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.

3. 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).

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.

4. Right time for new OS and HANA releases

Therefor we have to take a closer look at the maintenance strategy and lifecycles.

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.

◉ SPS3 will run out of maintenance in 04/2020

◉ We are searching for an OS which supports at least SPS4

My personal recommendation:

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

https://www.suse.com/lifecycle/

This is valid for the SLES4SAP subscriptions. SLES12 SP5 is currently (01/2020) not certified for SAP HANA.

If you want to go for a new SLES release I can recommend SLES12 SP4 when you are already on SLES12 and don’t want to change a lot and your staff is not familiar with the changes coming with SLES15. If you are already familiar with SLES15 go for SP1.

RHEL

https://access.redhat.com/support/policy/updates/errata

This is valid for the Update Services for SAP Solutions Add-on. Currently (01/2020) RHEL 7.7 and 8.1 are not certified for SAP HANA.

Due the short support of RHEL 8.0 I can’t recommend going for it.

At this point in time (01/2020) I would recommend RHEL 7.6.

Combining HANA and OS lifecycle

Start validating your OS in April 2020.

Start validating the latest HANA revision of SPS5 in November 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.