Preparing to Install › Preparing to Install Job Management Manager › Installing in an OpenVMS Cluster › Choosing Installation Directories

Choosing Installation Directories

CA Technologies supports Job Management Manager in a homogeneous OpenVMS cluster or a mixed cluster. A mixed OpenVMS cluster is one that has mixed architecture, mixed versions, or both. A mixed-architecture cluster has both Integrity and Alpha systems. A mixed version cluster has different nodes at different operating system versions. A cluster may also be mixed with both Alpha and Integrity nodes that are each running different versions of OpenVMS. For the manager to function correctly, each machine must have its own license. Nodes with the same architecture or the same system version should share executables. All other files must be shared on a cluster common disk. You can accomplish this set up as follows:

1. Select a common directory on a disk that:
   • Is served cluster-wide
   • Has at least 5,000 free blocks

   It is preferable to use a cluster member fault-tolerant disk—that is, a disk hosted on a multi-path storage controller and physically connected to more than one cluster member.

   When the installation procedure prompts for a pathname to the cluster common files area, provide the pathname to the selected storage area. For example, if the logical name of the designated shared disk is SHARED$DISK, the proposed pathname could be SHARED$DISK:[NSCHED].

   Note: The default answer to the prompt for the common disk, SYS$COMMON:[NSCHED], is only valid on homogeneous clusters and on standalone nodes.

   Only these clusters may have a system disk that is shared among all nodes. In a mixed-architecture cluster, a minimum of two system disks are required, one for Integrity and one for Alpha. Do not choose the default answer to the prompt on these clusters.

   The directory will be created by the installation procedure, if it does not yet exist. You do not need to create it manually prior to installation.

2. Select a platform-specific directory that:
   • Is common to all nodes with the same architecture (Integrity, Alpha) and system version
   • Has at least 30,000 or 56,000 free blocks, for Alpha or Integrity, respectively.

   When the installation procedure prompts for a pathname to the node-specific files area, specify the selected directory. As long as there is sufficient space available on the device SYS$COMMON, selecting the default answer to the prompt, SYS$COMMON:[NSCHED] is a safe choice.

   In a completely homogeneous cluster where all machines are of the same architecture and all machines are running an identical version of OpenVMS and patches, the node-specific area may be shared in order to save space. If the nodes share a system disk, this sharing of space happens automatically. In heterogeneous clusters, nodes of different types do not necessarily share system disks, and SYS$COMMON points to different locations. This device is safe to select. If you relocate files, you must select distinct directories for each node type.

   Note: The installation procedure stops running processes it encounters. When installing on a cluster, you save time if you do not automatically start the software after installation on each node. After you finish installing on the last node, run startup and IVP for each node.

3. Install on all cluster members.

   Repeat the installation on each of the cluster nodes where the manager will be needed. Provide a directory name for the system specific directory according to step 2. The default value for the system specific directory works in all types of clusters.

   Note: Installing the manager on one node in a cluster does not allow you to run the manager on other nodes by simply running the startup procedure. You must run the kit installation procedure on every member, even in a homogeneous cluster environment.

4. Start the manager on all cluster members on which it was installed. By default, the load-balancing mechanism will be engaged in a cluster environment. Verify the result of the load balancing startup by using one of the following commands:

   $ SCHEDULE SHOW STATUS
   or
   $ SCHEDULE SHOW LOAD_BALANCE
   

   Note: Basic load balancing may not provide desired results in a mixed-architecture cluster. We recommend observing the results on a few batches of jobs, then either using specific node restrictions for some or all jobs, or designing load-balance groups that restrain the execution of given jobs to selected cluster member subsets.

   Important! Be careful when making assumptions about which node is the default node, or which architecture the default node uses. Because batch queues may not be distributed across architectures or nodes, care should also be taken when using batch mode jobs.