SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: iSNS scalability



    Hi Ernest,
    
    Thanks for your comments.  I understand your observations
    and conclusions.  This has been a past topic of discussion
    among the coauthors the iSNS implementers we've been working
    with.
    
    Note that the scope of this iSNS document is meant to
    address the interaction between iSNS clients and the iSNS
    server.  Interaction among multiple iSNS servers is
    something to be addressed by future standards work, or by
    individual implementations using proprietary or standards-
    based mechanisms.  Perhaps I need to make that more clear
    about that in the document abstract.  But I understand your
    comments and would be open to addressing them in a separate
    draft.
    
    Comparison with DNS, while interesting and useful, needs to
    take into consideration significant differences between DNS
    and iSNS functionality.  Note the following:
    
    1)  DNS does not support dynamic addition, deletion, or
    updates of records by its clients.  Although zone transfers
    and the distribution of DNS record information is standardized,
    the process of changing and updating of the DNS records
    themselves is done administratively, outside of the DNS
    protocol mechanisms.  That really simplifies the job for DNS.
    For iSNS, dynamic updates of records is an integral part of the
    iSNS protocol.  The heirarchical model works well for DNS
    because database updates only need to flow in one direction--
    down the heirarchy.  With iSNS, updates and notifications will
    need to flow in both directions, because there will be updates
    done by iSNS clients at the lowest levels of the heirarchy.
    
    2)  The concept of authority--Who is authoritative?  In DNS,
    it's very simple.  Since we're only talking about names, the
    authority is imbedded in the name itself.  However, for
    discovery and management of storage devices, the authority is
    not necessarily related to the name, and the name of the device
    may have no relationship to its authority.  And I would be
    reluctant to delegate authority for my storage devices to "root"
    iSNS servers somewhere out there in the Internet.
    
    3)  Security:  DNS has limited control over what information
    is propagated down the heirarchy.  iSNS requires much stricter,
    granular control.
    
    Because of the above and especially because of 2), we felt that
    existing standards-based tools such as LDAP and SNMP would be
    sufficient for now.  Yes, as you point out it requires more
    manual intervention, but the feeling is that this is a GOOD thing
    since most administrators don't want discovery of their storage
    arrays to take place on the Public Internet without their
    knowledge, which is what happens with DNS all the time.
    
    That being said, I would be open to working with anyone interested
    in a new draft specifying interactions among iSNS servers.  If
    anyone is interested, please send me an e-mail.
    
    Josh
     
    > 
    > A major motive for the use of iSNS is to provide scalability 
    > in a storage
    > network. While many of the proposed features of iSNS do 
    > provide this, it
    > falls short in a few areas.
    > 
    > An organization with storage at several locations should have 
    > the option for
    > local management by each site, with an easy method to share 
    > storage between
    > sites. This is also required for sharing resources between 
    > organizations,
    > such as between business partners or between a Storage 
    > Service Provider and
    > customers. 
    > 
    > iSNS (draft 8) addresses this somewhat in Section 3.7, 
    > "Transfer of iSNS
    > Database Records between iSNS Servers". However, the 
    > mechanism suggested for
    > doing this may not be straight forward to automate and may 
    > require manual
    > intervention between sites to keep multiple iSNS servers 
    > synchronized. In
    > addition, since the mechanisms are suggested and not 
    > standardized, there
    > will probably not be a high degree of interoperabilty between 
    > different
    > implementations of iSNS.
    > 
    > The best example of a well-proven, scalable architecture to 
    > address this is
    > the Internet Domain Name Services (DNS). DNS scales from 
    > single-site to
    > multi-site to the global Internet. The key DNS concept 
    > lacking in iSNS is
    > that of local authority (i.e. ownership). With DNS, a site 
    > has authority for
    > its own domains. Requests for information about its domain 
    > are supplied by
    > its own servers (primary or secondary). When a server's 
    > domain name records
    > are modified, its database does not need to be replicated or 
    > synchronized
    > with external DNS servers. 
    > 
    > So, for example, in an organizaton global.com, there might be 
    > subdomains
    > partitioned and managed by different regions of the company, such as
    > us.global.com and europe.global.com. A region can further 
    > partition its
    > domain if desired,  into say london.europe.global.com,
    > rome.europe.global.com, etc. 
    > 
    > The concept of local authority, as used in DNS, could be 
    > applied to iSNS
    > objects such as Storage Nodes and Discovery Domains. That is, 
    > only one iSNS
    > server would maintain authoritative records for a particular object. A
    > hierarchical iSNS with local authority would add significantly to the
    > scalability of IP storage.
    > 
    > 
    > 
    > 
    


Home

Last updated: Mon Mar 25 19:18:10 2002
9295 messages in chronological order