Amar S. Tumballi
amar at zresearch.com
Sat Feb 17 01:55:02 UTC 2007
The need of a simple, reliable cluster filesystem is fueling the GlusterFS
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.
-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...
> Brent Nelson
> Director of Computing
> Dept. of Physics
> University of Florida
> Gluster-devel mailing list
> Gluster-devel at nongnu.org
More information about the Gluster-devel