If it is just for load balancing, I would go for a single LPAR. Easier to configure. All resources are available where they are needed, when they are needed.
If you are looking for uptime, then you need at least two LPARs, so you could survive a LPAR outage. And as you don't use VM, multiple LPARs would survive a Linux outage. You can share CPU across LPARs. You can share I/O across LPARs. But you have to dedicate memory to LPARs. Also, if you setup the IOCP to allow sharing of all you I/O devices across multiple LPARs, you will find that "control storage" requirements increases, which uses up more of your main memory. This, of course, is not the case on the newer processors. Also, multiple copies at a high level also allow for taking down parts for maintenance and/or reconfiguration and/or software upgrades and/or hardware upgrades, without a total outage. Very quickly, this type of discussion (over beers), moves away from the techie considerations to the business considerations. Tom Duerbusch THD Consulting Law of Cat Sleeping All cats must sleep with people whenever possible, in a position as uncomfortable for the people involved, and as comfortable as possible for the cat >>> Patrick Spinler <[EMAIL PROTECTED]> 12/7/2007 9:23 AM >>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 We're having a long running over a beer discussion about how best to configure one of our applications. During our last drinking session, er, debate, we thought it might be interesting to post here and see what, if any, consensus there is. In brief: when load balancing client network connections across multiple instances of an application, is it better to run multiple separate 1 virtual IFL linux guests, each with a separate copy of the application, or a single, large N virtual IFL linux guest with several copies of the application running inside it? Assumption: you have enough real IFL's to back the number of virtual IFL's you'd assign. Our real situation which gave rise to this question: We're running the tivoli monitoring suite of products on our z system in linux guests. As per IBM's documented recommendation, we're running one TEMS process for each apx 500 client systems we monitor. Currently, we have this configured as a number of separate linux guests, each running it's own copy of TEMS. With expansion we have budgeted for next year, though, we'll have enough real IFL's to consider consolidating all these TEMS proceses into a single, multi-virtual-ifl linux guess. We're not sure if there would be any cp scheduling benefits to either configuration, or any resource benefits (e.g. storage usage, or paging). Help support our fluid fueled debates ! What're the group's thoughts, please? Thanks! - -- Pat -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHWWWANObCqA8uBswRApO7AJ40MdZJtQnI0enpwLxV+FLAjcrG2ACfZwOC xaoLzQy/+vMMFNWgtETqLrI= =0gIM -----END PGP SIGNATURE----- ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
