Re: iSCSI URL scheme

[Daniel Smith <dfsmith@almaden.ibm.com>]

Your concerns are quite valid---here's the reasoning though; and yes, it's a
significant departure.  But not too much.

Black_David@emc.com wrote, quoting dfsmith@almaden.ibm.com:
> 
> >
> > I: <encrypted> Alright!  I want to connect to
> >    "scsi://niceshark.acme.com/bobsstorage/san3?wwn=0x7b4d72658a7410db"
> 
> This query is a *major* departure from SCSI practice at this level.
> The SCSI approach would be more along the lines of:

At this point, I will append to the conversation...

S: <encrypted> You got it!

> I: <encrypted> Alright! Show me all your LUNs that I can access.

S: <encrypted> You've got LUN 3.

I: <encrypted> What's the WWN of LUN 3?

s: <encrypted> 0x7b4d72658a7410d

On the other hand, had the the I requested "scsi://.../bobsstorage/san3" it
might have received a bigger Request LUNs response.

S: <encrypted> You've got LUNs 3, 5, 11, 28 and a bonus number 45.

The example given was an SSP-like environment.  Due to firewalling, all
storage accounts were presented to the outside world through one address:
niceshark.acme.com.  This presents a problem if there are lots of storage
accounts on niceshark---show me all your LUNs may return 10 million of the
things!  The alternative is to specify a subset (as done here in
/bobsstorage/san3, in this particular case a WWN was also specified) /or/ to
only present the LUNs that were authenticated as part of the login
authentication.

We (I?) prefer the former, because I would like to keep the service delivery
port name and the authentication procedure separate.  I can imagine where
the same key can be used to access /bobsstorage/san2 and /bobstorage/san1 as
well.

> This is an authorization check that can be implemented by a combination
> of accepting/denying the connection based on the client authentication
> information and/or only reporting the LUNs to which the Initiator has access
> (and after an exhaustive search, the Initiator may discover that a LUN it
> used to have access to [based on WWN} doesn't seem to be there any more).
> Fibre Channel makes widespread use of a mechanism similar to the latter at
> the
> target discovery level (nameserver based soft zoning, where the fabric
> nameserver
> only tells an Initiator about Targets it can access, rather than all the
> Targets it
> knows about).

Just as a personal note, this seems rather complex and wasteful.  Just as a
mailing list contributor, this method is still fully supported.

> > S: <encrypted> Ok, that URL has been changed to
> >   "scsi://bobstorage.san3.acme.com:9003/".  Please come again.
> 
> This is a common computer science solution to a large set of problems;
> introduce another level of indirection ;-).  While I understand the
> solution,
> I'm not at all clear on what the problem is and why it needs to be solved
> in this fashion.  There's been a lot of traffic on this, have I missed
> something?

In this case, management decided to change things without telling anybody. 
I, too, cannot fathom why this would be useful.  B-P (And there hasn't been
a lot of list traffic.  It's done in the HTTP land all the time, and
benefits the servers immensely; though not the users!)

Seriously though, this is a management convenience.  Consider this
situation.  You are the haggard and overworked storage administrator in
charge of your department's storage needs.  As part of your never-ending
upgrade plan, you want to swap out those people who use too little storage
(or access it too infrequently) to the cheaper server.  There are 57 of
them.  Rather than emailing them to update their SCSI buses, you tell the
main server to redirect them instead.  (Naturally, you are still peeved that
their silly custom installed operating systems don't bother to check the
master database when connecting to their SCSI buses.)

Whenever you have a `well known name' redirection is important.  While FC
gets by fine with a WWN, this is slightly different.  Imagine, if you will,
that all the SANs in the world have been joined together on the InterSAN. 
(It was Al Gore's initiative too.) To access a device you need a path (LUN)
and an identifier (WWN).  If the paths are dynamic, you cannot search for an
identifier without querying a database of some sort (san.yahoo.com?).  But
if the database is large, unwieldy and not completely up to date (e.g.,
Yahoo, Altavista, the DNS servers...), an attempt to access a well known
name may yield incorrect results.  ("Well, WWN x was always at LUN y
before---where has it gone, the database still says it's there.") I think
I'll invent a new maxim here.  "Any distributed root database of sufficient
size is going to update more slowly than the leaf nodes."  Has a nice ring
to it.

...
> for a good reason.  One question to think about is "If all SCSI targets
> are named by URLs on the server, where do the URLs come from?"
> An answer of the form "yet another config file or set of registry entries"
> is an obstacle to adoption, because tools have to be written to manage
> these, and administrators have to learn how to use them, and ...

All good points and I wish I could think of a really good scheme that has no
adoption obstacles.  If any of you have one, please post it.  (Answers of
the form "make the 8-byte WWN into a 1-byte path, 4-byte IP address, 2-byte
port number and 1-byte id" please note that IPv6 is a 16-byte routing
address scheme.  And we want iSCSI to be ideally transport (TCP) agnostic,
and definitely delivery (IP) agnostic.)

Daniel Smith.
-- 
IBM Almaden Research Center, 650 Harry Road, San Jose, CA 95120-6099, USA
K65B/C2 Phone: +1(408)927-2072 Fax: +1(408)927-3010