Can one LU be in multiple devices?
wrstuden at wasabisystems.com
Thu Sep 30 14:24:37 PDT 2004
* From the T10 Reflector (t10 at t10.org), posted by:
* William Studenmund <wrstuden at wasabisystems.com>
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-3-160682740; protocol="application/pkcs7-signature"
On Sep 28, 2004, at 7:20 PM, Paul von Behren wrote:
> * From the T10 Reflector (t10 at t10.org), posted by:
> * Paul von Behren <Paul.Vonbehren at Sun.COM>
> As a developer of storage management software (and storage
> management software standards), I believe that it would be a
> *bad* idea to allow an LU to be visible through multiple SCSI
> devices as a general rule. I believe that earlier in this thread,
> multipath and LUN masking were mentioned as special cases
> that touch on this issue. I see these as acceptable, but
> other multi-device LU configs seem unacceptable to me.
> But here's my opinion of a couple scenarios that should be allowed
> and a cases that should not.
> 1) Multipath is a good thing :-) We want to allow an LU to be
> accessible through multiple paths - even paths with multiple
> protocols (e.g. FC and iSCSI).
> 2) Virtual views are good. This includes LUN Masking as typically
> provided by FC RAID arrays - different initiators see different
> LU inventories (by issuing REPORT LUNS and INQUIRY and looking
> at peripheral qualifiers). From what I've read, it appears
> that iSCSI allows multiple nodes on a target to also provide
> virtual views.
My thought is that once we have the above two abilities, we have enough
complexity that I don't see how other configurations can make it any
worse. You already are at the point where a host OS needs to treat each
LU as independent - to look at VPD info to determine if it's seeing an
LU it already saw.
> What I think would be bad is for it to appear that two unrelated
> targets each contained the same LU. I think this would confuse
> management software. Customers want to be able to associate
> logical resources (like LUs) with an asset - i.e. LUs show up
> in a GUI as little boxes inside a big box that represent the
> array, tape library, etc that they just spent a zillion dollars
> purchasing. I think we want to avoid having an LU that seems to
> be part of two separate "big boxes".
While I understand this desire, I think the existence of FC <-> iSCSI
gateways makes this desire impossible.
Actually, let me take a step back. I think it depends on which GUI
screen you're looking at. If you're looking at the GUI controlling a
single device (even a large one), you can get to a point where you have
one little box for the LU. I.e. if you're looking at things from the
target side, you can do this. In iSCSI terms, you can get to a point
where you have one "network entity" (a la iSNS) that encompasses
everything, and all the LUs are in there.
However if you look at things from an over-view, or say from an
initiator's vantage point, then I don't think you can ever make the
assumption that things are nice and simple. And I don't think what
Mallikarjun's suggesting is the problem.
I think the problem is that we have permitted network entities (SCSI
devices) to be relay devices. FC <-> iSCSI gateways, by design, are
network entities that expose the LUs of another device. Thus at some
point of looking at more & more of the SAN, we will get to a GUI view
that includes both the original and the duplicated LU, and they'll be
in different entities. Specifically consider a node that has both FC
and iSCSI, and can see some node both through an FC <-> iSCSI gateway
and directly. It then sees the same LU in two separate entities.
Now, don't get me wrong. I think FC <-> iSCSI gateways are good things,
and should remain. I just think they are the most common example of a
device that breaks the "not in multiple devices" constraint.
> Virtual views are more constrained. I'll spare you the ASCII art
> (I'm famous in SNIA for ASCII UML), but here's how I envision
> acceptable joint custody of LUs. With multiple virtual views,
> there is still one big box (for the array), there's a bunch of
> little boxes (LUs) and there's a Venn diagram within the big box
> - allowing individual LUs to be part of different ovals representing
> the virtual views. And these ovals may also include all or a subset
> of the target ports - allowing multipath access.
> I think it would be useful for the emerging definitions and UML to
> reflect all these objects. I believe the big box corresponds to a
> SCSI target device. LUs and ports are well defined now. That
> leaves ovals. I view these as something different from a SCSI
> device. In FC, we never named these ovals. With LUN Masking, they
> correspond to the LU inventory I mentioned above. iSCSI target
> Nodes seem to be pretty close. But I think it would be useful
> if there was a transport-independent, SCSI definition of virtual
I agree with what you say above, that iSCSI target nodes are close to
(or can be used as close to) the Venn diagrams you mention, though for
iSCSI the big box is the network entity I mention above. At least from
the target's point of view. However I think that as soon as we start
looking from the initiator's point of view and can see gateways, the
restriction breaks down.
content-type: application/pgp-signature; x-mac-type=70674453;
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (Darwin)
-----END PGP SIGNATURE-----
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
More information about the T10