Operating System - OpenVMS
1827820 Members
2426 Online
109969 Solutions
New Discussion

How can I bring a cluster member up if other member unavailable

 
SOLVED
Go to solution
MarkW_1
Regular Advisor

How can I bring a cluster member up if other member unavailable

2 Alphaserver 4100s, running OpenVMS 6.21H3 had 2 be brought down because because of an electrical burn of 1 member. The 2nd member hangs at "waiting to form or join a vmscluster." The quorum disk is available when booted. Is there a way to bypass this message and bring the box up.
6 REPLIES 6
Volker Halle
Honored Contributor
Solution

Re: How can I bring a cluster member up if other member unavailable

Mark,

you can always boot conversationally using

>>> b -fl n,1 (n = system root)

then

SYSBOOT> SET EXPECTED_VOTES 1
SYSBOOT> C

This will bring up the node as a single member cluster (assuming it has at least VOTES=1).

YOU need to make sure, that no other member in this cluster is up and accessing the shared disks.

Volker.
Uwe Zessin
Honored Contributor

Re: How can I bring a cluster member up if other member unavailable

Something is *wrong* and I would be very careful, because you risk creating two clusters which can corrupt your disks.

Some things I would check first:

- are you booting from the correct root?
-- it is possible that both members attempt to boot from the same root (e.g. [SYS0])

- are you sure that the network hardware works properly?
-- if there is a chance that this is not the case, DO NOT attempt to worm around with member 2's system parameters!
.
Jan van den Ende
Honored Contributor

Re: How can I bring a cluster member up if other member unavailable

Mark,

I would expect the cluster to be able to form from 1 member + the quorum disk.
This needs investigation, but first, to get you up:

^P

to get you to the bootprompt again,
and boot conversational:

add -FL 0,1 (or, if you already use -FL, replace the second param by 1 )

This gets you to SYSBOOT>

Show VOTES , EXPECTED, QSKVOTES, DISK_QUORUM

Verify that DISK_QUORUM _DOES_ point to your quorumdisk.

Verify that VOTES + QDSKVOTE > EXPECTED / 2

If that is OK, ARE YOU SURE YOU SEE THE QDSK?

Probably, you will make the equation fit (largest possible EXPECTED that does fit) by
SYSBOOT> SET EXPECTED = nnn
SYSBOOT> cont


Success.

Proost.

Have one on me.

Jan




Don't rust yours pelled jacker to fine doll missed aches.
MarkW_1
Regular Advisor

Re: How can I bring a cluster member up if other member unavailable

Setting the expected votes 1 allowed me to boot up. Thanks. The quorum disk was not joined until later in the boot process. The second member did have an electical burn. That box is dead. This box will only be used for the next 2 months. Can I just change the expected vote count to 1 in modparams in case there is another reason to boot? It's current value is 3.
Volker Halle
Honored Contributor

Re: How can I bring a cluster member up if other member unavailable

Mark,

yes. Set EXPECTED_VOTES = 1 in MODPARAMS.DAT. This will make sure that it will be set correctly (for the current reduced configuration), if someone decides to run AUTOGEN.

Nevertheless, there seems to be something wrong with your initial setup, as a single node + a quorum disk should normally be allowed to boot, if configured correctly.

Volker.
Jan van den Ende
Honored Contributor

Re: How can I bring a cluster member up if other member unavailable

Mark,

to extend on previous postings:

The whole _INTEND_ of a quorum disk is, to allow each single one node of a two-node cluster to keep running, and to boot.

Please review QDSKVOTES and VOTES.
For your simplest config, I suggest both as 1.
In that case, the nominal value for EXPECTED_VOTES would be 3.

If that holds true, then, if you keep seeing the "waiting to f... etc" message, I am pretty sure that your node can NOT see the QDSK.

Normal would be to see "Accessing ", and continuing. There is a minimal way of accessing the quorum disk, such that it _WILL_ offer the vote(s) very early on in the boot procedure.

I already mentioned in my previous post, but please check the correct specification of the quorum disk.

And if your second node comes back (this system, or a replacement using this root), then you can check (and if needed, correct) the params for that BEFOREHAND by SYSGEN USE
Unless you have VERY SPECIFIC reasons, and you THOROUGHLY KNOW the consequences, you are best served with VOTES = 1 and for the QDSK; and EXPECTED = 3 for each node.

Success.

Proost.

Have one on me.

Jan
Don't rust yours pelled jacker to fine doll missed aches.