Shared System disk in cluster

[Zahid Ghani]

I have a 2-node cluster, each node with its own system disk.(VMS 7-31) I want to use disks in a storage module as system disk shared between the 2 nodes. What is recommended way of achieving this? thanks in adavnce.

[Mac Lilley]

Hello Zahid

It depends very much on how your existing cluster is configured.

You should check out the cluster documentation available at http://h7100.www7.hp.com/doc/731final/4477/4477pro.html

HTH

ML

[Ian Miller.]

A non-trivial excerise. RTFM but
basically copy one of the system disks to a disk of at least the same capacity in the shared storage. Examine startup files on both system disks and create common startup files taking account any differences on the shared disk. Create a second root on the that disk using SYS$MANAGER:CLUSTER_CONFIG_LAN.COM
You may wish to continue using the page and swap files on the current system disks - in which case make suitable edits in SYPAGSWPFILES .COM. Ditto for dump files (read up about DOSD).

[Jan van den Ende]

Zahid,

most important is deciding WHAT is common and WHAT is specific. As long as only one node boots off a system root, the difference is not that important, and often it gets blurred.

A multi-node systemdisk has topdirectories [SYSn] per node, and a topdir [VMS$COMMON].
The real trick is, in each [SYSn] there is a subdir [SYSCOMMON] that is only a pointer (alias) to VMS$COMMON. Physically it is not really there, but functionally it is.
CLUSTER_CONFIG.COM creates the base files in the correct locations. Now it is YOU who has to do the merging of everything you ever added to your systems, and EACH time you have to decide: CAN this be common (same code, same setups, whatever) or is it REALLY node-specific (device specifications, network definitions, that kind of stuff).
Bear in mind that eg, defining logical names or queues or whatever that contain the different nodenames, this code can still be common:

$ node = f$getsyi("nodename")
$ define/SYSTEM WHATEVER somename_'node'

Takes a little more effort setting up, but pays back manyfold in having only one procedure to maintain, and always being sure that it is the same code all over.

(btw, not EVERYTHING works flawless using Cluster_Wide logical names, but THEY also offer REAL convenience)


You may be pretty confident that unaltered, OS-delevered files are at the correct location.

Hope I didn't overwhelm you, but it REALLY is worth the effort: with two system disks, you are effectively maintaining two systems + some overhead; with one disk, you maintain one system + the less overhead!!

HTH,

Jan

[Dieter Rossbach]

Consider this as well:

To boot a system from a disk, the system has to have physical access to that disk. This is true with HS- or SAN-based disks, where each systm has a controller that connects that system directly to the storage system.

There is one exception to that rule: on system acts as boot node, the other as satellite. But then, system 2 depends on the availability of system 1.

Regards

Dieter

[Zahid Ghani]

Thanks for your replies.
This is what i did:
I have two nodes, Node1 and node2 with thier own system disks. I (image)copied node1 system disk to a new disk. Booted node 1 from this new disk. Ran Cluster_ config to create sys1 directory. On reboot the second node 'hung' while complainig about root directory.
The reason I posted this question was 'is there recommended way to create the system disk eg do you create 2 standalone systems and then run cluster _config on a particular node to create the second sys share, or from an existing cluster do you need to run Cluster-config.

[Ian Miller.]

existing node runs cluster config.
Did you change the boot flags of the node booting from SYS1?