Re: [Gluster-devel] AFR over somewhat slower link

[Krishna Srinivas]

On Tue, Apr 8, 2008 at 12:19 PM, Paul Arch <address@hidden> 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
>  address@hidden
>  http://lists.nongnu.org/mailman/listinfo/gluster-devel
>