[Gluster-devel] calculating brick quorum from glusterd

[Raghavendra Bhat]

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 api 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