Subject: [nfsv4] draft-fan-nfsv4-global-namespace-problem-statement-00.txt

From: Charles Fan <[email-masked]>
Date: Thu, 24 Mar 2005 14:14:33 -0800

Hi,

Please find attached an Internet Draft by Dave Noveck, Mario Wurzl and 
me about NFSv4 global namespace problem statement.  We submitted it to 
the Internet-Draft directory today.

Thanks,
Charles

INTERNET-DRAFT                                       C. Charles Fan
Expires: September 2005                                  Rainfinity

                                                        Dave Noveck
                                                  Network Appliance

                                                        Mario Wurzl
                                                                EMC

                                                         March 2005

                NFSv4 Global Namespace Problem Statement
       draft-fan-nfsv4-global-namespace-problem-statement-00.txt

Status of this Memo

     By submitting this Internet-Draft, I certify that any applicable
     patent or other IPR claims of which I am aware have been disclosed,
     or will be disclosed, and any of which I become aware will be
     disclosed, in accordance with RFC 3668.

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF), its areas, and its working groups.  Note that
     other groups may also distribute working documents as Internet-
     Drafts.

     Internet-Drafts are draft documents valid for a maximum of six
     months and may be updated, replaced, or obsoleted by other
     documents at any time.  It is inappropriate to use Internet-Drafts
     as reference material or to cite them other than as "work in
     progress."

     The list of current Internet-Drafts can be accessed at
     http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-
     Draft Shadow Directories can be accessed at
     http://www.ietf.org/shadow.html.

Copyright Notice

     Copyright (C) The Internet Society (2004).  All Rights Reserved.

Abstract

     NFS is one of the primary data access protocols for NAS, and
     naturally NFS users have been demanding a global namespace for NFS.
     This document intends to explain the rational for a global
     namespace, why it is an important feature for a network file system

Fan, Noveck, Wurzl       Expires September 2005                 [Page 1]

Internet Draft     Global Namespace Problem Statement         March 2005

     protocol, and the problems that a global namespace for files would
     solve.

Table of Contents

     1.    Introduction . . . . . . . . . . . . . . . . . . . . . . 2
     2.    The Applications . . . . . . . . . . . . . . . . . . . . 3
     3.    The Requirements . . . . . . . . . . . . . . . . . . . . 4
     4.    NFSv4 Global Namespace . . . . . . . . . . . . . . . . . 7
     5.    Suggested Approach . . . . . . . . . . . . . . . . . . . 7
           Acknowledgements . . . . . . . . . . . . . . . . . . . . 8
           Normative References . . . . . . . . . . . . . . . . . . 8
           Informative References . . . . . . . . . . . . . . . . . 8
           Author's Address . . . . . . . . . . . . . . . . . . . . 9
           Full Copyright Statement . . . . . . . . . . . . . . . . 9

1. Introduction

     During recent years, the range and complexity of Network Attached
     Storage (NAS) deployments has increased greatly.  Such trends as
     grid computing, virtualization, and information lifecycle
     management have helped to drive these wider, more complex
     deployments.  As a result, the need for tools to allow more
     manageable interaction with these more complex uses of NAS
     technology has brought forth a new set of requirements for what NAS
     users need to have in their environments.  A global namespace for
     files has emerged as one common requirement from NAS users.

     NFS is one of the primary data access protocols for NAS, and
     naturally NFS users have been demanding a global namespace for NFS.
     [Thurlow]  This document intends to explain the rationale for a
     global namespace, why it is an important feature for a network file
     system protocol, and the problems that a global namespace for files
     would solve.

     Fundamentally, how a network file-system object is named for access
     should be independent of where it is placed for storage.  A global
     namespace is a logical organization of files-system objects for
     user access.  Users expect it to be uniform, location independent,
     transparent to location changes, and is typically hierarchical.
     The creators and owners of file-system objects are the ones who
     decide how these objects should be named and where they should be
     found for access within the hierarchy of the global namespace.

     On the other hand, administrators are the ones to decide where the
     files should be physically stored.  In a large enterprise storage

Fan, Noveck, Wurzl       Expires September 2005                 [Page 2]

Internet Draft     Global Namespace Problem Statement         March 2005

     environment, there are a large number of NAS storage nodes, often
     distributed among multiple geographical sites.  The files may be
     distributed across the enterprise to satisfy a number of different
     goals including optimizing cost, optimizing performance and
     providing greater convenience of access and greater availability of
     the NAS data.

     A global namespace provides a unified view for data access,
     independent of where data is physically placed.  This namespace
     consists of mappings between names in the namespace and their
     corresponding physical locations, and acts as a road map to guide
     users to the locations of the data they seek.  This namespace is
     uniform and consistent for all users who access the data, and its
     presentation to the clients remains the same even when mappings
     change.

2. The Applications

     This section lists a few applications that would benefit from a
     global namespace.

2.1 NAS Storage Virtualization

     As NAS storage infrastructure scales up, each data site may house a
     large number of NAS storage units in a data center, and it is
     common to have multiple data centers in an enterprise.  It is
     desired that the data stored by these NAS units be managed as a
     single coherent space, rather than as a large number of disjoint
     data islands.

     A global namespace is an important enabler for NAS storage
     virtualization.  It provides a single-system view for data access
     into the enterprise-wide NAS storage.  A global namespace is
     desired to be re-configurable online: when the physical location of
     some data changes, the global namespace mapping is updated and
     users continue accessing the data without being interrupted.  With
     a global namespace in place, a virtualization solution can
     dynamically balance capacities among the physical NAS units behind
     the scenes, without affecting any of the user access.

2.2 Replication for Load Balancing & Grid Computing

     Storage grid is an integral part of any grid computing
     architecture.  A well-designed global namespace is a necessary
     component in creating a storage grid using NAS.  Multiple data
     replicas can be created, and the global namespace will be able to
     transparently guide clients to the appropriate replica based on

Fan, Noveck, Wurzl       Expires September 2005                 [Page 3]

Internet Draft     Global Namespace Problem Statement         March 2005

     load, distance, and access requirement (read or write).  This would
     effectively multiply the throughput capabilities of a storage grid,
     transparently to the users and applications.

2.3 Transparent Migration

     A similar benefit applies to migration.  A global namespace can
     keep the data presentation to the users and applications constant,
     while updating the mapping to the new location after the migration
     is complete.  This avoids the disruptive post-migration unmount and
     re-mount, while allowing the clients to find the right location for
     the requested data.

     Not only will this benefit one-time migration when users
     consolidate or upgrade storage equipment, but also make possible
     dynamic capacity balancing or hierarchical storage management
     applications that frequently move the data.

2.4 Transparent Fail-over

     With a global namespace, a high availability solution can handle
     the case where the backup node does not fully assume the identity
     of the primary node.  The global namespace gracefully points the
     clients to the new location of the data, and makes the fail-over a
     more transparent experience for the end-users and applications.

     This capability can be applied to online storage management as
     well.  Without a failure, global namespace facilities can be used
     to point the clients to another server, while this server is being
     serviced.  After the service is completed, the clients can then be
     redirected back.  The existence of a global namespace greatly helps
     reducing downtime during a normal storage management process.

2.5 Information Lifecycle Management

     As data go through different phases in their lifecycle, their
     storage requirements change.  An ILM solution optimizes the storage
     for the data according to the phase of their lifecycle.  A global
     namespace provides a way to guide clients to the appropriate
     physical locations of the data at the time, without the use of
     stubs on the file storage themselves.

3. The Requirements

     There are at least three different kinds of namespaces that have
     been referred to as global namespace for file storage:

Fan, Noveck, Wurzl       Expires September 2005                 [Page 4]

Internet Draft     Global Namespace Problem Statement         March 2005

     1    Intra-cluster namespace.  This is the unified namespace for a
          set of NAS servers in a tightly-coupled or aggregated cluster.
          People refer to it as "global" namespaces, as opposed to the
          "local" namespace of each node in the cluster.  Many propri-
          etary intra-cluster namespace schemes exist today as part of
          single-vendor solutions.

     2    Enterprise namespace.  This is the most requested form of
          "global namespace" by enterprise storage administrators.  An
          enterprise namespace provides a uniform view into network file
          storage for an entire enterprise.

     3    World-wide namespace.  This makes possible the "world-wide
          file storage", with a global URL to each file.  This could be
          achieved by an extension of the enterprise namespace scheme.

     This draft focuses on the enterprise namespace.  Enterprise file
     storage environment will continue to grow and continue to be het-
     erogeneous.  Standardization supports interoperability between dif-
     ferent vendors, and having a standards-based namespace solution for
     NFSv4 will help the wide adoption of the protocol.

     What are the requirements for an enterprise-wide namespace?  Here
     is a list of fundamental requirements:

     -    Location Independence: The namespace tree should be structured
          to reflect organizational or logical associations, independent
          of the physical location of the data.  This implies that there
          needs to be some sort of location table that serves to link
          the logical namespace and the physical locations.

     -    Uniformity of View: There should be a single location table of
          the namespace that all agree is authoritative.  This implies
          the existence of a root server and/or central repository for
          an enterprise domain, but does not imply that each client must
          mount into this unified namespace in the same way.

     -    Transparency: It is desired that when the physical location of
          the data changes due to administrative reasons, for example by
          migration or replication, the namespace presented to the
          client applications remain constant.  The update of the names-
          pace map entry can be achieved transparently to the clients.
          The client applications continue running, namespace remain
          constant, while the data is now from a different physical
          location.

Fan, Noveck, Wurzl       Expires September 2005                 [Page 5]

Internet Draft     Global Namespace Problem Statement         March 2005

     -    Security: The deployment of a namespace solution must not com-
          promise the security of data access.

     In addition to the above requirements, we must ask the following
     questions as well:

     -    Granularity of namespace mapping: Whether the namespace map-
          ping can happen at the file system granularity, or directory
          granularity, or file granularity, or sub-file granularity?

     -    Hierarchical Mapping: Is it possible for namespace entry /a/b
          to link to file server A, while /a/b/c to link to file server
          B?

     -    Variable Support: Depending on variables such as client OS,
          client geographical location, or time-of-day, can the names-
          pace mapping be different?  This is highly desired in many
          customer environments.

     -    Manageability.  Can the namespace be accessed and modified
          real-time by administrators? by applications? by user groups?
          How fast does a namespace mapping change propagate to all
          clients?

     -    Cycle Prevention.  Will the namespace tree be guaranteed to be
          acyclic?

     -    Multi-protocol Interoperability.  Will NFSv2 and v3 clients be
          able to use this same namespace?  Will this namespace be syn-
          chronized with the CIFS namespace?

     -    A viable global namespace solution will need to be location
          independent, unified, transparent and secure.  We should also
          consider additional user requirements to make sure we have a
          solution that addresses the needs of enterprise storage admin-
          istrators.

4. NFSv4 Global Namespace

     For NFS v2/v3 environments, the most popular namespace solution
     implemented is automounter daemon with automounter maps centrally
     managed at NIS server or LDAP server.  The popularity of this solu-
     tion shows that it addresses some of the namespace requirements
     outlined.  In particular, it supports the "location independence"
     requirement at export granularity, the "uniformity of view"
     requirement and the "security" requirement.  In addition, it

Fan, Noveck, Wurzl       Expires September 2005                 [Page 6]

Internet Draft     Global Namespace Problem Statement         March 2005

     supports hierarchical mapping and wildcard variables.  Because
     there is no server to server redirect, there is no cycle issues
     here either.

     So why do some NFS enterprise users still ask for a "global names-
     pace"?  What is lacking in an automounter-based solution?  First,
     the update of the automounter map is not completely transparent.
     Clients which have applications running and keeping the old mount
     active will not let go the old mount.  For some versions of some
     OS's, even after the mount become inactive, the old mount still
     won't be released.  Dealing with the varieties of client OS's and
     versions, this is a difficult problem to completely solve.

     Secondly the granularity of this solution is at the export level.
     For some of the above mentioned applications that require a global
     namespace, such as Load Balancing and ILM applications, finer gran-
     ularity (directory, file, and sub-file) is desired.

     In addition, some administrators have had experiences with the
     global namespace solution from other network file access protocols,
     such as CIFS and AFS.  CIFS includes specification of Dfs links
     that supports the deployment of Dfsroot namespace server.  AFS can
     dynamically map its volumes to different physical locations by the
     use of Volume Location Database (VLDB).  They desire comparable
     functionality be available in NFSv4.

     RFC3530 [RFC3530] specifies basic functionality useful for imple-
     menting an NFSv4 global namespace, either by using solely the
     facilities within RFC3530, or by augmenting them through features
     to be added in a minor version.

5. Suggested Approach

     First, we could choose a central repository, such as LDAP, for the
     namespace mappings.  We can work to define a standard schema for
     the NFS namespace mappings.  This work is not part of the NFSv4
     protocol itself, but it is reasonable for us to address it for the
     specific case of NFS namespace.  We should define well how servers
     and clients can access this central repository, and how it should
     support not only NFSv4, but v3 and v2 clients as well.

     Second, we need to clarify the client-server interactions based on
     RFC 3530.  This work is already under way, with both implementation
     and suggestions for errata for RFC 3530.  Both the migration case
     and the pure referral case need to be fully considered. [Noveck]
     The security issues should also be considered that the proposed
     scheme doesn't compromise existing level of security.  The hope is

Fan, Noveck, Wurzl       Expires September 2005                 [Page 7]

Internet Draft     Global Namespace Problem Statement         March 2005

     that this challenge will be overcome, and we'll be able to have the
     first client, server and namespace server reference implementation
     of the basic use of the NFS4ERR_MOVED and fs_location.

     Third, we should define a mechanism with which clients in the
     enterprise know where to find the root for the NFS enterprise
     namespace.  One simple solution is to leverage the DNS domain, and
     set up a convention that the DNS name nfsroot always corresponds to
     the root namespace server.  The root namespace server can refer
     clients to other namespace servers.  Schemes should be designed to
     enforce that the relationship between namespace servers is hierar-
     chical and not cyclical.  This scheme can be extended to support
     world-wide NFS namespace as well.

     Next, with NFSv4.x clients accessing the namespace through the
     namespace server via NFS protocol, it is then possible to enhance
     the protocol in the form of minor versions to support better trans-
     parency and finer granularity and better manageability.  Possible
     enhancements in 4.x that may worth some discussion include file-
     level referrals, lifetime on file handles, additional client-server
     exchange of variable values, etc.

Acknowledgements

     The authors would like to thank Andy Adamson, Ted Anderson and
     Robert Thurlow for their helpful comments on the draft.

Normative References

     [RFC3530]
          S. Shepler, et. al., "NFS Version 4 Protocol", Standards Track
          RFC

Informative References

     [Noveck]
          D. Noveck, C. Burnett, "Implementation Guide for Referrals in
          NFSv4", IETF Internet Draft, draft-noveck-nfsv4-refer-
          rals-00.txt

     [Thurlow]
          R. Thurlow, "A Namespace For NFS Version 4", IETF Internet
          Draft, draft-thurlow-nfsv4-namespace-00.txt

Author's Address

Fan, Noveck, Wurzl       Expires September 2005                 [Page 8]

Internet Draft     Global Namespace Problem Statement         March 2005

     C. Charles Fan
     Rainfinity
     2740 Zanker Road
     San Jose, CA 95134  USA

     Phone: +1 408 382 4755
     EMail: [email-masked]

Full Copyright Statement

     Copyright (C) The Internet Society (2004).  This document is sub-
     ject to the rights, licenses and restrictions contained in BCP 78
     and except as set forth therein, the authors retain all their
     rights.

     This document and the information contained herein are provided on
     an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REP-
     RESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
     INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
     IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
     THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
     WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

     The IETF takes no position regarding the validity or scope of any
     Intellectual Property Rights or other rights that might be claimed
     to pertain to the implementation or use of the technology described
     in this document or the extent to which any license under such
     rights might or might not be available; nor does it represent that
     it has made any independent effort to identify any such rights.
     Information on the procedures with respect to rights in RFC docu-
     ments can be found in BCP 78 and BCP 79.

     Copies of IPR disclosures made to the IETF Secretariat and any
     assurances of licenses to be made available, or the result of an
     attempt made to obtain a general license or permission for the use
     of such proprietary rights by implementers or users of this speci-
     fication can be obtained from the IETF on-line IPR repository at
     http://www.ietf.org/ipr.

     The IETF invites any interested party to bring to its attention any
     copyrights, patents or patent applications, or other proprietary
     rights that may cover technology that may be required to implement
     this standard.  Please address the information to the IETF at ietf-
     [email-masked].

Fan, Noveck, Wurzl       Expires September 2005                 [Page 9]

Internet Draft     Global Namespace Problem Statement         March 2005

Acknowledgement

     Funding for the RFC Editor function is currently provided by the
     Internet Society.

Fan, Noveck, Wurzl       Expires September 2005                [Page 10]

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: Aditya Pandit <[email-masked]>
Date: Wed, 30 Mar 2005 19:03:52 +0530

Hi,

Please find the updated version of 
draft-pandit-nfs-2-3-4-local-minor-interop-01.txt in internet-Draft 
directory.

URL:
http://www.ietf.org/internet-drafts/draft-pandit-nfs-2-3-4-local-minor-interop-01.txt

We have updated this draft with comments given by Garth Gibson and Benny 
Halevy. We are extremely thankful to both of them. 

Thanks,
Aditya and Sujay

---

From: Craig Everhart <[email-masked]>
Date: Wed, 30 Mar 2005 14:19:01 -0800

Hi.  I won't re-send the whole draft, but here are some comments.

(a) In 2.2, you mention that the global namespace will guide clients to the
correct replica based on read vs. write considerations.  I think this is
pretty tough or maybe impossible.  Posix applications aren't now expressing
whether they need R/W access at the beginning of transactions, so they
might read one file and write another, requiring the most up-to-date
version of data for the reading case.  It would be incorrect for the FS to
direct the initial "read" part of the transaction to a R/O replica, unless
there's some magic by which the R/O replicas are up to date with respect to
the R/W instance of the data.  So I think that other mechanisms will be
necessary to deal with choosing R/W data vs. allowing a somewhat outdated,
but available, R/O replica to be used.  In this draft, I'd just omit the
"access requirement" clause in 2.2.

(b) In 3, your second requirement for Uniformity of View.  Yes, there
should be an agreed-on view and an agreed-on authoritative procedure for
determining the global name space.  But I think it's misleading and
constraining to say that the authoritative data for the namespace needs to
be in a table.  It could just as easily, or perhaps better, be in the
"smart server" model, where it doesn't really matter where the smart server
gets its information.  I'm all for the agreed-on root server--but actually
that root server should really be multiple.  See (d) below...

(c) In 5, what "namespace mappings"?  I guess I don't understand what kind
of schema you have in mind.  Does it duplicate paths that are also in file
systems?  (Why?)

(d) In 5, "Third," yes, "nfsroot" is an OK idea.  But I'm partial to the
RFC 1183 idea of building on an "AFSDB" subtype, so that multiple servers
can naturally be returned as the root for the filesystem for a given
organization.  That is, suppose an organization abc.org replicates its root
file system to four replica servers.  It creates four AFSDB RRs in the DNS
zone for abc.org, each pointing to a different replica server.  AFSDB comes
with subtypes, and it would be perfectly reasonable to assign a given
subtype (e.g., 3) to use by NFSv4.  Possibly the "nfsroot" convention has
the same kinds of advantages, since there can be multiple A/AAAA records
for a given name, as long as the convention is that the name doesn't
correspond to just one server, but rather to a list of addresses, any of
which can be used at the client's preference.

But what is meant here by "root namespace server"?  Is this just an NFSv4
server, exporting files and directories and referrals to other servers?  Or
is some actual "namespace" protocol envisioned here?  Which one is actually
necessary?

            Craig

Craig Everhart
+1 919 543 2169

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 30 Mar 2005 17:04:24 -0600

> "access requirement" clause in 2.2.

I second this.

> that root server should really be multiple.  See (d) below...

And this.  Further, I think that namespace delegation from the "global
root" should be based on DNS -- look for per-domain NFS namespace root
from the top on down (from '.', through TLDs, and so on; neither '.' not
TLDs should actually have NFS namespace roots nor servers for them).

> which can be used at the client's preference.

I think we should use SRV RRs.  There is precedent for this; for
example, Kerberos V KDCs can be found through SRC RRs.

Note that looking for NFS root servers in this way has security
implications.  If you're not using DNSSEC then you need to use
domain-based service principal names for the NFS servers (well, if
you're interested in using RPCSEC_GSS).

> is some actual "namespace" protocol envisioned here?  Which one is actually

That is my view.  An NFSv4 namespace root server is just an NFSv4 server
using referrals to delegate sub-namespaces to other servers.

Cheers,

Nico
--

---

From: Chenggong Fan <[email-masked]>
Date: Thu, 31 Mar 2005 19:17:35 -0800

Hi Craig,

Thank you for the comments.  My comments below:

Craig Everhart wrote:
> (a) In 2.2, you mention that the global namespace will guide clients to 
> the correct replica based on read vs. write considerations. I think this 
> is pretty tough or maybe impossible. Posix applications aren't now 
> expressing whether they need R/W access at the beginning of 
> transactions, so they might read one file and write another, requiring 
> the most up-to-date version of data for the reading case. It would be 
> incorrect for the FS to direct the initial "read" part of the 
> transaction to a R/O replica, unless there's some magic by which the R/O 
> replicas are up to date with respect to the R/W instance of the data. So 
> I think that other mechanisms will be necessary to deal with choosing 
> R/W data vs. allowing a somewhat outdated, but available, R/O replica to 
> be used. In this draft, I'd just omit the "access requirement" clause in 
> 2.2.

I agree.  We'll omit it in the next revision.

> constraining to say that the authoritative data for the namespace needs 
> to be in a table. It could just as easily, or perhaps better, be in the 
> "smart server" model, where it doesn't really matter where the smart 
> server gets its information. I'm all for the agreed-on root server--but 
> actually that root server should really be multiple. See (d) below...

What I meant by the "location table" is the collection of mappings 
between the logical nodes in the namespace to the physical location (or 
locations).  What better wording do you suggest?

> (c) In 5, what "namespace mappings"? I guess I don't understand what 
> kind of schema you have in mind. Does it duplicate paths that are also 
> in file systems? (Why?)

The namespace mappings are referred to the abstraction between the 
logical namespace and physical locations.  We call for a standard schema 
to capture these mappings.

> RFC 1183 idea of building on an "AFSDB" subtype, so that multiple 
> servers can naturally be returned as the root for the filesystem for a 
> given organization. That is, suppose an organization abc.org replicates 
> its root file system to four replica servers. It creates four AFSDB RRs 
> in the DNS zone for abc.org, each pointing to a different replica 
> server. AFSDB comes with subtypes, and it would be perfectly reasonable 
> to assign a given subtype (e.g., 3) to use by NFSv4. Possibly the 
> "nfsroot" convention has the same kinds of advantages, since there can 
> be multiple A/AAAA records for a given name, as long as the convention 
> is that the name doesn't correspond to just one server, but rather to a 
> list of addresses, any of which can be used at the client's preference.

I agree that the name can correspond to multiple addresses.

> server, exporting files and directories and referrals to other servers? 
> Or is some actual "namespace" protocol envisioned here? Which one is 
> actually necessary?

Yes it is just an NFSv4 server that uses referrals to delegate 
sub-namespaces to other servers.

Thanks,
Charles