Re: Best MPIO Practices on VIOS

How does doing this effect mult-pathing.


On Sat, Dec 7, 2013 at 9:51 PM, Roberto José Etcheverry Romero <
yggdrasil.raiker@xxxxxxxxx> wrote:

No, i mean:
VIOS usually directs ALL IO activity thru the first path that it finds
(unless SDDPCM or something like that is installed and controller
preference is in order).
In this case i first had ALL io going thru the fscsi0 port. After a VIOS
reboot i saw some luns going out the fscsi1 port even though priority

still

was set as 1 and 1 in each path (VIOS must have seen fscsi1 path first
during initialization).
After doing the aforementioned changes in priority (even disks now have

255

as priority on the fscsi1 path and odd disks the same but for the fscsi0
path).
I now see balanced IO and better than before, since more FC and

controller

ports are in use (during disk initialization i saw a limit of around
400Mb/s and 8k IOPS per port, in fact it was then that i noticed all this
since 11 luns were on one port and 6 were on the other. the 6 finished a
lot earlier than the 11).
Ah, in case someone is wondering, the topas command brings all this data,
remember to change the mode with D and d to see both per disk and per
parent data.
Best Regards,



On Sat, Dec 7, 2013 at 10:30 PM, Jack Kingsley <iseriesflorida@xxxxxxxxx

wrote:

Roberto, can you define: rudimentary balancing, are you referring to

some

sort of load balancing within the Hitachi SAN.


On Sat, Dec 7, 2013 at 7:49 PM, Roberto José Etcheverry Romero <
yggdrasil.raiker@xxxxxxxxx> wrote:

Sigh, where it says 2 8GB Dual Port adapters, it should say 1 8GB

Dual

Port

adapter. only 1 per vios....


On Sat, Dec 7, 2013 at 9:46 PM, Roberto José Etcheverry Romero <
yggdrasil.raiker@xxxxxxxxx> wrote:

I'm setting up a 750 with Dual VIOS (full how-to to be compiled in

a

few

weeks).
Each VIOS has 2 8GB Dual Port adapters, each port goes to a

different

controller on the storage (i'm not savvy enough about Hitachi's VSP

series,

but they dint seem to use the DSXXXX style of "preferred

controller"

so

any

port is good).
I noticed i can change the path priorities on VIOS to make a

rudimentary

balancing (since IBM i uses most arms at the same time, it's ok to

do

it

this way and not with round robin or some more advanced algorithm).
My question was (since i couldn't find it in most of the

documentation

I've read):
¿Is there any problem with changing the priority on the paths on

certain

disks, for example even disks via fscsi0 and odd via fscsi1?
I cobbled together a nifty line that gets me the chpath command

with

current priorities which i can use to change priorities to what i

want

(1

for the least used path, 255 for preferred).
I just tested it and it takes effect immediately and, since the

paths

are

still there, mpio should do the failovers without problem in case

of

fiber

or switch failure (i will try it, once i finish restoring the

systems).

I know that there is no support for load balancing at the IBM i

level,

IBM

i just takes the first vscsi controller and directs all traffic

there

which

means that i have to alternate Load Source tagging between

partitions

but

since i didnt find anything against doing this manual load

balancing

AND

the vios commands allow me to do it (no oem_setup_env needed to do

it)

i

think it should be OK.
Thoughts?
If anyone wants, the line is this:
lspath -field name status parent | grep fscsi | while read disk

status

parent; do priority=`lspath -dev $disk -pdev $parent -lsattr -attr

priority

| grep priority | awk '{print $2}'`; echo "chpath -dev $disk -pdev

$parent

-attr priority=$priority"; done

I adapted it from an AIX blog and tailored for the vios syntaxis

and

output

This line only prints the commands that set all paths to the

current

setting. Only copying the output, modifying and then pasting back

would

change anything.

Best Regards,

Roberto

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

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

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

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