Re: Guest Partition Storage Configuration

Hi Jim

that's really useful feedback.

Just to clarify, the application server is running the JDE iSeries
servers. These guys want to have two of them so they can take one off
line for updates etc and always have one of them running.

The customer system has a history of being somewhat IO constrained
hence my questions about disk. I encountered a situation on another
machine where a guest and host virtually stopped during some system
operations (a save of the guest and a PTF load/apply on the host).
That guest was configured with only one storage space so that may
explain the issue. What it did do was cause me to consider how I might
isolate the IO for the guest from the IO from the host or come up with
a better configuration. (The guest in question was not configured by
me but I was trying to understand the options)

One of the scenarios we were considering was assigning 4 X 140 drives
to a user ASP and then building the Storage space(s) in there to keep
guest activity isolated to some specific drives, which was what
prompted my question. It sounds like I'd be better to assign those
drives to the system asp and then build 16 X 35gb storage spaces to
get my 500 gb of storage.

If there was a redbook or document that had more information regarding
approaches to these issues I'd be interested. So far my searching has
turned up precious little.

Thanks again for the responses, they are really helpful.

On Thu, Jun 23, 2011 at 8:24 AM, Jim Oberholtzer <midrangel@xxxxxxxxxx> wrote:

If I read the original post correctly you were discussing JDE servers so
I made the assumption you were discussing the Intel servers.  If these
are the IBM i database servers, I still recommend that you create the
drives in *SYSBAS, and allow IBM i to do it's thing.

As to the number of arms (network storage spaces) you need to provide
the server, the rule is the same with a hosted one as it would be with a
physical one, the more arms the better IBM i is going to react.  So with
that in mind, I would create all the storage spaces to mimic 35Gb
drives, and create as many as you need for the space requirement.  A
dead flat minimum in my view is 6 in order to keep IBM i  happy.  When
you link them to your virtualized server they will then show up in IBM i
as independent disk units and IBM i will happily use them.

Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects


On 6/22/2011 2:43 PM, Evan Harris wrote:

Hi Jim

Thanks for the response.

Part of the reasoning for separating the IO was due to performance
issues seen on other guests; we were looking at a minimum of 4 drives
for the application servers, not just one or two (not sure if I had
made that clear).

Following on from your response, is there any rule of thumb as to how
many to create, or what sizes to make the storage spaces ?

Making one large storage space will create I/O problems of it's own if
what my IBM resource has told me is accurate.

Do you have any best practise guidelines for this aspect ?

On Wed, Jun 22, 2011 at 11:37 PM, Jim Oberholtzer<midrangel@xxxxxxxxxx>  wrote:

 Evan,

 Based on your description of the situation, I think most will agree that
 best practice would have you create your storage spaces in SYSBAS.  If
 you isolate the drives for the storage spaces you will degrade the I/O
 capacity to a point where I wonder if the performance of the guest
 partitions would be sufficient.  Allow IBM i to do what it does best,
 manage storage.

 If you had an iASP that had many disk units in it to eliminate the I/O
 issues, then you could consider that.  For now I would create the
 storage spaces as needed and let them do their thing.

-- Regards Evan Harris http://www.auctionitis.co.n

--
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.