Capacity Provisioning for z/OS V2R1: Defined capacity and group capacity management
OzanBaran 120000M0Q0 Visits (12608)
Capacity Provisioning (CP) for z/OS V2R1 can manage Defined Capacity and Group Capacity limits. It can automatically adjust them based on a predefined policy as well as provides the end user with commands to make the adjustments from a z/OS console rather than the Support Element (SE).
In this blog entry we will share with you our experiences with this new enhancement. From here on we will refer to Defined Capacity as DC and Group Capacity as GC.
Specifically we will talk about:
High level introduction to DC and GC concepts
In various other documentations Defined Capacity and Group Capacity are also referred to as Soft Capping or WLM Capping.
An installation can specify a Defined Capacity expressed in millions of service
WLM keeps a 4-hour rolling average of the CPU usage of the LPAR, and when
The Group Capacity allows the definition of a group of LPARs on the same CPC
An LPAR can be restricted by Defined Capacity and in addition belong to a
For more details on Defined Capacity and Group Capacity concepts please refer to the following documentation:
z/OS Performance: WLM Soft Capping Support for Sub Capacity Pricing
MVS: Planning: Workload Management
Steps we took to start exploiting DC and GC
You need to have DC and GC limits in place before CP for z/OS can start managing them. In other words today CP for z/OS doesn't support initial assignment of these limits but just managing them once they are assigned.
Please note that the DC and GC limits... etc used in this blog entry are by no means recommendations for you. These are just values from one of our various tests. Limits you assign will depend on your configuration and requires capacity & performance planning.
For our test, we decided to assign DC and GC to one of our zEC12 CPCs, referred to as P91 in the examples below. These changes were done using the SE.
First we assigned DC to a set of our LPARs using the Change Logical Partition Controls task:
Next we created an LPAR Group, called PLEX1, using the Change LPAR Group Controls task. We added the above mentioned LPARs to it and gave it a GC of 4313.
Note that these changes can be made dynamically to the running systems and/or saved to the LPAR profiles to take effect in the future. We made the changes dynamically using the Save and Change button, shown above, and were able to see the results in RMF right away. Take a peek at the Image Capacity, Group and Limit fields for system JB0 from the RMF Monitor III CPC Capacity panel below.
Also even though we hadn't made any CP for z/OS changes yet we noticed a few messages in it's job log indicating that it was aware of the above changes:
05.45.16 S0022149 CPO3987I Group capacity observed. Current capacity is 4313 MSU for capacity group PLEX1 of CPC P91
Since CP for z/OS was already aware of the DC and GC updates we decided to take a look at some of the reports.
F CPOSERV,APPL=R DC PLEX=UTCPLXJ8 SYS=JB0
CPO1095I Defined capacity report generated at 08/05/2013 10:51:26
F CPOSERV,APPL=R GC CPC=P91 GROUP=PLEX1
CPO1096I Group capacity report generated at 08/05/2013 10:53:24
CP for z/OS policy updates we made to let it start managing our DC and GC limits
Before we describe the updates we made let us familiarize you with our CP for z/OS environment. Our domain consists of a z10, z196 and a zEC12 with 16 z/OS LPARs distributed across them and managed by CP for z/OS. We have three rules within our policy.
Each rule has a set of recurring time conditions as well as workload conditions and take effect only when both set of conditions are met. For instance the recurring time condition of our Evening rule is specified such that it is only active on week days between 6:00 PM and 6:00 AM.
The workload condition portion of our Evening rule is setup such that if the system Performance Index (PI) for any of our workloads (regardless of priority) exceeds 1.5 for 5 minutes additional resources that are available in our On/Of CoD record will be activated. Similarly once the system PI is 1.1 or less for 5 minutes unnecessary resources will be deactivated.
Now let's go back to our discussion on DC and GC support. First, per system, we added a Maximum Defined Capacity Scope to our policy. This value represents the total amount of DC MSU that can be added to that system by all the rules within the policy.
Next we assigned a Defined Capacity Scope (Max. Increase MSU), per system, in all our rules within the policy. This value limits the DC MSU that can be added by the specific rule.
We repeated the same actions for GC. First we added a Maximum Group Capacity Scope to our policy.
Then we updated all our rules with a Group Capacity Scope (Max. Increase MSU).
Finally we installed and activated our policy!
CP for z/OS DC support in action
Here are some sample messages related to CP for z/OS DC and GC support.
When CP for z/OS starts you will notice messages, per system and per LPAR group, on whether or not if it is managing DC and GC for those systems.
11.50.02 S0031098 CPO3986I Defined capacity observed. Current capacity is 1518 MSU for LPAR JF0 of CPC P91 with system JF0 in sysplex UTCPLXJ8
As CP for z/OS adjusts DC and GC you will see messages similar to these:
12.05.02 S0031098 CPO3964I Defined capacity decrease initiated to 1018 MSU for LPAR JF0 of CPC P91 with system JF0 in sysplex UTCPLXJ8
Links to additional documentation
For more details on CP for z/OS please refer to: MVS Capacity Provisioning User’s Guide
Make sure to take a look at their web site as well. I find the What’s New and FAQs sections to be very handy. Also if you are new to z/OS capacity provisioning take a look at the Further Info section for some introductory presentations.