Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
Applies to SUSE Linux Enterprise Server for SAP Applications 11 SP4

5 SUSE Linux Enterprise Server for SAP Applications Components

SUSE® Linux Enterprise Server for SAP Applications consists of several components such as SUSE Linux Enterprise High Availability Extension, the Kernel page-cache limit feature, and an Installation Wizard, which are briefly explained in the following sections.

5.1 SUSE Linux Enterprise High Availability Extension

The SUSE Linux Enterprise High Availability Extension add-on is part of SUSE Linux Enterprise Server for SAP Applications.

For more information about SUSE Linux Enterprise High Availability Extension, see

5.2 Resource Agents for SAP HANA System Replication

SUSE Linux Enterprise Server for SAP Applications supports SAP HANA System Replication using components of SUSE Linux Enterprise High-Availability Extension and two additional resource agents (RA).

Important: Package Update

The features described below are supported starting with version 0.151 of the package SAPHanaSR. Make sure to update to this version or a newer version of the package.

5.2.1 SAPHana Resource Agent

This resource agent from SUSE supports scale-up scenarios by checking the SAP HANA database instances for whether a takeover needs to happen. Unlike with the pure SAP solution, takeovers can be automated.

It is configured as a master/slave resource: The master assumes responsibility for the SAP HANA databases running in primary mode, whereas the slave is responsible for instances that are operated in synchronous (secondary) status. In case of a takeover, the secondary (slave resource instance) can automatically be promoted to become the new primary (master resource instance).

This resource agent supports system replication for the following in scale-up scenarios:

  • Performance-Optimized Scenario.  Two systems (A and B) in the same SUSE Linux Enterprise High-Availability Extension cluster, one primary (A) and one secondary (B). The primary system (A) is replicated synchronously to the secondary system (B).

  • Cost-Optimized Scenario.  The basic setup of A and B is the same as in the Performance-Optimized Scenario. However, the secondary system (B) is also used for non-productive purposes, such as for a development or QA database. The production database is only kept on permanent memory, such as a hard disk. If a takeover needs to occur, the non-productive system is stopped before the takeover is processed. The system resources for the productive database are then increased as quickly as possible via an SAP hook call-out script.

  • Chain/Multi-Tier Scenario.  Three systems (A, B, and C), of which two are located in the same SUSE Linux Enterprise High-Availability Extension cluster (A and B). The third system (C) is located externally. The primary system (A) is replicated synchronously to the secondary system (B). The secondary system (B) is replicated asynchronously to the external system (C).

    If a takeover from A to B occurs, the connection between B and C remains untouched. However, B is not allowed to be the source for two systems (A and C), as this would be a star topology which is not supported with current SAP HANA versions (such as SPS11).

    Using SAP HANA commands, you can then manually decide what to do:

    • The connection between B and C can be broken, so that B can connect to A.

    • If replication to the external system site is more important than local system replication, the connection between B and C can be kept.

For all of the scenarios, SUSE Linux Enterprise Server for SAP Applications supports both single-tenant and multi-tenant SAP HANA databases. That is, you can use SAP HANA databases that serve multiple SAP applications.

5.2.2 SAPHanaTopology Resource Agent

To make configuring the cluster as simple as possible, SUSE has developed the SAPHanaTopology resource agent. This agent runs on all nodes of a SUSE Linux Enterprise High-Availability Extension cluster and gathers information about the status and configurations of SAP HANA system replications. It is designed as a normal (stateless) clone.

5.2.3 For More Information

For more information, see:

5.3 Configuring SUSE Linux Enterprise Server for SAP Applications

5.3.1 Kernel: Page-Cache Limit


The kernel swaps out rarely accessed memory pages in order to use freed memory pages as cache to speed up file system operations, for instance during backup operations.

Some SAP solutions use large amounts of memory for accelerated access to business data. Parts of this memory are seldom accessed. When a user request then needs to access paged out memory, the response time is poor. It is even worse, when an SAP solution running on Java incurs a Java garbage collection. The system starts heavy page-in (disc I/O) activity and has a poor response time for an extended period of time.


A new kernel tune option has been introduced that allows the system administrator to limit the amount of page-cache that the kernel uses when there is competition between application memory and page-cache. This option tells the kernel that once the page-cache is filled to the configured limit, application memory is more important and should thus not be paged out. No pages will be paged out if the memory footprint of the workload plus the configured page-cache limit do not exceed the amount of physical RAM in the system.

Two new kernel options are available for configuration:

  • vm.pagecache_limit_mb (/proc/sys/vm/pagecache_limit_mb)

  • vm.pagecache_limit_ignore_dirty (/proc/sys/vm/pagecache_limit_ignore_dirty)

For permanent use, set them in /etc/sysctl.conf, e.g.

vm.pagecache_limit_mb = 1024
vm.pagecache_limit_ignore_dirty = 0

For background information, see SAP Note 1557506: Linux paging improvements https://launchpad.support.sap.com/#/notes/1557506.

5.3.2 Ports Configuration

SAP applications require many open ports and port ranges in the firewall. The exact numbers depend on the selected instances, for example:

  • 3200-3399,

  • 3600,

  • 4700-4899,

  • 7200-7299,

  • 50000-59999.

It is also necessary to open 1128 and 1129 (TCP and UDP), and all the ports needed for the databases used (Oracle, DB2, MaxDB, Sybase).

Warning: Firewall Activation

The firewall is disabled if you use the wizard, and enabled if you use the normal setup.

5.3.3 Important Log Files

The most important files for this product are:

  • Auto-installation related log files are in /var/adm/autoinstall/.

  • The installation wizard is a YaST module. Thus you will find wizard related log entries in /var/log/YaST/y2log.

  • We use a library for all SAP knowledge. Thus you will find related log entries in /var/log/SAPmedia.log.

5.4 The Installation Wizard

The Installation Wizard offers a guided installation path for both the SUSE Linux Enterprise Server operating system and the SAP applications.

Additionally, it includes an installation framework for 3rd party extensions.

The Installation Wizard consists of four parts:

  1. Installation of the operating system (SUSE Linux Enterprise Server).

  2. SAP Wizard Part 1: Copying all required SAP media to the local disk or use a shared storage medium.

  3. SAP Wizard Part 2: Collecting all parameters for the actual installation by querying the user interactively.

  4. SAP Wizard Part 3: Running the SAP Installer.

It is possible to run most of these parts separately. This way, very flexible installation scenarios are possible. Here are some examples:

  • Just prepare a machine with the operating system (SUSE Linux Enterprise Server) and run the SAP Wizard later.

  • Just prepare a machine with the operating system (SUSE Linux Enterprise Server), copy the SAP media, and collect the SAP installation parameters.

You can copy such an installation to other machines, maybe adjusting just a few SAP installation parameters. Then finally run the SAP Installer.

5.4.1 Supplement Media

The basic idea of the Supplement Media is to enable partners or customers to add their own tasks or workflows to the Installation Wizard.

It is done by adding a small XML file, which will be part of an AutoYaST XML file. This file must be called product.xml; then it will be included in the workflow.

This can be used for various types of additions, such as adding your own RPMs, running your own scripts, setting up a cluster file system or creating your own dialogs and scripts. product.xml

The product.xml file looks like a normal AutoYaST XML file, but with some restrictions.

The restrictions relate to the fact that only the parts for the second stage of the installation can be run, because the first stage was executed before.

Both XML files (autoyast.xml and product.xml) will be merged after the media is read and a new AutoYaST XML file is generated on the fly for the additional workflow.

The following areas or sections will be merged:

  <ask-list>         1
<software>           2
  <chroot-scripts>   3
  <post-scripts>     4
  <init-scripts>     5


see Section, “Own AutoYaST Ask Dialogs”


see Section, “Install Additional Packages”


after the package installation, before the first boot


during the first boot of the installed system, no services running


during the first boot of the installed system, all services up and running

All other sections will be replaced.

For the details of other customization options, see the SLES AutoYaST Guide, Chapter 4.12. Custom User Scripts. Own AutoYaST Ask Dialogs

For a general overview and details of the Ask feature of AutoYaST, see Chapter 4.17. Ask the User for Values During Installation of the SLES AutoYaST Guide (the AutoYaST Guide comes with the product or is available from http://documentation.suse.com/sles/11-SP4/).

For the supplement media you can only use dialogs within the cont stage (<stage>cont</stage>), which means they are executed after the first reboot.

Your file with the dialogs will be merged with the base AutoYaST XML file.

As a best practice, your dialog should have a dialog number and an element number, best with steps of 10. This helps to include later additions and also could be used as targets for jumping over a dialog or element dependent on decisions. We also use this in our base dialogs and if you provide the right dialog number and element number, you can place your dialog between our base dialogs.

You can store the answer to a question in a file, to use it in one of your scripts later. Be aware that you must use the prefix /tmp/ay for this, because the Installation Wizard will copy such files from the /tmp directory to the directory where your media data also will be copied. This is done because the next supplement media could have the same dialogs or same answer file names and would overwrite the values saved here.

Here is an example with several options:

<?xml version="1.0"?>
<!DOCTYPE profile>
<profile xmlns="http://www.suse.com/1.0/yast2ns"
  <ask-list config:type="list">
          <dialog config:type="integer">20</dialog>
          <element config:type="integer">10</element>
          <question>What is your name?</question>
          <default>Enter your name here</default>
          <help>Please enter your full name within the field</help>
             <rerun_on_error config:type="boolean">true</rerun_on_error>
             <environment config:type="boolean">true</environment>
function check_name() {
           local name=$1
           [ -z "$name" ] && echo "You need to provide a name." && return 1
           return 0
check_name "$VAL"
             <debug config:type="boolean">false</debug>
             <feedback config:type="boolean">true</feedback>
</profile> Install Additional Packages

You can also install RPM packages within the product.xml file. To do this, you can use the <post-packages> element for installation in stage 2.

For more information, see the SLES AutoYaST Guide, Chapter 4.5.6. Installing Packages during Stage 2. An example looks as follows:

 <post-packages config:type="list">
... Example Directory for the Supplement Media

# ls

5.4.2 ClamSAP

ClamSAP is a new antivirus toolkit integration with the SAP Virus Scan Interface that improves cross-platform threat detection.

ClamSAP is a ‘C’ shared library to link between ClamAV and the virus scan interface of SAP (NW-VSI). An SAP application can use the ClamAV engine to scan for malicious uploads in HTTP uploads for example. If you want to use Virus Scan within SAP applications, you can use Virus Scan Interface in SAP (Transaction › VSCAN). There is an open source adapter for the ClamAV engine at http://freshmeat.net/projects/clamsap/. The library allows integration of ClamAV into SAP and works also on Unix, where most other antivirus products do not run.

ClamAV is an open source (GPL) antivirus engine designed for detecting Trojans, viruses, malware, and other malicious threats. It is the de facto standard for mail gateway scanning. It provides a high performance multi-threaded scanning daemon, command line utilities for on-demand file scanning, and an intelligent tool for automatic signature updates. For more information, see http://www.clamav.net.

Print this page