Updated: 11 December 1998

OpenVMS Cluster Systems

The System Communications Architecture (SCA) defines the communications mechanisms that allow nodes in an OpenVMS Cluster system to cooperate. It governs the sharing of data between resources at the nodes and binds together System Applications (SYSAPs) that run on different Alpha and VAX computers.

SCA consists of the following hierarchy of components:

Communications Software	Function
System applications (SYSAPs)	Consists of clusterwide applications (for example, disk and tape class drivers, connection manager, and MSCP server) that use SCS software for interprocessor communication.
System Communications Services (SCS)	Provides basic connection management and communication services, implemented as a logical path, between system applications (SYSAPs) on nodes in an OpenVMS Cluster system.
Port drivers	Control the communication paths between local and remote ports.
Physical interconnects	Consists of ports or adapters for CI, DSSI, Ethernet, FDDI, and MEMORY CHANNEL interconnects.

1.4.1 System Communications

Figure 1-1 shows the interrelationships between the OpenVMS Cluster components.

Figure 1-1 OpenVMS Cluster System Communications

In Figure 1-1, processes in different nodes exchange information with each other:

• Processes can call the $QIO system service and other system services directly from a program or indirectly using other mechanisms such as OpenVMS Record Management Services (RMS). The $QIO system service initiates all I/O requests.
• A SYSAP on one OpenVMS Cluster node must communicate with a SYSAP on another node. For example, a connection manager on one node must communicate with the connection manager on another node, or a disk class driver on one node must communicate with the MSCP server on another node.
• The following SYSAPs use SCS for cluster communication:
  • Disk and tape class drivers
  • MSCP server
  • TMSCP server
  • DECnet class driver
  • Connection manager
• SCS routines provide services to format and transfer SYSAP messages to a port driver for delivery over a specific interconnect.
• Communications go through the port drivers to OpenVMS Cluster computers and storage controllers. The port driver manages a logical path, called a virtual circuit, between each pair of ports in an OpenVMS Cluster system.

Applications running on OpenVMS Cluster systems use DECnet¹ or TCP/IP (transmission control protocol and internet protocol) for application communication. The DECnet and TCP/IP communication services allow processes to locate or start remote servers and then exchange messages.

1.4.3 Cluster Alias

A DECnet feature known as a cluster alias provides a collective name for the nodes in an OpenVMS Cluster system. Application software can connect to a node in the OpenVMS Cluster using the cluster alias name rather than a specific node name. This frees the application from keeping track of individual nodes in the OpenVMS Cluster system and results in design simplification, configuration flexibility, and application availability.

1.5 System Management

The OpenVMS Cluster system manager must manage multiple users and resources for maximum productivity and efficiency while maintaining the necessary security.

1.5.1 Ease of Management

An OpenVMS Cluster system is easily managed because the multiple members, hardware, and software are designed to cooperate as a single system:

• Smaller configurations usually include only one system disk (or two for an OpenVMS Cluster configuration with both OpenVMS VAX and OpenVMS Alpha operating systems), regardless of the number or location of computers in the configuration.
• Software needs to be installed only once for each operating system (VAX and Alpha), and is accessible by every user and node of the OpenVMS Cluster.
• Users need to be added once to have access to the resources of the entire OpenVMS Cluster.
• Several system management utilities and commands facilitate cluster management.

Figure 1-2 illustrates centralized system management.

Figure 1-2 Single-Point OpenVMS Cluster System Management

The OpenVMS operating systems support a number of utilities and tools that assist you with the management of the distributed resources in OpenVMS Cluster configurations. Table 1-1 describes many of these products and indicates whether each is supplied with the OpenVMS operating system or is an optional product.

Table 1-1 System Management Tools

Tool	Supplied or Optional	Function
Accounting
VMS Accounting	Supplied	Tracks how resources are being used.
Configuration and capacity planning
LMF (License Management Facility)	Supplied	Helps the system manager to determine which software products are licensed and installed on a standalone system and on each of the computers in an OpenVMS Cluster system.
POLYCENTER Capacity Planner	Optional	Provides a capacity planning function to help system managers analyze how changes in the configuration affect user performance.
RBMS (Remote Bridge Management Software)	Optional	Maintains a database of the setup of a system's complement of network servers, and facilitates automatic loading of the servers upon system initialization.
SYSGEN (System Generation) utility	Supplied	Allows you to tailor your system for a specific hardware and software configuration. Use SYSGEN to modify system parameters, load device drivers, and create additional page and swap files.
CLUSTER_CONFIG.COM	Supplied	Automates the configuration or reconfiguration of an OpenVMS Cluster system and assumes the use of DECnet.
CLUSTER_CONFIG_LAN.COM	Supplied	Automates configuration or reconfiguration of an OpenVMS Cluster system without the use of DECnet.
POLYCENTER Console Manager (PCM) (formerly named VMScluster Console System [VCS])	Optional	Consolidates the console management of the OpenVMS Cluster system to a single, console terminal.
Event and fault tolerance
OPCOM message routing	Supplied	Provides event notification.
REMS (Remote Environment Monitoring Software)	Optional	Collects data on uninterruptible power supplies (UPSs), security systems, and the environment from computer rooms. Also provides quick responses to power, temperature, and water emergencies.
VAXsimPLUS	Supplied	Monitors system and device status and predicts failures.
Operations management
Clusterwide process services	Supplied	Allows OpenVMS system management commands, such as SHOW USERS, SHOW SYSTEM, and STOP/ID=, to operate clusterwide.
DECamds (Availability Manager for Distributed Systems)	Supplied	Collects and analyzes data from multiple nodes simultaneously, directing all output to a centralized DECwindows display. The analysis detects resource availability problems and suggests corrective actions.
DFS (Distributed File Service)	Optional	Allows disks to be served across a LAN or WAN.
DNS (Distributed Name Service)	Optional	Configures certain network nodes as name servers that associate objects with network names.
LATCP (Local Area Transport Control Program)	Supplied	Provides the function to control and obtain information from the LAT port driver.
LANCP (LAN Control Program)	Supplied	Allows the system manager to configure and control the LAN software on OpenVMS systems.
NCP (Network Control Protocol) utility	Optional	Allows the system manager to supply and access information about the DECnet for OpenVMS (Phase IV) network from a configuration database.
NCL (Network Control Language) utility	Optional	Allows the system manager to supply and access information about the DECnet--Plus network from a configuration database.
OpenVMS Management Station	Supplied	Enables system managers to set up and manage accounts and print queues across multiple OpenVMS Cluster systems and OpenVMS nodes. OpenVMS Management Station is a Microsoft Windows and Windows NT based management tool.
POLYCENTER Software Installation Utility (PCSI)	Optional	Provides rapid installations of software products.
Queue Manager	Supplied	Uses OpenVMS Cluster generic and execution queues to feed node-specific queues across the cluster.
Remote System Manager (RSM)	Optional	Automates operating system installations, layered software distribution, file backup and restore operations, and system administration.
DECmcc	Optional	Performs industry standard network and system management functions.
Show Cluster utility	Supplied	Monitors activity and performance in an OpenVMS Cluster configuration, then collects and sends information about that activity to a terminal or other output device.
SDA (System Dump Analyzer)	Supplied	Allows you to inspect the contents of memory as saved in the dump taken at crash time or as it exists in a running system. You can use SDA interactively or in batch mode.
SLS (Storage Library System)	Optional	Gives users the ability to manage collections of removable media, including magnetic tape, cartridge tape, and optical disks, to maintain a record of all information about backup or archived media.
SYSMAN (System Management utility)	Supplied	Enables device and processor control commands to take effect across an OpenVMS Cluster.
VMSINSTAL	Supplied	Provides software installations.
Performance
AUTOGEN utility	Supplied	Optimizes system parameter settings based on usage.
Monitor utility	Supplied	Provides basic performance data.
Security
Authorize utility	Supplied	Modifies user account profiles.
SET ACL command	Supplied	Sets complex protection on many system objects.
SET AUDIT command	Supplied	Facilitates tracking of sensitive system objects.
Storage management
Backup utility	Supplied	Allows OpenVMS Cluster system managers to create backup copies of files and directories from storage media and then restore them. This utility can be used on one node to back up data stored on disks throughout the OpenVMS Cluster system.
DEC File Optimizer for OpenVMS	Optional	Defragments disks by using the OpenVMS movefile subfunction.
Mount utility	Supplied	Enables a disk or tape volume for processing by one computer, a subset of OpenVMS Cluster computers, or all OpenVMS Cluster computers.
Volume Shadowing for OpenVMS	Optional	Replicates disk data across multiple disks to help OpenVMS Cluster systems survive disk failures.

• S--Supplied with the OpenVMS operating system
• O--Optional product that layers on the OpenVMS operating system

In addition to these utilities, several commands are available that allow the system manager to set parameters on HSC, HSJ, HSD, HSZ, HSG, and RF subsystems to help configure the system. See the appropriate hardware documentation for more information.

To help you understand the design and implementation of an OpenVMS Cluster system, this chapter describes its basic architecture.

2.1 OpenVMS Cluster System Architecture

Looking at Figure 2-1 from the bottom up, it illustrates the protocol layers within the OpenVMS Cluster system architecture, ranging from communications mechanisms to the users of the system. These protocol layers include:

• Ports
• System Communications Services (SCS)
• System Applications (SYSAPs)
• Other layered components

Figure 2-1 OpenVMS Cluster System Architecture

This lowest level of the architecture provides connections, in the form of communication ports and physical paths, between devices. The port layer can contain any of the following interconnects:

• CI
• DSSI
• Ethernet
• Fibre Channel
• FDDI
• MEMORY CHANNEL
• SCSI

Each interconnect is accessed by a port (also referred to as an adapter) that connects to the processor node. For example, the CI bus is accessed by way of a CI port. The interconnects are discussed in Chapter 3.

2.1.2 SCS Layer

The SCS layer provides basic connection management and communications services in the form of datagrams, messages, and block transfers over each logical path. Table 2-1 describes these services.

Table 2-1 Communications Services

Service	Delivery Guarantees	Usage
Datagrams
Information units of less than one packet	Delivery of datagrams is not guaranteed. Datagrams can be lost, duplicated, or delivered out of order.	Status and information messages whose loss is not critical Applications that have their own reliability protocols (such as DECnet)
Messages
Information units of less than one packet	Messages are guaranteed to be delivered and to arrive in order. Virtual circuit sequence numbers are used on the individual packets.	Disk read and write requests
Block data transfers
Any contiguous data in a process virtual address space. There is no size limit except that imposed by the physical memory constraints of the host system.	Delivery of block data is guaranteed. The sending and receiving ports and the port emulators cooperate in breaking the transfer into data packets and ensuring that all packets are correctly transmitted, received, and placed in the appropriate destination buffer. Block data transfers differ from messages in the size of the transfer.	Disk subsystems and disk servers to move data associated with disk read and write requests

The SCS layer is implemented as a combination of hardware and software, or software only, depending upon the type of port. SCS manages connections in an OpenVMS Cluster and multiplexes messages between system applications over a common transport called a virtual circuit. A virtual circuit exists between each pair of SCS ports and a set of SCS connections that are multiplexed on that virtual circuit.

2.1.3 System Applications (SYSAPs) Layer

The next higher layer in the OpenVMS Cluster architecture consists of the SYSAPs layer. This layer consists of multiple system applications that provide, for example, access to disks and tapes and cluster membership control. SYSAPs can include:

• Connection manager
• MSCP server
• TMSCP server
• Disk and tape class drivers

These components are described in detail later in this chapter.

2.1.4 Other Layered Components

A wide range of OpenVMS components layer on top of the OpenVMS Cluster system architecture, including:

• Volume Shadowing for OpenVMS
• Distributed lock manager
• Process control services
• Distributed file system
• Record Management Services (RMS)
• Distributed job controller

These components, except for volume shadowing, are described in detail later in this chapter. Volume Shadowing for OpenVMS is described in Section 6.6.

2.2 OpenVMS Cluster Software Functions

The OpenVMS Cluster software components that implement OpenVMS Cluster communication and resource-sharing functions always run on every computer in the OpenVMS Cluster. If one computer fails, the OpenVMS Cluster system continues operating, because the components still run on the remaining computers.

2.2.1 Functions

The following table summarizes the OpenVMS Cluster communication and resource-sharing functions and the components that perform them.

Function	Performed By
Ensure that OpenVMS Cluster computers communicate with one another to enforce the rules of cluster membership	Connection manager
Synchronize functions performed by other OpenVMS Cluster components, OpenVMS products, and other software components	Distributed lock manager
Share disks and files	Distributed file system
Make disks available to nodes that do not have direct access	MSCP server
Make tapes available to nodes that do not have direct access	TMSCP server
Make queues available	Distributed job controller

Copyright © Compaq Computer Corporation 1998. All rights reserved. Legal

4477PRO_001.HTML