[Gluster-devel] AFR

[Amar S. Tumballi]

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
>