Create cluster out of two existing standalone Alpha system

[Richard Brock]

Hi.

Although I have over 20 years of OVMS experience I've yet attempted to create a cluster as follows:

Both systems - running OVMS 7.3-2 on GS160s -
are standalone. Both have their own system disks and after clustering this must remain so ie, they both must continue to use their own complement of disks and especially the system disk. (Don't ask why, please!)

I know VMS 101 teaches us to create a cluster
the first thing to do is run cluster_config or cluster_config_lan.com.
But I also know that when doing so the procedures will ask for a new root on the system disk and then create it. This is don't really want to do.

Any ideas on the least painful way to accomplish this odd task?

Thanks.

Richard

[Jan van den Ende · Accepted solution]

Richard,

really the simplest way is to cheat, or, to put it somewhat else, to introduce some redundancy ahead of time.

Simply choose [SYS1] (or any other of your liking except SYSE or SYSF )
The new node will NOT be a satellite!

Amongst other things, this will create sys$common:[sysexe]cluster_authorise.dat

easiest is to also follow these steps on node2, but MAKE SURE your cluster id & password are the same. This forms your cluster.

Your done!


What is left as a task to realise futute redundancy is rename one of the [SYS0] to something unique.
Now at any furure time you can transfer the remaining [SYS0] to the system disk that does not hold it, or the renamed one the other way, and you have a cluster with two potential system disk. If you should require still more complexity....


But the basic are almost too simple (try showing that to a U*X admin!)

Success.

Proost.

Have one on me.

jpe

[Volker Halle]

Richard,

if the node you're running CLUSTER_CONFIG.COM on is NOT currently a cluster member (i.e. F$GETSYI("CLUSTER_MEMBER") = "FALSE), then the procedure will offer:

This node is not currently a cluster member.

1. ADD to existing cluster, or form a new cluster.

So no headaches about a new root ;-) You just need to run this on both nodes and make sure you specify the same cluster group number and password ! Also think about cluster-wide device names (different allocation classes ?)

Volker.

[Robert_Boyd]

Will you be cross-mounting (and cross-connecting?) any of the disks? Will you be sharing a common authorization database?

Depending on answers to questions like these, you may want to impose port allocation classes. You can of course get away with the simpler techniques of leaving allocation class to zero and use only the nodename$device: construct if there is only minimal cross-mounting.

The cluster manual is of course full of good ideas about how to set things up once you get past the steps already mentioned.

It is quite possible that all you need to do to create your cluster is run SYSMAN to set the cluster number and password, change MODPARAMS to enable clustering and re-autogen, and reboot. That should do it.

Robert

[Robert Gezelter]

Richard,

Please be careful to verify that the UICs are either the same OR that the UICs are appropriately disjoint (different individuals always have different UICs).

Otherwise, the results can be interesting (protection remember, is UIC based)

- Bob Gezelter, http://www.rlgsc.com

[Willem Grooters]

The easy way, if you can allow local system disk: Do as Volker suggested: Just run CLUSTER_CONFIG on both machines; either use the AEXCT cluser)id and password - or copy the resulting CLUSTER_CONFIG.DAT to the other system (bad habit, perhaps, but it works ;))
When you would like to swith to a single autorization, be aware that on different systems UIC's tend to be different, even when using "default values". This aplies to VMS-specific ones as well (for instance: TCPIP-service identifiers can be different!) (as I found out in doing so...)

[Robert_Boyd]

The trickiest part of merging 2 systems into a single cluster besides UICs is the potential myriad of non-UIC identifiers with differing binary values.

It is possible to write code to fix this up fairly easily. It involves creating a mapping from one system's ID list to the other. Then using the generated info to modify the identifier list on one system to match the overlap on the other system and simultaneously updating all of the files (and any other objects) to use the new value.

Then the remaining piece is to add the IDs that were missing to the system chosen to be the base. Ideally one might consider choosing the system with the largest number of unique identifiers as the "base" system.

The trick in all this is of course ... you also have to verify that all of the overlapping identifier names map to the same business functions/permissions/personnel before you go merging things together. It's quite possible that the usage on the 2 systems was different, in which case it would be important to make sure that instead of merging such IDs, they get separated by making one of them different and making sure that the binary IDs don't overlap any others.

Once upon a time I went through a process like this for a relatively small cluster environment where fortunately there was total commonality of purpose of identifiers with the same names on different systems.

Robert