The lesson here is to remember to regularly revisit and re-evaluate your goals over time.
SCENARIO 3: CHANGES TO THE SYSTEM ENVIRONMENT ARE PLANNED
Your systems are running great in goal mode and everyone is happy. However, your site is planning some environmental changes.
When planning a change to the workload’s environment, do the WLM Service Definition and assigned goals need to be considered? Once again, the answer is yes.
You do not need to micro-manage your goals or WLM Service Definition for every planned change to capacity, software level, or new software functionality. What I am saying is that if you are planning an environmental change that may affect the expected performance of the workloads, you need to at least consider the possibility that the change could affect the way WLM views and manages the workloads and resources, or that the environmental change may cause additional contention for resources.
Some of the many environmental changes that could affect the way WLM manages the workloads and system resources include:
- Certain changes in processor capacity
- Changes to LPAR definitions or configurations
- Changes in Sysplex configuration or technology
- Workloads introduced into an asymmetrical Sysplex
- Consolidation of servers or workloads
- Merging of two data centers or companies
- Exploitation of some of the newest DASD I/O subsystem technologies.
There are some additional areas, but this list should give you a good feel for the types of changes you should consider. Again, I am not saying to micro-tune your WLM Service Definition for all changes, but make sure you consider the possible effects to WLM management of workloads and system resources if you are considering any of these environmental changes:
As an example, lets refer back to Figure 1, which shows a service class period that had 30 units of work that all want to run concurrently. As I mentioned, velocity goals are entirely dependent on the using and delay state samples that are collected by WLM to assess the progress of work assigned the velocity goals. An increase/decrease in the number of processes could cause more/less using CPU samples and more/less CPU delay samples. This, in turn, will affect the velocity achieved by some workloads, but may not affect others. Some goals may become too easy, and others may become too aggressive.
Now let’s say that you decide to install a processor with the same number of CPUs but each a faster speed. In this case, since the work would be processed faster, you would expect to see less delay samples, which would result in an increase in expected velocity. The same would be true if you kept the speed of the processors the same, but increased the number of processors. If you took this same workload and ran it on slower processors, you would likewise expect the velocity to decrease. Velocity is a goal that is very sensitive to both the speed and number of CPUs processing the workload.
This scenario becomes especially interesting when a workload runs on multiple z/OS images in an asymmetrical Sysplex (see Figure 2). If velocity goals are sensitive to the speed and number of CPUs, and since goals are Sysplexwide, then what sort of goal is appropriate for a workload running in a Sysplex with both a small/slow machine and a big/fast machine? Should you assign an aggressive velocity goal to cater to the workload running on the big/fast machine? If you do this, you risk having a goal that is too aggressive for the workload when it is running on the small/slow machine. If you assign the workload a lower velocity to cater to the workload running on a small/slow machine, then the goal may be too easy for WLM on the big/fast machine. Each of these cases has implications on the way WLM manages the workloads and their performance.