Examples of solutions that WLM provides

In this first example, the SLO requests a fixed allocation of CPU shares for the Marketing workload, reserving a portion of the server’s available CPU resources. The 300 CPU shares being reserved equate to 3 cores (when managing SLOs for partitions, WLM equates each core to 100 shares). This SLO is priority 1 and is in effect at all times.

This SLO requests a fixed allocation of 800 CPU shares. However, the associated workload contains a payroll application that only runs twice a month. Consequently, the SLO is enabled only twice a month, on the 15th and 28th.

This SLO is enabled only part time and conditionally. Rather than allocating CPU resources on a specific date or time, they are allocated when a specified condition is met, in this case when the system accounting program is running. When the SLO is active, it works to ensure the system accounting program completes quickly by reserving 600 CPU shares for the associated workload. When the program is completed, the SLO is disabled. At that point, the SysAcct workload gets a specific percentage (usually 1%) of the total CPU resources, as explained in the section “Specifying when the SLO is active (optional)”.

This SLO is enabled based on a conditional metric. This example illustrates an SLO that is active only if the Serviceguard package pkgA is active on the current server. WLM provides a utility that generates a metric indicating whether a package is active. When the metric has value 1, the package is active, thus enabling the SLO. The SLO then causes WLM to attempt to allocate 300 CPU shares to the associated workload.

In this example, the workload (named Orders) is a collection of processes running in a virtual partition. WLM adjusts the CPU allocation of the virtual partition based on the CPU utilization of the workload within that partition. If the utilization is low (perhaps caused by fewer applications running), then the CPU allocation for the partition is reduced, making more resources available to other partitions in the complex. If utilization is high, the workload receives a larger CPU allocation. Regardless of utilization, this SLO ensures that the partition is allocated at least 200 shares but no more than 800 shares. (When managing partitions, WLM equates 1 core to 100 shares.)

In this scenario, the workload Development has multiple SLOs, with each SLO having a usage goal. The Development workload is owned by a department that funded 30% of the server. Consequently, that department expects to get 30% of the server when needed. In the following SLOs, 100 CPU shares represent the total CPU resources (cores) on the server. So, 30% of the server is 30 CPU shares. (CPU units based on a percentage of the system’s total CPU resources are known as relative CPU units, which is the default for WLM; examples previous to this one are based on absolute CPU units, which equate 100 shares to 1 core. For more information on using absolute and relative CPU units, see “Using absolute CPU units”.)

When the Development workload is busy, the following priority 1 SLO ensures that the workload gets 30% of the server’s CPU resources (the 30 shares funded by Development). When the workload is not busy, excess resources are available for sharing as long as the workload is getting at least 15% of the resources.

When the Development workload becomes very busy, the following priority 2 SLO enables the workload to borrow from other workloads that may have excess resources. Because this SLO is priority 2, it is met only after all priority 1 SLOs have been met. Based on usage patterns, the SLO lets the workload borrow up to an additional 20 shares if available. This allows the Development workload to access up to 50 CPU shares.

With multiprocessor systems, you can isolate CPU resources for users or applications by grouping processors together to form PSETs. WLM allows you to define workloads based on PSETs. If you then specify SLOs for these workloads, WLM automatically adjusts the number of processors in the PSETs based on progress toward the SLOs. In this example, the PSET workload Batch gets five processors, but only between 10pm and 4am. At other times, Batch gets a minimum of one processor by default.

WLM enables you to automate the resizing of partitions. You can adjust the partition size by having cores dynamically added and removed in response to varying demands.

Consider a system with two virtual partitions. The SLO for the Apps workload in partition 1 has a higher priority than the SLO for the Dev workload in partition 0. When CPU usage for Apps in partition 1 reaches a certain point, WLM automatically migrates a core from partition 0 to partition 1 to satisfy the higher-priority SLO. The following is an outline of the partition 1 SLO for workload Apps:

The SLO for partition 0 (workload dev) follows:

If you have the HP Instant Capacity software configured on each nPartition, you can configure WLM to “move” cores to the partitions where they are most needed. (Given the hardware isolation, the cores are not literally moved: WLM deactivates cores on one partition, then activates cores on another partition—giving the appearance of moving cores without incurring a charge for an additional core.)

Consider a system with two nPartitions. nPartition 0 is running the production, customer-accessible version of a shopping Web site, while nPartition 1 runs the test version of this Web site. The SLO for the Production workload on nPartition 0 has a higher priority than the SLO for the Test workload on nPartition 1.

When CPU utilization for the Production workload reaches a certain point, WLM automatically migrates a core from nPartition 1 to nPartition 0 to satisfy the higher priority SLO. The SLO for the Production workload in nPartition 0 is outlined as follows:

The SLO for the Test workload in nPartition 1 is outlined as follows:

Temporary Instant Capacity activates CPU resource capacity in a temporary “calling-card” fashion such as in 20-day or 30-day increments (where a day equals 24 hours for one core). You purchase a TiCAP codeword to obtain usage rights for a preset amount of days.. This codeword is applied to a system so you can turn on and off any number of Instant Capacity cores on the system as long as your prepaid temporary capacity time has not expired. (To activate a core, you need a minimum balance of 30 minutes of temporary capacity per core. Codewords must be applied in the order in which they were obtained.)

If you have WLM on a supported Temporary Instant Capacity system, you can configure WLM to minimize the costs of using these resources by optimizing the amount of time the resources are used to meet the needs of your workloads.

Similarly, HP offers a Pay per use (PPU) feature for customers interested in leasing CPU capacity from HP Finance. Pay per use provides capacity as needed but basing payment on actual metered or monitored use of that capacity. Using WLM with a system running a supported version of PPU, WLM increases or decreases the capacity automatically, allocating the minimum number of cores needed to satisfy SLOs. By minimizing the number of active cores, WLM reduces your costs.

After setting up your SLOs in the WLM configuration file as in some of the previous examples, you then configure the WLM global arbiter (wlmpard), setting the utilitypri keyword to control how Temporary Instant Capacity or PPU adjusts CPU resource capacity as needed. Using this keyword also ensures that WLM maintains compliance with your Temporary Instant Capacity codeword: when your usage rights expire, WLM no longer attempts to activate temporary resources. Note also that by default WLM does not activate Temporary Instant Capacity when 15 or fewer processing days of temporary capacity are available. You can change this default by setting the WLM global arbiter utility_reserve_threshold keyword. For more information on the utilitypri and utility_reserve_threshold keywords, see “Setting up your WLM global arbiter configuration file” or see wlmparconf(4).

For more information on configuring WLM to use Temporary Instant Capacity or PPU, see Chapter 7 “Managing SLOs across partitions”. For more information on integrating WLM with Temporary Instant Capacity and PPU, see “Integrating with Temporary Instant Capacity (TiCAP)/ Pay per use (PPU)”.

Management of Temporary Instant Capacity and PPU is available on standalone systems as well as across partitions.