Adding a test-rig node to VMS cluster

[David Lloyd_4]

I'm planning to add a node to a VMS/Alpha cluster to test/evaluate software, patches, etc., before they get pushed into the production and development environments.
The cluster is OVMS/Alpha V7.3-2, with two nodes (prod & dev) sharing a common system disk. I use a quorum disk.
I plan for the third node to be a member of the cluster, and have its own V7.3-2 system disk that can be used to test patches, etc.
I also plan to create an alternate system disk with V8.2 on it for testing and evaluation, so that the third node can be booted with either system disk, sometimes running V7.3-2 and other times running V8.2.
So the question is, will it freak out the cluster if the test-rig joins the cluster occasionally running a different version of VMS than the time before?
Would it be better to create another node persona (node name and IP) for the V8.2 system, and pretend to be a fourth node when the other disk is booted? Would this create quorum issues?

Thanks for your thoughts!

[Jan van den Ende · Accepted solution]

David,

no need to!

We have essentially the same:
4 node cluster plus one node that can be configured as needed:
A: It CAN be added to the cluster (it has its own root on the common system disk)
- this is used if one node for any reason leaves for some time, but mainly during the relocations we have done: add #5, shutdown another, relocate, join; repeat; #5 leaves again
B: It has a 2 system disks (2 different VMS versions) with copies of CLUSTER_AUTHORIZE.DAT.
- boot conversational, set VAXCLUSTER = 2, and it joins nicely.
- conv boot & VAXCLUSTER = 0 , and it boots standalone (of course, the startup sequence has to distinguish between cluster or standalone config)

Be aware though to have your startup conforming to the rest of the cluster when joining!

DISCLAIMER: use at your own risk. This DOES require that you KNOW what you are doing!

Please, keep us informed on your results,

Success.

Proost.

Have one on me.

jpe

[Steven Schweda]

There's a doomed/may-work/supported matrix
somewhere for different VMS versions in a
cluster. I believe that no one is likely to
care if the VMS version changes between
shutdown and startup for a node, but a
totally different identity could avoid some
user-confusion as well as playing it safe on
the version question.

I normally have the loose, odd-ball systems
which may join my cluster set to zero votes,
so they can't accidentally cause a quorum
loss when they go nuts and/or die.

[John Gillings]

>will it freak out the cluster if
>the test-rig joins the cluster
>occasionally running a different
>version of VMS than the time before?

No. You can boot whatever version you want (within sanity limits), and bounce back and forth at will. The other nodes won't mind at all.

Just make sure the test node has zero votes and doesn't automatically mount any critical production data (or, more generally, any disks on physically shared storage, like Fibre Channel). This will allow it to come and go anytime without interrupting other nodes, and without being a threat to data integrity.

Be aware that booting from a second system disk is non trivial. You need to make sure all systems use the same, common cluster environment. It sounds like in your case the test node should hook up to the environment (ie: define SYSUAF, RIGHTSLIST etc) to point to the "main" system disk.

See SYLOGICALS.TEMPLATE for a complete list of files you need to consider. Note that many of these are NOT NEGOTIABLE. Unless all nodes agree, and use the same physical files you can get some very odd behaviour.

[Jan van den Ende]

Small addendum to the above answer:

The extra system has NO direct connection to any of the disks of the regular cluster config. No way to get to the cluster disks if not a cluster member.
Booting it from the common system disk is done by booting it as a satellite, and using mounting all disks via MSCP.

Cluster boot from one of the local system disks mounts the cluster common disk (with the rest of the bootstrap environment, and the cluster common files like SYSUAF etc.) and continues from there on with a 'normal' clusternode startup.

hth.

Proost.

Have one on me.

jpe

[David Lloyd_4]

Success! Finally got the opportunity to do this.
I made an image copy of the cluster system disk, changed the [sys0] node name using information from the OVMS FAQ. Then with the hints provided by the forum, I was successful.
I now have a cluster with three nodes, where one node boots from its own system disk, which is a copy of the original system disk. I can know use this third node to test system patches.
Thanks for all the help!

--dave