Can one LU be in multiple devices?

William Studenmund 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>
*

--Apple-Mail-4-160682747
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-3-160682740; protocol="application/pkcs7-signature"


--Apple-Mail-3-160682740
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed

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

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.

Take care,

Bill
--Apple-Mail-3-160682740
Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFfDCCBXgw
ggNgoAMCAQICAUYwDQYJKoZIhvcNAQEEBQAwga0xCzAJBgNVBAYTAlVTMREwDwYDVQQIEwhOZXcg
WW9yazERMA8GA1UEBxMITmV3IFlvcmsxHTAbBgNVBAoTFFdhc2FiaSBTeXN0ZW1zLCBJbmMuMQww
CgYDVQQLEwNHSFExHzAdBgNVBAMTFldhc2FiaSBTeXN0ZW1zIFJvb3QgQ0ExKjAoBgkqhkiG9w0B
CQEWG3dlYm1hc3RlckB3YXNhYmlzeXN0ZW1zLmNvbTAeFw0wMzA4MTExODU2NDZaFw0wODA2MjUx
ODU2NDZaMIGXMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTESMBAGA1UEBxMJU2Fu
IERpZWdvMRcwFQYDVQQKEw5XYXNhYmkgU3lzdGVtczEbMBkGA1UEAxMSV2lsbGlhbSBTdHVkZW5t
dW5kMSkwJwYJKoZIhvcNAQkBFhp3cnN0dWRlbkB3YXNhYmlzeXN0ZW1zLmNvbTCBnzANBgkqhkiG
9w0BAQEFAAOBjQAwgYkCgYEA9CZhg4GVWYTRGcJz8lU1ipzInlBuGqfZQs88Z1rTP7+c3AyhKwpE
TyTmK4UhxslzKa93YLqifLxZKYt1jI6FNq40IQWCKBVywWBwmL5guCu0851f9ywH5Uj2wJdiDrOI
sOJKNpwNqml8bFdTrFS2qvyCxTIWVMLYAzUBBcl2F7MCAwEAAaOCATkwggE1MAkGA1UdEwQCMAAw
LAYJYIZIAYb4QgENBB8WHU9wZW5TU0wgR2VuZXJhdGVkIENlcnRpZmljYXRlMB0GA1UdDgQWBBTt
mjHbSBlMV48RWOBETM3EV0Tm/jCB2gYDVR0jBIHSMIHPgBQrBOnN88CNCHPaV5wLS212tcrgBaGB
s6SBsDCBrTELMAkGA1UEBhMCVVMxETAPBgNVBAgTCE5ldyBZb3JrMREwDwYDVQQHEwhOZXcgWW9y
azEdMBsGA1UEChMUV2FzYWJpIFN5c3RlbXMsIEluYy4xDDAKBgNVBAsTA0dIUTEfMB0GA1UEAxMW
V2FzYWJpIFN5c3RlbXMgUm9vdCBDQTEqMCgGCSqGSIb3DQEJARYbd2VibWFzdGVyQHdhc2FiaXN5
c3RlbXMuY29tggEAMA0GCSqGSIb3DQEBBAUAA4ICAQCpxoPEYunR7qiXyycEZd0UIatSt/WalMoH
nuN9S421iS/sD1wSDqzHyM5YyUWn4z4o6VhT2kD9UV4lk5aXxxefEfGzFcR7Xyah7tO3ziuReFfx
qUP5+DTlwDuUBc8Iow6NwY9GlRCKFSsEroLWLGODyYWgN1ojjKOtcXRiOZkYTP3VfDUV2/Xrhh9O
l6+3Otf069+KWeOWedWeMsbe1rac96yPEjPogToWkBXVJEeEQktd0BLETt7GUuSZg2Fho/nslqZv
nnnKZmrOfdFy9iXDL9T0Hp/OHf5B9RP+r00BJJFO8JzBPIL2IA3CBPApOQty5A00Jg1CGfDQxiV3
s8G0aRUbmFqg9r0OfhPYjJ8BHfw1HHWb7Cu91Sw+d5UnYracZhsR2Gc5H5CnfS6IZhc7ulfnSX8f
I4BXR4vbeRUG76J3rkkbkO1haYHLk5w5RlICHsJOBSElG9ggLBWNIfUZwAzo84lfmDmJMP1YCOmi
DFCbW1DgxhqVFpYEf5Pq2pVcCguopK2G9oZjH5fxq6ehisk9dN+7NEQ4OSqC43ehaStYOoQAJruN
e6e5tCtRMx7bMI7eVPiHxE9/Y38Q+sc5oRN9mCyyAXMweuMRNHAHAWdFB7NhHD6gBa2lh91zIMdf
iSVRlBXoMrBKJX6VecgnhvUp4G6QAnN7EMu6QHlc/jGCA0swggNHAgEBMIGzMIGtMQswCQYDVQQG
EwJVUzERMA8GA1UECBMITmV3IFlvcmsxETAPBgNVBAcTCE5ldyBZb3JrMR0wGwYDVQQKExRXYXNh
YmkgU3lzdGVtcywgSW5jLjEMMAoGA1UECxMDR0hRMR8wHQYDVQQDExZXYXNhYmkgU3lzdGVtcyBS
b290IENBMSowKAYJKoZIhvcNAQkBFht3ZWJtYXN0ZXJAd2FzYWJpc3lzdGVtcy5jb20CAUYwCQYF
Kw4DAhoFAKCCAe0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQw
OTMwMjEyNDM4WjAjBgkqhkiG9w0BCQQxFgQUzT+Pg5ByNY5pIJnds4RWtkvCCIEwgcQGCSsGAQQB
gjcQBDGBtjCBszCBrTELMAkGA1UEBhMCVVMxETAPBgNVBAgTCE5ldyBZb3JrMREwDwYDVQQHEwhO
ZXcgWW9yazEdMBsGA1UEChMUV2FzYWJpIFN5c3RlbXMsIEluYy4xDDAKBgNVBAsTA0dIUTEfMB0G
A1UEAxMWV2FzYWJpIFN5c3RlbXMgUm9vdCBDQTEqMCgGCSqGSIb3DQEJARYbd2VibWFzdGVyQHdh
c2FiaXN5c3RlbXMuY29tAgFGMIHGBgsqhkiG9w0BCRACCzGBtqCBszCBrTELMAkGA1UEBhMCVVMx
ETAPBgNVBAgTCE5ldyBZb3JrMREwDwYDVQQHEwhOZXcgWW9yazEdMBsGA1UEChMUV2FzYWJpIFN5
c3RlbXMsIEluYy4xDDAKBgNVBAsTA0dIUTEfMB0GA1UEAxMWV2FzYWJpIFN5c3RlbXMgUm9vdCBD
QTEqMCgGCSqGSIb3DQEJARYbd2VibWFzdGVyQHdhc2FiaXN5c3RlbXMuY29tAgFGMA0GCSqGSIb3
DQEBAQUABIGAvSViN+TV/MW/DJcEfY3giaS2/sc4BkVz8fBSXrMBPFaLVxJOR04DNQpUyTaBIlW8
ZjldMcz00e30PhiYuEkvh5Id0Egk0Oqnk4gxMw8IKjyu+pyjqe78PvV8WcitZLnIzUaikiVe6hwG
GAIs1KmH6/JLe3hnTEXKoUJjQ78ZdB8AAAAAAAA=

--Apple-Mail-3-160682740--

--Apple-Mail-4-160682747
content-type: application/pgp-signature; x-mac-type=70674453;
	name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (Darwin)

iD8DBQFBXHmgDJT2Egh26K0RApMFAKCaO5TBk5mNrx2jqY8FwpD3h1KCBwCcClj4
733PTOuLsviWV11wWsD/djY=
=q4Mw
-----END PGP SIGNATURE-----

--Apple-Mail-4-160682747--

*
* 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 mailing list