Strategies for effective partitioning of p690.

From: Green, Simon (Simon.Green@EU.ALTRIA.COM)
Date: Mon Dec 01 2003 - 12:18:04 EST


At the moment, we're running two large SP2 clusters at two sites. These
comprise a wide mix of SP2 PCI nodes and SP attached servers.

Our chosen strategy for new servers is to use p690's and LPAR.

One of the next things we're going to be doing is shifting applications off
old silver nodes - probably onto Regatta partitions. The main reason for
doing this is that we want the existing applications on those servers to use
the 64-bit kernel, which is not possible on the silvers. We'll re-use the
silvers to replace our few remaining MCA servers, and various small
applications and test systems.

The problem, though, is that even a small LPAR will be very powerful for
anything which will run adequately on a silver node at the moment. And
there are some within our company who are reluctant to have small LPARs in
the first place.

It seems likely that we'll have to have some LPARs with multiple work-loads
in them - probably with WLM to keep things under control. But should we be
going for small LPARs so that we can minimise these shared workloads, or
have larger LPARs with many different workloads? Oh: and the different
workloads could well be for different customers, which has the potential to
make agreeing maintenance outages a bit of a pain.

Fewer LPARs would be easier to manage - much less hassle allocating I/O
slots - but it won't be too difficult to cope with smaller partitions if we
maintain good records - will it?

Any of you folks have any opinions/experiences? Should we be going for big
LPARs each with lots of workloads, or lots of small LPARs with as few shared
workloads as possible? Is there an optimum number of LPARS in a p690?

Simon Green
Altria ITSC Europe Ltd

AIX-L Archive at https://new-lists.princeton.edu/listserv/aix-l.html

AIX FAQ at http://www.faqs.org/faqs/aix-faq/

N.B. Unsolicited email from vendors will not be appreciated.
Please post all follow-ups to the list.



This archive was generated by hypermail 2.1.7 : Wed Apr 09 2008 - 22:17:22 EDT