Bug 914804

Summary: [FEAT] Implement volume-specific quorum
Product: [Community] GlusterFS Reporter: Jeff Darcy <jdarcy>
Component: glusterdAssignee: bugs <bugs>
Status: CLOSED EOL QA Contact:
Severity: medium Docs Contact:
Priority: unspecified    
Version: mainlineCC: bugs, gluster-bugs, redhat
Target Milestone: ---Keywords: FutureFeature
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-10-22 15:46:38 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Jeff Darcy 2013-02-22 19:44:30 UTC
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 23:18:55 UTC
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 19:16:41 UTC
REVIEW: http://review.gluster.org/4363 (afr: add volume-specific quorum calculation) posted (#4) for review on master by Jeff Darcy (jdarcy)

Comment 3 Anand Avati 2014-03-12 20:06:23 UTC
REVIEW: http://review.gluster.org/4363 (afr: add volume-specific quorum calculation) posted (#5) for review on master by Jeff Darcy (jdarcy)

Comment 4 Shawn Heisey 2014-03-12 20:51:51 UTC
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 14:45:13 UTC
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 15:46:38 UTC
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.