RE: iSNS scalability

[Joshua Tseng <jtseng@NishanSystems.com>]

Sukanta,

I hope my previous message addressed your question.
In a nutshell, information in iSNS is dynamic and
not persistent.  While DNS is more or less a static
database, iSNS information can be dynamically updated
by client devices.  The approach you suggested would
require the storage administrator to call the DNS
admin to add or change the RR whenever a storage
device is added, removed, or re-zoned.  My experience
in working with IT departments is that network and
storage admins don't talk very often, if at all, so
I don't think this is a very promising approach.

Josh

> -----Original Message-----
> From: Sukanta ganguly [mailto:sganguly@yahoo.com]
> Sent: Monday, March 25, 2002 11:03 AM
> To: Ernest Dainow; 'Joshua Tseng'
> Cc: ips@ece.cmu.edu
> Subject: Re: iSNS scalability
> 
> 
> Hi All,
>   Since so much of DNS like features are required in
> the iSNS, wouldn't it be better the to add this as a
> new RR in the DNS server itself. The near-persistent
> data can stay in the DNS server, i.e in BIND database.
>   The iSNS client processing can be defined in the
> iSNS spec and the server can be dissolved.
>   What do you guys think ?
> 
> SG
> 
> --- Ernest Dainow <Ernest.Dainow@mcdata.com> wrote:
> > 
> > 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.
> > 
> > 
> > 
> > 
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Movies - coverage of the 74th Academy Awards®
> http://movies.yahoo.com/
>