8.
Ensure, within reason, a reasonable number of virtual disks are created and made
available to IBM i operating system.
One is tempted to simply lump all the storage one has in a
virtual environment into a couple (or even one) large virtual disk. Avoid this if at all possible.
For traditional (non-blade) systems: There is a great deal of variability here, so
generalizations are difficult. However, in the end, favor virtual disks that are within a binary
order of magnitude or two of the physical disk sizes. Make each them as close to the same size if
possible. In any case, strive to have half a dozen or more in an ASP if you can. Years of system
tuning (at all levels) tacitly expect a reasonable number of devices, so it makes sense to provide a
bunch. You don't need a count larger than the physical device count, however, unless the device
count is very small.
For blades-based systems: You only have 16 LUNs available. However, you should use
a good fraction of them rather than merely one or two. In our tests, we tended to use twelve to
sixteen LUNs. One wishes a sufficient number for IBM i operating system to work with -- one
wishes also to segregate physical devices between ASPs to the extent feasible.
9.
Prefer Symmetrical Configurations
. To the extent possible, we have found that physical
symmetry pays off more than we have seen before. Balancing the number of physical disks as
much as possible seems to help. Strive to have uniform LUN sizes, uniform number of disks in
each RAID set, balance (at least at the static configuration level) between the various internal
and external buses, etc. To the extent practical, the user should strive for even numbers of items.
10.
In general, do not share the same physical disk with multiple partitions.
Only If you are
running some minimal IBM i operating system partition (say, a very small Domino partition or
perhaps a middle tier partition that has no local data base), should you consider strategies where
IBM i operating system is sharing physical disks with other partitions. For more traditional
application sets (whether a traditional system or a blade) you'll have a data base or large enough
data contents generally to give each IBM i operating system partition its own physical devices.
Once you get to multiple devices, sharing them with other partitions will lead to performance
problems as the two partitions fight (in mutual ignorance) for the same arm, which may increase
seek time (at least) a little to a lot. Service time could be adversely affected as well.
11.
To the extent possible, think multiple VIOS partitions for multiple IBM i operating system
partitions.
If the physical disks deserve segmentation, multiple VIOS partitions may also be
justified. The main issue is load. If the IBM i operating system partitions are small (under two
CPUs), then you're probably better off with a shared VIOS partition hosting a couple of small
IBM i operating system partitions. As the IBM i operating system partitions grow, it will be
possible to justify dedicated VIOS partitions. Our current measurements suggest one VIOS
processor for every three IBM i operating system processors, but this will vary by the
application.
IBM i 6.1 Performance Capabilities Reference - January/April/October 2008
©
Copyright IBM Corp. 2008
Chapter 14 DASD Performance
219
