SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    RE: iSCSI: target discovery issue



    Joshua,
    
    Although being generic, it can also provide directory based privileges.  The
    various requests structures can also provide tailored responses.  Not to
    dwell on what has become a sensitive subject, there are alternatives to
    signaling other than that proposed by iSNS.  It seems a signaling method
    from IP based SCSI servers for informing clients of a need to check
    configuration would be far more useful with respect to scaling this
    architecture.
    
    Clients would naturally already have persistent connections to these servers
    greatly reducing the number of connections involved.  Signaling a change to
    affected servers can be handled through any number of IPCs especially if
    this number is within the realm of a few dozen servers and not thousands of
    clients.  The SCSI server should be able to filter these signals adequately
    based on common knowledge shared between server and client.  One other
    principle area of concern comes from the need of creating this global name
    space without a means of promulgating information across vendors.
    
    The signaling already present for Fibre-Channel switches and controller may
    need agents adopted for IP, but I would not be surprised if this already
    exists and most of the tools for managing this equipment already share these
    popular interfaces.  Signaling a change and distributing information should
    be two separate functions.  Distributing information is easily handled by
    generic servers.  A SAN should not be flapping at such a rate to mandate
    specialized persistent connections to each and every client nor high levels
    of overhead for servers to inform their clients if they find they were
    affected the a resent update.  Each server must manage their own domain and
    informing clients of a change seems like such a small matter.  This should
    not justify adding a name server for this purpose.
    
    Doug
    
    > If LDAP is what you are talking about, please see my previous notes
    > to Doug Otis regarding how LDAP is basically a generic directory service
    > that passively stores information deposited by clients, without any
    > regard to what that information is used for.  iSNS is also a protocol,
    > but since it is tailored to storage, it can interpret information
    > registered by clients, and take appropriate action.  That isn't to
    > say LDAP can't be used to accomplish some of the discovery and management
    > functions that iSNS has, but because iSNS has state-consciousness of
    > its client storage devices, it has more capabilities than a basic LDAP
    > server would have in managing storage devices.  David has already invited
    > anyone interested to write a draft on how LDAP can be used, and I would
    > be equally interested.  If you or someone else would oblige, then we
    > would have a "method E" of discovery iSCSI devices.
    >
    > Finally, I would like to note that iSNS capabilities are modeled on
    > those provided by T11's FC-GS-3.  Presumably, these capabilities are
    > based upon real-life lessons learned by the Fibre Channel community in
    > managing and operating large enterprise-class storage networks.  I like
    > to think that we are incorporating the fruit of those lessons into iSNS.
    > We looked at LDAP--we really did--to see if it could provide comparable
    > FC-GS-3 services in the IP domain.  But there are shortcomings which
    > forced us to create the iSNS protocol.  These shortcomings are documented
    > in the iSNS document.
    >
    > >
    > > Typically users register/login to distributed resource management pts
    > > (domain servers) and these applications handle authentication,
    > > authorization, and assignment of resources.  John makes
    > > important points in
    > > his email - you don't want all users informed of new storage
    > > coming on line,
    > > those systems that are intended to have access should be
    > > notified, or should
    > > explicitly "mount" the new storage.  It's not appropriate to
    > > burden each
    > > storage device with this task, it is definitely a value add feature
    > > appropriate to a centralized resource management application.
    >
    > Yes, this is where iSNS with the discovery domain feature provides
    > significant value in a large storage network.
    >
    > Regards,
    > Josh
    
    


Home

Last updated: Tue Sep 04 01:04:58 2001
6315 messages in chronological order