Booting a system into a cluster to obtain vote

[Ziggy Filek]

I have a cluster of multiple ES80s using a common system disk. For various reasons I want to boot an existing non-clustered AS2100A residing on the same LAN into the cluster just to provide a vote. I need the AS2100 to keep booting from its own system disk,I don't want to share any resources between the 2100 and the ES80s and I want SYSUAF, queue system, LMF and such on the AS2100A to remain separate and not to be disturbed. Is it possible?

[Jan van den Ende]

Ziggy,

One word: YES.

But first let me welcome you to the VMS forum!

Easiest is, if you know the Cluster number and cluster password for the existing cluster.

Then, on the AS2100A, just

@cluster_config

The questions should be self-explaining, and as long as the cluster number and password you provide are the same, the new system just joins the cluster.

If you do not know these, there are (sommewhat less simple) ways.
Just come back, and we will help you along.

Success!

Proost.

Have one on me.

jpe

[Ziggy Filek]

Thank you for the response. I don't know the cluster password, but I can simply set it from SYSMAN and reboot the cluster, right? What I'm concerned with before I actually run CLUSTER_CONFIG_LAN on the 2100 is whether it will give me a chance to specify that I want to leave everything local and not shared with the cluster (system disk, Queue Manager, SYSUAF etc). I understand from your response the answer is yes.
Another question: The VMS on the cluster is 7.3-2 and on the AS2100 it is 7.2
Is it going to work, or do I need a remedial kit or something? Upgrading OS is not an option for me at this time.

[Jan van den Ende]

Ziggy,

yes, if rebooting the cluster is an option, then that is perhaps the easiest. But, being VMS, and being who I am, a cluster reboot did not even enter my mind. (We have not done so for the last 9.5 years).


7.3-2 and 7.2(-x) CAN coexist in a cluster, AFAIK, but realise, it definitely is _NOT_ a supported config!.

"upgrade is not an option"
Because you NEED 7.2 (then, WHY?) or because the upgrading process is not?

If the latter, then configure the AS2100 to be a satellite of the cluster.
Copy the 2100 SYSTARTUP to the new system root, and, in that system roots SYLOGICALS.COM
MOUNT /CLUSTER (at least) the disk(s) that contain the system config files of the 2100
$ DEFINE/SYSTEM/EXEC SYSUAF and various configuration files (deine JUST the filename as the LNM).
Remember to define the DIRECTORY of the various queue files as QMAN$MASTER. You need to start a separate queue manager (see HELP START/QUEUE/MANAGER) (btw, you need to do that ANYHOW if you want to use two different queue control files (ergo: queue managers) in your cluster.

Any more specific answers after more specific questions/choices....

Proost.

Have one on me.

jpe

[Ziggy Filek]

Yeah, this is not a production system yet, it goes into production in February and then "never" comes down... I need 7.2 on the 2100 because there are applications on it that simply insist on this particular version. That is why I want this system to just provide a vote, nothing else, keeping everything local.
Thank you for you input.
Z.

[Andy Bustamante · Accepted solution]

Quick note, if you don't have the cluster password or group number, you can copy the SYS$SYSTEM:CLUSTER_AUTHORIZE.DAT from the ES80 cluster to the Alphaserver 2100a. This will save a cluster reboot.

This configuration falls into the "not supported but will probably run" category.

Andy

[comarow]

I have never seen cluster_autorization.dat
not work.

The gotcha to watch out for is are any duplicate volume or device labels. No volumes can have the same name.

[Andy Bustamante]

Apologies if I wasn't clear. I was referring to the operating system versions as unsupported. Moving cluster_authorize.dat will work.

Andy

[Ziggy Filek]

Do you mean one should first copy the cluster_authorize.dat and then run CLUSTER_CONFIG (which presumably would not ask for password), or, alternatively, run CLUSTER_CONFIG first, specifying any old password, and then overwrite the cluster_authorize.dat and boot?

[Jan van den Ende]

Ziggy,

no, even simpler.

Copy cluster_authorize.dat, set SYSGEN VaxCluster = 1, and boot.

You ARE one cluster now, but with all and any synchronisation still to be done.

Success!

Proost.

Have one on me.

jpe

[Volker Halle]

Jan,


copy ..., set SYSGEN VaxCluster = 1, and boot


shouldn't this say VAXCLUSTER=2 and also NISCS_LOAD_PEA0=1 ?!

AFAIK VAXcluster=1 will only work, if you have 'cluster hardware', i.e. a CI or DSSI interface.

Without NISCS_LOAD_PEA0=1, PEDRIVER will not be loaded and the node won't be able to talk SCS via the LAN (to join the existing cluster).

Also make sure to set VOTES=1 and EXPECTED_VOTES > 1, so the node will only join the cluster, if it can actually talk to the existing ES80 cluster.

Volker.

[Jan van den Ende]

Volker,

I guess you are right.

It has been such a long time since I played those games, and biological memories tend to detoriate...

But your remark does trigger some harmonics!

Ziggy, sorry for that!

Proost.

Have one on me.

jpe

[Ziggy Filek]

Yes, I figured that one too. VAXCLUSTER must be 2 and PEdriver needs to be loaded.
I have another question: I don't think I'll have any device naming conflicts, but my existing cluster uses port allocation classes (DEVICE_NAMING = 1), and the AS2100 I'm booting into it does not. Assuming no 2 device names are the same, there should be no problem, right? (I'm NOT going to share any resources).
Also, when I'm at it: to set port allocation classes for internal SCSIs one uses device names PKA and PKB (controllers, not actual drives). What should I use to set port alloclasses for CD ROM drives?
Thanks for your input!

[Jan van den Ende]

Ziggy,

>>>
What should I use to set port alloclasses for CD ROM drives?
<<<
They are just disk drives, albeit write protected.
There should be no naming conflicts, and that should be it.
About name conflicts:
Actually, there should also be no ADDRESS conficts, so, on any bus there can only be ONE device #n, be it the host itself, a disk, a tape. or anything.

hth

Proost.

Have one on me.

jpe

[Volker Halle]

Ziggy,

there may not be any 2 devices in an OpenVMS cluster with the same device name (either node$dxxx or $n$dxxx). They can exist, but there will be problems if both devices get mounted/accessed at the same time - the lock names will conflict !

If you use ALLOCLASS=0 and no port allocation classes on your AS2100A, it's devices will be called node$Dxxx, so there can be no conflicts with the rest of the cluster. You don't need to MSCP-serve them, but the AS2100A will see the MSCP-served devices from the rest of the cluster.

Regarding CDroms (DQA?): if the ES80s have the same ALLOCLASS, you would need to change the Unit-IDs of the various CDroms.
Typically, one would give each ES80 a unique ALLOCLASS, this would prevent device naming conflicts with locally attached devices.

Although you say 'you won't be sharing resources', you cannot prevent sharing of the resource/lock database. You could set LOCKDIRWT=0 on the AS2100A to prevent it from receiving resource directory entries from other nodes in the cluster, but this would cause all lock directory lookups from local applications on the AS2100A to always need to go to any of the ES80s.

Also make sure you limit the QUEUE_MANAGER from trying to fail over to or from the AS2100A. On the AS2100A issue: START/QUE/MANAGER/ON=as2100a - on the rest of the cluster, make sure there is no '*' in the queue manager list of node names.

Volker.

[comarow]

To reassure you, what you are doing is very common. It is simply using a NI cluster, something we have all being doing since the
80s.

There are a few sysgen parameters to set, make sure SCS traffic isn't being filtered,
and it works. It works all over the pace.

The gotchas are a problem with your network.
Any device names being the same
Any volume labels being the same.
Make sure it's not mastering any resources from the rest of the cluster
(set lockdirwt below the other nodes).

You're not doing anything unusual, so if anything pops up, we've all been through it.