RE: iSNS scalability

[Joshua Tseng <jtseng@NishanSystems.com>]

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.
> 
> 
> 
>