Policies tab
Edit Policies

A fixed policy guarantees that a workload's compartment has a fixed (constant) amount of CPU resources.

Fixed policies do not have a priority you can set. gWLM satisfies these policies before attempting to satisfy any other type of policies.

This type of policy has a target based on utilization. With a CPU utilization policy, gWLM attempts to keep a workload's CPU utilization below the target by adding CPU resources when the workload is using too much of its current CPU allocation. For example, assume a workload has a utilization policy with a target of 80% and an allocation of 5 CPUs. If the workload is consuming 4.5 CPUs, its utilization percentage is 4.5/5, or 90%. gWLM would attempt to allocate additional CPU resources to the workload's compartment to meet the target. An allocation of 6 CPUs would result in a utilization percentage of 4.5/6, or 75%, meeting the target.

You can set a priority for utilization policies to ensure gWLM attempts to satisfy the policies in a particular order.

An OwnBorrow policy allows you to set the:

A compartment is guaranteed its owned CPUs when needed. When a workload is not busy, gWLM may lend CPUs from that workload's compartment--down to its minimum--to help workloads that are busy. (If a compartment has lent out CPUs and that compartment's workload becomes busy, the compartment re-acquires those lent-out CPUs immediately.) Also, a compartment with a busy workload can borrow CPUs--up to its maximum--assuming CPUs are available for borrowing.

OwnBorrow policies do not have a priority you can set.

A custom policy allows you to provide your own metric. gWLM then manages an associated workload, adjusting allocation as needed, based on how the value of its metric compares to a target you specify. (You update values for the metric using the gwlmsend command in the HP-UX or Linux instance where the workload is running.)

The Metric response can be direct or inverse. With a direct response, as gWLM increases the CPU allocation, the metric values increase. An example of a metric that has a direct response is transactions per second. With an inverse response, when gWLM increases the CPU allocation, the metric values decrease. For example, response time is a metric that has an inverse response.

You can set a priority for custom policies to ensure gWLM attempts to satisfy the policies in a particular order.

You want gWLM to allocate a constant amount of CPU to a workload

Fixed

You have your own metric by which you want gWLM to manage a workload

Custom

IT acts as a service provider to business units

OwnBorrow

This policy type allows you to set an owned amount of resources, while also giving you control over how workloads borrow and lend resources.

gWLM provides a "topborrowers" report and a "resourceaudit" report to help you manage your data center using this model. For more information, see the gwlmreport(1M) man page.

You have static vpars but you want to move to a model where CPUs migrate between vpars

OwnBorrow

For each vpar, set its number of owned CPUs to its static number of CPUs. The vpar is then guaranteed those owned CPUs when needed.

You have npars but you want to move to a model where CPUs migrate between npars

OwnBorrow

Install the HP product Instant Capacity on each npar. (This software allows gWLM to simulate CPU movement among the npars.)

For each npar, set its number of owned CPUs to the number of CPUs you want to guarantee the npar has when needed.

You want to tap into a pool of resources taking or giving CPU resources as needed--with no guaranteed access to resources beyond a minimum request

Utilization