[Federated-fs] Discussion of FSN resolution: what is required vswhat is expected

[Black_David at emc.com]

Dan,

As one of the people who had things to say about this, I think my
primary
concern is that the functionality provided by the NSDB should be
architected
and viewed as a "service" at this stage of the work, so as not to
preclude
distributed name resolution infrastructures, even though the easiest and
most obvious implementation is to just go ask the responsible NSDB for
the
resolution.  We definitely need to allow for multiple name resolution
"services" for the same reason that multiple NSDBs are allowed.

Beyond this, I don't have strong disagreements with most of what Dan
wrote.

Thanks,
--David

> A few points related to FSN resolution came up in the conference call,
so I
> think it's a good idea to discuss the current draft requirements and
> different methods that can satisfy those requirements.
> 
> The first requirement is that an FSN must convey two pieces 
> of information:
> 
> 1. The NSDB that "owns" the information about the FSN.
> 
> 2. The "junction key" that identifies the fileset and is used by the
"owner"
> NSDB as the key for information about that fileset.
> 
> This leads to the simple resolution mechanism outlined in the current
draft:
> to find the FSLs for an FSN, use the FSN to find the NSDB, and then
ask
> the NSDB for the FSLs for the junction key represented by the FSN.
> 
> Given the current requirements and definition, this resolution method
MUST
> work.  However, there is no requirement that this is the resolution
method
> that must be used!  This method is the fallback when all else fails
> (although for a simple implementation, it could be the only method).
> 
> For example, in a clustered system, all servers in the cluster might
funnel
> their requests through a local proxy NSDB that caches the responses
from the
> owner NSDBs.  If two servers request the same resolution within a
short
> period of time, then the first might have to go through to the owner
NSDB,
> but the second could be answered from the cache.  Cache entries would
be
> marked stale and invalidated after a given period of time elapsed.  A
> callback could be registered at the owning NSDB for FSNs of local
interest
> (i.e., the FSNs present in junctions within the section of the
namespace
> implemented by the server), if that turns out to work better than
polling.
> 
> There are many solutions to this kind of problem, but I won't claim to
know
> enough about the parameters of the system -- how many nodes, how fast
the
> FSN bindings change, etc -- to pick the winner.  I don't think we'll
know
> for sure until we actually build one, but we need to make something
flexible
> enough that the real behavior of the system can emerge.  We don't want
> something that admins only use in limited ways because those are the
only
> ways that the system works!
> 
> One solution that doesn't satisfy the current criteria is to use a
> hierarchical system, similar to DNS.  The resolution method starts
with a
> local NSDB (or similar service) and escalates up through the hierarchy
until
> the value is found, and then the results are cached along this path.
The
> problem with this approach is not technical -- we know how to do this.
The
> problem is that I don't see a way to map a hierarchy onto a federation
of
> peers.  The federation member(s) that hosts the root(s) of the
hierarchy
> have an asymmetric relationship with the other members.  Instead of a
> junction being a relationship between two federation members, now
additional
> federation members may be required in order to traverse a junction.
> 
> You may note the arguable contradiction (or hypocrisy) that I am
opposed to
> using intra-federation DNS-like resolution for FSNs, but I am
perfectly
> happy assuming that the system uses DNS to perform many
federation-oriented
> tasks, such as finding NSDBs or naming the servers on which filesets
are
> implemented.  This is because the DNS framework is a superset of any
> federation -- the root servers (and probably most of the ancestors on
the
> way to the root) are independent of and/or outside of the federation.
> 
> Please add your thoughts...
> 
> What do we need to require in order to make a flexible resolution
protocol
> possible?
> 
> Thanks,
>     -Dan
> 
>