RE: iSCSI: establish a nexus with everything you see?

[Black_David@emc.com]

Marj,

I think the fastest way to resolve this one is to agree that
both alternatives are plausible and leave it at that.  The
"conservative reuse" issues don't require resolving aggressive
vs. lazy connection establishment behavior, and the less
we constrain how existing SCSI code expects to operate (i.e.,
we should allow both alternatives), the better iSCSI will
fit into existing systems.  Does that sound reasonable?

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 249-6449 *NEW*      FAX: +1 (508) 497-8500
black_david@emc.com         Cell: +1 (978) 394-7754
---------------------------------------------------

> -----Original Message-----
> From: KRUEGER,MARJORIE (HP-Roseville,ex1)
> [mailto:marjorie_krueger@hp.com]
> Sent: Thursday, January 03, 2002 2:47 PM
> To: 'Black_David@emc.com'; cbm@rose.hp.com
> Cc: ips@ece.cmu.edu
> Subject: iSCSI: establish a nexus with everything you see?
> 
> 
> I've changed the subject line cause we're going off on a 
> tangent that isn't
> really associated with conservative reuse.
> 
> > > If that's indeed so, the assertion that it's only the 
> external factors
> > > that decide
> > > nexii is not always true.  Consider the case of an FC initiator 
> > > port discovering target ports using an FC Name Server, 
> and an iSCSI
> > > initiator port discovering target ports using a "SendTargets" 
> > > command.  In either case,
> > > the initiator SCSI port may not really establish a nexus 
> > > with a discovered target SCSI port, unless the application (or
> > > even the SCSI class driver) really wants to do an I/O 
> > >(starting with an open() system call in Unix systems).
> > 
> > I strongly disagree with that.  Virtually all commercial OS
> implementations
> > of SCSI do aggressive establishments of the nexii as part 
> of the boot
> sequence,
> > as SCSI code tends to expect a "bus walker" to find devices 
> in the boot
> > sequence, and make sure they work.  Put a trace analyzer to 
> work on a boot
> > and watch all the TEST UNIT READY and similar commands flow 
> by.  Is anyone
> > making significant changes to this "bus walker" boot 
> paradigm out there?
> 
> I disagree with your notion of the "aggressive 
> establishments" behavior
> being good and desirable.  In practical implementations, it 
> causes many
> problems for FC networks when these over-zealous 
> implementations grab disks
> that aren't intended for them.  Elaborate zoning methods were 
> developed to
> try to alleviate these problems and haven't necessarily 
> helped due to the
> complexity of configuring larger FC networks.  Companies have 
> made money
> developing software that reside between the host SCSI layer 
> and FC drivers
> that "see" all the FC disks, but only establish nexus with 
> those that have
> been properly allocated to this host :-)
> 
> When you say "Virtually all commercial OS implementations" 
> you must mean MS
> and Sun OS?  Cause I can think of others that don't establish 
> SCSI nexus in
> this manner.  The whole concept of "plug-n-play" belies the 
> notion that SCSI
> nexus must exist at boot time.
> 
> > There's also a subtle issue to watch out for here in that 
> this delays
> > error discovery - if the shared persistent reservations are being
> > used by cluster software, discovering that the alternate 
> path nexus can't
> > be established when trying to fail over to it is way too 
> late.  For things
> > like quorum volumes, I'm fairly sure that cluster software 
> checks all the
> > access paths at initialization time, but can someone 
> familiar with cluster
> > software comment on whether the alternate access paths 
> needed for failover
> > of application volumes are checked in advance, vs. relying 
> on the OS to
> > complain if the SCSI connection to the device didn't set up 
> correctly?
> 
> Cluster software is a whole nother ballgame.  I don't see how 
> this is tied
> to the "agressive establishment" idea, except loosely.  I'd 
> expect a network
> with clustering software to be set up much differently than a simpler
> "singly attached storage" environment.  Early iSCSI 
> clustering networks may
> have to have SCSI nexus "preconfigured" in some manner to 
> efficiently boot
> and bring up all alternate paths.
> 
> Marjorie Krueger
> Networked Storage Architecture
> Networked Storage Solutions Org.
> Hewlett-Packard
>