[comp.os.vms] Thoughts On Creating And Using A Cluster Common System Disk...

CLAYTON@XRT.UPENN.EDU ("Clayton, Paul D.") (06/02/88)

The following is provided as food for thought in light of VMS 5.x being in the 
not to distant future and the various systems that will be going through the 
upgrade process.

It is my recommendation that all systems be installed with the 'Cluster Common
System Disk' directory structure. This 'feature' has been around since the 
beginning of V4, but has been an OPTION in the installation procedure. The 
result is a VMS system disk that has the 'funny' and sometimes hard to follow 
logical name search lists for such entities as SYS$SYSTEM. These logicals 
first point to SYS$SYSROOT:[SYSEXE], then go to SYS$COMMON:[SYSEXE]. This 
format allows files to be either 'exclusive', using the term loosely, to a 
particular system or 'shared' among all cluster members.

The basis for this recomendation is detailed below.

1. ONLY by installing even number releases of V4, which are 'remastered' 
versions of the complete VMS system, can the option be invoked to build a 
cluster common system disk (CCSD). If your system happens to be at 4.7, with a 
single system boot disk and you now have a cluster, either CI or NI, walking 
in the door, you have a lot of work to do. First is to install 4.6 (again) 
and this time select the CCSD option, then install 4.7 (again), then install 
all the options (ie. DECnet and multi-processing keys) (again) that got wiped 
due to the install. This is very time consuming and can lead to significant 
errors.

2. The type of errors that occur are the result of how VMSINSTAL functions.
The current trend is to have layered products be either contained in the 
'normal' VMS directories, for example SYS$SYSTEM, or in their own directories 
which themselves are SUB-DIRECTORIES of the 'normal' directories. Examples of 
the specific problem products are DECserver software and DECpage. Both of 
these are contained in their own directories. The problem is due to which 
version of the logical name do you use to get to the software? The system 
startup files had the logical names associated with the product pointing to 
SYS$COMMON:[xxx], while the directory as a result of building a CCSD had the 
directory off of SYS$SPECIFIC:[xxx]. The result is a 'broken' product and a 
user community that is upset. This is fixed by RENAMing directory files around 
the system disk to get the directory placement to match the logicals, or 
vice-versa. This is time consuming and error prone, and has to be done product 
by product.

3. The other alternative, for the strong willed, is to make a CCSD the 'hard' 
way. This is to go into STARTUP.COM and change the logicals for the main VMS 
system logicals, then build your own [V4COMMON] directory with appropiate 
backlinks. This is VERY time consuming and VERY error prone. Plus ALL the same 
problems in #2 are still there, which takes more time and creates more errors.

4. There is considerable interest in people with 'cluster' background in the 
job market these days. With LAVC's on the rise and the future of having CI/NI 
clusters, combined, the outlook is bright. The knowledge has to be learned
though. The school of hard knocks is the best place to learn it, if the 
company can live with the possible problems. Having a SINGLE system cluster, 
functioning with a quorum disk, is a GREAT place to start getting use to the 
way the disk is set up. It will also show the difference when installing 
layered products, at least those from DEC. The only thing missing at that 
point then will be more nodes for a multi-node cluster. When that happens, 
you will hopefully not have to mope your way around the system logicals, and 
therby the directories, attempting to find things when problems occur. You 
will have already mastered them and the only new item to deal with is the 
hardware. 

5. IMAGINE the look of surprise on your boss's face when you tell him that the 
existing system is ready for its first cluster member and it only took a day, 
OR LESS, to do it. You will be well on your way to establishing a 'guru' 
status in the organization, as well as a rep for being a very good planner.

My bottom line is that it is not easy going to a CCSD, but once you are there 
a basis has been established from which to grow, for both yourself and the 
system.

SO, when you are passing through the last versions of VMS V4 or starting V5 
and VMSINSTAL asks you if you want a CCSD, I would HIGHLY recommend that you 
say YES, and get very use to the results.

Thank you for your time and efforts in reading this article!!

pdc

Paul D. Clayton 
Address - CLAYTON%XRT@CIS.UPENN.EDU

Disclaimer:  All thoughts and statements here are my own and NOT those of my 
employer, and are also not based on, or contain, restricted information.

cmf@cisunx.UUCP (Carl M. Fongheiser) (06/07/88)

In article <8806020317.AA29481@linc.cis.upenn.edu> CLAYTON@XRT.UPENN.EDU ("Clayton, Paul D.") writes:
] 1. ONLY by installing even number releases of V4, which are 'remastered' 
] versions of the complete VMS system, can the option be invoked to build a 
] cluster common system disk (CCSD). If your system happens to be at 4.7, with a 
] single system boot disk and you now have a cluster, either CI or NI, walking 
] in the door, you have a lot of work to do. First is to install 4.6 (again) 
] and this time select the CCSD option, then install 4.7 (again), then install 
] all the options (ie. DECnet and multi-processing keys) (again) that got wiped 
] due to the install. This is very time consuming and can lead to significant 
] errors.

 [ some text deleted ]

] SO, when you are passing through the last versions of VMS V4 or starting V5 
] and VMSINSTAL asks you if you want a CCSD, I would HIGHLY recommend that you 
] say YES, and get very use to the results.
] 
] Thank you for your time and efforts in reading this article!!

If you're upgrading to V5 soon, don't bother playing around with 4.6 or
whatever.  With the V5 upgrade, your system disk is AUTOMATICALLY converted
into a cluster common disk.  It's not an option any more!


						Carl Fongheiser
						University of Pittsburgh
						...!pitt!cisunx!cmf
						cmf@unix.cis.pittsburgh.edu
						cmf@Pittvms.BITNET

OBERMAN@ICDC.LLNL.GOV ("Kevin Oberman, LLNL, 422-6955, L-156", 415) (06/08/88)

Paul Clayton's remarks on Cluster Common Disks are valid and I would stongly
urge anyone seeing the question to answer YES! 

But you won't see the question during the V5.0 installation or upgrade!
The reason is that cluster disks are MANDITORY under V5. If your disk is
not already common, it will be made so under V5.0 in either installation
or upgrade.

Even DEC figures these things out once in a while :-).

					R. Kevin Oberman
					Lawrence Livermore National Laboratory
					Internet: oberman@icdc.llnl.gov
   					(415) 422-6955

Disclaimer: Don't take this too seriously. I just like to improve my typing
and probably don't really know anything useful about anything.

IMHW400@INDYVAX.BITNET (06/09/88)

Thanks to the author of the original posting, for much food for thought.
There are a couple of points I'd like to see cleared up, though.

1)      OK, *how* do you make a single-node cluster?  When we put in our
        first VAX a year ago, it *wouldn't boot* until we set VAXCLUSTER=0!
        Yes, we have an HSC and CI hardware.  What is the magic incantation
        that will satisfy VMS as to the existence of a cluster, when there
        is only one service node?

2)      "...when putting up V5.0, and it asks you if you want the CCSD...."
        The impression I got from a recent DECUS session is that the V5.0
        installation *won't ask*; from here on *all* system disks will be
        structured as cluster-common.  Did I misunderstand something?  If
        not, this is yet another reason to become familiar with the CCSD
        structure.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Mark H. Wood    IMHW400@INDYVAX.BITNET   (317)274-0749 III U   U PPPP  U   U III
Indiana University - Purdue University at Indianapolis  I  U   U P   P U   U  I
799 West Michigan Street, ET 1023                       I  U   U PPPP  U   U  I
Indianapolis, IN  46202 USA                             I  U   U P     U   U  I
[@disclaimer@]                                         III  UUU  P      UUU  III

brent@uwovax.uwo.ca (06/10/88)

> 
> If you're upgrading to V5 soon, don't bother playing around with 4.6 or
> whatever.  With the V5 upgrade, your system disk is AUTOMATICALLY converted
> into a cluster common disk.  It's not an option any more!
> 
     Ok, I'm running 4.6, and I can't upgrade to 4.7 until we get
another upgrade to TCP/IP.  Is there any benefit to 4.7 prior to
5.0, or should I skip that level?  I already have a cluster common
system disk.  Cetainly if 5.0 cannot be scheduled by the fall (we
are a university site), it likely won't go until spring, and in
that case I'd install 4.7 asap.  Your thoughts?  Is 4.7 any "closer"
to 5.0 than 4.6?  b.

thierbac@umbc3.UMD.EDU (Ed Thierbach ) (06/15/88)

In article <8806150744.AA24120@ucbvax.Berkeley.EDU> IMHW400@INDYVAX.BITNET writes:
>Thanks to the author of the original posting, for much food for thought.
>There are a couple of points I'd like to see cleared up, though.
>
>1)      OK, *how* do you make a single-node cluster?  When we put in our
>        first VAX a year ago, it *wouldn't boot* until we set VAXCLUSTER=0!
>        Yes, we have an HSC and CI hardware.  What is the magic incantation
>        that will satisfy VMS as to the existence of a cluster, when there
>        is only one service node?
>
I had a single-node CI-based cluster for a year, consisting of a VAX 8300
and dual HSC50s.  As I recall, the system parameters were set thusly:

	VAXCLUSTER=1
	VOTES=1
	QUORUM=1
	SCSNODE="our_node_name"
	SCSSYSTEMID=our_scs_node_number

Make sure SCSNODE and SCSSYSTEMID are defined; without them, SCS may have a
hard time figuring things out.  SCSNODE should be the same as your DECnet
node name (to avoid confusion), and SCSSYSTEMID should be set according to
the formula:

	(DECnet area number * 1024) + DECnet node number

We didn't use a quorum disk; a single node worked just fine that way.
However, if you're just setting up the cluster, I'd recommend using one,
just so it's already in place when you add your second cluster node.
(If I had been working here when DEC set the 8300 up, I probably would
have had them set up a quorum disk.)  The Guide to VAXclusters tells how
to set them up.

I haven't gone through the V5 upgrade yet, but maybe it sets up the 
cluster SYSGEN parameters if it discovers you're not clustered yet.
Maybe one of the net's "V5 veterans" can fill us in.

Hope all this helps out somewhat.

--Ed Thierbach
--Roy F. Weston, Inc.
--thierbac@umbc3.umd.edu