SEO

I need one more advice from you , regarding VSCSI . I have just
implemented a VIOS setup with one VIOS and a large number of client
Lpars.

I have used same VSCSI 9 (let's say vscsix ) on each client lpar to
mapp disks for rootvg as well as disks for datavg.

In my environment, rootvg is offcource on a scsi disk , being exported
from VIOS servers , while datavg are on san disk ( again physically
attached to FC adapters of VIOS servers).

Question is that , what is best stretegy... Technically possible to
use same vscsi for rootvg and datavg , but what is best practise ( and
also from performance point of view)...

I have searched manuals and redbook , nobody says about different
VSCSI for rootvg and datavg ...

For me , solution works fine and off course more complexity in
management , if i retain with single vscsi strategy for each client
lpar....

Any comments or suggestions ...

Polani wrote:
> I need one more advice from you , regarding VSCSI . I have just
> implemented a VIOS setup with one VIOS and a large number of client
> Lpars.
>
> I have used same VSCSI 9 (let's say vscsix ) on each client lpar to
> mapp disks for rootvg as well as disks for datavg.
>
> In my environment, rootvg is offcource on a scsi disk , being exported
> from VIOS servers , while datavg are on san disk ( again physically
> attached to FC adapters of VIOS servers).
>
> Question is that , what is best stretegy... Technically possible to
> use same vscsi for rootvg and datavg , but what is best practise ( and
> also from performance point of view)...
>
> I have searched manuals and redbook , nobody says about different
> VSCSI for rootvg and datavg ...
>
> For me , solution works fine and off course more complexity in
> management , if i retain with single vscsi strategy for each client
> lpar....
>
> Any comments or suggestions ...
>

We use SCSI disks exclusively internal to the VIO server, and our SAN
disks get fed to the clients. The way we number our Server/Client
adapters is that we match numbering for both adapters, i.e, server
adapter slot 5 will be slot 5 on the client, and have odds on VIO1 and
evens on VIO2.

We make no distinction between what is rootvg and datavg on the clients,
they all use the same adapters. With the performance of the memory
interconnect, I don't think there is any gain by adding to that
complexity. We dual source our SAN to the VIO servers, so that each
client will have the same LUN provided to it by both VIO servers. We
alternate the primary/secondary flag for the LUNS to the VIO servers. I
can't remember the "chpath" syntax, but basically we make hdisk0 primary
to VIO1, hdisk1 primary to VIO2, and so on.

Now granted, we have an open checkbook on disk resources at this point,
so we can play a little. If you must use SCSI disks to your clients, so
be it, but I would stay away from that. Doing so would either mean no
redundancy, or requiring you to mirror on the client.

I am going to end here, because this was an initial ramble. Pick what
you can from that and we and discuss further.

SG

"0xdeadabe" <none@nowhere.net> wrote in message
news:479b5718$0$30705$4c368faf@roadrunner.com...
> Polani wrote:
>> I need one more advice from you , regarding VSCSI . I have just
>> implemented a VIOS setup with one VIOS and a large number of client
>> Lpars.
>>
>> I have used same VSCSI 9 (let's say vscsix ) on each client lpar to
>> mapp disks for rootvg as well as disks for datavg.
>>
>> In my environment, rootvg is offcource on a scsi disk , being exported
>> from VIOS servers , while datavg are on san disk ( again physically
>> attached to FC adapters of VIOS servers).
>>
>> Question is that , what is best stretegy... Technically possible to
>> use same vscsi for rootvg and datavg , but what is best practise ( and
>> also from performance point of view)...
>>
>> I have searched manuals and redbook , nobody says about different
>> VSCSI for rootvg and datavg ...
>>
>> For me , solution works fine and off course more complexity in
>> management , if i retain with single vscsi strategy for each client
>> lpar....
>>
>> Any comments or suggestions ...
>>
>
> We use SCSI disks exclusively internal to the VIO server, and our SAN
> disks get fed to the clients. The way we number our Server/Client
> adapters is that we match numbering for both adapters, i.e, server adapter
> slot 5 will be slot 5 on the client, and have odds on VIO1 and evens on
> VIO2.
>
> We make no distinction between what is rootvg and datavg on the clients,
> they all use the same adapters. With the performance of the memory
> interconnect, I don't think there is any gain by adding to that
> complexity. We dual source our SAN to the VIO servers, so that each
> client will have the same LUN provided to it by both VIO servers. We
> alternate the primary/secondary flag for the LUNS to the VIO servers. I
> can't remember the "chpath" syntax, but basically we make hdisk0 primary
> to VIO1, hdisk1 primary to VIO2, and so on.
>
> Now granted, we have an open checkbook on disk resources at this point, so
> we can play a little. If you must use SCSI disks to your clients, so be
> it, but I would stay away from that. Doing so would either mean no
> redundancy, or requiring you to mirror on the client.
>
> I am going to end here, because this was an initial ramble. Pick what you
> can from that and we and discuss further.
>
> SG
>
>
>

Open checkbook! Must be somebody elses checkbook

On Sat, 26 Jan 2008 04:25:38 -0800 (PST), Polani wrote:

> I need one more advice from you , regarding VSCSI . I have just
> implemented a VIOS setup with one VIOS and a large number of client
> Lpars.
>
> I have used same VSCSI 9 (let's say vscsix ) on each client lpar to
> mapp disks for rootvg as well as disks for datavg.
>
> In my environment, rootvg is offcource on a scsi disk , being exported
> from VIOS servers , while datavg are on san disk ( again physically
> attached to FC adapters of VIOS servers).
>
> Question is that , what is best stretegy... Technically possible to
> use same vscsi for rootvg and datavg , but what is best practise ( and
> also from performance point of view)...
>
> I have searched manuals and redbook , nobody says about different
> VSCSI for rootvg and datavg ...
>
> For me , solution works fine and off course more complexity in
> management , if i retain with single vscsi strategy for each client
> lpar....
>
> Any comments or suggestions ...

I actually just posed this question to IBM. Their response was that
GENERALLY the only time you need more than 1 vscsi device is for
multipathing. Adding VSCSI devices is not a way to achieve improved
performance.

On Feb 2, 10:15 am, "W.B." <civikmin...@yahoo.com> wrote:
> On Sat, 26 Jan 2008 04:25:38 -0800 (PST), Polani wrote:
> > I need one more advice from you , regarding VSCSI . I have just
> > implemented a VIOS setup with one VIOS and a large number of client
> > Lpars.
>
> > I have used same VSCSI 9 (let's say vscsix ) on each client lpar to
> > mapp disks for rootvg as well as disks for datavg.
>
> > In my environment, rootvg is offcource on a scsi disk , being exported
> > from VIOS servers , while datavg are on san disk ( again physically
> > attached to FC adapters of VIOS servers).
>
> > Question is that , what is best stretegy... Technically possible to
> > use same vscsi for rootvg and datavg , but what is best practise ( and
> > also from performance point of view)...
>
> > I have searched manuals and redbook , nobody says about different
> > VSCSI for rootvg and datavg ...
>
> > For me , solution works fine and off course more complexity in
> > management , if i retain with single vscsi strategy for each client
> > lpar....
>
> > Any comments or suggestions ...
>
> I actually just posed this question to IBM. Their response was that
> GENERALLY the only time you need more than 1 vscsi device is for
> multipathing. Adding VSCSI devices is not a way to achieve improved
> performance.


I actually had an interesting case a few months ago that prompted us
to use more than just one VSCSI device into a single LPAR. Take a look
at the following example:

I was faced with assigning a large number of small 20GB LUNS to an
LPAR. To be exact, it was 8TB worth of 20GB LUNS, hence, I ended up
having to assign 400 backing devices. Initially I did this by simply
using a single VSCSI device thinking that it was all just "in-memory"
transactions anyway and that the VIO SCSI virtualization algorithm
would not care if it was dispatching all my SCSI traffic through a
single in memory "queue" (not really the right term, but perhaps an
adequate "visual"). However, after all was plugged together the
throughput on the 400+ hdisks was not all that great and the single
VSCSI seemed pretty pegged when we watched it in nmon. So after doing
all the standard VIO/LPAR tuning exercises (queue_depth, load balance
algorighm, MPIO priorities, bla bla bla) we started looking closer at
the amount of LUNs on the single VSCSI device. And yes, oddly enough,
the I/O appeared to improve when we worked the LUN/VSCSI ratio closer
to 128 LUNs per VSCSI. Has anybody experienced a similar performance
condition?