[Gluster-devel] AFR over somewhat slower link
Krishna Srinivas
krishna at zresearch.com
Wed Apr 9 02:03:08 UTC 2008
On Tue, Apr 8, 2008 at 12:19 PM, Paul Arch <paul at esidium.com.au> wrote:
> Hi,
>
> Sorry if this has been answered before, I did take a quick delve but
> couldn't find explicitly an answer.
>
> We are looking at setting up AFR over initially a 10Mb point to point link
> with ping times ~ 70ms return. This will progress up to 100Mb as required.
>
> ** Hope this comes out ok apologizes if it doesn't **
>
> [ Internet ] ---> [ CPU ] -> ( glusterfs client )
> ( glusterfsd primary
> storage)
> |
> | { 10Mbit
> point to point / AFR translator}
> |
> ( glusterfsd
> secondary storage)
>
Sorry, this has not come ok :)
> My questions are ;
>
> 1. When the process on CPU WRITES to the glusterfs, does it wait until the
> write is confirmed @ secondary storage before return ?
> ( will we see our software systems block until this happens, or does the
> write hit the glusterfs client, it returns OK and the software continues )
>
It does not wait till all the writes have completed, it waits for the first
successful return and immediately returns to application.
> 2. When the process on CPU READS, will it only attempt to read from the
> primary storage, UNLESS for some reason it is un-available ( in which case
> it would switch to secondary storage )
> ( or will it try to combine read from both PRIMARY and STORAGE to serve the
> requirements for glusterfs -> CPU ? )
>
you can specify "option read-subvolume <subvolname>"
or you can specify "option read-subvolume *" to schedule different files
on different subvols for reads.
> 3. Assuming AFR is working correctly between the primary and secondary
> storage, is it possible to setup a 'read/only' translator off the secondary
> storage ? :
>
> ..........................
> | { 10Mbit point to point / AFR
> translator}
> |
> ( glusterfsd secondary storage)
> [ CPU ] <---( glusterfs client )
>
> Bearing in mind that the glusterfsd primary and secondary will be
> both utilising unify translator also ( otherwise we could just mount the FS
> )
>
Sorry I am not able to understand the question. Could you frame it again
in a different way?
> 4. Sorry this one is probably quite obvious but I couldn't find an answer to
> it ( or is it too obvious !! ) Is this topology OK ?
>
> [CPU] [CPU] [CPU]
> ( glusterfs ) ( glusterfs ) ( glusterfs)
> | | |
> ----------------------------------------
> ( glusterfsd primary storage)
>
> So several CPU/Glusterfs clients hit one glusterfsd direct, rather than
> having to stuff say a NFS client in front of the glusterfs to serve the
> clients
>
Correct, this is possible. You dont need NFS client.
Regards
Krishna
>
>
> --
>
> Paul Arch
>
> ---------------------------
> Esidium Group Pty. Ltd.
> Ph: (08) 6461 4230
> Fax: (08) 6461 4238
> http://www.esidium.com.au
> ---------------------------
>
>
>
>
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at nongnu.org
> http://lists.nongnu.org/mailman/listinfo/gluster-devel
>
More information about the Gluster-devel
mailing list