[Gluster-users] Thank you + Glusterfs design question

[Marcio Teixeira]

Thank you to everyone who helped me with the Fedora 10 rpmbuild issue.
The "--without modglfs" worked like a charm.

 

I would like to do a sanity check on a GlusterFS design I was planning
to implement. I have a situation where I have many machines, each with
different amounts of disk storage available under a /scratch mountpoint.
As a first step, I would like to use the "distribute" translator to
distribute files among these machines and present a unified view of the
files. Second, I would like to add redundancy, so that each file is
stored on at least two machines and can easily be recovered if a node
crashes.

 

My idea was to create two directories on each machine called
"/scratch/.glusterfs_storage_primary" and
"/scratch/.glusterfs_storage_secondary" and expose them as bricks. Then
I would then have two instances of the distribute translator, one which
would aggregate all the ".glusterfs_storage_primary" bricks, and the
other which would aggregate all the ".glusterfs_storage_secondary"
bricks. Then, on top of that, I would use the replicate translator with
self-healing to replicate files across these two aggregates.

 

My questions:

 

1)      Are there any obvious flaws with this approach I should know
about before attempting it?

2)      What would I have to do to ensure that both copies of the file
did not hash to the same node in the primary and secondary aggregates?
My initial thought was that a matter of having the subvolumes be listed
in a different order on one distribute translator vs. the other (say, in
one the subvolumes are listed in alphabetical order while in the other
they are listed in reverse alphabetical order)

3)      If I add or remove a subvolume from the distribute translator in
such a way as to alter the position of other subvolumes in the list
(say, when adding a new subvolume in the middle of an alphabetized
list), will this totally mess up the file-to-host hashing and make my
existing files inaccessible?

 

Thank you,

 

-- Marcio

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-users/attachments/20090527/061bd0ed/attachment.html>