Bug 914804 - [FEAT] Implement volume-specific quorum
[FEAT] Implement volume-specific quorum
Product: GlusterFS
Classification: Community
Component: glusterd (Show other bugs)
Unspecified Unspecified
unspecified Severity medium
: ---
: ---
Assigned To: bugs@gluster.org
: FutureFeature
Depends On:
  Show dependency treegraph
Reported: 2013-02-22 14:44 EST by Jeff Darcy
Modified: 2015-10-22 11:46 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2015-10-22 11:46:38 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Jeff Darcy 2013-02-22 14:44:30 EST
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.
Comment 1 Shawn Heisey 2013-11-22 18:18:55 EST
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.
Comment 2 Anand Avati 2014-03-12 15:16:41 EDT
REVIEW: http://review.gluster.org/4363 (afr: add volume-specific quorum calculation) posted (#4) for review on master by Jeff Darcy (jdarcy@redhat.com)
Comment 3 Anand Avati 2014-03-12 16:06:23 EDT
REVIEW: http://review.gluster.org/4363 (afr: add volume-specific quorum calculation) posted (#5) for review on master by Jeff Darcy (jdarcy@redhat.com)
Comment 4 Shawn Heisey 2014-03-12 16:51:51 EDT
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.
Comment 5 Niels de Vos 2014-11-27 09:45:13 EST
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.
Comment 6 Kaleb KEITHLEY 2015-10-22 11:46:38 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.