RE: iSCSI: problem with LUN discovery

["John Hufferd/San Jose/IBM" <hufferd@us.ibm.com>]

Y P Cheng,
OK, now I have detected an important communication problem here.  What you
are calling a LUN is not what the rest of us folks (or at lest me) call a
LUN.

The LUN is the Logical Unit Number that is used to address the Lowest
addressable view of a Storage Entity (Sometimes, but not often in Storage
Controllers, called a Disk).

The Storage Controller (or Raid Array if you wish) will have had the
administrator configure the Physical Disks in some manor of RAID, or even
as JBODs (Just a Bunch of Disks).  Now if JBODs  then the Physical Disks
may show through to the Hosts.  But on larger systems this seldom happens.

The Logical Volume that the Storage Controller/Raid Array exports to the
outside world is known as the LU.  The addressing number that the Storage
Controller/Raid Array wants to assign to a specific initiator is called the
LU number or LUN.  Since the various host may be assigned the same and
different LUs in the same Storage Controller the LU number for any specific
LU may be different.  The only way to determine if two Logical Volumes are
the same, is by comparing the VPD page 83h.  If it matches then the Logical
Volumes are the same.

The Physical Disk LUNs that are seen by the Storage Controller are only
seen by that Storage Controller, and not addressable by Host systems.

By the way, when a Software Virtualizer (like Veritas Virtual Volume
Manager) sees volumes, it too sees the logical volumes which the Storage
Controller wishes it to see.

Now the Virtual Volume Manager software, can Stripe, and mirror (perhaps
across different Storage Controllers) and in general make a further
virtualization to the Logical Disks that the Storage Controller exported to
it.

On a SAN one of the things a SAN volume manager wants to do, is permit
various host that want to share a physical disk, to be able to do that,
therefore, it will access the Storage Controller from the various Hosts,
and then by comparing their VPD page 83h, determine which volumes are the
same thing.  Now Veritas since they have code in each Host, they can also
remap where the Host thinks its first sector is, and leave a little room
for it to configure various information that it needs.  In Fact if all you
systems use the same SAN volume manager, it can address all the volumes and
leave various signatures on each one that it sees. This also can be used
for various management reasons (like giving a volume a human readable
Volume Name).

Again, for this to work the Storage Controller must have been told what
Logical Volumes to give to which ever host are running the SAN volume
manager.  (Thats right, not all volume managers have support on all
systems, so this is not a truly universal approach, but it works well in
many environments.)  In the end though, it is the Storage Controller that
is in charge, and it will only give up its control if required by the
Storage Controller Administrator.

.
.
.
John L. Hufferd


"Y P Cheng" <ycheng@advansys.com>@ece.cmu.edu on 10/04/2000 02:25:42 PM

Sent by:  owner-ips@ece.cmu.edu


To:   "Nelson Nahum" <nnahum@store-age.com>, "'John Muth'"
      <muth@veritas.com>, <ips@ece.cmu.edu>
cc:
Subject:  RE: iSCSI: problem with LUN discovery



> From: Nelson Nahum [mailto:nnahum@store-age.com]
> Sent: Wednesday, October 04, 2000 1:54 PM
>
> The question is if a storage controller keeps a different GUID
> for every LUN
> created. If not we are in the same problem as WWN, LUN naming.
> The question is how to identify a LUN in a storage controller that can
> create and delete thousands of LUNs, and that the same WWN, LUN
> combination
> can address different volumes depend on the intiator.
> Also to keep this identifier in the EEPROM of the controller is not a
good
> idea, as cause problems when the controller is replaced.

Lets make sure we are talking within the same context.  In my view, LUN is
an address, not a name.  It is like the Dept. 514 of IBM Storage Division.
Another company certainly can have a Dept. 514 as well.  If EMC provide
data
services to hundreds of companies, the data are housed in different logical
volumes with different LUNs.  The owner of a volume will change, but the
LUNs stay around.  Each LUN or volume consists of many disks, each will
have
a GUID so we can tell if someone swap out the disks on us.  One only gets
to
see the LUNs assigned to him, aka LUN Masking.  To know which volume a
client is permitted to access has nothing to do with the LUN uniqueness.  A
volume has a unique name like Engineering-of-Connectcom.  But the
uniqueness
is only within the EMC Storage Division.  We certain can have a
Engineering-of-Connectcom at IBM Storage Division.  We find the URLs of EMC
and IBM Storage Divisions using a different services.  When login and
authenticate, we get the LUN of Engineering-of-Connectcom. Therefore, I
missed your point on needing WWN for LUN naming.

> I think that the best way is to identify a LUN by a string composed by a
> <GUID> (or S/N) <date> and <time> of the LUN creation. This
> method allows to
> create infinite LUNs (over the time) in a given controller.
> Keeping this string in the media and presented it in a Inquiry page
avoids
> the identification problems in controllers with multiple channels, that
> supports different mapping for multiple initiators.

What you suggested should be in the mode page defined by SAM-2.  Given the
access of a particular LUN comes before one has a chance to send the
inquiry
command..

Y.P. Cheng, CTO, ConnectCom Solutions Corp.>