Using HP Global Workload Manager with SAP

22
The next figure shows the conditional policy.
Such an arrangement allows automatic consumption of TiCAP during failover, but disables it when the
package is moved off this system, presumably back onto its primary system.
Example 4: SAP separating batch and dialog processes
SAP instances can have different types of work, such as batch or dialog, and a given set of processes
from the instances assigned to handle these types of work. However, from the operating system level
with tools like ps, it is not possible to know which processes are handling batch, for instance.
To separate these into different workloads in this example, we use SGeSAP’s ability to query SAP
directly and produce a map of process function, like batch (BTC) to operating system process ID (PID).
That PID list is then collected with a procmap and returned to the local gwlmagent. Those processes
are then moved into the correct workloads so their collective resources can be controlled.
Prerequisites
As with the previous example, we use gWLM-provided policies for this example. For illustration, we
want dialog processes to own 4 cores (of 8 total), batch to own 3, and OTHER, which includes the
Oracle instance, to own 1 core. In a real environment, these policy values would likely be different
based on SAP administrator knowledge or Capacity Advisor runs against historical data.
For process placement, we’ll illustrate the use of the wlmsapmap procmap tool from the WLM
Toolkits. This depends on functionality of SGeSAP, so you will need Serviceguard and Serviceguard
Extensions for SAP installed and configured. Also, the wlmsapmap tool itself comes in WLM Toolkits,
so that (no-cost) bundle needs to be installed on the managed node. You can obtain the WLM Toolkits
bundle at http://software.hp.com.
For instructions on using SGeSAP to produce the process map file needed by wlmsapmap, see the
document Managing Serviceguard Extension for SAP, available from http://docs.hp.com. Search the
file for “procmap.”