topic Re: Merging system disks on two already clustered systems in Operating System - OpenVMS

Merging system disks on two already clustered systems

William Webb_2 — Mon, 02 Oct 2006 11:17:12 GMT

This isn't one of *my* projects but a colleague asked me for my thoughts about it-

He is tasked with a system consolidation where two systems have individual system disks although they are already clustered (both Alphas clustering through their respective network interfaces.

He's considering merging their system disks.
If they weren't clustered already, it'd be relatively simple, but, since they already are, it becomes, ahem, interesting-- to say the least.

Anybody been down this road before and got a list put together or any suggestions or caveats?

Thanks in advance,

WWWebb

Re: Merging system disks on two already clustered systems

Peter Zeiszler — Mon, 02 Oct 2006 15:04:00 GMT

We did this long time ago when we moved off local disks to SAN storage.

I ended up taking image of system A disk. Rebooted system A into cluster with SAN disk.
Then added new root for system B and copied all of the autogen details to that directory.
Rebooted system B into the san disk and re-ran autogen. Its like adding system B to the cluster for the first time.

There are probably easier methods but this was the most straight forward way I thought of with minimal downtime.

Re: Merging system disks on two already clustered systems

Jan van den Ende — Mon, 02 Oct 2006 15:52:08 GMT

William,

perhaps not the "easiest" way, as in, requiring the least knowledge, but what I found the "easiest" in service disruption and in amount of work:

firstly: (may/should already have been done): merge SYSUAF, RIGHTSLIST, proxy files ... all other authorisation files.
(if this is an issue, there have been several threads on it already, both here, on COV, and ATW).
Then: backup <>...]*.*. [:[SYS...] /OWN=ORIG /EXCL=[.SYSCOMMON...]*.*.*
Next:
SET FILE /ENTER=[:>:[SYS]SYSCOMMON.DIR [000000]VMS$COMMON/DIR.

Shutdown node that has root moved; change BOOTDEF_DEV and BOOT_OSFLAGS to reflect new config; boot.
DONE.

Of course, this assumes that all node specific stuff is in SYS$SPECIFIC (which usually is not a problem, but also, that all cluster-common stuff is LNMÃ©d away to a cluster-common non-sd disk (Preferably), OR, is in SYS$COMMON.
On system disks with only ONE node booting from it, the latter condition needs checking: quite often those files "fail over" to SYS$SPECIFIC.

hth

Proost.

Have one on me.

jpe

Re: Merging system disks on two already clustered systems

Wim Van den Wyngaert — Tue, 03 Oct 2006 01:14:06 GMT

"all node specific stuff is in SYS$SPECIFIC"

...

wished that was true.

sys$common:[syserr] contains files for all cluster nodes. Copy them too.

Some products install stuff in sys$common:[prodname.nodename] or alike. Check for the nodename in files.

sys$startup contains scripts specific for the node that contain node specific startup (they should be in sys$specific but offen are not).

I would compare all files on the 2 disks and try to understand what to do with each difference.

Wim

Re: Merging system disks on two already clustered systems

Peter Zeiszler — Tue, 03 Oct 2006 12:36:41 GMT

If doing the merging also make sure the 2 nodes are at same patch levels. Just in case one of those stray patches is required by the hardware.

Re: Merging system disks on two already clustered systems

William Webb_2 — Wed, 04 Oct 2006 10:46:17 GMT

After considerable ponderation of the various solutions and caveats proffered in this thread, we concurred that merging the system disks was not an option at this time due to certain project constraints.

Thanks to all who replied.

WWWebb