Hi Rodger, Thanks for the review.
Rodger Etz-Brown wrote: > My 2c: > In a community, every 2c matters... thanks for the feedback :) > Either give out a warning when one tries to change from weak to strong > membership without an already defined quorum, e.g. > > # clq set -p multiple_partitions=false membership > WARNING: Cluster has been set to strong membership, but no quorum defined.... > I agree. May be not print it as a "WARNING:" (after all, the software wants the user to switch to strong membership first, and then add a quorum device). We can say something like : "Cluster will use strong membership; configure a quorum device to ensure high availability" > Or we could combine the step of changing membership model and adding a quorum > device (where -q would be optional): > > # clq set -p multiple_partitions=false membership -q <quorumdevice> > Though I am not familiar with the CLI part, I think this may not align with the CLI design. "clq set -p ..." changes a setting of a property (multiple_partitions) while operating on the object "membership". On the other hand, "clq add <quorumdevice>" operates on an object that is a quorum device. > Regards, > Rodger > Thanks & Regards, Sambit > On Wed, Feb 18, 2009 at 12:47:41PM +0530, Sambit Nayak wrote: > >> Hi Piotr, >> >> Thanks for the review. :) >> >> The concept of "weak membership model" (which is equivalent to >> multiple_partitions=true setting right now) has a requirement that the >> cluster should have no quorum devices configured. >> >> To put it differently, if there are any quorum devices configured, then >> the cluster cannot be using "weak membership model"; it will be "strong >> membership model". >> >> So, the sequence of steps is as mentioned in the doc : >> (i) first change to strong membership model by setting >> multiple_partitions=false >> (ii) add a quorum device for higher availability >> >> I understand you are saying that if a node goes down in between steps >> (i) and (ii) above, then there will be a loss of quorum. >> >> But let me try to argue like this : >> - going by the notion that weak membership means no quorum devices, the >> CLI prevents addition of any quorum devices when cluster is running weak >> membership. So how does CLI know that the user really intends to add a >> quorum device with an intention to switch to strong membership? >> - alternately, the software could have the behaviour that as soon as a >> user adds a quorum device, the cluster switches to strong membership >> automatically. But it is not very good to do such 'automated' actions >> when we do not really know what the user was intending to do; I mean, >> the user intends to do action1, but we also automatically perform >> action2 additionally in the background. >> - besides, removal of the last quorum device from a 2-node cluster is >> anyway allowed under strong membership; let's trust the admin to know >> what he/she is doing. :) >> >> Hoping I could answer some of your queries... >> >> Thanks & Regards, >> Sambit >> >> Piotr Jasiukajtis wrote: >> >>> Weak Membership design: >>> >>> "6.4 To Switch from Weak to Strong membership model >>> 1. In order to switch from Weak to Strong membership model, the >>> cluster must be fully >>> formed. In other words, both nodes must be up and both nodes must be >>> in the same cluster >>> partition. The transition cannot be done while the cluster is in a >>> split-brain condition. >>> 2. Set the multiple_partitions property to false to switch to Strong >>> membership. >>> clq set -p multiple_partitions=false membership >>> 3. Now add a quorum device (quorum server or a shared disk) to provide >>> high availability. Without a quorum device, any disconnect between >>> the cluster nodes or single >>> node failure will result in complete cluster panic. >>> clq add d3" >>> >>> Well, I think 'clq add d3' should be in the first place so the proper >>> sequence would looks like: >>> # clq add d3 >>> # clq set -p multiple_partitions=false membership >>> >>> This prevents the cluster panic. >>> >>> >>> >> _______________________________________________ >> ha-clusters-discuss mailing list >> ha-clusters-discuss at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/ha-clusters-discuss >> > _______________________________________________ > ha-clusters-discuss mailing list > ha-clusters-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/ha-clusters-discuss >
