WLM and IRD
For years, the IBM mainframe architecture has allowed a mainframe to be divided into separate Logical Partitions (LPARs) so different types of work can run in their own unique environment. Inside a partition, WLM prioritizes all the work depending on its importance. LPARs are assigned LPAR weights, which is the percentage of overall processing power that’s assigned to all the work in that partition. If a workload shifts so more processing power is needed in a particular partition, LPARs shift processing power to the partition that needs it as long as CPU cycles are available. If all the partitions were at peak utilization, the operator had to manually change the LPAR weights. If the demand was unpredictable and irregular (as in a Web server environment), and the system was highly utilized, the operator had to monitor the system at all times, day and night, to ensure high-priority workloads received the resources they needed.
In addition, the connection between channel path and I/O control units is statically defined. In the event of a significant shift in workload, those channel path assignments had to be changed by an operator. Once an I/O request made it to the channel subsystem, it was serviced on a first-in-first-out basis. This could cause your highest priority work to be delayed due to significant I/O contention from lower priority work.
The IRD is composed of three parts. Two of the three are in place for QoS functionality in a channel environment. However, the features that are enabled for ESCON currently don’t “function” in FICON environments. The interleaving capabilities of FICON, coupled with its bandwidth, led to the belief that QoS functionality wasn’t needed or desired in FICON environments. That attitude is changing.
Dynamic Channel Path Management (DCM)
Dynamic Channel Path Management (DCM) is the first channel QoS functionality. DCM lets z/OS dynamically change channel path definitions to ESCON director-attached DASD control units in response to changing workloads. It does this by moving channel resources to the control units where they’re required.
The I/O configuration definition process is complex and requires significant skill. During system initialization, DCM builds tables that represent the physical I/O topology. These tables include entries for each director, channel and DASD control unit that’s accessible (physically attached). These topology tables are then used by DCM to determine what potential paths exist that DCM could add to a control unit to help achieve its bandwidth requirements. The process involves determining how many channels are required by a control unit, and how many other control units, if any, can share that set of channels. For availability, even if only a single channel is ever required by a control unit, two or more are normally defined to it in case of a failure somewhere along the path. Even when the configuration seems perfect, workload changes can produce a situation where an I/O configuration that allowed meeting a response time goal last week is inadequate this week. There may be sufficient I/O resources; they just aren’t where they’re needed.
DCM is designed to let WLM dynamically move channel paths through the ESCON director from one I/O control unit to another in response to changes in the workload requirements. When used in combination with WLM running in goal mode, DCM moves the channel resources to control units used by business-critical workloads to ensure they meet their goals. By defining a number of channel paths as “managed,” they become eligible for this dynamic assignment.
Moving bandwidth to the important workloads uses DASD I/O resources much more efficiently. This may help reduce the number of channel paths needed and could improve availability. In the event of a hardware failure, another channel can be dynamically moved over to handle the work requirements. If the nature of the workload is such that most subsystems have their peak channel requirements at the same time, DCM will be of little help, since its job is to reassign existing channels. DCM works best when there are variations over time between the channel requirements of different DASD subsystems.
Use of DCM in combination with control unit priority queuing type functionality, channel subsystem priority queuing and Parallel Access Volumes (PAVs) lets z/OS function in a more self-tuning and self-defining manner, enhancing end-to-end QoS functionality.