|
Jeff I wanted your opinion about startup.com files in a VMS Cluster environment. I work at a hospital that has a three node cluster consisting of two alpha 8400 and a GS140. Currently we have a "SYSTARTUP_VMS.COM file in a common directory. Some of other startup procedures are in the node specific directories, "SYPAGSWPFILES.COM" for example is in node specific directory for two nodes, and in a common directory for the third node. I understand that this configuration is not good, but the system still boots correctly. The "Open VMS Cluster System" manual recommended "SYSTARTUP_VMS.COM" file should be Node specific with another "COM" file in a common directory for common procedures. Where do you recommended "Startup Command Procedures" be executed from in a cluster environment. Mike from Tallahassee |
Dear Mike from Tallahassee That's a very good question, and you can
get many different answers and opinions on the subject
depending on who you talk to. Mainly, we are talking about
four, possibly five command procedures, all located in
SYS$MANAGER. They are SYCONFIG.COM, SYLOGICALS.COM,
SYPAGSWPFILES.COM, SYSTARTUP_VMS.COM and optionally
SYLOGIN.COM if you have one defined. Concerning your current set up, yes, it
will boot up correctly, but remember, should any node not
find it's SYPAGSWPFILES.COM file in it's specific directory,
it will execute the one in the common root which is tailored
for your third node. But before we go any further, some
background on the topic. In a VMS Cluster the system disk is
constructed such that each boot node sees it's own root of
directories (known as the specific root) and then the common
root (known to all nodes). This is done so that each system
root does not need to duplicate files that all systems
require, for example executable files. Most of the logical names that pertain to
the system disk are what they call "Search lists". This
means they point to two or more places. In the case of these
logical names, for any given root they point to the node's
specific root, then to the common root. So this means
whenever a system file is needed the file system first looks
in the node's specific root, and if the file is not found
there, then it looks in the common root. To look at this
structure enter in the command : $SHOW LOGICAL
SYS$SYSROOT Doing this for each node you will find
that each node has it's own first translation (the specific
root) and they all share the same second translations (the
common root). Now to get to the ROOT of your question
(no pun intended). Which root do you put these files in? My
preference is to put them all into the common root. I'll
tell you why in a moment, but first I'll present reasons for
doing otherwise. First of all, different nodes in a
cluster are typically configured differently hardware wise.
This is a good reason for putting SYCONFIG.COM in the
specific root, and maintaining a separate SYCONFIG.COM file
for each node in your cluster. And certainly if you have an
alternate page and swap device, or secondary page and swap
files, and these are different for each node, one can argue
that the file SYPAGSWPFILES.COM also be placed in the
specific root, and a separate or each node in the cluster.
Finally if your Cluster is known as a Heterogeneous Cluster
instead of a Homogeneous Cluster, which means each node is
vastly different in configuration and use (such as a
different set of users and different purpose like one for
accounting and one for payroll) then you could argue for the
other three files also being placed in the specific
root. Not me! Even if you have all of the above
conditions, I believe it is best to have all of these files
located in the common root, because it makes it so much
easier to maintain and make changes. Imagine if you had a
five node cluster, and you needed to make a change cluster
wide. Would it be easier to change one file, or five? If you
had five files to change, you might make a slight mistake in
one causing a problem that you wouldn't find until a user
complained about it. Or you might even forget to change one
node. It is hard to keep multiple files synchronized with
changes. I manage a 67 node cluster consisting of Alphas and
VAXs, with 4 system disks, and believe me, the larger your
cluster grows, the more important this becomes. If you have one file in one location, you
only make one change, and you can keep a complete history of
all changes in the comment section of the command procedure.
But now you have another problem. If you have one file that
serves all nodes in a cluster, how do you get the one
procedure to do different things based on the particular
node that it is running on, or the particular architecture
of the CPU (VAX or Alpha). Very simple! Use the lexical
function F$GETSYI. This wonderful function can give you all
sorts of great information about the particular node you are
running on, or even about other nodes in your cluster.
Here are two DCL code examples. The first
helps you determine which node you are running on. The
second shows you how to determine what kind of CPU
architecture your are running on. In the first case, if a
new node is added to the cluster, the system is alerted by
an OPCOM message that the command procedure needs to be
edited to handle the new addition. $ $ This way you can easily maintain your
cluster by having fewer files to maintain. If you have multiple system disks in your
cluster, you may want to have some of these files specified
only once in your cluster. If this is true, you still need
to have at least one of these files on each boot disk. They
could, in turn call their equivalent on a master system
disk, but this gives you a single point of failure should
that master system disk go down. So I recommend against
having a single file for a multiple SYSTEM DISK cluster. But
each system disk should have one, and only one version of
the appropriate file in the common root. I hope this helps! Sincerely! Jeff Cameron
$!*** How to determine which node is executing this
procedure
$ NODE = F$GETSYI ("NODENAME")
$ IF (NODE .EQS. "SPOCK") THEN $ GOTO SPOCK
$ IF (NODE .EQS. "KIRK") THEN $ GOTO KIRK
$ IF (NODE .EQS. "MCCOY") THEN $ GOTO MCCOY
$
$ PROCEDURE = F$ENVIRONMENT ("PROCEDURE")
$ REQUEST -
"''node' is not known to file ''procedure'. Please
EDIT."
$ GOTO DONE
$
$SPOCK:
$!*** Put commands specific to node SPOCK here.
$ GOTO DONE
$
$MCCOY:
$!*** Put commands specific to node MCCOY here.
$ GOTO DONE
$
$KIRK:
$!*** Put commands specific to node KIRK here.
$ GOTO DONE
$
$DONE:
$!*** How to determine the CPU architecture
$ ARCH = F$GETSYI ("ARCH_NAME")
$
$ IF (ARCH .EQS. "Alpha")
$ THEN
$ RUN/DETACHED ORDER_PROCESSING_AXP.EXE
$ ELSE
$ ENDIF
$
$ IF (ARCH .EQS. "VAX")
$ THEN
$ RUN/DETACHED ORDER_PROCESSING_VAX.EXE
$ ELSE
$ ENDIF
$
DCL | Utilities | Management | Tips