The management of additional capacity is based on a policy that contains rules for activation and deactivation and for capacity increases and decreases. You can create and edit a policy by using the Capacity Provisioning Management Console. When the policy is complete, you must install it into the policy repository of the domain before it can be activated. You can have multiple policies for different purposes in the policy repository of the domain, but at any time only one policy can be active in the domain.
Figure 2 shows the basic structure of a policy.
Each provisioning policy is identified by name. The names of rules, provisioning conditions, time conditions, and workload conditions must be unique within the policy. These names are used in commands to the Provisioning Manager (for example to enable or disable a rule or a provisioning condition), and in reports from the Provisioning Manager that reference these policy elements.
A Capacity Provisioning policy includes a maximum processor scope which defines the total amount of temporary processor resources that can be activated for CPCs by all the rules contained in the policy. Each rule also contains a processor scope that restricts the temporary capacity that can be activated by that rule. If the processor scope of a rule includes restrictions on CPCs, they must also be included in the maximum processor scope, otherwise no additional processor capacity is activated for these CPCs.
Specifying a processor limit in the maximum processor scope is optional. It is necessary if the policy intends to allow the activation of temporary processor resources for the CPC.
For example, suppose you want to allow one additional zAAP to be activated when an online service class is impacted, and one or two additional zAAPs when a batch service class is impacted, but you do not want to have more than two additional zAAPs active at the same time. To model this scenario, you define a maximum processor scope of two zAAPs and two rules: one for the online service class with a processor scope of one zAAP and one for the batch service class with a processor scope of two zAAPs. With these rules, if two additional zAAPs are requested for a batch application and one additional zAAP is requested for an online application at the same time, one of the requests is unfulfilled. Either the rule for the batch service class activates only one additional zAAP, or the rule for the online service class activates no additional zAAPs. In total, no more than two additional zAAPs are active at the same time.
For each CPC, you can also specify the increments in which general purpose capacity is to be added. There is one increment for the first activation (primary activation) and one increment for all further activations (secondary activations). The capacity increments are specified in MSU and denote the minimum amount of capacity that can be added. The default increment is one MSU, meaning the software model with the next higher capacity. The capacity increments are used for workload-based capacity activation. Neither the primary nor the secondary activation amounts must exceed the maximum capacity specified as Max. activation (MSU). If you specify primary and secondary increments and the next activation would exceed the capacity of either the defined On/Off Capacity on Demand record for the CPC or the capacity allowed by the processor scope, the next increment is limited to activate the maximum allowed remaining capacity.
| CPC | Maximum activation (MSU) | Maximum zAAP processors | Maximum zIIP processors | Primary activation (MSU) | Secondary activations (MSU) |
|---|---|---|---|---|---|
| CPC0 | 200 | 0 | 4 | 1 | 1 |
| CPC1 | 300 | 3 | 2 | 70 | 50 |
Table 3 shows an example of a maximum processor scope with limits for two CPCs. The first definition for CPC0 specifies that 200 MSU, four additional zIIPs, but no zAAPs can be activated on that CPC . With values for primary and secondary activations of 1 MSU the definition determines that each workload-based activation should choose the software model with the next higher capacity. The second definition specifies that a maximum of 300 MSU, two zIIPs, and three zAAPs can be activated on CPC1. The first workload-based activation on that CPC would activate at least 70 additional MSU, all following activations at least 50 additional MSU each.
A Capacity Provisioning policy includes a logical processor scope, which defines the systems on which the Provisioning Manager monitors the number of logical processors to issue provisioning recommendations. Specifying a logical processor limit is optional. If a limit is defined for a system the Provisioning Manager monitors the number of logical processors for this system and informs you when changes are required. If a console message is displayed, follow the recommendation and perform the activation and deactivation on the affected system yourself. When the specified limit is reached the Provisioning Manager stops to recommend on additional logical processors.
The number of logical processors on a system can only be increased if offline logical processors are available on this system. This is the case if processors were configured offline or if they are defined as reserved processors in the LPAR in which the system is running.
The logical processor scope is only observed if the system is running with WLM LPAR CPU management turned off and has shared processors.
The Provisioning Manager recommends to configure logical processors online if the number of logical processors restricts the consumption of physical capacity. This situation can occur due to a shortage of logical processors or in combination with a physical activation. The Provisioning Manager recommends to configure logical processors offline if the number of logical processors of a system prevents a change to the physical capacity of the CPC on which the system is running. In this case, the deactivation of physical resources is postponed until logical processors have been configured offline. The Provisioning Manager does not attempt to optimize the number of logical processors for the consumed capacity. However, the HiperDispatch function can be used for that purpose.
Recommendations to take additional logical processors online or offline are issued in confirmation and autonomic processing modes. These modes are described in detail on page Processing modes.
Table 4 shows an example of logical processor limits:
| System | Sysplex | Maximum CP Processors | Maximum zAAP Processors | Maximum zIIP Processors | Action |
|---|---|---|---|---|---|
| SYS0 | PLEX0 | 7 | 5 | 3 | Message on runtime system |
| SYS1 | PLEX1 | Max. possible | 0 | 0 | Message on managed system |
The fields in Table 4 have the following meaning:
A Capacity Provisioning policy includes a maximum defined capacity scope which specifies the total Defined Capacity that can be added by all the rules contained in the policy. A capacity limit in the Maximum Defined Capacity Scope is identified by a system and sysplex name. The management of the system's Defined Capacity changes the limit of the LPAR in which the system is running.
Each rule also contains a defined capacity scope that restricts the capacity that can be increased by that rule. If the defined capacity scope of a rule includes restrictions for a system, a maximum defined capacity limit for the same system is needed, otherwise Defined Capacity is not increased for this system.
Specifying a capacity limit in the maximum defined capacity scope is optional. It is necessary if the policy intends to allow Defined Capacity increases for the system.
For each capacity limit in the maximum defined capacity scope, you must also specify the increments by which Defined Capacity is to be increased. Defined Capacity increments are used for workload-based capacity increases. You can define one value for the first increase (primary increment) and one value for all further increases (secondary increments). Defined Capacity increments are specified in MSU. The default increment value is one MSU. Neither the primary nor the secondary increments must exceed the maximum increase specified as Max. Increase. If the next workload-based increment would exceed the capacity allowed by the defined capacity scope, the next increment is limited to increase the allowed remaining capacity.
| System | Sysplex | Max. Increase (MSU) | Primary Increment (MSU) | Secondary Increments (MSU) |
|---|---|---|---|---|
| SYS0 | PLEX0 | 100 | 30 | 20 |
Table 5 shows an example of a maximum defined capacity scope with a limit related to system SYS0 in sysplex PLEX0. The limit specifies that Defined Capacity can be increased by up to 100 MSU. The first workload-based increment for that system would increase the Defined Capacity by 30 MSU, all following increments by 20 additional MSU each.
A Capacity Provisioning policy includes a maximum group capacity scope which specifies the total Group Capacity that can be added by all the rules contained in the policy. In the scope you define limits for individual capacity groups. A capacity group is identified by the name of the capacity group and the name of the CPC on which the capacity group is defined.
Each rule also contains a group capacity scope that restricts the capacity that can be increased by that rule. If the group capacity scope of a rule includes restrictions for a capacity group, a maximum group capacity limit for the same group is needed, otherwise Group Capacity is not increased for this group. Group capacity scopes only take effect if at least one system running in an LPAR belonging to that capacity group is observed by the Provisioning Manager.
Specifying a capacity limit in the maximum group capacity scope is optional. It is necessary if the policy intends to allow Group Capacity increases for that capacity group.
For each capacity limit in the maximum group capacity scope, you must also specify the increments by which Group Capacity is to be increased. Group capacity increments are used for workload-based capacity increases. You can define one value for the first increase (primary increment) and one value for all further increases (secondary increments). Group capacity increments are specified in MSU. The default increment value is one MSU. Neither the primary nor the secondary increments must exceed the maximum increase specified as Max. Increase. If the next workload-based increment would exceed the capacity allowed by the group capacity scope, the next increment is limited to increase the allowed remaining capacity.
| Group | CPC | Max. Increase (MSU) | Primary Increment (MSU) | Secondary Increments (MSU) |
|---|---|---|---|---|
| GRP0 | CPC0 | 250 | 30 | 20 |
Table 6 shows an example of a maximum group capacity scope with a limit for capacity group GRP0 on CPC0. The limit specifies that its Group Capacity can be increased by up to 250 MSU. The first workload-based increment for that group would increase the Group Capacity by 30 MSU, all following increments by 20 additional MSU each.
A provisioning rule contains a set of provisioning conditions and scopes which define provisioning limits for different types of capacity. The provisioning scopes restrict the capacity that can be provisioned by the conditions in the rule:
Provisioning conditions describe the situations in which capacity changes are allowed. Two types of conditions are supported:
If only time conditions but no workload conditions are defined, the Provisioning Manager executes a scheduled provisioning and deprovisioning of additional capacity.
A rule specifies the amount of additional capacity that can be added and the conditions under which an increase is allowed. In the provisioning scopes you can limit the additional capacity that can be provisioned for that rule. You can use time conditions to select periods when you expect significant capacity shortages, and optionally you can identify triggers such as a WLM service class with an associated application. The workload based trigger will only activate additional capacity or increase capacity within periods specified by the time conditions and when at least one of the specified service classes is suffering by processor shortage. Rules should be defined for all applications for which additional capacity should be provisioned.
A rule can be enabled or disabled. Only enabled rules are considered by the Provisioning Manager. You can specify whether a rule is initially enabled or disabled. This status can be changed at runtime by using the Provisioning Manager commands ENABLE POLICY and DISABLE POLICY. Thus, you can specify different scenarios in the policy and activate only those scenarios that are relevant at a certain time, or you can temporarily disable provisioning, for example, if a maintenance period overlaps with a time condition in the policy.
The workload conditions apply to all time conditions of the provisioning condition. For example, a workload condition can be defined for a service class SC1 associated with month-end jobs, and time conditions can be defined to cause provisioning on January 31st, February 28th, and so on. To consider workloads running on different sysplexes or systems, several workload conditions can be specified. For example, service class SC2 could be specified to trigger provisioning when running in sysplex PLEX1 and service class SC3 to trigger provisioning on system SYS2 only when running in sysplex PLEX2.
All capacity included in the provisioning scopes of a rule are shared by all conditions within that rule. If you want to provision a different set of capacity for a condition, create a new rule for this condition.
Provisioning conditions can be enabled or disabled in the same way as rules. Only enabled provisioning conditions are considered by the Provisioning Manager. You can specify in the policy whether a provisioning condition is initially enabled or disabled. This status can be changed at runtime, in the same way as rules, by using the Provisioning Manager commands ENABLE POLICY and DISABLE POLICY. In this way, you can specify different scenarios in the policy and activate only those scenarios that are relevant at a particular time. You can also temporarily disable part of the policy, for example, if a maintenance period overlaps with a time condition.
A time condition defines one or several periods during which the provisioning of additional capacity is allowed.
You can choose between two different types of time conditions:
A nonrecurring time condition specifies one period that has a clear start and end point in time. It is defined by the following parameters:
Figure 3 describes two nonrecurring time conditions and shows how the Provisioning Manager interprets them. On the left, you see the effect of time condition TC1. Resource shortages are only considered between the start time and the deadline; resource shortages between the deadline and the end time cannot trigger activation of additional capacity. The boxes represent additionally provisioned general purpose capacity, with primary activations of 30 MSU and a secondary activation of 20 MSU, both set in the policy. On the right, you see the effect of time condition TC2. In this condition, the period between the start time and the deadline is very short compared to the period between the deadline and the end time. This means that additionally provisioned capacity can remain active for a longer period but cannot be increased after the deadline.
A recurring time condition describes weekly repeating periods. The periods describe the time of the day when provisioning of additional capacity is allowed and the days of the week to which these times apply.
A recurring time condition is defined by the following parameters:
Deprovisioning of additional capacity assumes that it has been active for at least a minimum activation time, as specified in the Capacity Provisioning control parameters in Table 17. If not, deprovisioning is delayed to fulfill that duration.
Figure 4 describes a recurring time condition that covers the weekends: all Saturdays and Sundays from start date until end date are eligible for provisioning of additional capacity. Provisioning can occur on any of these days between the start time and the deadline time. The boxes represent additionally provisioned general purpose capacity, with a primary activation of 30 MSU and a secondary activation of 20 MSU, both set in the policy. Resource shortages that occur at a different day of the week than the selected ones or outside the range that is specified by start date and end date do not trigger provisioning. Provisioned capacity is deprovisioned as soon as the end time is reached. The example assumes that minimum activation time for the resource type is short enough to allow deprovisioning not later than at end time.
If time conditions are defined in a provisioning condition, but workload conditions are not, the Provisioning Manager schedules provisioning and deprovisioning of additional capacity as specified by the provisioning scopes of the rule. The maximum additional allowed capacity in the provisioning scopes is provisioned at start time and deprovisioned at the specified end time.
Use Capacity Provisioning to define business-critical work as being eligible for provisioning by defining workload conditions. The concept of a workload condition is based on the WLM service class model:
A Capacity Provisioning workload condition specifies service class periods eligible for provisioning with several parameters:
Use Any in sysplex (*) to specify that the workload condition applies to all systems of the specified sysplex.
Use Any (*) to specify that the workload condition applies to all sysplexes observed by the Provisioning Manager.
The specification of the importance filter is optional; as an alternative, you can specify included service classes.
For more information about importance filters, see Importance filter.
Included Service Classes are specified by service class period filters; see Service class period filter.
Excluded Service Class Filters are specified by service class period filters; see Service class period filter.
At least one importance filter or included service class period must be defined for a workload condition to take effect.
The Provisioning Manager determines service class periods to be considered for provisioning as follows:
All service class periods remaining in the set are monitored and can trigger provisioning. Whenever a new WLM service policy is activated, the set of observed service class periods is redetermined.
Make sure that service classes and classification rules are properly defined in WLM before using the service classes as provisioning triggers for Capacity Provisioning.
The Provisioning Manager uses two major indications to detect when a service class period is impacted by insufficient processing capacity: the performance index (PI), and the resource demand of the service class period. The resource demand of a service class period can be detected automatically by the Provisioning Manager. You define PI thresholds in the provisioning policy as provisioning criteria that are associated with importance filters or included service classes.
The PI provided by WLM is calculated as the ratio of the specified goal of a service class period to the measured response time or velocity of the work running in this period. A PI of 1.0 indicates that the work is meeting the goal. A PI lower than 1.0 indicates that the work in the service class period exceeds the goal. A PI higher than 1.0 indicates that the goal is not fulfilled. In practice, a PI higher than 1.0 might be adequate for your installation, so you can assign a sufficient or appropriate target PI threshold to each service class period. Capacity Provisioning considers an action if the PI of a defined service class period is higher than the target PI for a specified amount of time. The PI that exceeds the limit for the specified amount of time indicates that WLM or, when active, Intelligent Resource Director (IRD), have not been able to resolve the bottleneck by shifting access to processor resources. The speed at which the Provisioning Manager is to react if a PI exceeds tolerance is also installation-dependent. Individual provisioning criteria can be defined for eligible service classes within the workload condition.
Importance filters and included service classes filters have the following parameters in common:
Provisioning PI and provisioning PI duration are used by the Provisioning Manager to detect whether observed service class periods are impacted by insufficient processing capacity. Before any actions are taken, the Provisioning Manager considers the resource demand of the service class period to ensure that the activation of additional processing capacity can improve the PI. Deprovisioning PI and deprovisioning PI duration are used by the Provisioning Manager to detect when a service class period no longer needs help.
For example, assume that a workload condition is specified including ONLINE service class. This condition is defined with one period of WLM service definition WLMSD, a provisioning PI of 1.8, and duration of 10 minutes, and a deprovisioning PI of 1.2 and duration of 10 minutes. If the PI of the service class period changes within a defined time condition, as shown in Figure 5, the Provisioning Manager detects three instances in which the provisioning PI criteria are fulfilled. For the first instance the Provisioning Manager provisions additional capacity by a primary activation amount as set in the policy, which is 20 MSU in this example. For the second instance the additional capacity corresponds to a secondary activation value of 30 MSU. The third instance is ignored, because it occurs after the deadline. The Provisioning Manager also detects an instance in which the deprovisioning PI criteria are fulfilled. The Provisioning Manager then decides that ONLINE service class no longer needs additional capacity and deprovisions it.
The performance index of many workloads can change rapidly, for example because the amount of work varies, or because additional capacity becomes available in the system. If the provisioning duration includes several observation intervals, such as RMF MINTIME, it may be difficult to encounter a contiguous number of monitoring intervals where the PI exceeds the provisioning PI for the entire provisioning duration.
Managing a workload via moving average PI can account for that behavior. When the actual performance index of a workload decreases below the provisioning PI for a short time the moving average PI can still exceed that limit. Consequently, high PI values in the provisioning duration might be recognized more reliably.
Figure 6 shows a fluctuating workload that does not meet the provisioning criteria because during the specified provisioning PI duration, the PI temporarily drops below the provisioning PI.
Optionally, the Provisioning Manager can average the PI provided by the monitoring component for a service class period. In this case the Provisioning Manager calculates a moving average PI. The actual PI pattern is averaged by using an exponentially weighted moving average (EWMA) function. The calculation considers current PI observations (interval t in the formula) as well as all preceding PI observations (as far as back to the first observed interval 0 in the formula) of a continuous time series, and weights the values with a user-specified smoothing factor as shown in Figure 7.
The graph that results from moving average smoothening is characterized by a more evenly value pattern; it might allow for activations in situations that would not be taken into account without the additional smoothening.
Figure 8 shows the PI pattern, smoothened by the EWMA PI formula.
The smoothening algorithm delays the moments when the provisioning PI limit or the deprovisioning PI limit are being crossed; the smaller the smoothing factor, the more PI limit crossings are delayed. Hence, related capacity activations or deactivations are also delayed. Reducing provisioning or deprovisioning PI durations adequately can compensate for this delay.
The formula assumes that a contiguous series of PI values (time interval i=0 to t) is available, meaning that PI values are reported for every interval. For patterns with short gaps in workload, the formula disregards all PI observations that precede the last gap. The series of contiguous PI values can also be interrupted after subcapacity changes to the managed hardware, when the monitoring component, such as RMF, needs to recalculate the provided data.
To prevent high PI values from distorting the computed moving average PI pattern, a maximum capping PI value must be specified. This value limits the PI values that are considered to the maximum value specified by the capping PI. PI values that exceed that limit are replaced by the capping PI during computation of the moving average PI. That protects the resulting moving average PI graph from very high PI values that would have long-term effects. By default, the PI is capped at 5.5. If needed, it can be set to a different value, or moving average PI capping can be disabled.
Management on behalf of moving average PI and the capping value of the maximum capping PI is set globally. Hence, both values, the smoothing factor and the maximum capping PI, apply to all observed workloads.
For setting the moving average weight factor, see key SystemObservation.MovingAveragePiWeight in Table 17.
For setting the moving average capping, see key SystemObservation.MovingAveragePiCapping in Table 17.
An importance filter selects service class periods based on their importance. It includes the following parameter.
An importance filter also includes Provisioning Criteria PI values indicating when service class periods that match the importance filter are considered to be suffering. For more information about Provisioning Criteria PI values, see Provisioning criteria.
For example, if you specify importance value 3 in a filter, all service class periods with importance values 3, 2, and 1 match the filter and the specified provisioning criteria is applied to them. To define different provisioning criteria only for service class periods of importance value 1, you define another importance filter with the new criteria. The filter for importance value 3 then applies only to service class periods with importance values 3 and 2, and the filter for importance value 1 applies only to service class periods with importance value 1.
Included and excluded service class periods are identified by service class period filters, which contain criteria that a service class period must match to be considered or ignored by the Provisioning Manager. These filters include the following parameters:
In an excluded service class filter, this period and all periods with a higher period number are excluded from provisioning.