Gluster users - Jul 2016 - About Gluster cluster availability when one of out of two nodes is down

Currently on a two node set up, if node B goes down and node A is rebooted
brick process(es) on node A doesn't come up to avoid split brains. However
we have had concerns/bugs from different gluster users on the availability
with this configuration. So we can solve this issue by starting the brick
process(es) if quorum is not enabled. If quorum is enabled we'd not.
Although quorum option really doesn't make sense in a two node cluster, but
we can leverage this option to get rid of this specific situation.

I'd like to know your feedback on this and then I push a patch right away.

~Atin
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.gluster.org/pipermail/gluster-users/attachments/20160630/33621ece/attachment.html>

On 06/30/2016 11:40 AM, Atin Mukherjee wrote:
> Currently on a two node set up, if node B goes down and node A is 
> rebooted brick process(es) on node A doesn't come up to avoid split 
> brains.
This has always been the case. A patch I had sent quite some time back 
(http://review.gluster.org/#/c/8034/) was eventually abandoned, I think 
`volume start force` should suffice instead of adding checks in code.
-Ravi
> However we have had concerns/bugs from different gluster users on the 
> availability with this configuration. So we can solve this issue by 
> starting the brick process(es) if quorum is not enabled. If quorum is 
> enabled we'd not. Although quorum option really doesn't make sense
in
> a two node cluster, but we can leverage this option to get rid of this 
> specific situation.
>
> I'd like to know your feedback on this and then I push a patch right
away.
>
> ~Atin
>
>
> _______________________________________________
> Gluster-users mailing list
> Gluster-users at gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.gluster.org/pipermail/gluster-users/attachments/20160630/8d2e1dbf/attachment.html>

Is it not the default behavior that if a volume looses quorum, the files are 
still available in read-only mode?  If so, it makes sense to me that this 
behavior would continue after a reboot. Otherwise the user is going to be 
very confused.

Ted Miller
Elkhart, IN, USA


On 6/30/2016 2:10 AM, Atin Mukherjee wrote:
> Currently on a two node set up, if node B goes down and node A is rebooted 
> brick process(es) on node A doesn't come up to avoid split brains.
However
> we have had concerns/bugs from different gluster users on the availability 
> with this configuration. So we can solve this issue by starting the brick 
> process(es) if quorum is not enabled. If quorum is enabled we'd not. 
> Although quorum option really doesn't make sense in a two node cluster,
but
> we can leverage this option to get rid of this specific situation.
>
> I'd like to know your feedback on this and then I push a patch right
away.
>
> ~Atin
>
>
> _______________________________________________
> Gluster-users mailing list
> Gluster-users at gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.gluster.org/pipermail/gluster-users/attachments/20160630/378c062e/attachment.html>

A gentle reminder for your feedback, if I don't see any objections on this,
the default behaviour is going to change here where daemon processes will
be started at the time of glusterd init and irrespective of peer count.

On Thursday 30 June 2016, Atin Mukherjee <amukherj at redhat.com> wrote:
> Currently on a two node set up, if node B goes down and node A is rebooted
> brick process(es) on node A doesn't come up to avoid split brains.
However
> we have had concerns/bugs from different gluster users on the availability
> with this configuration. So we can solve this issue by starting the brick
> process(es) if quorum is not enabled. If quorum is enabled we'd not.
> Although quorum option really doesn't make sense in a two node cluster,
but
> we can leverage this option to get rid of this specific situation.
>
> I'd like to know your feedback on this and then I push a patch right
away.
>
> ~Atin
>

-- 
Atin
Sent from iPhone
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.gluster.org/pipermail/gluster-users/attachments/20160702/66ae1cbe/attachment.html>