Anyone For LPAR?

January 30, 2012 Dan Burger

Among the IBM i user base, you often hear about the great technology being used by the customers at the enterprise end of the spectrum. Meanwhile, in the small to midsize shops, you hear complaints that the technology is too complex. The functionality could be put to use, but the complexity is prohibitive. Logical partitioning, or LPAR in the IBM mainframe and now Power Systems lingo, is one of the technologies that fits that description.

You’ll find LPARs being used in just about every large enterprise that depends on the IBM i for core business applications. When you explore the midsize business district, LPARs are likely to show up about 50 percent of the time at the top of the midrange and more like 25 percent at the lower range. In the small companies, LPAR is almost never found.

Another way to classify or categorize this would be to say any of the Power 570, 770, 595, and 795 monsters of the midrange that are not taking advantage of partitioning are as rare as a Cleveland Browns Super Bowl ring. The Power 550 and 740 boxes have about a fifty-fifty chance of using LPARs. And the Power 515, 520, 525, and 720 class machines are not the happy LPAR hunting grounds.

These are generalized numbers because no one claims to have an accurate accounting of this sort of thing. And those with some insight into these accounts don’t want their faces shown on TV or their names mentioned in digital publications.

So is LPAR technology–the technology that allows multiple, independent operating-system instances to run on the same physical machine, workload balancing with shared processors and memory, and consolidation of servers–finding any new businesses in the IBM midrange?

Complexity is an issue. That’s certainly true in the smallest shops, but the case for needing the benefits of LPAR in those shops is pretty small as well. If IBM i could run Windows in a partition, it might be useful to a small shop, but that’s not happening and neither is the idea of converting Windows users to Linux users to any great degree.

Even in shops where the benefits of LPAR add up to a sensible return on investment, that complexity thing dogs thoughts of implementation. Some of this complexity phobia could be overcome with a little help from a business partner that has LPAR skills and a few notable guides on staff. Often, however, there are cultural clashes that undermine what could be savvy business reasons to implement partitioning. Almost all shops, IBM i included, have multiple platforms involved in various tasks–sometimes for good business reasons and sometimes not. But for generally bad reasons, there are platform-specific turf wars that build the silos that need to be dissolved. There’s more animosity in many of the multi-platform shops then at a Democrats versus Republicans buffalo chip toss. It always makes me wonder whether CEOs are unaware of this uncompromising fortress building or do they just prefer to stay out of the line of fire? I’ll just say that in many cases where LPARs could be beneficial, the ground is too muddy to plow.

I was recently pointed in the direction of an IBM i shop that has been in the LPAR game for more than five years–long enough to have recently gone through an operating system and a hardware upgrade that caused a closer examination of the existing LPAR environment, the ramifications of additional processing power, and the concerns for how long and how complicated this upgrade from a Power 570 to a Power 770 would be.

The company shall remain anonymous because you wouldn’t believe how cranky companies can get when you mention them in print. Even when you put them in a good light there’s always someone who wants to rewrite copy to include advertising jingles and canned quotes from the CEO that mentions awards for helping orphans and saving the whales. Too many cooks spoil the soup, you know. Maybe you’ve noticed this whitewashing in most of the case studies that get published.

Anyway, by the size of the iron involved, you can guess that this is an enterprise-level company. It’s a 500-store retailer with headquarters and a single warehouse located in the Midwest. A 70-person IT staff looks after a system that is largely dependent on SAP ERP applications as well as home-grown RPG applications running on IBM i.

One of the system administrators at this nationwide retailer was very helpful in describing the environment, so I’ll use it as an example.

For starters, this system admin couldn’t be happier about the seven LPARs that are set up to provide a central point of management. Ease of management was the main reason that partitioning was implemented in the first place. Without the LPARs, the system would require more hardware and more system management. Beyond that, certain efficiencies pertaining to resource sharing would be lost and more hardware costs would be incurred.

In this case, there are seven partitions: three production partitions, three development and testing partitions, and a single partition for a solitary AIX application. By the way, the AIX server was always administered by the IBM i staff, which completely negates the potential for tales of knife stabbings, poisonings, and other assorted mayhem.

The biggest partition is devoted to SAP development. It has the most resources allotted to it and is running multiple instances of SAP and the IBM i operating system.

One of the production partitions runs the home-grown, RPG-based inventory system that interfaces with SAP. Another production partition is devoted to the Kronos time-keeping application.

Each partition has resources assigned within a minimum and maximum value, which allows adjustments to changing workloads.

Help in setting up the original LPAR environment and getting through the hardware upgrade was provided by one IBM’s largest business partners. An important aspect of this was having a person familiar with IBM’s system management tools who could lead the company through the changes that needed to be made. One important step was figuring out, from a hardware perspective, what needed to be accomplished within the life time of the newly installed Power 770 box.

Prior to the hardware upgrade, the original LPAR environment was set up to share processors and memory and to create an easier and more efficient system to manage. That remained a high priority, and getting that right presented only a few quickly resolved problems.

“It’s all laid out in the planning tool,” according to the system administrator. “It won’t let you make many mistakes. And once you have things laid out on the planning tool, it gets imported into the HMC [Hardware Management Console]. We did the basic layout and adjusted memory and CPU for each partition, although we didn’t change much in terms of assigning processors. If we had three processors assigned to an LPAR, we left it that way when we upgraded. That gave us a baseline.”

“Because we were getting faster processors, we made our first step based on our experience before the upgrade. Then we looked at the performance from the new system and made adjustments from there, assigning more processing power to jobs with the highest priorities. We had one job that was taking 4 or 5 hours to complete before the upgrade. After the upgrade it was running in 40 minutes. This was without changing any code, so it was the result of the hardware. We had a 70 percent decrease in processing time on some of our jobs.”

A few new benefits were added during the upgrade process. One was the capability to share a CD ROM drive and tape drives. In the previous set up, each portioned system had its own CD ROM drive. With the new system two CD ROM drives are shared with the seven partitions and managed from the HMC. Sharing tape drives also reduced costs by allowing resources to be moved on an as needed basis.

The one AIX partition that was mentioned earlier was also added during the upgrade process. Because the pSeries server that hosted the app had a lot of hours on the clock, it was discarded and the AIX environment now runs in a partition controlled through the HMC.

The transition was smooth. Part of the credit goes to the knowledgeable staff and part of the credit goes to the business partner with expertise in partitioning. It should also be mentioned that the IBM i operating system upgrade to i 6.1 was done in advance of bringing in the new hardware, which made this a phased project and limited the amount of change happening at one time.

At the end of my conversation with the system admin, she did acknowledge that the learning curve for anyone unfamiliar with partitioning might be worrisome.

So what are the lessons learned?

If you don’t have the expertise, it doesn’t mean LPARs are out of reach. If it makes business sense, it can be done. The expert assistance is available to handle the complexity of the implementation. The system skills required after deployment aren’t out of the ordinary, according to my systems admin source at the enterprise level retailer. She’s never had any formal training–just learned the job from the previous system admin who retired.

On the topic of new business deployments of LPAR technology, it’s already playing a large role in the hosted services business (also known as managed services). Last week I traded emails with Paul Ratchford, product manager at CCSS, a provider of system automation software that is often found in LPAR environments. He concurred with the rise in managed services spurring an increased use of LPAR technology.

Ratchford also suggested a related topic dealing with virtualization and whether a virtual IBM i (OS/400) system is a viable alternative to creating a new partition. He says there are CCSS customers noodling this question right now.

Expect some discussion on this topic in an upcoming edition of The Four Hundred.

Table of Contents

Content archive

Recent Posts

Subscribe

Pages

Search