On 11/23/2015 03:26 AM, Tom Farrar wrote: > Good Morning All, > > I'm looking at deploying 3 Gluster nodes, two in one location and the > third in another. The link between these two locations is fast and > fairly low latency, around ~4ms. The volumes are all low write/high read > with the largest being a few TBs (with lots of small files). While the > primary location will have two nodes in, the secondary location (with > one node) will see local reads and writes. > > I'm a little concerned about running the replication in separate > locations given that from what I've read Gluster doesn't like latency. > Is this a valid concern? I've seen a few options for what I believe is > keeping reads local so they don't go to the distant node, but I'm > struggling to find a definitive answer (cluster.read-subvolumeperhaps). For reads, the clients will read from the server that responds the fastest to the Lookup call. Usually that will be from the closest, lowest latency, server. That's automatic, there is no configuration required for that. Aside from that, using geo-rep to replicate to the remote system is probably a good fit for your use case; clients only know about the closest systems and never incur the hit for the synchronous write to the remote system. -- Kaleb _______________________________________________ Gluster-users mailing list Gluster-users@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-users
