[Linux-cluster] GFS on SAN, does a quorum make sense?
Dan B. Phung
phung at cs.columbia.edu
Fri May 6 17:58:08 UTC 2005
On 6, May, 2005, Lon Hohberger declared:
> On Thu, 2005-05-05 at 18:49 -0400, Dan B. Phung wrote:
> > From my understanding,
> > the quorum/voting procedure is to prevent split-brain scenarios where two
> > nodes coming up for the first time might try to form two separate clusters
> > of the same name, which will cause data corruption. How would I prevent
> > that, while still allowing any one node, even by itself, to access the
> > storage media.
> It's not to prevent two nodes: it's to prevent "less than a majority" of
> the nodes (votes really) from forming their own cluster.
right, sorry, that was just an eg, which you extend to the N-node
> What you're trying to do is exactly what the algorithm is designed to
> prevent :)
that's what I was afraid of!
> Consider a case where any one node can become quorate (by itself) in an
> N-node cluster. If you unplug the network cables on each node and start
> up the cluster software on all N nodes, you'll end up with an N-way
> split brain! I think that is probably not a good thing.
> You can do it manually by adjusting cman_tool's expected votes down to a
> small number while doing a one-node boot, but please ensure the rest of
> the cluster is down before doing so.
ah, I see, and that would overide the cluster.conf node/vote counts.
Woudn't another way be to somehow mark the file system with a unique
cluster id (randomly generated) so that mounting would fail if the cluster
isn't part of the other clusters? ...or rather, at a higher level, what
would help is an inband locking mechanism. I guess I should start reading
the design docs and published papers to see how this would work.
> > Another use of the quorum is for distributed disks in the case of a node
> > failure the I/O to that disk is fenced. Is that correct?
> -- Lon
> Linux-cluster mailing list
> Linux-cluster at redhat.com
More information about the Linux-cluster