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