X-MimeOLE: Produced By Microsoft Exchange V6.5
Received: by onstor-exch02.onstor.net 
	id <01C79D96.1ECEFB37@onstor-exch02.onstor.net>; Wed, 23 May 2007 16:57:29 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-class: urn:content-classes:message
Subject: RE: how Onstor perform load balancing of IO paths
Date: Wed, 23 May 2007 16:57:28 -0700
Message-ID: <BB375AF679D4A34E9CA8DFA650E2B04E03D91088@onstor-exch02.onstor.net>
In-Reply-To: <02ec01c79d95$78536e10$464da8c0@glasshousetech.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: how Onstor perform load balancing of IO paths
Thread-Index: AcedlYKjPcpVSwmZRAymhF3ntnmERwAAGDFw
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>

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

-----Original Message-----
From: Michael Tracy [mailto:mtracy@css.glasshouse.com]=20
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=20


