X-MimeOLE: Produced By Microsoft Exchange V6.5
Received: by onstor-exch02.onstor.net 
	id <01C79E21.62E6EBFA@onstor-exch02.onstor.net>; Thu, 24 May 2007 09:34:23 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C79E21.62E6EBFA"
Content-class: urn:content-classes:message
Subject: RE: how Onstor perform load balancing of IO paths
Date: Thu, 24 May 2007 09:34:23 -0700
Message-ID: <BB375AF679D4A34E9CA8DFA650E2B04E02FB2554@onstor-exch02.onstor.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: how Onstor perform load balancing of IO paths
Thread-Index: AceeH1pKkn1Ce6K6SHiEeHs4TILbMAAAEcMw
References: <BB375AF679D4A34E9CA8DFA650E2B04E03D91088@onstor-exch02.onstor.net> <006601c79e1f$551f2df0$464da8c0@glasshousetech.com>
From: "Bill Nadzam" <bill.nadzam@onstor.com>
To: "Michael Tracy" <mtracy@css.glasshouse.com>,
	"dl-cstech" <dl-cstech@onstor.com>
Cc: "TechPartner" <TechPartner@onstor.com>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C79E21.62E6EBFA
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

No!
Sorry, this explains why it is important, but not how one determines =
which path is a primary and the other a secondary.
Other vendors have shared this information with us. And in some cases =
ONStor has been able to figure this out through trial and error. =
Basically moving the access from one path to another, looking at the =
Inquiry response stings.
=20
ONStor has requested this information from HDS and Hitachi, but has yet =
to come up with a spec on how to determine the correct paths. Give a =
project and access to at least 3 of the HDS systems at one time, it =
could be reverse engineered. As of today, all you can offer them is the =
"scsi move <devname> path" command. This will allow the path to be set. =
This is not persistent through boot cycles. So a reboot, all go back to =
default.
=20
Sorry.

________________________________

From: Michael Tracy [mailto:mtracy@css.glasshouse.com]
Sent: Thu 5/24/2007 9:19 AM
To: Bill Nadzam; dl-cstech
Cc: TechPartner
Subject: Re: how Onstor perform load balancing of IO paths



They also attached this data.
Does this help any?

Michael

----- Original Message -----
From: "Bill Nadzam" <bill.nadzam@onstor.com>
To: "Michael Tracy" <mtracy@css.glasshouse.com>; "dl-cstech"
<dl-cstech@onstor.com>
Cc: "TechPartner" <TechPartner@onstor.com>
Sent: Wednesday, May 23, 2007 7:57 PM
Subject: RE: how Onstor perform load balancing of IO paths


> The simple answer is that Hitachi has never wanted to provide ONStor
> with the information needed to do the owned or Primary controller path
> selection. This has been an issue with them for some time.
>
> So, we just pick a round robin path as the devices get opened for
> service.
>
>
> -----Original Message-----
> From: Michael Tracy [mailto:mtracy@css.glasshouse.com]
> Sent: Wednesday, May 23, 2007 4:53 PM
> To: dl-cstech
> Cc: TechPartner
> Subject: how Onstor perform load balancing of IO paths
>
> Customer asking question on how the load-balancing is handled.
>
> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D
> More interesting issue to us .. how Onstor perform load balancing of =
IO
> paths. We noticed that some LUNs on backend (Hitachi Thunder/AMS1000)
> are accessing by Onstor via non-default path. From Hitachi side we
> configure the LUNx to use controller 0 (default and current controller
> in Hitachi LUN
> creation/config) but after this LUNx is mapped to Onstor and started
> accessing with IO, the Onstor device changes the port and shows us =
that
> original Hitachi's controller 0 path is closed and path to Hitachi
> controller 1 is open instead. Then we checked form Hitachi side, we =
see
> LUNx has default controller 0 but current controller 1 (originally =
LUNx
> has been created with default controller 0 and current controller 0).
>
> We have been explained this issue to Onstor System Engineer - Scott
> Moyer during our recent meeting at Princeton and we are wondering how =
we
> can avoid this situation. I am enclosing here a paper from Hitachi
> explaining why Hitachi performance is degraded if LUN is accessing by
> non-default controller path. Please take a look and let us know.
>
> For better understanding path change issue please see below (as =
example
> only) ..
>
> Hitachi configured =3D
> RAID Group 0 RAID Group 1
> LUN 0 (default controller =3D 0; current controller =3D 0) LUN 4 =
(default
> controller =3D 1; current controller =3D 1) LUN 1 (default controller =
=3D 0;
> current controller =3D 0) LUN 5 (default controller =3D 1; current
> controller =3D 1) LUN 2 (default controller =3D 0; current controller =
=3D 0)
> LUN 6 (default controller =3D 1; current controller =3D 1) LUN 3 =
(default
> controller =3D 0; current controller =3D 0) LUN 7 (default controller =
=3D 1;
> current controller =3D 1)
>
> Onstor configured =3D
> NAS volume 0 =3D Hitachi's LUNs 0-3 (show sp2.0 is open and this is a =
path
> to LUNs on Hitachi's controller 0) NAS volume 1 =3D Hitachi's LUNs 4-7
> (show sp2.1 is open and this is a path to LUNs on Hitachi's controller
> 1).
>
> As you may see from above, Hitachi and Onstor is balanced. Now, we =
start
> accessing NAS volume 0 (no traffic on volume 1). After a while, we saw
> from Onstor side ..
> NAS volume 0 =3D LUN0/sp2.0 open and use path to Hitachi controller 0;
> LUN1/sp2.0 closed, sp2.1 open instead (sp2.1 path to Hitachi =
controller
> 1); LUN2/sp2.0 - no changes . path to Hitachi controller 0 is used as
> configured originally; LUN3/sp2.0 closed, sp2.1 open instead (again,
> change happens from original config).
> For NAS volume LUNs from Hitachi side we see .
> LUN 0 (default controller =3D 0; current controller =3D 0) LUN 1 =
(default
> controller =3D 0; current controller =3D 1) LUN 2 (default controller =
=3D 0;
> current controller =3D 0) LUN 3 (default controller =3D 0; current
> controller =3D 1)
>
> (!!!) As you may see, Onstor did the load balancing and it is good and
> as expected but Hitachi does not like this because LUNs start =
accessing
> via non-default path. This behavior has a huge impact on Hitachi
> performance.
>
> The question here - how we can prevent this? Any ideas how to change
> load balancing behavior?
> (*) One thing we can do in a future to change our config ( I can not
> redesign NAS volumes which already in use) as ..
> NAS volume 0 =3D LUN 0, 4, 1, 5; NAS volume 1 =3D LUN 2, 6, 3, 7.
>
> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D
>
> I'm not sure the answer here so am hoping someone can shed light on =
the
> matter?
> I assume this is handled by the backend's active-active multipathing
> software.
>
> Thanks
> Michael
>
>
>



------_=_NextPart_001_01C79E21.62E6EBFA
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML dir=3Dltr><HEAD><TITLE>Re: how Onstor perform load balancing of IO =
paths</TITLE>=0A=
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dunicode">=0A=
<META content=3D"MSHTML 6.00.2900.3086" name=3DGENERATOR></HEAD>=0A=
<BODY>=0A=
<DIV id=3DidOWAReplyText83078 dir=3Dltr>=0A=
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 =
size=3D2>No!</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Sorry, this explains why it =
is important, but not how one determines which path is a primary and the =
other a secondary.</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Other vendors have shared =
this information with us. And in some cases ONStor has been able to =
figure this out through trial and error. Basically moving the access =
from one path to another, looking at the Inquiry response =
stings.</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>ONStor has requested this =
information from HDS and Hitachi, but has yet to come up with a spec on =
how to determine the correct paths. Give a project and access to at =
least 3 of the HDS systems at one time, it could be reverse engineered. =
As of today, all you can offer them is the "scsi move &lt;devname&gt; =
path" command. This will allow the path to be set. This is not =
persistent through boot cycles. So a reboot, all go back to =
default.</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Sorry.</FONT></DIV></DIV>=0A=
<DIV dir=3Dltr><BR>=0A=
<HR tabIndex=3D-1>=0A=
<FONT face=3DTahoma size=3D2><B>From:</B> Michael Tracy =
[mailto:mtracy@css.glasshouse.com]<BR><B>Sent:</B> Thu 5/24/2007 9:19 =
AM<BR><B>To:</B> Bill Nadzam; dl-cstech<BR><B>Cc:</B> =
TechPartner<BR><B>Subject:</B> Re: how Onstor perform load balancing of =
IO paths<BR></FONT><BR></DIV>=0A=
<DIV>=0A=
<P><FONT size=3D2>They also attached this data.<BR>Does this help =
any?<BR><BR>Michael<BR><BR>----- Original Message -----<BR>From: "Bill =
Nadzam" &lt;bill.nadzam@onstor.com&gt;<BR>To: "Michael Tracy" =
&lt;mtracy@css.glasshouse.com&gt;; =
"dl-cstech"<BR>&lt;dl-cstech@onstor.com&gt;<BR>Cc: "TechPartner" =
&lt;TechPartner@onstor.com&gt;<BR>Sent: Wednesday, May 23, 2007 7:57 =
PM<BR>Subject: RE: how Onstor perform load balancing of IO =
paths<BR><BR><BR>&gt; The simple answer is that Hitachi has never wanted =
to provide ONStor<BR>&gt; with the information needed to do the owned or =
Primary controller path<BR>&gt; selection. This has been an issue with =
them for some time.<BR>&gt;<BR>&gt; So, we just pick a round robin path =
as the devices get opened for<BR>&gt; service.<BR>&gt;<BR>&gt;<BR>&gt; =
-----Original Message-----<BR>&gt; From: Michael Tracy [<A =
href=3D"mailto:mtracy@css.glasshouse.com">mailto:mtracy@css.glasshouse.co=
m</A>]<BR>&gt; Sent: Wednesday, May 23, 2007 4:53 PM<BR>&gt; To: =
dl-cstech<BR>&gt; Cc: TechPartner<BR>&gt; Subject: how Onstor perform =
load balancing of IO paths<BR>&gt;<BR>&gt; Customer asking question on =
how the load-balancing is handled.<BR>&gt;<BR>&gt; =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D<BR>&gt; More interesting issue to us .. how =
Onstor perform load balancing of IO<BR>&gt; paths. We noticed that some =
LUNs on backend (Hitachi Thunder/AMS1000)<BR>&gt; are accessing by =
Onstor via non-default path. From Hitachi side we<BR>&gt; configure the =
LUNx to use controller 0 (default and current controller<BR>&gt; in =
Hitachi LUN<BR>&gt; creation/config) but after this LUNx is mapped to =
Onstor and started<BR>&gt; accessing with IO, the Onstor device changes =
the port and shows us that<BR>&gt; original Hitachi's controller 0 path =
is closed and path to Hitachi<BR>&gt; controller 1 is open instead. Then =
we checked form Hitachi side, we see<BR>&gt; LUNx has default controller =
0 but current controller 1 (originally LUNx<BR>&gt; has been created =
with default controller 0 and current controller 0).<BR>&gt;<BR>&gt; We =
have been explained this issue to Onstor System Engineer - Scott<BR>&gt; =
Moyer during our recent meeting at Princeton and we are wondering how =
we<BR>&gt; can avoid this situation. I am enclosing here a paper from =
Hitachi<BR>&gt; explaining why Hitachi performance is degraded if LUN is =
accessing by<BR>&gt; non-default controller path. Please take a look and =
let us know.<BR>&gt;<BR>&gt; For better understanding path change issue =
please see below (as example<BR>&gt; only) ..<BR>&gt;<BR>&gt; Hitachi =
configured =3D<BR>&gt; RAID Group 0 RAID Group 1<BR>&gt; LUN 0 (default =
controller =3D 0; current controller =3D 0) LUN 4 (default<BR>&gt; =
controller =3D 1; current controller =3D 1) LUN 1 (default controller =
=3D 0;<BR>&gt; current controller =3D 0) LUN 5 (default controller =3D =
1; current<BR>&gt; controller =3D 1) LUN 2 (default controller =3D 0; =
current controller =3D 0)<BR>&gt; LUN 6 (default controller =3D 1; =
current controller =3D 1) LUN 3 (default<BR>&gt; controller =3D 0; =
current controller =3D 0) LUN 7 (default controller =3D 1;<BR>&gt; =
current controller =3D 1)<BR>&gt;<BR>&gt; Onstor configured =3D<BR>&gt; =
NAS volume 0 =3D Hitachi's LUNs 0-3 (show sp2.0 is open and this is a =
path<BR>&gt; to LUNs on Hitachi's controller 0) NAS volume 1 =3D =
Hitachi's LUNs 4-7<BR>&gt; (show sp2.1 is open and this is a path to =
LUNs on Hitachi's controller<BR>&gt; 1).<BR>&gt;<BR>&gt; As you may see =
from above, Hitachi and Onstor is balanced. Now, we start<BR>&gt; =
accessing NAS volume 0 (no traffic on volume 1). After a while, we =
saw<BR>&gt; from Onstor side ..<BR>&gt; NAS volume 0 =3D LUN0/sp2.0 open =
and use path to Hitachi controller 0;<BR>&gt; LUN1/sp2.0 closed, sp2.1 =
open instead (sp2.1 path to Hitachi controller<BR>&gt; 1); LUN2/sp2.0 - =
no changes . path to Hitachi controller 0 is used as<BR>&gt; configured =
originally; LUN3/sp2.0 closed, sp2.1 open instead (again,<BR>&gt; change =
happens from original config).<BR>&gt; For NAS volume LUNs from Hitachi =
side we see .<BR>&gt; LUN 0 (default controller =3D 0; current =
controller =3D 0) LUN 1 (default<BR>&gt; controller =3D 0; current =
controller =3D 1) LUN 2 (default controller =3D 0;<BR>&gt; current =
controller =3D 0) LUN 3 (default controller =3D 0; current<BR>&gt; =
controller =3D 1)<BR>&gt;<BR>&gt; (!!!) As you may see, Onstor did the =
load balancing and it is good and<BR>&gt; as expected but Hitachi does =
not like this because LUNs start accessing<BR>&gt; via non-default path. =
This behavior has a huge impact on Hitachi<BR>&gt; =
performance.<BR>&gt;<BR>&gt; The question here - how we can prevent =
this? Any ideas how to change<BR>&gt; load balancing behavior?<BR>&gt; =
(*) One thing we can do in a future to change our config ( I can =
not<BR>&gt; redesign NAS volumes which already in use) as ..<BR>&gt; NAS =
volume 0 =3D LUN 0, 4, 1, 5; NAS volume 1 =3D LUN 2, 6, 3, =
7.<BR>&gt;<BR>&gt; =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D<BR>&gt;<BR>&gt; I'm not sure the answer here so =
am hoping someone can shed light on the<BR>&gt; matter?<BR>&gt; I assume =
this is handled by the backend's active-active multipathing<BR>&gt; =
software.<BR>&gt;<BR>&gt; Thanks<BR>&gt; =
Michael<BR>&gt;<BR>&gt;<BR>&gt;<BR></FONT></P></DIV></BODY></HTML>
------_=_NextPart_001_01C79E21.62E6EBFA--
