MAINFRAME > Administrator > LPAR

LPAR and PR/SM


Having worked with LPAR on Processor Resource/Systems Manager (PR/SM), Im surprised that people still find it mysterious. In overly simple terms, PR/SM LPAR is similar to multi-tasking under a single z/OS image, and LPAR management is really no different than address-space management, although IBM has introduced some new features to make it interesting.

PR/SM works on the premise that the images under control wont all peak at the same time, which is an especially effective strategy for global companies in multiple time zones. For instance, while the Western Hemisphere heads to bed, Asia/Pacific is just waking up. If the images all peak at once, PR/SM has little benefit.

Defining LPARs

Technical reasons should take precedence for assigning multiple parameters to manage each LPAR. A high-profile political workload that only requires a small percentage of CEC shouldn't be assigned weights that overbalance more technical workloads. Intelligent Resource Director (IRD) and processor weight/vary management can help address much of the issue; so most LPARS with varying weights and logical processors (LPs) can be defined if IRD manages them.

Simplicity

PR/SM LPAR is a form of multi-tasking, which, like z/OS performance management, has to be monitored, tracked and planned. If you don't manage individual images, then you cant manage LPARs.

Weights should reflect the needs of each image, regardless of the workloads importance. Memory should be assigned to ensure that paging isn't an issue. In my opinion, ESCON Multiple Image Facility (EMIF) channels are IBMs best idea since Execute Channel Programming (EXCP). They save the cost of buying more channels to handle devices that were shared among LPARS, and they continue the philosophy of sharing rather than dedicating resources.

Managing

If you're doing any form of capacity/performance management, you are 90 percent on your way to managing your LPARs. If you know each workloads needs, you can roll that up to each image and to each CEC. This only differs in degree from managing individual workloads. Theres less granularity; if you monitor it, you can manage it.

Enhancements

The three major PR/SM enhancements over the past few years are (in my mind):

  • Dynamic Channel Management (DCM)
  • IRD
  • Sub-Capacity Licensing

DCM - There was a joke, when 3990 control units first came out. You had three channels for performance and one for availability. The point was that anything more than three channels is overkill. Now we have many more available. I tend to think that we don't need all the extras over three, but allowing for DCM cant hurt. Its easy to implement and can address some fringe problems.

IRD - First, be aware that I haven't used this. Ive researched it and talked to my contacts within IBM Canada, and I think it's one of the best things we can implement within any image on any CEC with multiple LPARs.

Processor Vary Management, even though I haven't worked directly with it, is one of the best ways to help reduce the overhead introduced with managing LPARs. Also, weight management can help address sudden spikes in demand.

Theres no way the performance/configuration analyst can address the requirements as quickly as the software and hardware can. Getting the PR/SM hypervisor to manage issues that can take analysis and change control is a more efficient approach.

Sub-Capacity Licensing-In my mind, this is one of the better implementations of managing software costs. Again, it's not something that I have direct experience with, but Im pushing to get it implemented where I work.

Anything that can reduce the total cost of ownership (TCO) is a good thing. There's management of the smaller LPARs, but (hopefully) its cheaper than the alternative.

An example

Assume:
You’re using MQ Series for a simple, small application.

  • You’re currently running it on a 200+-million service units (MSU) image.

Why not:
Create a small LPAR with just enough connectivity to run the MQ Series part, plus whatever is required to support MQ and its channels. This could theoretically range closer to 100 MSUs.

  • You’ve just saved 100 MSUs in software charges by creating a smaller LPAR.

Conclusion

PR/SM LPAR isn't a mystery. As with any infrastructure management facility, it must be monitored and tuned. It's no different than managing address spaces in a z/OS environment. There's a cost to managing it, in terms of operating overhead, systems programmer time and performance analysis. But, in the long term, assuming that workloads don't all peak at the same time, it's a method of helping ensure effective usage of processing resources.

Ted MacNeil is a capacity/performance analyst with more than 25 years in the IBM mainframe environment. Ted can be reached at tedmacneil@alumni.uwaterloo.ca.


comments powered by Disqus

Advertisement

Advertisement

2019 Solutions Edition

A Comprehensive Online Buyer's Guide to Solutions, Services and Education.

ADMINISTRATOR > LPAR

LPAR and PR/SM

Virtualizing Resources on the Mainframe

How to virtually get the most from your System z platform.

IBM Systems Magazine Subscribe Box Read Now Link Subscribe Now Link iPad App Google Play Store
Mainframe News Sign Up Today! Past News Letters