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

From: Jon Haswell <[email-masked]>
Date: Wed, 24 Dec 2003 12:17:08 -0800

Brent Callaghan wrote :

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

I agree that LDAP et al are available, tested and deployed and I expect us
to use them as the underlying infrastructure for the global namespace. What
I am arguing against is allowing the NFS clients (and by extension other
filesystem clients) direct access to them. I want to see the NFS servers
accessing them and acting as proxies for passing this information to the
NFS clients. The reason for doing this is so the NFS servers can act as
smart proxies and manipulate this data, if they so desire, prior to it
being received by the NFS clients.

When trying to optimize a clustered NFS server as part of a larger global
namespace the NFS servers may choose to move clients between nodes in the
cluster on the fly, present different location information to different
clients etc. I do not want to have to push this type of dynamic, on the
fly, changes to far up the global namespace - in particular I don't see how
we could easily have different views of the namespace presented to
different clients simulateneously via LDAP or the like.

I absolutely agree with you in that we should avoid at all costs trying to
recreate LDAP or the like within V4, I am only arguing for the V4 clients
to only access this data via the V4 server using the already established V4
protocol (with minor corrections to the bits of it that may be broken).

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

I agree that it can work as you describe, in this case I am saying it is
simpler to coordinate, in all error situations etc, if the clients are
getting their information from one level in the hierarchy, as opposed to
some getting NFS V4 referrals and some going direct to the namespace
servers.

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

I'm not sure how manadating NFS clients obtain their namespace information
via the NSF V4 protocol breaks any of the other protocols. Yes if data
movement is going to happen then all supported protocols are going to need
to handle this movement either by redirection or by proxy methods for
support of legacy or little used protocols.

We typically find that any one machine/cluster/data set is predominently
accessed by a single protocol and we will frequently only load balance for
that protocol and leave all other protocols on a single node etc, i.e. for
the non-domin ant protocol we provide access but not performance.

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

Firstly I agree with the dumbest clients statement, hence unless there is a
really good reason why complicate a spec by defining or allowing a more
sophisticated client that will not be implemented. With regard to
transparent switching solutions for V2/V3 I do not like the current
transparent solutions, and I'm thinking virtualization boxes here, and want
to avoid them for V4

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

To do this requires a front end node that can switch the traffic between
backend nodes. This is inherently more expensive than a cluster that
exports the IP addresses of all it's nodes and directs the clients between
them. While this may not seem as clean it is far more scalable and
virtually as easily managed once the initial IP addresses are assigned.

Jon Haswell
IBM Research
Tel 408 927 2074 Tie 457 2074
Fax 408 927 3030 Tie 457 3030

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

---

From: Julian Satran <[email-masked]>
Date: Thu, 25 Dec 2003 11:38:38 +0200

To all the good arguments made for using a (presumably virtually-single) 
an existing name service is that it will help preserve (and enforce) a 
single view of the global name-space.
Referals while very light will not do that.

If this group can agree on this item the Jon's (valid) concern about who 
should access it can be discussed separately.

Julo

Jon Haswell <[email-masked]> 
Sent by: [email-masked]
24/12/2003 22:17

To
[email-masked]
cc

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

already
nice

to use them as the underlying infrastructure for the global namespace. 
What

fly, changes to far up the global namespace - in particular I don't see 
how

I absolutely agree with you in that we should avoid at all costs trying to
recreate LDAP or the like within V4, I am only arguing for the V4 clients
to only access this data via the V4 server using the already established 
V4
protocol (with minor corrections to the bits of it that may be broken).

transparent
specific
>solution - even if it's "better".

Firstly I agree with the dumbest clients statement, hence unless there is 
a
really good reason why complicate a spec by defining or allowing a more
sophisticated client that will not be implemented. With regard to
transparent switching solutions for V2/V3 I do not like the current
transparent solutions, and I'm thinking virtualization boxes here, and 
want
to avoid them for V4

single,
making

Jon Haswell
IBM Research