Re: Why do companies partition their Power Servers?

You clearly understand the requirements of building subsystems for your customers. This is good and it IS a valid method of supporting multiple customers. As you state they use a 'non traditional (for i) interface' which makes separating them with subsystems simpler than it would if they used command lines and such. It's also likely that they don't use traditional IBM i user profiles either I suspect which is another reason LPARs can be better in some situations.

To build LPARs with scripting is a tad more difficult than building subsystems that much is true. The commands in IBM i for subsystems are all well defined and understood (OK By good admins at least!) so that is a win for your method.

Effectively to build LPARs with a script you need connectivity to the HMC with SSH to issue the appropriate commands there to create the partition and it's profile. You also need connectivity to the storage (be that IBM i, VIOS, or SAN) to issue the appropriate commands to create the new partition, hopefully a clone by the way rather than empty disks!

Clearly this is more difficult for an IBM i specialist because the commands on the HMC are, um, "Less clear" and involve somewhat more parameters than CRTSBS, CRTCLS, ADDRTGE et al. But once it's all understood it falls to SMOP once again.

- Larry "DrFranken" Bolhuis

"SMOP": Simple Matter Of Programming.

www.frankeni.com
www.iDevCloud.com
www.iInTheCloud.com

On 6/11/2014 12:09 PM, Nathan Andelin wrote:

Evan,

I agree that using IBM i subsystems and libraries to isolate and manage
workloads may compete against the idea of using LPARs. But my questions
were asked with an open mind, and I am listening. We benefit by having a
separate development box. But I'm the one doing the PTFs and OS upgrades
and getting a sense of the cost of managing 2 systems.

We're using subsystems, libraries, and soft-coded library lists as part of
a SAAS business model. All of our applications have browser user
interfaces. We don't give customers access to command lines.

I set up the 60 runtime environments last week by calling a CL program
which runs the commands for setting up the subsystems and libraries for an
individual client. Last week I evoked that program from an RPG program
which looped through a client list. The whole process ran in something like
40 minutes.

The process can be used to setup various development and test environments,
in addition to separate environments for separate customers.

At some point, I intend on exposing the process to prospective customers,
who might fill out a browser form, then receive an email containing a
hyperlink to a login page for their web portal entry-point.

Everything I have read about setting up IBM i LPARS appears to involve an
HMC type user interface, a technical expert, and a fairly significant
number of steps. What are LPAR scripts and how they work?

-Nathan




On Tue, Jun 10, 2014 at 11:35 PM, Evan Harris <auctionitis@xxxxxxxxx> wrote:

Hi Nathan

I think your last statement is telling:

"I believe it will be much easier to to manage 60 such soft-coded
environments than 60 LPARS."

So long as you "believe" this, any discussion to the contrary likely falls
on deaf ears.

Some of the reasons we end up deploying separate LPARs for clients is (in
no particular order):
- Separation of workload(s)
- Creation of QA/Test environments
- Copies of Production environments
- A general desire to have a dedicated system environment for one reason or
another

This is by no means an exhaustive list as other posts have indicated.

It's pretty easy to create a new LPAR - certainly no more complicated than
creating 60 subsystems along with the associated jobqs, routing entries,
outqueues, user profiles, job descriptions, libraries and all the other
paraphernalia that doing things this way requires (I think you made this
sound way simpler than it really is). It's just a different mindset and a
different set of commands.

Where a separate LPAR helps is in things like maintaining separate System
values, providing root access (where it is sensible), duplicating library
names etc.

For a vendor it also helps in getting the customer to "believe" their
environment is completely separate and dedicated to them. They understand
the concept of a Virtual Machine well enough. Explaining how separate
libraries, job queues, etc would segregate the workload and data would in
many cases be a tough sell.

You should also take into account that what you are doing is pretty
non-typical in my experience. It's rare to encounter a system that runs
primarily one application, totally controlled by in house application
specialists(s) with no other applications competing on the system. Most
systems have a number of applications that don't necessarily want to
co-exist with anything else and/or in-house code that has not been as
carefully crafted as your applications clearly have.

You are truly fortunate that your applications have been built in the way I
get the impression they have.

You are only serving an application and conceivably you have sufficient
control that you can configure a new application without needing the
additional insulation a complete LPAR affords you. This is not the same as
hosting or providing a complete environment for a different workload, for
separate customers looking for a completely dedicated system for their
application.

Separate LPARs also provides much better - and more demonstrably visible
- workload segregation as access to CPU and memory is much more clearly
defined than in your scenario - unless you also created another 60
dedicated storage pools.


--

Regards
Evan Harris
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.