[Gluster-devel] calculating brick quorum from glusterd

[Raghavendra Bhat]

The patch has been sent for the review. http://review.gluster.org/#/c/5998/

Regards,
Raghavendra Bhat

On 09/17/2013 01:06 PM, Raghavendra Bhat wrote:
> The idea as of now is to make quorum check flexible instead of tying 
> to one
> particular command or function. Its because any cli command that wants 
> to check
> for quorum can make use of this aphttp://review.gluster.org/#/c/5998/i 
> and proceed.
>
> It is done such that a cli command can be implemented to get the 
> quorum status.
>
> * An independent method to get the information about the bricks from 
> all the
>   peers.
>
> * An inpenedent method to calculate the quorum (Its usually executed 
> in the
>   originator glusterd).
>
> The cli command to get the quorum status, and other glusterd commands 
> which want
> to do the quorum check (snapshot as of now) will make use of the above 
> apis.
>
> Note that whoever wants to make use of the quorum related APIs MUST 
> hold the
> cluster lock (might be changed to volume wide lock in future) and call 
> the above
> functions.
>
> Please provide inputs.
>
> Regards,
> Raghavendra Bhat
>
>
> On 09/12/2013 02:14 PM, Vijay Bellur wrote:
>> On 09/12/2013 11:24 AM, Raghavendra Bhat wrote:
>>>
>>> Hi,
>>>
>>> As of now whenever a cli command is executed, all the glusterds will 
>>> try
>>> to do the corresponding changes to their respective bricks. It would be
>>> better if glusterd can check whether the quorum (useful especially for
>>> afr replated operations) has been met, for some volume operations.
>>>
>>> One way to handle this is, in the stage phase of the op, when the
>>> originator glusterd will broadcast the stage op to all the glusterds,
>>> the remaining glusterds will send the information about whether the
>>> bricks running in that machine are up or not. The originator glusterd
>>> will collect the information sent by other glusterds and will check
>>> whether the quorum has been met or not.
>>>
>>> This can be used by some features such as snapshots where when snapshot
>>> cli command is issued, glusterd will fail the snapshot if quorum is not
>>> met.
>>
>> Volume topology aware quorum is useful for a few cases:
>>
>> 1. Bringing down bricks in a replica set if quorum is lost.
>>
>> 2. Refusing configuration changes that involve interactions with 
>> bricks if quorum is not available (as with snapshots).
>>
>> As such, it would be useful to have glusterd notify its peers when a 
>> brick goes offline or comes online. online/offline status could be 
>> maintained in volinfo of each glusterd and this information could be 
>> used to determine quorum availability. For the sake of simplicity, 
>> you can possibly make an assumption that all bricks associated with a 
>> node are offline if glusterd on that node is offline.
>>
>> In addition to this having a new interface/RPC to pull the brick 
>> information over instead of piggybacking on a different RPC would be 
>> better.
>>
>> -Vijay
>
>
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at nongnu.org
> https://lists.nongnu.org/mailman/listinfo/gluster-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20130925/bae300f8/attachment-0001.html>