HANA 2.0 SP1 on SUSE 12 SP02

This time I will show you how to install SAP HANA 2.0 SP01 with latest patch on SUSE 12 SP02. I am not using Redhat because they refused to give me a trial with SAP repositories, so SUSE for the win.

Required SAP Notes

1984787 – SUSE LINUX Enterprise Server 12: Installation notes

2205917 – SAP HANA DB: Recommended OS settings for SLES 12 / SLES for SAP Applications 12

2404375 – SAP HANA Platform 2.0 SPS 01 Release Note

2456795 – SAP HANA 2.0 SPS 01 Database Revision 011

2235581 – SAP HANA: Supported Operating Systems

Register your system first. Assign a hostname, static IP address and then continue.

Setup your disk layout according to your landscape. Considering this is only a test system I am giving 100 GB to operating system, 25 GB to SWAP and rest to HANA.

Change Software settings

Disable Firewall and continue

Check disks

Check release

Install Vmware Tools

Mount Vmware Tools and copy compressed file into /tmp

Update system (if anything is available for your subscription)

Copy installation files into /hana/install

-Reminder. Do not use installation packages from SAP Marketplace. Use packages from Support Package instead.

Adjust SUSE Linux to HANA

SLES 12 SP2 requirements (applies currently to Intel-based systems only)

glibc-2.22-51.6 or newer

systemd-228-142.1 or newer

Copy “/usr/lib/tuned/sap-hana/tuned.conf” to “/etc/tuned/sap-hana/tuned.conf” and change/add “force_latency” to the following:

force_latency=70

Manually create the file “/etc/systemd/logind.conf.d/sap.conf” with the following content:

[Login]

UserTasksMax=infinity

To enable these changes, a system reboot is required.

From SUSE RL

The version of systemd shipped in SLES 12 SP2 uses the PIDs cgroup controller. This provides some per-service fork() bomb protection, leading to a safer system.

However, under certain circumstances you may notice regressions. The limits have already been raised above the upstream default values to avoid this but the risk remains.

If you notice regressions, you can change a number of TasksMax settings.

To control the default TasksMax= setting for services and scopes running on the system, use the system.conf settingDefaultTasksMax=. This setting defaults to 512, which means services that are not explicitly configured otherwise will only be able to create 512 processes or threads at maximum.

For thread- or process-heavy services, you may need to set a higher TasksMax value. In such cases, set TasksMax directly in the specific unit files. Either choose a numeric value or even infinity.

Similarly, you can limit the total number of processes or tasks each user can own concurrently. To do so, use the logind.confsetting UserTasksMax (the default is 12288).

nspawn containers now also have a TasksMax value set, with a default of 16384.

From <https://www.suse.com/releasenotes/x86_64/SUSE-SLES/12-SP2/>

Also you can edit logind.conf

UUIDD Check

tuned HANA

Turn off auto NUMA balancing

SAP HANA is a NUMA (non-uniform memory access) aware database. Thus it does not rely on the Linux kernel’s features to optimize NUMA usage automatically. Depending on the workload, it can be beneficial to turn off automatical NUMA balancing (autoNUMA). In order to permanently switch off autoNUMA either

Call saptune with the parameter “HANA” (starting with SLES 12 for SAP Applications SP2)

# saptune solution apply HANA

Edit /etc/default/grub

search for the line starting with “GRUB_CMDLINE_LINUX_DEFAULT” and append to this line

numa_balancing=disable

Save your changes and run

# grub2-mkconfig -o /boot/grub2/grub.cfg

After a reboot, autoNUMA will be disabled.

Use YaST2 bootloader, execute

# yast bootloader

Choose “Kernel Parameters” tab (ALT-k) and edit the “Optional Commandline Parameters” section by appending

numa_balancing=disable

To enable this change, a system reboot is required. In a scale-out environment, those changes have to be done on every server of the landscape. In case you already have a running HANA instance, rebooting the server should only be done when a standby server is configured. Do not reboot all servers at once. For single node instances a downtime has to be considered.

Disable transparent hugepages

With SLES 12, the usage of transparent hugepages (THP) is generally activated for the Linux kernel. The THP allows the handling of multiple pages as hugepages to reduce the translation lookaside buffer (TLB) footprint, in situations where it might be useful. Due to the special manner of HANA’s memory management, the usage of THP may lead to hanging situations and degradations.

To check the current configuration run the following command:

# cat /sys/kernel/mm/transparent_hugepage/enabled

Its output should read:

always madvise [never]

If this is not the case you can disable the THP usage at runtime by issuing the following:

# echo never > /sys/kernel/mm/transparent_hugepage/enabled

There is no need to shut down the database to apply this configuration. This setting is then valid until the next system start. To persist the disabling of THP usage you have the following options:

Call saptune with the parameter “HANA” (starting with SLES 12 for SAP Applications SP2)

# saptune solution apply HANA

Edit /etc/default/grub

search for the line starting with “GRUB_CMDLINE_LINUX_DEFAULT” and append to this line

transparent_hugepage=never

Save your changes and run

# grub2-mkconfig -o /boot/grub2/grub.cfg

After a reboot, the usage of THP will be disabled.

Use YaST2 bootloader, execute

# yast bootloader

Choose “Kernel Parameters” tab (ALT-k) and edit the “Optional Commandline Parameters” section by appending

transparent_hugepage=never

To enable this change, a system reboot is required. In a scale-out environment, those changes have to be done on every server of the landscape. In case you already have a running HANA instance, rebooting the server should only be done when a standby server is configured. Do not reboot all servers at once. For single node instances a downtime has to be considered.

Configure C-States for lower latency in Linux (applies to Intel-based systems only)

An Intel CPU normally operates in C-state C0. When the processor is put to a higher C-state, it will save power. But for low latency applications, the additional time needed to stop and restart the execution of the code will cause performance degradations. We recommend to limit the C-states to C0 and C1 by setting the following parameters:

intel_idle.max_cstate=1 processor.max_cstate=1

To set this parameter permanently, use one of the following options:

Call saptune with parameter “HANA” (starting with SLES 12 for SAP Applications SP2)

# saptune solution apply HANA

Edit /etc/default/grub

search for the line starting with “GRUB_CMDLINE_LINUX_DEFAULT” and append to this line

intel_idle.max_cstate=1 processor.max_cstate=1

Save your changes and run

# grub2-mkconfig -o /boot/grub2/grub.cfg

After a reboot the usage of C-states C2 and higher will be disabled.

Use YaST2 bootloader, execute

# yast bootloader

choose “Kernel Parameters” tab (ALT-k) and edit the “Optional Commandline Parameters” section by appending

intel_idle.max_cstate=1 processor.max_cstate=1

To enable this change, a system reboot is required. In a scale-out environment, those changes have to be done on every server of the landscape. In case you already have a running HANA instance, rebooting the server should only be done when a standby server is configured. Do not reboot all servers at once. For single node instances a downtime has to be considered.

Energy Performance Bias EPB (applies to Intel-based systems only)

The Linux 3.x kernel obeys the EPB bit in the CPU flags. Consequently, it configures the CPUs according to the global “energy performance bias” setting in the BIOS. If the EPB setting in the BIOS is “Maximum performance”, all should be fine. Otherwise, the CPUs try to save power at the cost of reduced performance. The power management dialog in YaST (yast2 power-management) has a dropdown menu where you can set the system to “low latency/maximum performance” resp. “Low Latency Computing”, it takes effect immediately, and a reboot is not required.

You can achieve the same on the command line by running

# cpupower set -b 0

Further Optimization

VFS Caches

echo 50 > /proc/sys/vm/vfs_cache_pressure

Memory Overcommit

echo 1 > /proc/sys/vm/overcommit_memory

echo 70 > /proc/sys/vm/overcommit_ratio

HANA Installation

Install components

AFL

Data Provisioning Agent

Smart Data Access (normally you have this package, only install / update if you have lower version)

HANA Client

HANA Cockpit 2.0

In HANA 2.0, Cockpit 1.0 is installed as default and you cannot use it. If you want to use Cockpit you need to use 2.0 of it. It is recommended to install in another server and use it as a central HANA management system.

Remember to take note of your ports.

HANA Studio

Result

Remember, after HANA 2.0 SP1, it is no longer to create single systems. All HANA databases are now multitenant databases. If you have standalone database and want to migrate HANA 2.0 SP01 consider multitenant sizing.

HANA Cockpit Setup

Register Resources and systems

HANA Cockpit Monitoring