Hello, I suggest Tom to clarify if he intends geo-rep or replica.
Tom, do you expect automatic failover to remote site if local is down ? Cordialement, Mathieu CHATEAU http://www.lotp.fr 2015-11-23 14:37 GMT+01:00 Kaleb S. KEITHLEY <[email protected]>: > 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 > [email protected] > http://www.gluster.org/mailman/listinfo/gluster-users >
_______________________________________________ Gluster-users mailing list [email protected] http://www.gluster.org/mailman/listinfo/gluster-users
