Gluster users - Feb 2014 - Abusing georeplication for read-only replication?

I have a file system that contains several hundred thousand very small files
which are served to several clients (so, stat'd and read frequently). I need
to replicate any changes to those files on to four systems which need read-only
access, and three for read-write. The read-only systems don't need real-time
access, but should be updated as quickly as possible.

I've tried using the fuse mount on the read-only systems, which gives
predictably atrocious performance over a high - latency link. The NFS client is
a little better, but I'd prefer some fall over capability. I was originally
thinking about using an inotify-based rsync job, but then I thought that Gluster
might be able to do this for me easier. What if I set the ro systems to be
geo-replicated peers, and just used their local brick directly as my
"read-only" volume? Assuming my application is smart enough to not
write to the brick & doesn't care about any metadata, and my volume is a
straight replica with no striping, is there any real problem with this that
I'm overlooking? That would get rid of the slow network stat(), and just
have a minimal delay in replication while remaining fault-tolerant, right?

--Danny

On Tue, Feb 4, 2014 at 2:12 AM, Danny Sauer <danny at dannysauer.com>
wrote:
> I've tried using the fuse mount on the read-only systems, which gives
predictably atrocious performance over a high - latency link. The NFS client is
a little better, but I'd prefer some fall over capability. I was originally
thinking about using an inotify-based rsync job, but then I thought that Gluster
might be able to do this for me easier. What if I set the ro systems to be
geo-replicated peers, and just used their local brick directly as my
"read-only" volume? Assuming my application is smart enough to not
write to the brick & doesn't care about any metadata, and my volume is a
straight replica with no striping, is there any real problem with this that
I'm overlooking? That would get rid of the slow network stat(), and just
have a minimal delay in replication while remaining fault-tolerant, right?

If you're only interested in a delayed read-only copy of the data,
then yes, geo-replication could work.
You'd have to test to see if you're happy with the setup... Also, your
receiving RO end needs to be big enough to accommodate the amount of
storage you'll be pushing there...