Creating a Simple Cluster

To begin, let us build a simple cluster. Suppose that several Alphas are connected to an Ethernet network and each computer has a hard drive. Now suppose that OpenVMS is installed on just one of those computers and it is booted (leave the others alone for now). After loading licenses and so forth, this computer can be made into a one-node cluster. Creating a cluster with one member is done with a script called CLUSTER_CONFIG, which displays the following information and menu. This script would be used to create the Boot Server and a File Server for the cluster.

     MANAGER> @cluster_config                        Cluster Configuration Procedure                           Executing on a Alpha System         This system is running DECnet Phase IV.         DECnet will be used for MOP downline loading.             Use CLUSTER_CONFIG.COM to set up or change an OpenVMS Cluster             Configuration.             To ensure that this procedure is executing with the required             privileges, invoke it from the system manager's account.             Enter a "?" for help at any prompt. If you are familiar with             the execution of this procedure, you may want to mute extra notes             and explanations by invoking it with "@CLUSTER_CONFIG BRIEF".         EAGLE is an Alpha system         so the following functions can be performed:     MAIN MENU        1. ADD an Alpha node to the cluster.        2. REMOVE a node from the cluster.        3. CHANGE a cluster member's characteristics.        4. CREATE a duplicate system disk for EAGLE.        5. EXIT from this procedure. 

There are several more steps in the procedure that are not included in the example. The system manager specifies the following:

• The node's name and address

• Whether the node is to be a boot server (if not, the name of the boot server)

• Whether the node is to be a file server (if not, the name of the file server)

• The name of the node's root of the system directory tree

• The voting information used for the cluster integrity algorithm

After the single-node cluster is formed, the manager would probably want to install layered products, such as TCP/IP, C++, and so on, and license them. Again, these products only have to be installed and licensed once for all of the nodes, but the licenses must have enough units for all of the nodes. See Chapter 3 for the license discussion. The manager must also create accounts for the users of the cluster. All services installed on EAGLE are available on all of the nodes without any special considerations.

Finally, to add the other nodes, use CLUSTER_CONFIG again for each one. These nodes are called satellites. Nodes may be either VAX or Alpha computers, with no restrictions on CPU speed, memory size, or devices connected to the node (e.g., both a VAX without a display or keyboard and only 12 megabytes of memory and an Alpha with display, keyboard, and mouse and several hundred megabytes of memory may be cluster members). Depending on the interconnect communications hardware configuration, up to 95 satellites can be added to the cluster. The interconnect between computers determines the limit of the number of nodes, as detailed in the next section. As CLUSTER_CONFIG is run, the manager will be instructed to boot the satellite, and it will automatically configure itself for the physical characteristics of the particular machine. In other words, the satellites do not have to be identical to EAGLE in any way. Each one can have a different CPU model, a different amount of memory, and a different number of disks. With special care a satellite can be a VAX instead of an Alpha. This configuration is not discussed further.

After all of the nodes have been configured, the cluster will have the following characteristics:

• When a satellite boots, EAGLE will serve the boot programs using Maintenance Operations Protocol (MOP) and then serve all OpenVMS files as required using Mass Storage Control Protocol (MSCP). ^[1]

• When a user logs into a satellite (or the server), SYSUAF, the login scripts, and the other files required to affect the login process will be served to the satellite.

• The user's process will be created on that satellite and will reside there until the session is complete.

• Any files accessed by that user will be served from EAGLE.

• Commands entered by the user will cause images to be loaded from EAGLE into the satellite's memory for execution.

• Assuming the queue manager is running on EAGLE, print and batch requests will be transferred to EAGLE for processing.

• The cluster-locking mechanism will control access to a file by more than one user, even write accesses.

• As more users log in to the cluster, the load will be balanced across the satellites. OpenVMS assigns new users to the least utilized node.

Failure of a satellite node or the network segment connecting a node to the cluster will not affect the cluster's performance, only the single node. Depending on how the cluster is set up, a user's session on the failed node can be forced to roll over to another node; however, failure of EAGLE will cause the entire cluster to collapse, because it is the file server for all nodes.

^[1]MSCP is a disk-independent read/write communications protocol designed to make all disk I/O requests uniform. The disk server translates the MSCP message into disk-specific operations.