HP OpenVMS Systems Documentation

The OpenVMS operating system, which runs on each node in an OpenVMS Cluster, includes several software components that facilitate resource sharing and dynamic adjustments to changes in the underlying hardware configuration.

If one computer becomes unavailable, the OpenVMS Cluster system continues operating because OpenVMS is still running on the remaining computers.

1.3.1 OpenVMS Cluster Software Functions

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

SCA consists of the following hierarchy of components:

1.4.1 System Communications

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 communicates with a SYSAP on another node using a logical path called connection. For example, a connection manager on one node communicates with the connection manager on another node, or a disk class driver on one node communicates 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
  • SCA$TRANSPORT, which provides node-to-node communications to the intracluster communication (ICC) programming interface, available through ICC system services, and to the distributed queue manager
• SCS routines provide connection setup and services to format and transfer SYSAP messages to a port driver for delivery over a specific interconnect.
• Communications go through the port drivers to port drivers on other OpenVMS Cluster computers and storage controllers. A port driver manages a logical path, called a virtual circuit, between each pair of ports in an OpenVMS Cluster system. A virtual circuit provides reliable message delivery for the connections multiplexed upon it.
  Starting with OpenVMS Version 8.4, cluster systems can use Transmission Control Protocol and Internet Protocol (TCP/IP) stack for cluster communication. PEDRIVER is enhanced with the capability to use TCP/IP in addition to LAN for cluster communication. For more information, see Chapter 3.

Applications running on OpenVMS Cluster systems use TCP/IP, DECnet, or ICC for application communication.

ICC allows processes to efficiently exchange messages with processes running on other cluster members using system communications services and the underlying cluster interconnect. The DECnet and TCP/IP communication services allow processes to locate or start remote servers and then exchange messages.

DECnet provides a feature known as a cluster alias. A cluster alias is a collective name for the nodes in an OpenVMS Cluster system.

Application software can use the cluster alias as the name to connect to a node in the OpenVMS Cluster. DECnet chooses the node to which the application makes a connection. The use of a cluster alias frees the application from keeping track of individual nodes in the OpenVMS Cluster system and results in design simplification, configuration flexibility, and application availability. It also provides a mechanism for load balancing by distributing incoming connections across the nodes comprising the cluster.

1.4.4 failSAFE IP

You can configure a standby failover target IP address that failSAFE IP assigns to multiple interfaces on a node or across the OpenVMS Cluster system. When, for example, a Network Interface Controller fails or a cable breaks or disconnects, failSAFE IP activates the standby IP address so that an alternate interface can take over to maintain the network connection. If an address is not preconfigured with a standby, then failSAFE IP removes the address from the failed interface until it recovers. When the failed interface recovers, failSAFE IP detects this and can return its IP address.

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 co-operate as a single system:

• Smaller configurations usually include only one system disk (or two for an OpenVMS Cluster configuration with both OpenVMS Alpha and OpenVMS Integrity server operating systems), regardless of the number or location of computers in the configuration.
• Software must be installed only once for each operating system (Alpha or Integrity servers), and is accessible by every user and node of the OpenVMS Cluster.
• Users must be added once to access 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 system supports a number of utilities and tools to assist you with the management of the distributed resources in OpenVMS Cluster configurations. Proper management is essential to ensure the availability and performance of OpenVMS Cluster configurations.

OpenVMS and its partners offer a wide selection of tools to meet diverse system management needs. Table 1-2 describes the HP products available for cluster management and indicates whether each is supplied with the operating system or is an optional product, which is purchased separately. For information about OpenVMS Partners and the tools they provide, see the OpenVMS System Management website:

http://h71000.www7.hp.com/openvms/system_management.html

OpenVMS Partners offer a wide selection of tools to meet diverse system management needs. The types of tools are described in the following list:

• Schedule managers
  Enable specific actions to be triggered at determined times, including repetitive and periodic activities, such as nightly backups.
• Event managers
  Monitor a system and report occurrences and events that may require an action or that may indicate a critical or alarming situation, such as low memory or an attempted security breaking.
• Console managers
  Enable a remote connection to and emulation of a system console so that system messages can be displayed and commands can be issued.
• Performance managers
  Monitor system performance by collecting and analyzing data to allow proper tailoring and configuration of system resources. Performance managers might also collect historical data for capacity planning.

For information about OpenVMS Partners and the tools they provide, see the OpenVMS System Management website:

http://h71000.www7.hp.com/openvms/system_management.html 

In addition to these utilities and partner products, several commands are available that allow the system manager to set parameters on Fibre Channel, SCSI and SAS storage subsystems to help configure and manage the system. See the appropriate hardware documentation for more information.