[Gluster-devel] AFR over somewhat slower link

Paul Arch paul at esidium.com.au
Tue Apr 8 06:49:06 UTC 2008


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)

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 )

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 ? )

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
)

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



-- 

Paul Arch 

--------------------------- 
Esidium Group Pty. Ltd. 
Ph:  (08) 6461 4230 
Fax: (08) 6461 4238 
http://www.esidium.com.au
---------------------------







More information about the Gluster-devel mailing list