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 case below. > 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? > > Yes. > > -- Lon > > -- > > Linux-cluster@xxxxxxxxxx > http://www.redhat.com/mailman/listinfo/linux-cluster > -- -- Linux-cluster@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/linux-cluster
