Using HP-UX Workload Manager with SAP

4 Abbreviations used

WLM

HP-UX Workload Manager

PRM

HP-UX Process Resource Manager

PSETs

HP-UX Processor Sets

FSS

HP-UX Fair Share Scheduler

SLO

Service-level objective

vPars

HP-UX Virtual Partitions

nPars

nPartitions

wlmsapmap

The WLM SAP process ID finder utility

5 Workload requirements

The workload separation described here is largely aimed at CPU-bound workloads, or workloads that are contending for CPU resources. Although not covered in this paper, WLM can also control disk bandwidth and memory. Examples of those controls are described in other documentation. Also not covered here are workloads that are contending for, or limited by, network resources.

6 Platforms used for this paper

The SAP/WLM techniques outlined here were tested with the software revisions indicated in the table below.

7 Separating processes into WLM workload groups

To understand what tools we have at our disposal to separate and control workloads, this section provides a quick overview of WLM workload groups and separation. Much more information on the operation of WLM (and PRM, which provides some of WLM's functionality) can be found in the WLM User's Guide and the wlm(5) manpage. These documents are available on systems with WLM installed. In addition, they are available through http://www.hp.com/go/wlm.

7.1 WLM overview

WLM controls workloads on HP-UX servers based on WLM workload groups. You define the workload groups and assign applications and users to the groups. WLM then adjusts the CPU allocations for the groups based on your defined service-level objectives (SLOs). WLM can also control memory and disk bandwidth allocations for the workload groups. (In the WLM context, a 'workload' is a group of HP-UX processes that jointly perform some work.)

WLM has two types of workload groups:

• FSS workload groups
  With these groups, WLM uses the Fair Share Scheduler (FSS) to allocate CPU based on CPU time slices. A given FSS group is provided with a particular share of the CPU allocation across all CPUs in the system. This provides good resource sharing, as the CPU allocation is very fine, but provides very little isolation and limited CPU locality.

• PSET workload groups
  WLM can use PSETs (processor sets) as the foundation for workload groups. For these groups, WLM manages the number of CPUs assigned to the underlying PSETs. A PSET offers its processes dedicated CPUs—no other processes on the system can access those CPUs.

WLM can also manage CPUs across either:

• virtual partitions (vPars)

  or

• nPartitions (nPars) that use Instant Capacity cores

vPars offer dedicated resources to their processes. In addition, a vPar has its own instance of the HP-UX operating system, providing OS isolation. nPars also offer dedicated resources and their own instances of HP-UX. In addition, nPars offer hardware isolation. With Instant Capacity, CPU resources are installed on a system but are not available for use until purchased. This feature allows you to buy a system that meets current needs but also provides a quick and efficient upgrade path.

With virtual partitions (vPars), WLM migrates CPUs between the vPars as their respective SLOs demand. Using nPars that have CPU resources managed by Instant Capacity software, WLM can deactivate CPU resources on one nPar and activate a purchased but inactive Instant Capacity core on another nPar that needs the CPU resource more. This pseudo-movement of CPUs ensures resources are available where they are needed without incurring the charge of purchasing more CPU resources.

To summarize, WLM can manage the items in the following table.

While FSS workload groups provide very flexible CPU allocation, they provide no OS or hardware isolation. Conversely, vPars and nPars offer more isolation, but CPU allocation is less flexible and administration overhead is increased.

7.2 WLM's separation mechanisms

For PRM-based configurations, WLM provides several methods to place processes in workload groups. It is important to understand these methods as they are used in our SAP workload separation methods. First, let's see how we define workloads. The following snippet from a WLM configuration file creates three workload groups: OTHERS, servers_grp, and SAP_grp:

	prm {
	    groups = OTHERS : 1,
		 servers_grp : 2,
		 SAP_grp : 3;
	}
    

The following sections explore how WLM places processes in defined workload groups.

7.2.1 User records: workload separation by process owner UID

The first mechanism to separate workloads is a user record. With user records, you can place processes according to their owner's UID. Here is an example:

	prm {
	    groups = OTHERS : 1,
		     testers : 2,
		     coders : 3,
		     surfers : 4;

	    users = moe : coders surfers,
		    curly : coders surfers,
		    larry : testers surfers;
	}
    

Besides the default OTHERS group, this example has three groups of users: testers, coders, and surfers. The user records cause processes started by users moe and curly to be run in group coders by default, and user larry's processes to be run in group testers by default. Each user is also given permission to run jobs in group surfers if they wish, using the prmrun or prmmove commands mentioned later. Users not belonging to either the coders group or testers group are placed in OTHERS by default.

7.2.2 Application records: workload separation by binary name The next mechanism to separate workloads is an 'app record'. This simply names a particular application binary and the group in which it should be placed. There are two variants of interest.

7.2.2.1 Separation by binary names

	prm {
	    groups = OTHERS : 1,
		 servers_grp : 2,
		 SAP_grp : 3;

	    apps = SAP_grp : /sapmnt/C00/exe/sap;
	}
    

The app record above causes the PRM application manager to place any newly running sap executables into the group SAP_grp.

7.2.2.2 Separation by alternate names

	prm {
	    groups = OTHERS : 1,
		 servers_grp : 2,
		 SAP_grp : PSET;

	    #
	    # Note that /bin/sh must appear in either
	    # /etc/shells or /opt/prm/shells for this to work
	    #
	    apps = SAP_grp : /bin/sh startSAPinst.sh ;
	}
    

The app record above causes the PRM application manager to place any newly running /bin/sh script named startSAPinst.sh into the group SAP_grp. Note that for this to work, /bin/sh must appear in either /etc/shells or /opt/prm/shells. See the wlmconf(1M) manpage for more information on alternate names.

NOTE on polling: It is important to realize that for either application name or alternate names, the process is not placed in the workload group at fork() time. Rather, the PRM application manager periodically polls for newly started processes that match app records. If it detects one or more matches, the processes are moved to their respective workload groups. For more information, see the application manager discussion in the WLM documentation.

7.2.3 Secure compartment records: workload separation by secure compartment ID The third mechanism to separate workloads is a secure compartment (scomp) record. The scomp record specifies which workload group the processes running in a certain secure compartment should be placed in. For instance, the following example causes the processes that are part of the SAP_sec_comp compartment to be run in the the SAP_grp workload group:

	prm {
	    groups = OTHERS : 1,
		 servers_grp : 2,
		 SAP_grp : 3;

	    scomp = SAP_sec_comp : SAP_grp;
	}
    

7.2.4 Process map records: user-defined workload separation The final mechanism to separate workloads is a process map (procmap) record. A procmap record allows a user to specify their own criteria for placing processes into workload groups. The procmap record consists of two elements: a workload group and a process ID (PID) finder utility. The PID finder utility is a script or series of commands connected by pipes that return a list of PIDs for the processes that should be moved to the corresponding group. For instance, here is a procmap record that causes processes whose PIDs were returned by the wlmsapmap utility to be moved to the SAP_grp workload group:

	prm {
	    groups = OTHERS : 1,
		 servers_grp : 2,
		 SAP_grp : 3;

	    procmap = SAP_grp : /opt/wlm/toolkits/sap/bin/wlmsapmap -t DIA
			-f /etc/cmcluster/C11/wlmprocmap.C11_D01_node1;
	}
    

The PID finder utility is not a persistent process, rather each PID finder utility is run by WLM every 30 seconds. This allows WLM to place new processes into their correct workload groups as those processes get started.

For more information on group permissions and precedence of user, application, scomp, and procmap records, see the WLM documentation.

7.2.5 prmrun: starting a process in a workload group

Besides using app and user records to place processes into groups, you can explicitly start processes in particular groups. Given the group and user records described above, user larry running the command:

	% my_really_big_job &
    

	% prmrun -g surfers my_really_big_job &
    

7.2.6 prmmove: moving an existing process to a workload group

Besides using prmrun to start new processes in particular groups, existing processes can be moved to a new group with the prmmove command. If larry from the above example has a job running with process ID (PID) 4065 running in group testers, he could move that process to group surfers by running the command:

	% prmmove surfers -p 4065
    

7.2.7 Default: inheriting workload group from parent process

If a process is not named by an explicit user, app, scomp, or procmap record, or has not been started with prmrun or moved with prmmove, it simply starts and runs in the same group as its parent process. So for a setup like this:

	prm {
	    groups = OTHERS : 1,
		    mygrp : 2;
	}
    

8 WLM workload and resource monitoring tools

There are a wide variety of tools available to help you monitor the process placement and resource allocation and use of your workloads.

• prmmove(1), prmrun(1)
  tools to place processes in workload groups
• ps(1) -R, ps(1) -P
  tools to see processes' current workload group
• wlminfo(1M)
  command-line tool to monitor wlmd or wlmpard SLO status, metrics, and workload group allocation and usage
• wlmgui(1M)
  graphical tool to monitor a single or multiple machines' WLM setups

9 Use cases

9.1 Using WLM to manage a partition hosting SAP

Hosting an SAP system in a virtual partition (vPar) or nPartition (nPar) is an effective way to isolate the SAP instance for security purposes. The drawback to this solution is that when the SAP system is not consuming all the CPU resources, those resources are just going to waste instead of being used in another partition on the complex. WLM can resolve this issue by migrating the unused CPUs to other vPars or nPars so that they are no longer going to waste.

9.1.1 Configuration

Starting with WLM A.03.00, strictly host-based configurations are available that allow a partition (vPar or nPar) to be managed as a single workload. Host-based configurations are similar to the existing PRM-based configurations in that SLOs and metrics can still be defined, but host-based configurations do not use the prm structure in the configuration. Therefore, there are no FSS or PSET workload groups. When usage goals are driving the service-level resource requests, the usage of the entire HP-UX instance is considered. Outside of the prm structure, all the other configuration elements are available to host-based configurations.

Using host-based configurations to migrate CPU resources across partitions is fairly straightforward: Each partition being managed by WLM must have a local configuration running, and there is generally a single global arbiter running to manage all the partitions in a physical complex. The global arbiter daemon is wlmpard, and it can be run on any HP-UX system that has network connectivity to the partitions being managed. The following is an example of a host-based configuration that can be deployed on one of the managed partitions:

	primary_host = sap_server;

	tune {
	    wlm_interval = 5;
	}

	slo slo_myslo {
	    pri = 1;
	    goal = usage _CPU;
	}

The configuration uses sap_server as the global arbiter and has a service level with a usage goal to drive the resource requests. A configuration similar to this would be running on each of the partitions being managed by WLM. The complete example configuration is available with more comments as part of the core WLM product and is located at /opt/wlm/examples/wlmconf/par_usage_goal.wlm.

The global arbiter configuration is even more straightforward than the configuration local to each partition. There are actually no required settings in the wlmpard configuration file, but the following example uses the interval keyword so that wlmpard will consider reallocating resources among the partitions every 10 seconds:

	par {
	    interval = 10;
	}

There are other settings in the wlmpard configuration file to control the size of the log file and the network port that configurations local to the partitions connect to. Another interesting WLM feature controlled in the global arbiter file is WLM's utility mode. This mode allows available CPU resources, including Temporary Instant Capacity (TiCAP) and Pay-Per-Use (PPU) resources, to be activated when they are needed. The keyword that controls WLM's utility mode is the utilitypri keyword. Its value specifies the lowest service level priority at which WLM is allowed to activate additional CPU resources. Expanding the previous example:

	par {
	    interval = 10;
	    utilitypri = 2;
	}

Now, this configuration will activate additional TiCAP or PPU CPU resources if any service level at or above priority 2 is failing. The CPU resources will be deactivated once it is determined the service levels will be passing if the CPU resources are deactivated. This example configuration is available with more comments as part of the core WLM product and is located at /opt/wlm/examples/wlmconf/par_usage_goal.wlmpar.

wlminfo can be used to monitor the resource consumption and service-level objective status for partitions. Using the wlminfo host command, you can see the resource allocation and consumption for the local HP-UX instance:

	Hostname                 CPUs  CPUs Used  Interval
	localhost                   1          0         5

9.1.2 Monitoring

The wlminfo host command only displays output for the host that the command was run on. To see usage information about all the partitions being managed by the global arbiter, run the wlminfo par command on the system where wlmpard is running. Output similar to the following will be displayed:

	Hostname                 Intended CPUs  CPUs  CPUs Used  Interval
	sap_server                           1     1          0         5
	ora_server                           3     3       0.54         5

In this case, sap_server is the system where the WLM global arbiter is running as well as a managed partition. When the sap_server partition begins to get busy, CPUs will be transferred from ora_server to sap_server to satisfy the resource request for sap_server:

	Hostname                 Intended CPUs  CPUs  CPUs Used  Interval
	sap_server                           3     3       2.32         5
	ora_server                           1     1       0.67         5

If all the active CPU resources are in use and the resource requests are still not being met, WLM will activate available TiCAP or PPU resources to satisfy the requests. Note that the total number of active CPUs increased from 4 to 6:

	Hostname                 Intended CPUs  CPUs  CPUs Used  Interval
	sap_server                           5     5       3.72         5
	ora_server                           1     1       0.48         5

As shown by this example, using WLM's host-based configurations to migrate CPU resources across partitions is an effective way to share unused resources across partitions. This resource-sharing strategy can be used in any environment, but it is best suited for environments where there is either only one application running in a partition or multiple applications are running in each partition and there is no concern for resource management among the applications within each partition.

Previous discussions of the global arbiter imply that in general only one global arbiter manages all the partitions for a physical complex, but there are situations when multiple wlmpard daemons are needed for a complex. See the wlmpard(1M) manpage for more information.

9.1.3 Case summary

The examples shown here describe how to use WLM to automatically migrate CPU resources across partitions with strictly host-based configurations. The same techniques can be used with PRM-based configurations where there are FSS and PSET workload groups. When CPU resources are migrated among partitions and PRM-based configurations are used, the CPU resources are allocated to the workload groups that are in the most need of the resources.

9.2 Using WLM user records to isolate an SAP system

An SAP system can be given the resources it needs so that the system can run more efficiently without competing for resources against other SAP systems or other applications. Isolating an entire SAP system is straightforward with WLM's user records.

9.2.1 Configuration

In this example, all the processes from the SAP system running as a specified user will be placed in the same workload group. The user record description above was a generic example, but now the same approach can be applied to an SAP system. For example, assume that the SAP system P00 is running and the processes are running as user p00adm. The following WLM configuration file segment would place all the processes running as p00adm into the SAP workload group:

	prm {
	    groups = OTHERS : 1,
		     Apache : 2,
		     SAP : 3;

	    apps = Apache : /opt/hpws/apache/bin/httpd;

	    users = p00adm : SAP;
	}

9.2.2 Monitoring

wlminfo, the WLM command-line monitoring tool, can be used to monitor the resource consumption and service-level objective status for the SAP system. Using the wlminfo groups command, you can see the resource allocation and consumption for the workload groups:

	Workload Group   PRMID  CPU Shares  CPU Util  Mem Shares  State
	OTHERS               1      402.00      0.00        0.00  ON
	Apache               2       96.00      0.00        0.00  ON
	SAP                  3      102.00      0.00        0.00  ON

Because both the SAP and Apache workload groups are idle, their resource entitlements settle at around their gmincpu values of 100 shares. Once the SAP system is running in the SAP workload group, the CPU Util column will show the amount of resources being consumed:

	Workload Group   PRMID  CPU Shares  CPU Util  Mem Shares  State
	OTHERS               1      402.00      0.00        0.00  ON
	Apache               2       96.00      0.00        0.00  ON
	SAP                  3      102.00     99.80        0.00  ON

The wlminfo slo command can be used to monitor the status of the service-level objectives associated with the workload groups:

	SLO Name             Group        Pri    Req Shares  State Concern
	s_apache             Apache         1    100     96  PASS
	s_sap                SAP            1 159.21    162  PASS

The wlminfo slo command provides you with all the essential information needed to verfiy the service-level objectives are being satisfied. The one column that has empty fields in this case is the Concern column. This is because all of the workloads have been allocated enough resources and as a result their SLOs are passing, so there is no need for concern. If one of the SLOs had been failing due to its resource request not being met, the Concern column would indicate a reason why it is failing. In the following case, the service level is failing because it has reached its maximum resource request of 300 shares:

	SLO Name             Group        Pri    Req Shares  State Concern
	s_apache             Apache         1    100    102  PASS
	s_sap                SAP            1    300    300  FAIL  Max

9.2.3 Case summary

This use case describes how to isolate a single SAP system from all other workloads for resource management purposes. Because each SAP system is generally run as different users, this same technique can be used to consolidate multiple SAP systems onto the same node and have their resources managed by WLM. Using the configuration file excerpt from above as a starting point, it can be expanded to accommodate multiple SAP systems:

	prm {
	    groups = OTHERS : 1,
		     Apache : 2,
		     SAP_P00 : 3,
		     SAP_P01 : 4,
		     SAP_P02 : 5;

	    apps = Apache : /opt/hpws/apache/bin/httpd;

	    users = p00adm : SAP_P00, p01adm : SAP_P01, p02adm : SAP_P02;
	}

With this expanded configuration, all processes run as user p00adm will run in the SAP_P00 workload group; all processes run as user p01adm will run in the SAP_P01 workload group; and all processes run as user p02adm will run in the SAP_P02 workload group.

9.3 Separating entire SAP instances into different workloads

A single SAP system consists of several different instances, with each one serving an important role in the overall picture. It is sometimes beneficial to control the amount of resources used by a single SAP instance as a whole to allow the other instances and applications access to the resources they need to run at their appropriate level of service. WLM can be used to separate an SAP instance into its own workload group so that the amount of resources the instance consumes can be controlled.

9.3.1 Configuration

The WLM feature that can be used to separate out the different types of SAP processes is process maps. As described previously, process maps allow a user to specify their own criteria for placing processes into workload groups. The process map records consist of a workload group name and a process ID (PID) finder utility. The PID finder utility returns a list of PIDs that WLM then moves into the correct workload group.

To make it easier to separate SAP processes into different workload groups, HP has developed a PID finder utility that works together with the Serviceguard extensions for SAP (SGeSAP) product. This PID finder utility is part of the WLM Toolkits product and can be found at /opt/wlm/toolkits/sap/bin/wlmsapmap. In order to isolate an entire SAP instance to its own workload group, one option and argument are needed:

	wlmsapmap -f map_file

	/etc/cmcluster/SID/wlmprocmap.SID_SAPInstance_hostname

where SID is the SAP system ID, SAPInstance is the instance identifier, and hostname is the node SAP is running on. Putting this all together into an example, /etc/cmcluster/C11/wlmprocmap.C11_D01_node1 is the map file for instance D01 of SAP system C11 running on node1.

The following excerpt from an example WLM configuration file shows how to use the wlmsapmap utility to separate the instances D01 and D02 of SAP system C11 into different workload groups:

	prm {
	
	    groups = OTHERS : 1,
		     SAP_DO1 : 2,
		     SAP_DO2 : 3;

	
	    procmap =
		SAP_D01 : /opt/wlm/toolkits/sap/bin/wlmsapmap
			-f /etc/cmcluster/C11/wlmprocmap.C11_D01_node1,

		SAP_D02 : /opt/wlm/toolkits/sap/bin/wlmsapmap
			-f /etc/cmcluster/C11/wlmprocmap.C11_D02_node1;
	}

Two workload groups are created, SAP_DO1 for the DO1 instance and SAP_D02 for the D02 instance. The two process map records use different map files because one map file corresponds to one SAP instance of one SAP system running on a node. WLM will run the wlmsapmap commands with the arguments to get the list of PIDs for the processes that should be moved to the corresponding workload group. The end result is that all processes for instance DO1 are running in the SAP_D01 workload group and all the processes for instance D02 are running in the SAP_D02 workload group. The entire example configuration is available at /opt/wlm/toolkits/sap/config/split_inst.wlm or it can be viewed in the appendix.

A vital component required to make this WLM/SAP environment work is the SGeSAP (T2357BA) product delivered by HP. Beginning with revision B.04.01.00, SGeSAP includes an SAP monitor that creates the map files for the SAP instances. The main utility involved in creating the map file is /opt/cmcluster/sap/bin/sapmap. This utility is started by configuring /etc/cmcluster/sap/SID/sapdisp.mon as a service of the SAP package, where SID is the SAP system ID. This is done by declaring the service in the package configuration file and defining the service in the package control file. For example, using the SAP system C11 and instance D01, /etc/cmcluster/C11/d01.config is the package configuration file and /etc/cmcluster/C11/d01.control.script is the package control file. The following parameters in the specified files would be set. d01.config should include the following:

	SERVICE_NAME                   d01C11disp
	SERVICE_FAIL_FAST_ENABLED      NO
	SERVICE_HALT_TIMEOUT           300

and d01.control.script should contain:

	SERVICE_NAME[0]="d01C11disp"
	SERVICE_CMD[0]="/etc/cmcluster/C11/sapdisp.mon D 01"
	SERVICE_RESTART[0]=""

	WLM_PROCMAP=1

The default interval for updating the map files is 30 seconds, but this can be adjusted by setting the DISPMON_INTERVAL parameter in the /etc/cmcluster/sap/C11/sap.config file. For example,

	DISPMON_INTERVAL=60

causes all the map files for the entire SAP system of C11 to be updated every 60 seconds rather than the default of 30. Keep in mind that the above examples are for an SAP system of C11 and an instance of D01; different SAP environments will require different parameter values based on the system and instance identifiers.

9.3.2 Monitoring

To monitor resource consumption and service level status for this use case, you can use the same techniques as used for the previous use cases. As you will see, the wlminfo groups and slo commands provide similar output for this configuration, respectively:

	Workload Group   PRMID  CPU Shares  CPU Util  Mem Shares  State
	OTHERS               1      156.00      0.00        0.00  ON
	SAP_D01              2      162.00    100.20        0.00  ON
	SAP_D02              3      282.00    199.80        0.00  ON

	SLO Name             Group        Pri    Req Shares  State Concern
	s_SAP_D01            SAP_D01        1 159.61    162  PASS
	s_SAP_D02            SAP_D02        1 281.78    282  PASS

9.3.3 Case summary

This use case describes how to separate individual SAP instances from a single SAP system for resource management purposes using WLM. The process map feature and the wlmsapmap utility are used together to identify the processes associated with an SAP instance and then move those processes to the correct workload group. The resources allocated to and consumed by the various SAP instances can be monitored using the different variations of the wlminfo command.

9.4 Separating SAP processes into different workloads

Each SAP instance has many different types of processes, each with its own pattern and quantity of resource consumption. Among these types are dialog, batch, and update processes. While each one of these serves an important function within the SAP instance, some of the processes can consume more resources than others—resulting in starvation for every other process. This problem can be resolved by using WLM to separate the different types of processes into different workload groups and placing resource restrictions on them accordingly.

9.4.1 Configuration

This use case is similar to the previous one in that it makes use of WLM's process map feature, the wlmsapmap utility, and the SGeSAP product. However, in this case we are interested in separating out specific process types within the instance. The wlmsapmap utility supports this by providing a -t option that allows you to specify the process types:

	wlmsapmap -f map_file -t process_types

Because the map file location follows the same naming scheme as described in the previous use case, it will not be described here.

The following excerpt from a WLM configuration file shows how to use the wlmsapmap utility to separate the batch and dialog processes from the same SAP instance into different workload groups:

	prm {
	
	    groups = OTHERS : 1,
		     Batch : 2,
		     Dialog : 3;

	    procmap =
		Batch : /opt/wlm/toolkits/sap/bin/wlmsapmap
		    -f /etc/cmcluster/C11/wlmprocmap.C11_D01_node1 -t BTC,

		Dialog : /opt/wlm/toolkits/sap/bin/wlmsapmap
		    -f /etc/cmcluster/C11/wlmprocmap.C11_D01_node1 -t DIA;
	}

Two workload groups are created by this configuration, one for the batch processes and one for the dialog processes. The same map file is used for each process map record because the processes are part of the same SAP instance. The batch processes are identified by the BTC argument, and the dialog processes are identified by the DIA argument. Other process types, such as update processes (UPD), can also be specified as an argument to the process type option -t.

	prm {
	    groups = OTHERS : 1,
		     Batch : 2,
		     Dialog : 3;

	    procmap =
		Batch : /opt/wlm/toolkits/sap/bin/wlmsapmap
		    -f /etc/cmcluster/C11/wlmprocmap.C11_D01_node1 -t BTC,

		Dialog : /opt/wlm/toolkits/sap/bin/wlmsapmap
		    -f /etc/cmcluster/C11/wlmprocmap.C11_D01_node1 -t "DIA,UPD";
	}

9.4.2 Monitoring

The same techniques used for the previous use cases can be used to monitor resource consumption and service level status for this use case. The wlminfo groups and slo commands provide similar output for this configuration:

	Workload Group   PRMID  CPU Shares  CPU Util  Mem Shares  State
	OTHERS               1      162.00      0.00        0.00  ON
	Batch                2      282.00    200.00        0.00  ON
	Dialog               3      156.00     99.80        0.00  ON

	SLO Name             Group        Pri    Req Shares  State Concern
	s_Batch              Batch          1 282.19    282  PASS
	s_Dialog             Dialog         1 156.41    156  PASS

9.4.3 Case summary

This use case describes how to separate individual process types within an SAP instance into different workload groups. This allows for a finer level of control for the various types of processes, including batch, dialog, and update processes. As with the previous use case, WLM's process map feature and the wlmsapmap utility were used to identify the processes and move them to the appropriate workload group.

10 References and links

10.1 HP-UX Workload Manager

• HP-UX Workload Manager information page (http://www.hp.com/go/wlm)

10.2 SAP Software

• SAP AG (http://www.sap.com)

11 Copyrights, trademarks

SAP is a registered trademark of SAP AG in Germany and several other countries.

All brand names are trademarks of their respective owners. Technical information in this document is subject to change without notice.
© Copyright Hewlett-Packard Company 2005

Appendix A: WLM configuration files

A.1 WLM configuration files

A.1.1 isolate_sap.wlm

#
# Name:
#	isolate_sap.wlm
#
# Version information:
#	@(#) HP WLMTK A.01.09 (2005_12_19_20_15_29) hpux_pa
#
#	(C) Copyright 2005 Hewlett-Packard Development Company, L.P.
#
#	$Revision: 1.2 $
#
# Caveats:
#	DO NOT MODIFY this file in its /opt/wlm/toolkits/sap/config location!
#	Make modifications to a copy and place that copy outside the
#	/opt/wlm/ directory, as items below /opt/wlm will be replaced
#	or modified by future HP-UX WLM product updates.
#
# Purpose:
#	This example demonstrates WLM's ability to isolate an SAP workload
#	and allocate CPU resources based on the workload's usage.  FSS
#	workload groups are used, but PSET groups could be used as well.
#
# Dependencies:
#	This example was designed to run with HP-UX WLM version A.02.00 or
#	later.

#
# Set the interval on which WLM takes CPU requests and makes changes in CPU
# allocations to 5 seconds. (The default interval is 60 seconds. Using a
# smaller interval allows WLM to respond more quickly to changes in
# workload performance.)
#
# Use absolute_cpu_units mode so that 100 shares equals 1 CPU.
#
tune {
    wlm_interval = 5;
    absolute_cpu_units = 1;
}

#
# prm structure
#
#	Define groups for the various workloads.  Use an application record
#	to isolate the Apache workload and a user record to isolate the SAP
#	workload.  All httpd processes will be moved to the Apache group, and
#	all processes run as user p00adm will be moved to the SAP group.
#
prm {
    groups = OTHERS : 1,
	     Apache : 2,
	     SAP : 3;

    apps = Apache : /opt/hpws/apache/bin/httpd;

    users = p00adm : SAP;
}

#
# The following SLO requests resources on behalf of the Apache workload.
# This SLO requests a static entitlement of 100 shares.
#
slo s_apache {
	pri = 1;
	entity = PRM group Apache;
	cpushares = 100 total;
}

#
# The following SLO requests resources on behalf of the SAP workload.
# This SLO is usage-based, so more CPU resources will get allocated as
# the workload gets busier.
#
slo s_sap {
	pri = 1;
	entity = PRM group SAP;
	mincpu = 100;
	maxcpu = 300;
	goal = usage _CPU;
}
	

A.1.2 split_inst.wlm

#
# Name:
#	split_inst.wlm
#
# Version information:
#	@(#) HP WLMTK A.01.09 (2005_12_19_20_15_29) hpux_pa
#
#	(C) Copyright 2005 Hewlett-Packard Development Company, L.P.
#
#	$Revision: 1.3 $
#
# Caveats:
#	DO NOT MODIFY this file in its /opt/wlm/toolkits/sap/config location!
#	Make modifications to a copy and place that copy outside the
#	/opt/wlm/ directory, as items below /opt/wlm will be replaced
#	or modified by future HP-UX WLM product updates.
#
# Purpose:
#	This example demonstrates WLM's ability to separate SAP instances
#	within the same SAP system and allocate CPU resources based on the
#	workload's usage.  FSS workload groups are used, but PSET groups
#	could be used as well.  The process map (procmap) feature is used
#	to move the different SAP instance processes to the appropriate
#	workload groups.
#
# Dependencies:
#	This example was designed to run with HP-UX WLM version A.03.01 or
#	later.

#
# Set the interval on which WLM takes CPU requests and makes changes in CPU
# allocations to 5 seconds. (The default interval is 60 seconds. Using a
# smaller interval allows WLM to respond more quickly to changes in
# workload performance.)
#
# Use absolute_cpu_units mode so that 100 shares equals 1 CPU.
#
tune {
    wlm_interval = 5;
    absolute_cpu_units = 1;
}

#
# prm structure
#
#	Define groups for the various workloads.  Use process maps to map
#	the different SAP instance processes to the appropriate workload
#	groups.  When wlmsapmap uses just the map file argument, all the SAP
#	processes from that instance are moved to the corresponding
#	workload group.
#
prm {
    groups = OTHERS : 1,
	     SAP_D01 : 2,
	     SAP_D02 : 3;

    procmap =
	SAP_D01 : /opt/wlm/toolkits/sap/bin/wlmsapmap
			-f /etc/cmcluster/C11/wlmprocmap.C11_D01_node1,

	SAP_D02 : /opt/wlm/toolkits/sap/bin/wlmsapmap
			-f /etc/cmcluster/C11/wlmprocmap.C11_D02_node1;
}

#
# The following SLO requests resources on behalf of the SAP_D01 workload.
# This SLO is usage-based, so more CPU resources will get allocated as
# the workload gets busier.
#
slo s_SAP_D01 {
	pri = 1;
	entity = PRM group SAP_D01;
	mincpu = 100;
	maxcpu = 300;
	goal = usage _CPU;
}

#
# The following SLO requests resources on behalf of the SAP_D02 workload.
# This SLO is usage-based, so more CPU resources will get allocated as
# the workload gets busier.
#
slo s_SAP_D02 {
	pri = 1;
	entity = PRM group SAP_D02;
	mincpu = 100;
	maxcpu = 300;
	goal = usage _CPU;
}
	

A.1.3 split_procs.wlm

#
# Name:
#	split_procs.wlm
#
# Version information:
#	@(#) HP WLMTK A.01.09 (2005_12_19_20_15_29) hpux_pa
#
#	(C) Copyright 2005 Hewlett-Packard Development Company, L.P.
#
#	$Revision: 1.4 $
#
# Caveats:
#	DO NOT MODIFY this file in its /opt/wlm/toolkits/sap/config
#	location!  Make modifications to a copy and place that copy
#	outside the /opt/wlm/ directory, as items below /opt/wlm will
#	be replaced or modified by future HP-UX WLM product updates.
#
# Purpose:
#	This example demonstrates WLM's ability to separate different types
#	of SAP processes into different workload groups.  The process map
#	(procmap) feature is used to move SAP batch and dialog processes
#	into different workload groups.
#
# Dependencies:
#	This example was designed to run with HP-UX WLM version A.03.01 or
#	later.

#
# Set the interval on which WLM takes CPU requests and makes changes in CPU
# allocations to 5 seconds. (The default interval is 60 seconds. Using a
# smaller interval allows WLM to respond more quickly to changes in
# workload performance.)
#
# Use absolute_cpu_units mode so that 100 shares equals 1 CPU.
#
tune {
    wlm_interval = 5;
    absolute_cpu_units = 1;
}

#
# prm structure
#
#	Define groups for the various workloads.  The procmap feature is
#	used in conjunction with the SAPTK process ID finder so that the
#	SAP batch processes are moved to the Batch group and the dialog
#	processes are moved to the Dialog group.
#
#	Note that when multiple process types are specified with the -t
#	option, quotes must be used around the argument; otherwise, the
#	comma separating the process types is interpreted as a procmap
#	record separator rather than a process type separator.  For example:
#
#	    procmap = BTC_UPD : opt/wlm/toolkits/sap/bin/wlmsapmap
#		-f /etc/cmcluster/C11/wlmprocmap.C11_D01_node1 -t "BTC,UPD";
#
#	This would move all the batch (BTC) and update (UPD) processes
#	to the BTC_UPD workload group.
#
prm {
    groups = OTHERS : 1,
	     Batch : 2,
	     Dialog : 3;

    procmap =
	Batch : /opt/wlm/toolkits/sap/bin/wlmsapmap
		    -f /etc/cmcluster/C11/wlmprocmap.C11_D01_node1 -t BTC,

	Dialog : /opt/wlm/toolkits/sap/bin/wlmsapmap
		    -f /etc/cmcluster/C11/wlmprocmap.C11_D01_node1 -t DIA;
}

#
# The following SLO requests resources on behalf of the Batch workload.
# This SLO is usage-based, so more CPU resources will get allocated as the
# workload gets busier.
#
slo s_Batch {
	pri = 1;
	entity = PRM group Batch;
	mincpu = 100;
	maxcpu = 300;
	goal = usage _CPU;
}

#
# The following SLO requests resources on behalf of the Dialog workload.
# This SLO is usage-based, so more CPU resources will get allocated as the
# workload gets busier.
#
slo s_Dialog {
	pri = 1;
	entity = PRM group Dialog;
	mincpu = 100;
	maxcpu = 300;
	goal = usage _CPU;
}