gluster-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gluster-devel] ZkFarmer


From: Anand Avati
Subject: Re: [Gluster-devel] ZkFarmer
Date: Tue, 8 May 2012 17:57:49 -0700



On Tue, May 8, 2012 at 4:08 PM, Ian Latter <address@hidden> wrote:
> On 05/08/2012 12:27 AM, Ian Latter wrote:
> > The equivalent configuration in a glusterd world (from
> > my experiments) pushed all of the distribute knowledge
> > out to the client and I haven't had a response as to how
> > to add a replicate on distributed volumes in this model,
> > so I've lost replicate.
>
> This doesn't seem to be a problem with replicate-first vs.
distribute-first,
> but with client-side vs. server-side deployment of those
translators.  You
> *can* construct your own volfiles that do these things on
the servers.  It will
> work, but you won't get a lot of support for it.  The
issue here is that we
> have only a finite number of developers, and a
near-infinite number of
> configurations.  We can't properly qualify everything.
One way we've tried to
> limit that space is by preferring distribute over
replicate, because replicate
> does a better job of shielding distribute from brick
failures than vice versa.
> Another is to deploy both on the clients, following the
scalability rule of
> pushing effort to the most numerous components.  The code
can support other
> arrangements, but the people might not.

Sure, I have my own vol files that do (did) what I wanted
and I was supporting myself (and users); the question
(and the point) is what is the GlusterFS *intent*?

The "intent" (more or less - I hate to use the word as it can imply a commitment to what I am about to say, but there isn't one) is to keep the bricks (server process) dumb and have the intelligence on the client side. This is a "rough goal". There are cases where replication on the server side is inevitable (in the case of NFS access) but we keep the software architecture undisturbed by running a client process on the server machine to achieve it.

We do plan to support "replication on the server" in the future while still retaining the existing software architecture as much as possible. This is particularly useful in Hadoop environment where the jobs expect write performance of a single copy and expect copy to happen in the background. We have the proactive self-heal daemon running on the server machines now (which again is a client process which happens to be physically placed on the server) which gives us many interesting possibilities - i.e, with simple changes where we fool the client side replicate translator at the time of transaction initiation that only the closest server is up at that point of time and write to it alone, and have the proactive self-heal daemon perform the extra copies in the background. This would be consistent with other readers as they get directed to the "right" version of the file by inspecting the changelogs while the background replication is in progress.

The intention of the above example is to give a general sense of how we want to evolve the architecture (i.e, the "intention" you were referring to) - keep the clients intelligent and servers dumb. If some intelligence needs to be built on the physical server, tackle it by loading a client process there (there are also "pathinfo xattr" kind of internal techniques to figure out locality of the clients in a generic way without bringing "server sidedness" into them in a harsh way)


 I'll
write an rsyncd wrapper myself, to run on top of Gluster,
if the intent is not allow the configuration I'm after
(arbitrary number of disks in one multi-host environment
replicated to an arbitrary number of disks in another
multi-host environment, where ideally each environment
need not sum to the same data capacity, presented in a
single contiguous consumable storage layer to an
arbitrary number of unintelligent clients, that is as fault
tolerant as I choose it to be including the ability to add
and offline/online and remove storage as I so choose) ..
or switch out the whole solution if Gluster is heading
away from my  needs.  I just need to know what the
direction is .. I may even be able to help get you there if
you tell me :)


There are good and bad in both styles (distribute on top v/s replicate on top). Replicate on top gives you much better flexibility of configuration. Distribute on top is easier for us developers. As a user I would like replicate on top as well. But the problem today is that replicate (and self-heal) does not understand "partial failure" of its subvolumes. If one of the subvolume of replicate is a distribute, then today's replicate only understands complete failure of the distribute set or it assumes everything is completely fine. An example is self-healing of directory entries. If a file is "missing" in one subvolume because a distribute node is temporarily down, replicate has no clue why it is missing (or that it should keep away from attempting to self-heal). Along the same lines, it does not know that once a server is taken off from its distribute subvolume for good that it needs to start recreating missing files.

The effort to fix this seems to be big enough to disturb the inertia of status quo. If this is fixed, we can definitely adopt a replicate-on-top mode in glusterd.

Avati

reply via email to

[Prev in Thread] Current Thread [Next in Thread]