<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">The patch has been sent for the review.
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<a href="http://review.gluster.org/#/c/5998/">http://review.gluster.org/#/c/5998/</a><br>
<br>
Regards,<br>
Raghavendra Bhat<br>
<br>
On 09/17/2013 01:06 PM, Raghavendra Bhat wrote:<br>
</div>
<blockquote cite="mid:52380696.4010805@redhat.com" type="cite">The
idea as of now is to make quorum check flexible instead of tying
to one
<br>
particular command or function. Its because any cli command that
wants to check
<br>
for quorum can make use of this
aphttp://review.gluster.org/#/c/5998/i and proceed.
<br>
<br>
It is done such that a cli command can be implemented to get the
quorum status.
<br>
<br>
* An independent method to get the information about the bricks
from all the
<br>
peers.
<br>
<br>
* An inpenedent method to calculate the quorum (Its usually
executed in the
<br>
originator glusterd).
<br>
<br>
The cli command to get the quorum status, and other glusterd
commands which want
<br>
to do the quorum check (snapshot as of now) will make use of the
above apis.
<br>
<br>
Note that whoever wants to make use of the quorum related APIs
MUST hold the
<br>
cluster lock (might be changed to volume wide lock in future) and
call the above
<br>
functions.
<br>
<br>
Please provide inputs.
<br>
<br>
Regards,
<br>
Raghavendra Bhat
<br>
<br>
<br>
On 09/12/2013 02:14 PM, Vijay Bellur wrote:
<br>
<blockquote type="cite">On 09/12/2013 11:24 AM, Raghavendra Bhat
wrote:
<br>
<blockquote type="cite">
<br>
Hi,
<br>
<br>
As of now whenever a cli command is executed, all the
glusterds will try
<br>
to do the corresponding changes to their respective bricks. It
would be
<br>
better if glusterd can check whether the quorum (useful
especially for
<br>
afr replated operations) has been met, for some volume
operations.
<br>
<br>
One way to handle this is, in the stage phase of the op, when
the
<br>
originator glusterd will broadcast the stage op to all the
glusterds,
<br>
the remaining glusterds will send the information about
whether the
<br>
bricks running in that machine are up or not. The originator
glusterd
<br>
will collect the information sent by other glusterds and will
check
<br>
whether the quorum has been met or not.
<br>
<br>
This can be used by some features such as snapshots where when
snapshot
<br>
cli command is issued, glusterd will fail the snapshot if
quorum is not
<br>
met.
<br>
</blockquote>
<br>
Volume topology aware quorum is useful for a few cases:
<br>
<br>
1. Bringing down bricks in a replica set if quorum is lost.
<br>
<br>
2. Refusing configuration changes that involve interactions with
bricks if quorum is not available (as with snapshots).
<br>
<br>
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.
<br>
<br>
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.
<br>
<br>
-Vijay
<br>
</blockquote>
<br>
<br>
_______________________________________________
<br>
Gluster-devel mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:Gluster-devel@nongnu.org">Gluster-devel@nongnu.org</a>
<br>
<a class="moz-txt-link-freetext" href="https://lists.nongnu.org/mailman/listinfo/gluster-devel">https://lists.nongnu.org/mailman/listinfo/gluster-devel</a>
<br>
</blockquote>
<br>
</body>
</html>