IBM has been advancing its on-demand strategy for several years now, with capacity on demand (CoD) available on the IBM iSeries and pSeries server lines. The latest development in this strategy, on/off capacity on demand (OOCoD), was unveiled in May 2003. Available only on IBM z990 servers, OOCoD lets customers turn on and off processors to deal with workload peaks and subsequent dips. The technology can be a powerful tool, helping organizations manage temporary spikes in workload without making long-term hardware and software investments.
To realize the full potential of OOCoD, organizations must carefully manage the decision to activate additional capacity. A solid performance and availability management strategy is fundamental to the OOCoD decision process and the key to effectively leveraging this promising new technology.
Use Tool as Intended
By introducing OOCoD, IBM comes closer to achieving a true usage-pricing model. Capacity upgrade on demand (CUoD), an earlier offering, provided the ability to turn on dormant processors. The processors, however, became permanently activated. CUoD users, consequently, could not deactivate processors to coincide with periods of lower computing requirements. Conversely, OOCoD lets organizations more closely align computing resources with fluctuations in business activities.
OOCoD, when managed carefully, provides organizations with an opportunity to reduce hardware costs by adding temporary capacity. Consider an example. IBM charges one-forty-fifth of the purchase price of a central processor (CP) for each 24-hour interval of OOCoD use. Turning on a temporary processor for fewer than 45 days means, in the simplest of scenarios, that a company would have paid rent accruing to less than the purchase price of a CP.
This example makes it clear that organizations with relatively infrequent usage peaks, or those that plan to regularly reassess their capacity needs based on temporary usage peaks, will benefit most from the OOCoD option. The example also illustrates the need to carefully manage use of the function to optimize its benefit. In addition, a break-even point must be analyzed to understand when makes more economic sense to purchase additional processors rather than pay for temporary OOCoD usage.
Software charges are another consideration when evaluating OOCoD. Depending on the pricing model for each application running on affected central processor complexes (CPCs), the addition of temporary CPU capacity may impact software costs.
Cost reduction is OOCoD’s ultimate value proposition. To harness its potential, however, organizations must activate the function at the appropriate time and for the appropriate duration—namely, when certain that CPU capacity shortages exist at all three levels of the mainframe hierarchy:
- Intra-logical partition (LPAR)
- Inter-LPAR (within an LPAR cluster if intelligent resource director [IRD] is active)
- CPC as a whole.
Performance availability and systems management technologies—which provide real-time as well as historical data—are paramount to identifying a true need for additional capacity. The decision to activate OOCoD must be guided by the same principles used to ensure a well-maintained z/OS environment. These include the disciplines and procedures of ongoing performance tuning and availability management. IT must continually monitor the environment and stay abreast of the daily changes in resource consumption to maximize the system. The ability to measure, compare, identify hot spots, and analyze components of the system (including individual LPAR and Sysplex information) and its workloads is essential to a successful OOCoD implementation.