|
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:
>> -- Regards Evan Harrishttp://www.auctionitis.co.n>>> > 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.nz
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.