Clusters

This chapter shows you how to use VDM on VAXCLUSTER systems. VDM can be run on clusters that are mixed VAX andAXP architectures, however, it must be installed on at least one node of each type, and, if you are running with multiple major versions of the operating system (ie: 6.2 and 7.0); it should be installed under each version once. It can be installed in a common directory; in cases of multiple major version of OpenVMS there should be a separate exe directory for each version; define the logical VDM_EXE to point to the correct area for each node.

If you install VDM on a common disk, you need not install it on each node.  However, there are a couple of things you have to do to make it available to all nodes of the cluster:

you must define the logical names VDM_EXE and VDM_DAT on each node, preferably by executing the VDM_STARTUP procedure on each node

if you are using node specific DCLTABLES.EXE files, you will have to add the VDM command verb to each of the tables, or add the command verb to your process command table when you want it to be available _ see the preceding section.

If you don't install VDM on a common disk, then you must install it on each node for it to be available on all nodes of the cluster.

Data collection
When you run VDM on a cluster, you should have the data files on a disk that is accessible from all nodes in the cluster.  This way, you can generate the reports from any node in the cluster.  The collection procedures can be run from any node in the cluster.  Because of the way VDM is written, you can run multiple collections from different machines.  However, only one process can access the VDM data files at one time.  When you are running multiple collections, make sure that they are running at different times.

Common SYSUAF.DAT
If you have a common SYSUAF.DAT for your cluster, you can use VDM as if you were on a single Alpha AXP and VAX.  VDM will automatically find your SYSUAF.DAT using the OpenVMS-supplied logical "SYSUAF".


Multiple SYSUAF.DAT files
On the other hand, if your cluster has a separate SYSUAF.DAT for each node, you will have to direct VDM to use the SYSUAF.DAT on a different node.  To do this, define the logical sysuaf in your process logical name table.  For example:

$ DEFINE /PROCESS SYSUAF -
    NODE2::$4$DUA0:[SYS0.SYSCOMMON.SYSEXE]SYSUAF.DAT
$ VDM /REPORT=PROTECTION /OUTPUT=NODE2_PROTECTION

to create a file protection report for the users on NODE2 by running VDM on a SYSUAF on a different node. Be sure to define SYSUAF in your process table; this will prevent the system from trying to use that UAF when other users log in.

If you don't have a logical defined for SYSUAF, VDM will use the SYSUAF.DAT on your current node.


STARTUP command procedure
The VDM installation procedure creates a file, VDM_STARTUP.COM and copies it to the SYS$MANAGER directory.  This command procedure defines the system logicals VDM requires to run and must be executed on every node that you wish to run VDM data collection or reports on.

VDM/MONITOR on VAXCLUSTER
This section describes VDM/MONITOR processing on VAXcluster systems.

VDM/MONITOR will run on a cluster.  However, you should only run VDM/MONITOR on a node which has access to all the disks that you want to check.  If you have disks that are only accessible from one machine, you will have to run VDM/MONITOR on that machine, in order to check and cleanup those disks.

Permanent data file
You should not have the permanent data file shared across the cluster, because you could create a situation where two separate machines submit jobs at the same time to clean up a disk. Each running copy of VDM/MONITOR should have its own permanent data file, with only the disks that it is checking in the file.

Error and output log
These files are created by the detached process if an error occurs.  The error text will be placed in these files.  The errors from the detached process will also be signalled on the console, so it is not really necessary to give these files special consideration.

HITMAN free disk events and VDM/MONITOR
If you are using the product HITMAN from Saiga Systems to monitor free space or errors on your disks we suggest you move this functionality to VDM at your convenience. VDM allows you to customize how often your disks are checked, by disk, and provides two thresholds (worry and panic) with separate actions for each making it more flexible than the corresponding free space HITMAN event.

VDM and RA
   With Version 6 of RA it is now possible to collect data for both RA and VDM in a single RA data collection pass. Cohort V3 users will find that this decreases the data collection overhead by nearly 50%. To set this up a new command procedure has been included with RA called COMBINED_AUTOSUBMIT.COM. If VDM and RA data collections are running normally simply run this command procedure to submit SAIGA_DISK_COLLECTION_node.COM and remove the individual data collections from the queues. We do suggest having data collections working normally before making this change. Since RA’s data collection is significantly more involved than VDM’s the common collection is run during the RA data collection.