RE: iSCSI: Wrapping up SendTargets

[Joshua Tseng <jtseng@NishanSystems.com>]

David,

> 
> > Before you or anyone calls consensus, I would like to see
> > how SLP can solve the following issues:
> 
> Some of this was covered in:
> 
> http://ips.pdl.cs.cmu.edu/mail/msg04812.html
> 
> So, some short answers here ...
> 
> > 1)  Management of Discovery Domains.  You don't want
> > incompatible file systems discovering each other, or
> > very bad things will happen.  Say 'goodbye' to the Unix
> > file system who's host is discovered by SLP....
> 
> Management at the DHCP server of which SLP
> scope(s) each system gets configured with.

This is still manual configuration of SLP scopes.  In the
DHCP server, you would configure lists of MAC addresses
of DHCP clients with the DHCP option (containing the SLP
scope) to be assigned to that client.

So let's run through a summary of this process:

1)  Create list of iSCSI devices (identified by iSCSI name)
you want to include in a particular scope.

2)  Figure out the 6-byte MAC address for each of those devices.

3)  Enter each MAC address into a list in the DHCP configuration
file, along with a name for that scope to be sent as an option.

4)  Do the same thing for every other scope.

5)  Pray that you don't accidentally place the a MAC address
into the wrong list (e.g., your NT initiator into the list
containing your Unix file system hosts).

> 
> > 2)  Transfer of X.509 digital certificates.  SLP cannot
> > easily transfer binary entities.  This affects the iSCSI
> > target device's ability to enforce its access control list.
> 
> I'm not sure that having yet another protocol
> and server involved in security administration
> is a "feature", let alone a "requirement".

As I mentioned in my message to Jim, the ability to configure
discovery domains and set up the security policies in a single
step, using one tool, would be useful IMO.  The alternative
is to configure your DHCP server (see above).  Then independently
configure your SRP for iSCSI.

Josh

> 
> 3)  Monitoring of available devices.  SLP relies upon
> service agents re-registering periodically, in order to keep
> the freshness of its database entries.  But this leads to a
> dilemma: if SA's re-register too often, the DA will be
> overwhelmed.  And if they register not often enough, then
> you will have stale device entries.  The fact is, SLP was
> not designed to be a real-time discovery protocol. But in
> storage networks, real-time information is crucial, as even
> slightly out-of-date information can lead to unnecessary
> logins and other events that will seriously degrade the
> performance of the storage network.
> 
> These time periods are measured in minutes,
> which doesn't sound like a scaling issue.
> I'm sceptical that this is actually a problem
> in practice, as something doing failover
> (e.g., cluster software) will tend to have
> its own mechanism to detect failure (e.g.,
> what if the storage fails, but the controller
> is still happily responding to iSNS polls?).
> 
> 4)  State Change Notifications.  This is important to
> support failover and redundancy capabilities, and to
> ensure that initiators can persistently maintain their
> sessions with targets in the event of network topology
> changes.
> 
> On this one, Josh is correct, especially about
> discovery of new targets.  More and more OS's
> can cope with this happening after boot, and
> I believe HP-UX is among them ;-).  Being
> able to hook up a new target and have it
> automatically discovered by the corresponding
> initiators could be very useful.
> 
> This is for further discussion.
> 
> Comments?,
> --David
> 
> ---------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 42 South St., Hopkinton, MA  01748
> +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
> black_david@emc.com       Mobile: +1 (978) 394-7754
> ---------------------------------------------------
>