On Tue, Apr 19, 2011 at 02:34:20PM -0400, Jeff Darcy wrote: > For *synchronous* replication which is already very latency-sensitive, > adding the extra hop (client to server1 to server2 instead of client to > server1/server2 in parallel) is likely to do more harm than good. Using a > separate network for replication is only a "recognized best practice" with > *asynchronous* replication or when other measures have been taken to hide > or make up for the additional latency. Jeff, Thanks for the details. I'm not sure that the diagram you suggest applies to my setup. There are three client circumstances in my case: 1. A gluster client is external to the servers. In this case I think the client will do the normal client to server1/server2 in parallel, once I get the configuration right, using the servers' LAN addresses. 2. An nfs client is external to the servers. In this case it's going to be client to server1 to server2, so speeding the server1 to server2 link with a dedicated crossover should speed the process, while avoiding extra load on the main LAN. 3. A gluster client is running locally on one of the servers. In this case again it's client to server1/server2 in parallel, and there's no use to bother the LAN with the extra traffic, and introduce the switch as a point of failure, when extra ethernet ports for a crossover are available. In a setup where all client use is type 1 here, your point holds well. But with nfs client use, and/or gluster client use locally on one of the mirroring gluster servers, it still looks like best practice to use a crossover to me. Or do I have the logic wrong? Whit