Chapter 21: Clustering and Galaxy Systems

VMS Clusters

Clustering is a technique whereby two or more computer systems are coupled together more tightly than in a simple network. VMScluster systems can share disks and other resources and provide clusterwide access to them.

It is possible to configure a VMScluster in such a way that it does not matter which cluster member a user logs into; each system acts identically to all the others, and all the same files, printers, and queues are available.

VMScluster members may also use the same system disk (boot device), sharing one on-disk copy of the OpenVMS operating system. Certain features of the file system make it possible for each system to have some private and some shared files. This permits the sharing of a system disk while providing for some system-specific files.

The OpenVMS queuing mechanism (batch, printer, and server queues) is clusterwide; a user on each system can submit a job to any queue available in the cluster.

The network manager can also specify a single DECnet nodename to refer to the entire cluster. This name is called an alias node identifier or cluster alias. Users accessing cluster systems can use this alias as if it were an actual nodename to achieve the same kind of abstraction via DECnet.

In order to understand the implications of this type of resource sharing, imagine two users updating a record in a file at the same time. Both users could simultaneously attempt to read the same record in the same file, modify the data, and then update the record on disk. If there were no mechanism in place to coordinate such accesses, whichever update occurred first would be overwritten by the update that occurred second. In order to avoid this problem, one user's read-modify-write sequence must execute uninterrupted. The second user's accesses must be stalled until the first user is finished.

Most operating systems can perform this type of synchronization among different processes on the same system, but cluster systems can provide this service to all processes anywhere in the cluster.

The key to this type of resource sharing is the Distributed Lock Manager. The Lock Manager is made up of a clusterwide database of resource locks and the software to manage it.

When a process needs to access a resource, the Lock Manager provides the process with a resource lock for that resource, associating it with the process intending to use the resource and the type of access requested. The Lock Manager ensures that all cluster members are updated with the same lock information.

A resource lock has one of six modes, indicating the type of access requested. They are as follows:

1. EX—Exclusive. No other process will be allowed any access.

2. PW—Protected write. This process will be allowed to read and write the resource. Other processes may only read it.

3. PR—Protected read. This process intends to read the resource. No other process may write it.

4. CW—Concurrent write. This process can read and write the resource. Other processes are under no restrictions.

5. CR—Concurrent read. This process intends to read the resource. Other processes are under no restrictions.

6. NL—Null. The process does not intend to access the resource at this time, but is expressing a potential future interest in the resource. Converting an existing lock from one mode to another is faster than acquiring a new lock, so processes with intermittent interest in a resource usually lower an existing lock to NL mode, rather than releasing the lock between accesses.

Should another process anywhere in the cluster request access to the same resource, the Lock Manager grants the request only if the intended access is compatible with existing locks. Otherwise, the requesting process must wait until the other locks are released or converted to a compatible mode.

The compatibility among the lock modes is shown in Figure 21-1. One axis represents a lock already held (you may select either axis), and the other axis represents the mode of a lock being requested. The table indicates whether the requested lock is compatible with the existing lock and, therefore, whether it will be immediately granted.

Figure 21-1: Lock Mode Compatibility

Adherence to the rules of the OpenVMS Lock Manager is voluntary. A process could access a resource without acquiring a lock, thereby causing synchronization problems.

Therefore, most OpenVMS language compilers include inherent support for the Lock Manager in their I/O routines, relieving the programmer from manually acquiring locks for each resource. BLISS and Assembly Language (Macro) do not include this support, so programmers using those languages must manually call Lock Manager system services.