Admin Alert: Configuring iSeries Partitions the Right Way

by Joe Hertvik

Like many OS/400 administrators, I deal with partitioned AS/400 and iSeries boxes. While partitioning is a great boon for server consolidation and isolating workloads into separate virtual iSeries boxes, there's one crucial item to take into account before you set up a partitioned iSeries box. The magic ingredient for happy partitioning is this: Don't use your controlling, or primary, partition as an iSeries production server.

Configuring the controlling partition as a production box will make the lives of your secondary partitions more miserable than a character in a country music song. Rather, the controlling partition should be configured as a thin primary partition manager, whose only job is to control the machine's secondary partitions, without performing any production functions itself.

To understand the concept of the thin primary partition manager, let's look at a simple example. Suppose you're ordering a new iSeries Model 820 box with four processors that you want to partition into two iSeries servers: PARTITION1 and PARTITION2. Initially, you decide to partition the box this way:

• PARTITION1--the controlling partition: OS/400 V5R1 configured with three processors
• PARTITION2--the secondary partition: OS/400 V5R1 configured with one processor

Both boxes will be used as production servers, and other system resources would be allocated accordingly. This is a rational setup, but it creates a dangerous dependency between PARTITION1 and PARTITION2. Because PARTITION1 is the controlling partition for PARTITION2, any system activity that involves powering down or IPLing PARTITION1 will also power down or IPL PARTITION2. The two partitions are connected at the hip, so that PARTITION1 must always be active in order to access PARTITION2.

Using PARTITION1 as the controlling partition creates several difficult situations:

• You want to apply PTFs and IPL PARTITION1, but you can't because it will also IPL PARTITION2.
• There's a system problem with PARTITION1 that causes the machine to automatically IPL. This also automatically IPLs PARTITION2 as well, causing an unexpected shutdown on two machines, rather than one.
• You need to upgrade PARTITION1 to OS/400 V5R2, but you need to schedule downtime on PARTITION2 to do this, because it cannot stay active during an upgrade.

These problems are compounded if you add more secondary partitions to your machine.

The solution is to configure your controlling partition as a thin primary partition manager, which has minimum resources and does not function as a production box. To do this, we would configure our 820 partitions in the following way:

• PARTITION0--controlling partition: OS/400 V5R1 configured with .25 CPU
• PARTITION1--secondary partition: OS/400 V5R1 configured with 2.75 CPUs
• PARTITION2--secondary partition: OS/400 V5R1 configured with one CPU

We've changed the controlling partition to a new partition, PARTITION0, a thin primary that uses a very low percentage of the available CPU. Other system resources, such as Main Storage and DASD, would also be assigned minimal values. Since OS/400 V5R1, IBM has allowed you to assign partial processor units to a partition in capacity increments of .01 processors. Although partitions can be assigned as little as .1 CPU processor units, IBM's recommendation is that the minimum number of processor units that should be assigned to a single partition is .25. PARTITION0 will never host applications or databases; its only job is to serve as partition manager for the secondary partitions. And because it does minimal processing, PARTITION0 can run for months before IPLing and it's highly unlikely that it will suffer a system crash.

Because we've made PARTITION0 our controlling partition, we can now configure PARTITION1 as a secondary partition, removing the dangerous dependencies between PARTITION1 and PARTITION2. Our two production partitions can now act as independent servers, and we're free to upgrade or IPL PARTITION1 without affecting any other partition. PARTITION2 remains a secondary partition.

The downside of creating a thin primary controlling partition is that it uses some system resources to create a seldom-used partition. The trade-off is that you lose system resources to a thin primary partition manager but gain the freedom to run and manage your partitioned production servers as independent entities.

For more information on creating and managing logical partitions in an OS/400 environment, download the IBM Redbook LPAR Configuration and Management: Working with IBM eServer iSeries Logical Partitions (PDF file).

Sponsored By COSYN SOFTWARE

Are you running BPCS and frustrated by BPCSOUTQ limitations? Are you upgrading to a new BPCS version and paying expensive programmers to modify your vanilla software just to change spool file behavior? Let COSYN SPOOL MANAGER do it for you. Now you can get those spool files where you want them (including into the trash can) without changing BPCS. Cosyn Spool Manager lets you change spool file attributes, move to another OUTQ, copy, delete, *SAVE, *HOLD, call programs and many more. Cosyn's Spool Manager's rules-based logic allows you to control spool files in real time. Rules can apply to a single user, a group of users or system-wide. You'll be up and running in no time with our simple install and supplied BPCS template. Find out why Spool Manager has been successful for companies like Firestone, Nestle, Marley and many more. You can get more information, or trial it for yourself at www.cosynsoftware.com.