Operating System - OpenVMS
1748036 Members
5170 Online
108757 Solutions
New Discussion юеВ

Re: remove a quorum disk when adding a 3rd node to cluster

 
SOLVED
Go to solution
Paul Coviello
Frequent Advisor

remove a quorum disk when adding a 3rd node to cluster

We are going to add an ES47 into a 2 host cluster of ES40's. VMS 7.3-2. EVA5000. We were thinking of changing modparams and sysgen to get rid of quorum disk and to keep expected votes the way it is, thinking that the ES47 would take the place of the qdisk.
Is this the right process to take?

thanks
Paul
29 REPLIES 29
├Еge R├╕nning
Trusted Contributor

Re: remove a quorum disk when adding a 3rd node to cluster

Yes, with a 3 node cluster most people would prefer no Q-disk and give one vote to each member. EXPECTED_VOTES should be set to the sum of all votes in the cluster(3). But you need to reboot after changing the sysgen paramaters to stop using the Q-disk.
VMS Forever
Paul Coviello
Frequent Advisor

Re: remove a quorum disk when adding a 3rd node to cluster

so would you change them, then a reboot and then bring in the 3rd member?

thanks
Paul
Uwe Zessin
Honored Contributor
Solution

Re: remove a quorum disk when adding a 3rd node to cluster

Yes, it makes sense to do it in this order - else you would have to change 3 system roots.
.
Dima Bessonov
Frequent Advisor

Re: remove a quorum disk when adding a 3rd node to cluster

The interesting point here is, what value would you assign to EXPECTED_VOTES. Definitely _not_ 3 - otherwise you'll suspend the entire cluster every time you want to reboot a node. By default AUTOGEN will calculate it as 2 if you have three nodes with 1 vote each. Still, when you start up the entire cluster, you won't get it running until you bring at least two nodes up. To be able to work right after the first node is up, you must hard-code EXPECTED_VOTES as 1 in MODPARAMS.DAT. But then there's a risk of cluster partitioning and thus corrupting the file system on the disks. This may happen when your storage interconnect is not same as cluster interconnect (say, the first one is SCSI and the second one is Ethernet) and the cluster interconnect has failed. Imho, if your cluster has more than one path for cluster communications (say, redundant LAN adapters) this risk is almost nonexistent and you may safely use EXPECTED_VOTES=1 and have your cluster available right after the first node has completed its startup. Community, your opinions?
Kris Clippeleyr
Honored Contributor

Re: remove a quorum disk when adding a 3rd node to cluster

Dmitry,


The interesting point here is, what value would you assign to EXPECTED_VOTES. Definitely _not_ 3 - otherwise you'll suspend the entire cluster every time you want to reboot a node.


Definitely NOT true. In a cluster with 3 voting members, you can safely set EXPECTED_VOTES to 3. Even if a voting member crashes, the cluster happily continues because of the of the fact that quorum is calculated as:
(sum of all votes of all voting members + 2) / 2
In this case that means:
(3+2)/2 = 2.
So the cluster is happy if 2 voting members (one vote each) are present.


By default AUTOGEN will calculate it as 2 if you have three nodes with 1 vote each.


I'm not sure about that, maybe someone else can shed a light on this.


Still, when you start up the entire cluster, you won't get it running until you bring at least two nodes up.


You have a point there. But in a cluster with three voting members, don't you want at least 2 of them to be present, before you turn over the cluster to the end-users.
Certainly I would.

Greetz,

Kris
I'm gonna hit the highway like a battering ram on a silver-black phantom bike...
Dima Bessonov
Frequent Advisor

Re: remove a quorum disk when adding a 3rd node to cluster

Kris,

Agreed that EXPECTED_VOTES=3 will be OK for two remaining nodes.

> But in a cluster with three voting
> members, don't you want at least 2 of
> them to be present, before you turn over
> the cluster to the end-users.
> Certainly I would.

It depends. Imho, the more time my cluster is available, the better for users. To me, performance is secondary to availability. And consider another situation: you're a system manager doing an upgrade or another change. No chance to check if everything went well until _two_ nodes finished startup. Another point: some upgrades simply require to shut down all other nodes booting from the same system disk. Do you prefer to change EXPECTED_VOTES and reboot every such time?
Uwe Zessin
Honored Contributor

Re: remove a quorum disk when adding a 3rd node to cluster

If you set EXPECTED_VOTES too low and you start your nodes without realizing that they can not talk together - well, you will get a partitioned cluster (better: multiple single-node clusters) that will corrupt you disks! I ONLY set it down that low when I want to boot a single node and I *know* that all others are down. I would then boot the next node(s) with higher values of EXPECTED_VOTES.

By the way: there has been a change in behaviour: I don't know when it changed, but I know that in earlier OpenVMS releases a single node was able to form a VMScluster, but then blocked due to not enough votes for quorum. The system manager could then get that node life with a quorum recalculation request through the 'IPC>' mechanism. I have noted that with V7.3-2 a cluster is only formed when enough votes for the quorum are present. Indeed that requires changing EXPECTED_VOTES through a conversational bootstrap, but - as I already wrote - I would NOT hardcode it.
.
Paul Coviello
Frequent Advisor

Re: remove a quorum disk when adding a 3rd node to cluster

ok now that we have gone thru that! what is the consensus on what the the votes should be?

thanks
Paul
Uwe Zessin
Honored Contributor

Re: remove a quorum disk when adding a 3rd node to cluster

For normal operation, assuming that all nodes have same importancy?

Get rid of the quorum disk und give each node VOTES=1 and EXPECTED_VOTES=3.
.