[Gluster-devel] AFR

[Brent A Nelson]

Many thanks for your response.

With regards to number 3, yes, I mean file locking (and byte-range locking 
of a file if that's also supported).  I just wanted to make sure that file 
locks are handled properly for replicated data.

With regards to number 4, I just wanted to be certain that if you had 
multiple storage targets on each of multiple nodes, that you can configure 
it such that your replica of any data is always on another node, never on 
the same node.  Otherwise, if a node went down, of course, you'd lose 
access to the data AND the replica.

> Let me know what else you want to know (and if you have tried, GlusterFS
> already, your feed back about the software). Finally its the users who gives
> the shape to software.

That is a very cool aspect of the GlusterFS project.  With its modular 
design, all sorts of cool features are being coded at an amazingly rapid 
rate.  Very impressive.

Thanks,

Brent

On Fri, 16 Feb 2007, Amar S. Tumballi wrote:

> Hi Brent,
> The need of a simple, reliable cluster filesystem is fueling the GlusterFS
> developpers :)
>
> I will try to answer your questions one by one.
>
> 1) AFR will write the data simultaniously to all the nodes (in GlusterFS term,
> on each of its child nodes). It won't store data till close (), or not even
> any of the two glusterfsd servers talk to themself. (Our design is such that,
> each server is independent of other servers). In case of one node failure, it
> still writes to available nodes, but when the missing node comes up, the
> 'glusterfs-fsck' (in development phase) will take care of getting a replica
> of all the missing files.
>
> 2) Yes, thats the idea. When we have the opportunity to make our read faster
> by reading it in different chunks, we want to utilize that. But with this
> release, we are not yet having it. :|
>
> 3) you mean file locking (fnctl?) ? (because in clustered filesystem, we have
> locking of namespace too)
>
> 4) Can you elaborate more on your question?
>
> For your general question, answer would be yes :) (as we have very flexible
> configuration, we can cover your needs).
>
> Let me know what else you want to know (and if you have tried, GlusterFS
> already, your feed back about the software). Finally its the users who gives
> the shape to software.
>
> Regards,
> -bulde (on #gluster - irc.gnu.org)
>
>
> On Fri, Feb 16, 2007 at 03:24:56PM -0500, Brent A Nelson wrote:
>> I see that the AFR automatic replication module is now listed as complete
>> and scheduled for the February 20th 1.4 release.  While we are eagerly
>> awaiting it, is there any documentation somewhere about how it operates?
>>
>> It sounds like this will provide an easily installed and configured, truly
>> redundant (no single points of failure) high-performance distributed
>> filesystem, without having to resort to extra layers (such as drbd).  In
>> otherwords, filesystem nirvana. ;-)
>>
>> Some some-what specific questions:
>>
>> 1) When does replication take place? When a client is writing to a file,
>> does it write to two (or more) servers at the same time, or does one server
>> replicate the file to the other server after close, or...? If a replica
>> server goes down, how does it catch up with changes since it was down? Do
>> the clients know to use the good replica server while the other server is
>> catching up?
>>
>> 2) Assuming replicas are in sync, will clients load-balance reads across
>> the multiple replicas for increased performance? What about writes?
>>
>> 3) How are locks handled between replicas?
>>
>> 4) GlusterFS looks to be extremely flexible with regards to its
>> configuration, but I just want to be sure: if AFR is working with multiple
>> nodes, each containing multiple disks as part of a filesystem, will we be
>> able to guarantee that replicas will be stored on different nodes (i.e., so
>> a node can fail and the data will still be fully available).
>>
>> A completely vague, general question:
>>
>> I'd like to run standard departmental services across one or more
>> redundant, distributed filesystems.  This would include home directories
>> and data directories, as well as directories that would be shared amongst
>> multiple servers for the express purpose of running redundant (and
>> load-leveled, when possible) services (mail, web, load-leveled NFS export
>> for any systems that can't mount the filesystem directly, hopefully
>> load-leveled SAMBA, etc.). Would GlusterFS (with AFR) be a good match?
>>
>> I've been working with Lustre+DRBD+Heartbeat, and it seems like it will
>> work, but the complexity of it makes me nervous (it may be fragile, and
>> prone to breakage with future updates, especially with its strong
>> dependence still upon numerous kernel patches that differ by kernel
>> release).  GlusterFS sounds much simpler (thanks to its modularity) and is
>> about to get built-in replication...
>>
>> Thanks,
>>
>> Brent Nelson
>> Director of Computing
>> Dept. of Physics
>> University of Florida
>>
>>
>> _______________________________________________
>> Gluster-devel mailing list
>> Gluster-devel at nongnu.org
>> http://lists.nongnu.org/mailman/listinfo/gluster-devel
>>
>