HP OpenVMS Systems Documentation

Another option for saving dump-file space is to share a single dump file among multiple computers. While this technique makes it possible to analyze isolated computer failures, dumps will be lost if multiple computers fail at the same time or if a second computer fails before you can analyze the first failure. Because boot server failures have a greater impact on cluster operation than do failures of other computers you should configure dump files on boot servers to help ensure speedy analysis of problems.

Dump files cannot be shared between architectures. However, you can share a single dump file among multiple Alpha computers, and another single dump file among multiple Integrity computers and another single dump file among VAX computers. Follow these steps for each operating system:

$ RENAME SYS$SYSDEVICE:[SYS
n.SYSEXE]SYSDUMP.DMP .OLD

Because multiple LAN and mixed-interconnect clusters coexist on a single extended LAN, the operating system provides mechanisms to ensure the integrity of individual clusters and to prevent access to a cluster by an unauthorized computer.

The following mechanisms are designed to ensure the integrity of the cluster:

• A cluster authorization file (SYS$COMMON:[SYSEXE]CLUSTER_AUTHORIZE.DAT), which is initialized during installation of the operating system or during execution of the CLUSTER_CONFIG.COM CHANGE function. The file is maintained with the SYSMAN utility.
• Control of conversational bootstrap operations on satellites.

The purpose of the cluster group number and password is to prevent accidental access to the cluster by an unauthorized computer. Under normal conditions, the system manager specifies the cluster group number and password either during installation or when you run CLUSTER_CONFIG.COM (see Example 8-13) to convert a standalone computer to run in an OpenVMS Cluster system.

OpenVMS Cluster systems use these mechanisms to protect the integrity of the cluster in order to prevent problems that could otherwise occur under circumstances like the following:

• When setting up a new cluster, the system manager specifies a group number identical to that of an existing cluster on the same Ethernet.
• A satellite user with access to a local system disk tries to join a cluster by executing a conversational SYSBOOT operation at the satellite's console.

Reference: These mechanisms are discussed in Section 10.8.1 and Section 8.2.1, respectively.

10.8.1 Cluster Group Data

The cluster authorization file, SYS$COMMON:[SYSEXE]CLUSTER_AUTHORIZE.DAT, contains the cluster group number and (in scrambled form) the cluster password. The CLUSTER_AUTHORIZE.DAT file is accessible only to users with the SYSPRV privilege.

Under normal conditions, you need not alter records in the CLUSTER_AUTHORIZE.DAT file interactively. However, if you suspect a security breach, you may want to change the cluster password. In that case, you use the SYSMAN utility to make the change.

To change the cluster password, follow these instructions:

$ RUN SYS$SYSTEM:SYSMAN

SYSMAN>

Example 10-2 illustrates the use of the SYSMAN utility to change the cluster password.

$ RUN SYS$SYSTEM:SYSMAN
SYSMAN> SET ENVIRONMENT/CLUSTER
%SYSMAN-I-ENV, current command environment: 
        Clusterwide on local cluster 
        Username SYSTEM        will be used on nonlocal nodes
SYSMAN> SET PROFILE/PRIVILEGES=SYSPRV
SYSMAN> CONFIGURATION SET CLUSTER_AUTHORIZATION/PASSWORD=NEWPASSWORD
%SYSMAN-I-CAFOLDGROUP, existing group will not be changed
%SYSMAN-I-CAFREBOOT, cluster authorization file updated
 The entire cluster should be rebooted.
SYSMAN> EXIT
$

You can adjust the maximum packet size for LAN configurations with the NISCS_MAX_PKTSZ system parameter.

10.9.1 System Parameter Settings for LANs and IPs

Starting with OpenVMS Version 7.3, the operating system (PEdriver) automatically detects the maximum packet size of all the virtual circuits to which the system is connected. If the maximum packet size of the system's interconnects is smaller than the default packet-size setting, PEdriver automatically reduces the default packet size.

Starting with OpenVMS 8.4, OpenVMS can make use of HP TCP/IP services for cluster communications using the UDP protocol. NISCS_MAX_PKTSZ will only affect the LAN channel payload size. To affect the IP channel payload size use the NISCS_UDP_PKTSZ parameter. For more information about the NISCS_UDP_PKTSZ parameter, see HELP.

10.9.2 How to Use NISCS_MAX_PKTSZ

To obtain this parameter's current, default, minimum, and maximum values, issue the following command:

$ MC SYSGEN SHOW NISCS_MAX_PKTSZ 

You can use the NISCS_MAX_PKTSZ parameter to reduce packet size, which in turn can reduce memory consumption. However, reducing packet size can also increase CPU utilization for block data transfers, because more packets will be required to transfer a given amount of data. Lock message packets are smaller than the minimum value, so the NISCS_MAX_PKTSZ setting will not affect locking performance.

You can also use NISCS_MAX_PKTSZ to force use of a common packet size on all LAN paths by bounding the packet size to that of the LAN path with the smallest packet size. Using a common packet size can avoid VC closure due to packet size reduction when failing down to a slower, smaller packet size network.

If a memory-constrained system, such as a workstation, has adapters to a network path with large-size packets, such as FDDI or Gigabit Ethernet with jumbo packets, then you may want to conserve memory by reducing the value of the NISCS_MAX_PKTSZ parameter.

10.9.3 How to Use NISCS_UDP_PKTSZ

This parameter specifies the upper limit on the size, in bytes, of the user data area in the largest packet sent by NISCA on any IP network.

NISCS_UDP_PKTSZ allows the system manager to change the packet size used for cluster communications over IP on network communication paths.

PEdriver uses NISCS_UDP_PKTSZ to compute the maximum amount of data to transmit in any packet.

Currently, the maximum payload over an IP channel is defined by one of the following three parameters. The least of the 3 values will be in effect.

• NISCS_UDP_PKTSZ SYSGEN parameter
• 1500 bytes
• IP_MTU of the interface supported by TCP/IP stack

If you decide to change the value of the NISCS_MAX_PKTSZ or NISCS_UDP_PKTSZ parameter, edit the SYS$SPECIFIC:[SYSEXE]MODPARAMS.DAT file to permit AUTOGEN to factor the changed packet size into its calculations.

10.10 Determining Process Quotas

On Alpha systems, process quota default values in SYSUAF.DAT are often higher than the SYSUAF.DAT defaults on VAX systems. How, then, do you choose values for processes that could run on Alpha systems or on VAX systems in an OpenVMS Cluster? Understanding how a process is assigned quotas when the process is created in a dual-architecture OpenVMS Cluster configuration will help you manage this task.

10.10.1 Quota Values

The quotas to be used by a new process are determined by the OpenVMS LOGINOUT software. LOGINOUT works the same on OpenVMS Alpha and OpenVMS VAX systems. When a user logs in and a process is started, LOGINOUT uses the larger of:

• The value of the quota defined in the process's SYSUAF.DAT record
• The current value of the corresponding PQL_Mquota system parameter on the host node in the OpenVMS Cluster

Example: LOGINOUT compares the value of the account's ASTLM process limit (as defined in the common SYSUAF.DAT) with the value of the PQL_MASTLM system parameter on the host Alpha system or on the host VAX system in the OpenVMS Cluster.

10.10.2 PQL Parameters

The letter M in PQL_M means minimum. The PQL_Mquota system parameters set a minimum value for the quotas. In the Current and Default columns of the following edited SYSMAN display, note how the current value of each PQL_Mquota parameter exceeds its system-defined default value in most cases.

$ RUN SYS$SYSTEM:SYSMAN
SYSMAN> PARAMETER SHOW/PQL

%SYSMAN-I-USEACTNOD, a USE ACTIVE has been defaulted on node I64MOZ 
Node I64MOZ:   Parameters in use: ACTIVE 
Parameter Name    Current    Default    Minimum    Maximum Unit  Dynamic 
--------------    -------    -------    -------    ------- ----  ------- 
PQL_DASTLM             24         24          4         -1 Ast         D 
PQL_MASTLM              4          4          4         -1 Ast         D 
PQL_DBIOLM             32         32          4         -1 I/O         D 
PQL_MBIOLM              4          4          4         -1 I/O         D 
PQL_DBYTLM         262144     262144     128000         -1 Bytes       D 
PQL_MBYTLM         128000     128000     128000         -1 Bytes       D 
PQL_DCPULM              0          0          0         -1 10Ms        D 
PQL_MCPULM              0          0          0         -1 10Ms        D 
PQL_DDIOLM             32         32          4         -1 I/O         D 
PQL_MDIOLM              4          4          4         -1 I/O         D 
PQL_DFILLM            128        128          2         -1 Files       D 
PQL_MFILLM              2          2          2         -1 Files       D 
PQL_DPGFLQUOTA     700000     700000     512000         -1 Pagelets    D 
PQL_MPGFLQUOTA     512000     512000     512000         -1 Pagelets    D 
PQL_DPRCLM             32         32          0         -1 Processes   D 
PQL_MPRCLM              0          0          0         -1 Processes   D 
PQL_DTQELM             16         16          0         -1 Timers      D 
PQL_MTQELM              0          0          0         -1 Timers      D 
PQL_DWSDEFAULT      53417      32768      16384         -1 Pagelets 
PQL_MWSDEFAULT      53417      16384      16384         -1 Pagelets 
PQL_DWSQUOTA       106834      65536      32768         -1 Pagelets    D 
PQL_MWSQUOTA       106834      32768      32768         -1 Pagelets    D 
PQL_DWSEXTENT     1619968     131072      65536         -1 Pagelets    D 
PQL_MWSEXTENT     1619968      65536      65536         -1 Pagelets    D 
PQL_DENQLM           2048       2048         64         -1 Locks       D 
PQL_MENQLM             64         64         64         -1 Locks       D 
PQL_DJTQUOTA         8192       8192          0         -1 Bytes       D 
PQL_MJTQUOTA            0          0          0         -1 Bytes       D 

In this display, the values for many PQL_Mquota parameters increased from the defaults to their current values. Typically, this happens over time when the AUTOGEN feedback is run periodically on your system. The PQL_Mquota values also can change, of course, when you modify the values in MODPARAMS.DAT or in SYSMAN. If you plan to use a common SYSUAF.DAT in an OpenVMS Cluster, with both Integrity servers and Alpha computers, remember the dynamic nature of the PQL_Mquota parameters.

10.10.3 Examples

The following table summarizes common SYSUAF.DAT scenarios and probable results on Integrity servers and Alpha computers in an OpenVMS Cluster system.

You might decide to experiment with the higher process-quota values that usually are associated with an OpenVMS Alpha system's SYSUAF.DAT as you determine values for a common SYSUAF.DAT in an OpenVMS Cluster environment. The higher Alpha-level process quotas might be appropriate for processes created on host Integrity server nodes in the OpenVMS Cluster if the Integrity server systems have large available memory resources.

You can determine the values that are appropriate for processes on your Integrity server and Alpha systems by experimentation and modification over time. Factors in your decisions about appropriate limit and quota values for each process will include the following:

• Amount of available memory
• CPU processing power
• Average work load of the applications
• Peak work loads of the applications

During the life of an OpenVMS Cluster system, computers join and leave the cluster. For example, you may need to add more computers to the cluster to extend the cluster's processing capabilities, or a computer may shut down because of a hardware or fatal software error. The connection management software coordinates these cluster transitions and controls cluster operation.

When a computer shuts down, the remaining computers, with the help of the connection manager, reconfigure the cluster, excluding the computer that shut down. The cluster can survive the failure of the computer and continue process operations as long as the cluster votes total is greater than the cluster quorum value. If the cluster votes total falls below the cluster quorum value, the cluster suspends the execution of all processes.

10.11.1 Restoring Votes

For process execution to resume, the cluster votes total must be restored to a value greater than or equal to the cluster quorum value. Often, the required votes are added as computers join or rejoin the cluster. However, waiting for a computer to join the cluster and increasing the votes value is not always a simple or convenient remedy. An alternative solution, for example, might be to shut down and reboot all the computers with a reduce quorum value.

After the failure of a computer, you may want to run the Show Cluster utility and examine values for the VOTES, EXPECTED_VOTES, CL_VOTES, and CL_QUORUM fields. (See the HP OpenVMS System Management Utilities Reference Manual for a complete description of these fields.) The VOTES and EXPECTED_VOTES fields show the settings for each cluster member; the CL_VOTES and CL_QUORUM fields show the cluster votes total and the current cluster quorum value.

To examine these values, enter the following commands:

$ SHOW CLUSTER/CONTINUOUS
 
COMMAND> ADD CLUSTER

Note: If you want to enter SHOW CLUSTER commands interactively, you must specify the /CONTINUOUS qualifier as part of the SHOW CLUSTER command string. If you do not specify this qualifier, SHOW CLUSTER displays cluster status information returned by the DCL command SHOW CLUSTER and returns you to the DCL command level.

If the display from the Show Cluster utility shows the CL_VOTES value equal to the CL_QUORUM value, the cluster cannot survive the failure of any remaining voting member. If one of these computers shuts down, all process activity in the cluster stops.

10.11.2 Reducing Cluster Quorum Value

$ SET CLUSTER/EXPECTED_VOTES=3