Re: iSCSI MIB Object Model

[Mark Bakke <mbakke@cisco.com>]

Somesh-

We are looking into making the LU and LUN tables optional,
which would help in this case.   I will bring up the appropriateness
of including them at IETF next week.

I like your idea of keeping track of the last few LUN errors.

I assume that you would like to see something like:

1. Each target includes a list of errors; the target would fill
   in something like the timestamp, LUN, and initiator WWUI that
   caused that error last.

2. Each session includes a list of errors, and does a similar
   thing.

Does this sound reasonable?  Do you have other ideas for doing
this that would simplify finding out what went wrong with LUs
and LUNs?

--
Mark

Somesh Gupta wrote:
> 
> Mark,
> 
> > -----Original Message-----
> > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> > Mark Bakke
> > Sent: Wednesday, March 14, 2001 12:49 PM
> > To: Venkat Rangan
> > Cc: IPS; jmuchow@cisco.com
> > Subject: Re: iSCSI MIB Object Model
> >
> >
> > Venkat-
> >
> > You have captured many of our open issues in this
> > message.  Please see my comments below.
> >
> > Thanks,
> >
> > Mark
> >
> > Venkat Rangan wrote:
> > >
> > > Mark,
> > >
> > > The UML is very nice, and the new object model, covering both
> > > Initiator and Target instances is also nice.
> > >
> > > Overall, we do have some concern over the need for maintaining
> > per-LU and
> > > per-LUN statistics. In some iSCSI implementations, the iSCSI entity is
> > > merely an intermediate layer, with no knowledge of LUs and LUNs. Placing
> > > this in the GeneralInfo category and making it mandatory would add undue
> > > burden on these implementations.
> >
> > One of our open questions is "how much is too much?".  We added the LU
> > and LUN statistics for a few reasons:
> >
> > 1. The iSCSI layer does see the LUN; it is included in the SCSI Command
> >    message.
> >
> > 2. For implementations that include the actual target and LUs, such
> >    as storage controllers, there is no other way to get information
> >    on LUNs through SNMP, since there is no SCSI MIB.
> >
> > 3. We felt that in this case customers might require LU- or LUN-level
> >    accounting.
> 
> I just did a rough (very rough) calculation for the amount of data
> required per lu and per lun - It is of the order of 256 bytes per lu
> and 512 bytes (actually more like 350) per lun. The number of
> Luns/lus can be in the 10s of thousands.
> 
> Even though the iSCSI PDU header carries a LUN number, this value
> is really transparent to the iSCSI layer. The iSCSI layer should
> not even know how many LUNs there are in the system. The size of
> the data set, and the cost of managing it are fairly significant.
> The ability of systems to dynamically add & delete LUNs/LUs should
> not be tied to the ability of the iSCSI layer to track the stats.
> 
> I think reasons 1 & 2 are not very good reasons. An analogy would
> be asking TCP to perpetually keep statistics on every 4-tuple that
> was ever used to create a connection.
> 
> I would recommend focusing on the error cases only for one - and
> perhaps have a table per error type tracking the last "n" errors.
> What does it matter if an R2T was received for a LUN or not? It
> just becomes a bunch of probably unneeded information to weed
> through to get to the real info.
> 
> >
> > However, keeping statistics at this level does create some work; perhaps
> > there is a way to make it optional.
> >
> > > In Section 5.9:
> > >    "The iscsiLUTable contains a list of iSCSI Logical Units that are
> > >    accessible via the iSCSI target."
> > >
> > > Would this list be the same as what the "Report LUNs" command
> > would give?
> >
> > It depends.  A LUN is just the address of a logical unit, and in the
> > general case, is only valid between a particular initiator and a
> > particular
> > target.  If a second initiator issues a "Report LUNs" to the same target,
> > it may get back a different list if the target is performing some sort of
> > LUN mapping.  Some targets will show the same set of LUNs
> > regardless of the
> > initiator; some won't.  There is no reliable way given the current MIB to
> > find out what "Report LUNs" would return; this is probably the domain of
> > a SCSI MIB.
> >
> > > In Section 5.7:
> > >    "The iscsiLunTable contains an entry for each known LUN that is being
> > >    accessed using this session.  Note that is may not contain all of the
> > >    LUNs that could be accessed; the only ones available to iSCSI are the
> > >    ones that have been addressed specifically by iSCSI commands.
> > >    Therefore, LUNs that have been discovered via mechanisms such as the
> > >    SCSI "report LUNs" will not appear in this table until they are
> > >    specifically addressed by the initiator.
> > >
> > > How long do these entries live in the table? If iSCSI sessions
> > logout and
> > > close, do these entries continue to remain?
> >
> > The current intent is to have entries live only as long as the sessions;
> > these would be removed when the session is removed.  This is the simplest
> > solution and would put the smallest burden on the implementation.
> >
> > However, we still have an open "requirements" question on whether anyone
> > wants these to hang around longer.
> >
> > > Thanks,
> > >
> > > Venkat Rangan
> > > Rhapsody Networks Inc.
> > > http://www.rhapsodynetworks.com
> > >
> >
> > --
> > Mark A. Bakke
> > Cisco Systems
> > mbakke@cisco.com
> > 763.398.1054
> 
> Somesh
> 
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com

-- 
Mark A. Bakke
Cisco Systems
mbakke@cisco.com
763.398.1054