Red Hat Bugzilla – Bug 914804
[FEAT] Implement volume-specific quorum
Last modified: 2015-10-22 11:46:38 EDT
From the commit message on http://review.gluster.org/#change,4363
Volume quorum is mostly the same as the current cluster quorum - same triggers,
same calculations, same actions - except that it only counts servers which have
an interest in a volume. Interest comes from either having a brick for that
volume or from being named as an arbiter via the cluster.arbiter option on the
volume. An arbiter has no data for the volume it arbitrates, but can break
quorum ties when there are only two servers with bricks for the volume.
In other words, volume-level quorum fixes the absurdity of having a volume go down because some servers that had nothing to do with the volume (but happened to be part of the same cluster) went down. The arbiter feature allows us to take advantage of the larger cluster *voluntarily* to handle the tricky n=2 case.
I am interested in the arbiter feature.
My volumes are replica 2. I have a total of six servers, two of which have no bricks - they are used as network access gateways for NFS/Samba. The volumes have bricks on the other four servers.
There should be enough hardware here such that I can turn on quorum and everything would function perfectly if one of those six servers crashes hard or gets rebooted.
REVIEW: http://review.gluster.org/4363 (afr: add volume-specific quorum calculation) posted (#4) for review on master by Jeff Darcy (firstname.lastname@example.org)
REVIEW: http://review.gluster.org/4363 (afr: add volume-specific quorum calculation) posted (#5) for review on master by Jeff Darcy (email@example.com)
Arbiter nodes is an awesome concept, one that I *really* want to be able to use.
Here's a minor enhancement idea. I have no idea how straightforward it would be, and it should probably be a new BZ anyway:
Make it possible to configure multiple (at least two) arbiter candidates for each volume, from which an active arbiter is chosen. If the active arbiter goes down, elect a new one.
Feature requests make most sense against the 'mainline' release, there is no ETA for an implementation and requests might get forgotten when filed against a particular version.
because of the large number of bugs filed against mainline version\ is ambiguous and about to be removed as a choice.
If you believe this is still a bug, please change the status back to NEW and choose the appropriate, applicable version for it.