Re: [nfsv4] Global namespace for v4.1?

brent@eng.sun.com

Message-ID: <3FE9E5F9.8050302@eng.sun.com>
From: Brent Callaghan <brent@eng.sun.com>
Subject: Re: [nfsv4] Global namespace for v4.1?
Date: Wed, 24 Dec 2003 11:16:09 -0800

Jon Haswell wrote:
> Brent Callaghan wrote :
> 
>>You may be reading too much into this.  My interpretation is simply
>>that a global namespace that depends on v4 referrals will force
>>customers to install a network of v4 referral servers to provide
>>access to their established base of v2/v3 servers.
> 
> 
> Well my reaction is that clients should not be allowed to interrogate the
> name service directly. Let me explain why I don't believe forcing the
> client to use the NFS V4 protocol is an issue and why I believe it is
> advisable to have the client constrained in this manner.
> 
> Firstly, unless I have missed something, we haven't yet determined what the
> protocol to the namespace server will be. We might choose to use LDAP for
> the namespace server and to define a schema for it that we will be
> querying, or it might be something else. Whatever it is however the
> combination of the protocol+schema will be new and have to be 'installed'.
> If an organization is upgrading from v2/v3 to a global namespace I believe
> that will be a major transition for them and they will have to install a
> set of namespace referral servers, why is it a bigger issue if they talk
> NFS V4 as opposed to LDAP+schema ?

Yes, a new global namespace will have to be installed.  It's easier just
to install it just on the clients - than on both clients and servers.

Keep in mind that name services like LDAP, Active Directory etc are already
widely deployed, have published APIs and libraries, trained admins and nice
administrative tools.  With an NFSv4 based referral service, you'd have to
start from scratch.

> Secondly as to why I believe we should have the clients constrained. Once
> we have established our global namespace and defined how data migration and
> replication is going to work we are going to need management agents that
> will migrate and replicate data and manage all the components in the system
> to make this seamless and reliable. If we have the clients independantly
> contacting the backend namespace server then we have to ensure we keep this
> in sync with the data movement occuring between the servers. While it is
> not a disaster if clients are going to the wrong server during transitions,
> due to skew between the NFS servers and the namespace it is undesirable -
> as I write this I expect somebody to be saying, but he is thinking that the
> namespace referrel is on the data servers and in big installations that
> won't be the case. I agree with this but my point is that I won't to be
> able to design smaller more compact systems where the referrels are
> happening on the data servers and to be able to rely on clients not going
> behind my back).

I don't understand your reasoning.  Data movement between NFS servers
may not use the NFS protocol at all.  A data movement tool can just
as easily make namespace changes with a back-end namespace server
as it can with a network of NFSv4 referral servers.  As long as the
data movement and namespace update steps are done in the right order,
there needn't be a sync problem.

Keep in mind that the market doesn't sell "NFS Servers" - they're
muli-protocol NAS servers that handle a variety of file access
protocols: most notably NFS v2/v3, CIFS, AFP, Netware, FTP, HTTP etc
Any cross server movement of data must take into account all these
other access methods - not just NFSv4 clients.

> My final point on this topic is that even if we do define a protocol where
> clients are allowed to access a namespace server directly we should have a
> way for an NFS server to tell them to stop doing this, either temporarily
> or permanently. Hence if the server knows it is going to get out of sync
> with the namespace for some period of time, say when it is internally
> moving things around in some closely coupled cluster, it can force the
> colients to come through it, Perhaps think of using a form of delegation
> that allows clients to go to a global namespace, but which can be revoked
> by a server.

Again, as long as the data movement steps are done in the right order,
there should be no issue with getting out of sync with the namespace.
The time to move data >> time to update the namespace.

 > <snip>
> I really would like to avoid having to try and represent this type of
> dynamic and client specific location information from an LDAP schema or the
> like and be able to force the clients, at least in this case, to get their
> namespace information from the NFS server directly, even when this NFS
> server cluster is also part of a larger global namespace, i.e. I want to be
> able to use the NFS servers as a filter on the view of the global namespace
> stored in LDAP or wherever.

My guess is that NAS cluster vendors will continue to design for multiple
protocols and assume the dumbest clients.  If you already have a transparent
solution for switching v2/v3 and CIFS clients from node to node, then it's
easier to extend the same solution to v4 clients, rather than build v4 specific
solution - even if it's "better".

I'd expect an NFS cluster to advertise itself, and be administered as a single,
virtual NFS server, i.e. the cluster will likely load balance without making
any changes to the name service or the perceived location of the data.

	Brent

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4