|
This help page explains how to set up your environment and then
implement gWLM to get the most benefit from gWLM.
gWLM allows you to decrease the number of CPUs needed on a server while
increasing utilization of the remaining CPUs. gWLM best optimizes CPU
utilization in an environment where CPU resources can be borrowed (moved
between workloads). The following sections suggest ways you can maximize
the amount of CPU resources that can be borrowed:
 | | Setting up npars to maximize resource sharing
(npar requirements) |
Using the HP product Instant Capacity,
gWLM simulates the movement of CPUs between npars by turning off an
active CPU in one npar then turning on a deactivated CPU in another npar in
the same complex. Thus, the first npar has one less active CPU, while the
second npar has one additional active CPU. (gWLM maintains the number of
active CPUs, honoring the Instant Capacity licensing limits. As a result,
no costs are incurred.) When setting up npars to be managed by gWLM:
Each npar must have the HP product Instant Capacity installed and running
Each npar must have the following property set to 'on' in the file
/etc/opt/gwlm/conf/gwlmagent.properties:
com.hp.gwlm.platform.icap.manageWithIcap
Each npar must not be divided into virtual partitions
In addition, while you can create an SRD with a single npar, gWLM can
only simulate CPU movement when there are at least two npars.
| | Setting up vpars to maximize resource sharing |
When setting up your HP-UX virtual partitions (vpars), you can increase the
number of CPUs that can be borrowed by setting the:
To maximize the number of CPUs a vpar can borrow, set the vpar's
maximum number of CPUs to a large number.
| | Setting up SRDs to maximize resource sharing |
In defining your SRDs, you can increase the amount of CPU resources that
can be borrowed by:
Creating bigger SRDs, with more workloads and more resources
For example, if you have a single-cell nPartition (with four CPUs), you may
only be able to host two vpars. There can be some borrowing, but it would
be limited. However, with a two-cell nPartition (with eight CPUs), you may
be able to host four or five vpars, each with its own workload. With the
additional workloads, it is much more likely that at least one workload
is idle. Busy workloads can then borrow CPUs from the idle workload.
Mixing critical and less-critical workloads
Combining important workloads that need immediate CPU access wastes
resources as it forces you to set aside CPU resources so that each
workload can meet its peak demand at the same time. Alternatively, you
can combine both critical and less-critical workloads. You would still
set aside CPU resources for the critical workloads. However, you would
set aside fewer resources for the less-critical workloads, relying on
their being able to borrow resources from critical workloads that are not
at peak demand--as is often the case because demands on workloads are
staggered.
Mixing workloads that run at different times
Combining workloads that run at different times, such as a highly
user-interactive workload that runs during the day and a
noninteractive batch job that runs at night, frees up resources for sharing
to other workloads that may be running.
| | Setting up OwnBorrow policies to maximize resource
sharing |
When defining OwnBorrow policies, there are a number of parameters that
affect how resources are shared:
Minimum CPU resources
The value you specify for a policy's minimum CPU is guaranteed and is not
shared with other workloads. Setting these values as low as possible
makes more CPU resources available for sharing. For npar, vpar, and pset
compartments, the lowest minimum you can specify is one CPU. For
compartments based on fss groups, you can specify values less than one
CPU. However, be sure to give fss-group compartments enough CPU resources
so that the workloads can get started.
Owned CPU resources
Set the amount of a policy's owned CPU resources according to how
critical the workloads are that will use the policy:
Critical workloads
Set the owned CPU resources to meet peak demand for critical workloads.
For workloads that have a high business value (and for which high
latency would have an adverse business impact), such as most production
workloads, set the owned CPU resources so that the workloads'
performances are acceptable under peak demand.
Less-critical workloads
Set the owned CPU resources to meet minimum requirements for
less-critical workloads, relying on borrowing for additional resources.
These workloads have lower business values and infrequent periods of
minor latency would not be as detrimental to the business. Typically,
test and development workloads fall into this category. If they get all
the resources they need most of the time, but may occasionally get
less, the impact on the business is negligible. These workloads need to
be guaranteed enough resources for some minimally acceptable
performance, but can rely on borrowing resources to meet their
remaining needs.
As stated earlier, combining multiple workloads of both types in an SRD
helps ensure CPU resources are available for borrowing when needed.
Maximum CPU resources
The larger a maximum value you specify, the more resources a workload can
borrow. Set these values to the total number of CPUs on the server--or a
value between Owned CPUs and the total CPU count if you want to limit a
workload's CPU access.
|
