On 04/19/2011 01:25 PM, Whit Blauvelt wrote: >> So... I've a very similar configuration, and while it is strongly >> discouraged by Gluster proper, we just place the configured client >> files on the machines and do it that way. > > Wonder what the discouragement is about. With other mirroring tech, > setting up this way is recognized best practice. for a system which > prides itself on flexibility of deployment, this shouldn't be a big > stretch, IMHO. I can't speak for the Gluster team, of course, but I suspect the discouragement has to do with a configuration space that's already quite large and not recommending configurations that are more likely to be mistakes than well-thought-out decisions. 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. Otherwise, it only tends to work when the front-end network is overloaded, which in my experience means that it's under-provisioned and will eventually have to be upgraded anyway. In any case it does work and it's not hard to do. You can even store the client volfiles on the server if you want, but storing hand-crafted volfiles under /etc/glusterd/vols (or /var/lib/glusterd/vols on Fedora) is risky because they tend to get overwritten any time the CLI is used to make changes. Greg's suggestion of just distributing them yourself and using "glusterfs -f" to point to them is probably safer.
