I am trying to configure replicated storage over three sites - each site having a full replica of a file system, using either GlusterFS, or XtreemeFS. This replica must be readable - very fast - locally to each site, without having to access any remote nodes (we intend to use the storage cluster to store a huge number of third party header files, and libraries for a large C++ project). Writes must be possible from any site, but performance is not so important. Synchronous writes would be acceptable. Unfortunately, I seem to be running in to an issue, with how to configure these file systems to select a replica that is local to a site for high performance reads. I have also looked at DRBD, and creating a ring topology, or dual master replication, but rejected this idea, because it just seems too complex. I am software engineer, not IT person, so please forgive any ignorance in this area. I appreciate this this is a very technically difficult problem, and would like a good solution that handles the locking semantics for writes correctly. For Gluster, I can't see any practical way to achieve this. For XtreemeFS, I was assuming that that I could assign a 'datacenter map', and use storage policy WqRq, but unfortunately, this doesn't seem to work. It seems that if I have three replicas, I must have three replicas available to any server that attempts to write (for Gluster, it also seems that all three Bricks will also be written synchronously, regardless of site...). Do I need to set up replicated meta data server for XtreemeFS, each with a different ordering of data center map (to prioritise local replicate) to achieve this? How do I force usage of the local replicat on each site? Mounting appears to require the URL of the directory server, so there does not seem to be any easy way to force a specific ordering of replica selection. Is there any alternative that will allow me to have mutli-master writes, and suitable choice of local replicas, for good read performance?