Hi Rodger, Thanks a ton for reviewing the command line design. Please find my answers inlined ..
Rodger Etz-Brown wrote: > My 2c: > > 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.... > > This is will be a good way to let know the user what he/she is about to do and there could be a potential outage if the quorum device is not added any sooner. I shall make this fix. > 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> > > This will be against the general object oriented command line policy. Each command is designed to do operations on a specific object. Hence we we need to add to quorum device to the cluster, we need to use the "clq" command and use the "add" operation with the operand being the new "quorum device". Hope this answers your query ! > Regards, > Rodger > > 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 >
