On 03/04/2016 10:05 PM, Diego Remolina wrote:
I run a few two node glusterfs instances, but always have a third
machine acting as an arbiter. I am with Jeff on this one, better safe
than sorry.
Setting up a 3rd system without bricks to achieve quorum is very easy.
This is server side quorum. This is good. But what we are discussing
here is for just 2 nodes, what should be the default.
Pranith
Diego
On Fri, Mar 4, 2016 at 10:40 AM, Jeff Darcy <jda...@redhat.com> wrote:
I like the default to be 'none'. Reason: If we have 'auto' as quorum for
2-way replication and first brick dies, there is no HA. If users are
fine with it, it is better to use plain distribute volume
"Availability" is a tricky word. Does it mean access to data now, or
later despite failure? Taking a volume down due to loss of quorum might
be equivalent to having no replication in the first sense, but certainly
not in the second. When the possibility (likelihood?) of split brain is
considered, enforcing quorum actually does a *better* job of preserving
availability in the second sense. I believe this second sense is most
often what users care about, and therefore quorum enforcement should be
the default.
I think we all agree that quorum is a bit slippery when N=2. That's
where there really is a tradeoff between (immediate) availability and
(highest levels of) data integrity. That's why arbiters showed up first
in the NSR specs, and later in AFR. We should definitely try to push
people toward N>=3 as much as we can. However, the ability to "scale
down" is one of the things that differentiate us vs. both our Ceph
cousins and our true competitors. Many of our users will stop at N=2 no
matter what we say. However unwise that might be, we must still do what
we can to minimize harm when things go awry.
_______________________________________________
Gluster-users mailing list
gluster-us...@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-users
_______________________________________________
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel
