| Previous | Contents | Index |
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:
| Step | Action |
|---|---|
| 1 | Decide whether to use full or selective dump files. (Selective recommended.) |
| 2 | Determine the size of the largest dump file needed by any satellite. |
| 3 |
Select a satellite whose memory configuration is the largest of any in
the cluster and do the following:
|
| 4 | Rename the dump file to SYS$COMMON:[SYSEXE]SYSDUMP-COMMON.DMP or create a new dump file named SYSDUMP-COMMON.DMP in SYS$COMMON:[SYSEXE]. |
| 5 |
Rename the old system-specific dump file on each system that has its
own dump file:
$ RENAME SYS$SYSDEVICE:[SYS n.SYSEXE]SYSDUMP.DMP .OLD The value of n in the command line is the root for each system (for example, SYS0 or SYS1). Rename the file so that the operating system software does not use it as the dump file when the system is rebooted. |
| 6 |
For each satellite that is to share the dump file, do the following:
|
| 7 | Reboot each node so it can map to the new common dump file. The operating system software cannot use the new file for a crash dump until you reboot the system. |
| 8 | After you reboot, delete the SYSDUMP.OLD file in each system-specific root. Do not delete any file called SYSDUMP.DMP; instead, rename it, reboot, and then delete it as described in steps 5 and 7. |
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:
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:
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:
| Step | Action |
|---|---|
| 1 | Invoke the SYSMAN utility. |
| 2 | Log in as system manager on a boot server. |
| 3 |
Enter the following command:
$ RUN SYS$SYSTEM:SYSMAN |
| 4 |
At the SYSMAN> prompt, enter any of the CONFIGURATION commands in
the following list.
|
| 5 | If your configuration has multiple system disks, each disk must have a copy of CLUSTER_AUTHORIZE.DAT. You must run the SYSMAN utility to update all copies. |
| Caution: If you change either the group number or the password, you must reboot the entire cluster. For instructions, see Section 8.6. | |
Example 10-2 illustrates the use of the SYSMAN utility to change the cluster password.
| Example 10-2 Sample SYSMAN Session 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.
This parameter only affects the IP channel payload and not the LAN channel payload. LAN channel payload is controlled by the NISCS_MAX_PKTSZ parameter. |
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:
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.
| WHEN you set values at... | THEN a process that starts on... | Will result in... |
|---|---|---|
| Alpha level | An Alpha node | Execution with the values you deemed appropriate. |
| Integrity server node | LOGINOUT ignoring the typically lower Integrity server level values in the SYSUAF and instead use the value of each quota's current PQL_M quota values on the Alpha system. Monitor the current values of PQL_M quota system parameters if you choose to try this approach. Increase as necessary the appropriate PQL_M quota values on the Alpha system in MODPARAMS.DAT. | |
| Integrity server level | Integrity server node | Execution with the values you deemed appropriate. |
| An Alpha node | LOGINOUT ignoring the typically lower Integrity server level values in the SYSUAF and instead use the value of each quota's current PQL_M quota values on the Alpha system. Monitor the current values of PQL_M quota system parameters if you choose to try this approach. Increase as necessary the appropriate PQL_M quota values on the Alpha system in MODPARAMS.DAT. |
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:
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
To prevent the disruption of cluster process activity, you can reduce
the cluster quorum value as described in Table 10-6.
| Technique | Description |
|---|---|
| Use the DCL command SET CLUSTER/EXPECTED_VOTES to adjust the cluster quorum to a value you specify. |
If you do not specify a value, the operating system calculates an
appropriate value for you. You need to enter the command on only one
computer to propagate the new value throughout the cluster. When you
enter the command, the operating system reports the new value.
Suggestion: Normally, you use the SET CLUSTER/EXPECTED_VOTES command only after a computer has left the cluster for an extended period. (For more information about this command, see the HP OpenVMS DCL Dictionary.)
Example: For example, if you want to change expected
votes to set the cluster quorum to 2, enter the following command:
The resulting value for quorum is (3 + 2)/2 = 2. Note: No matter what value you specify for the SET CLUSTER/EXPECTED_VOTES command, you cannot increase quorum to a value that is greater than the number of the votes present, nor can you reduce quorum to a value that is half or fewer of the votes present. When a computer that previously was a cluster member is ready to rejoin, you must reset the EXPECTED_VOTES system parameter to its original value in MODPARAMS.DAT on all computers and then reconfigure the cluster according to the instructions in Section 8.6. You do not need to use the SET CLUSTER/EXPECTED_VOTES command to increase cluster quorum, because the quorum value is increased automatically when the computer rejoins the cluster. |
| Use the IPC Q command to recalculate the quorum. | Refer to the HP OpenVMS System Manager's Manual, Volume 1: Essentials for a description of the Q command. |
| Select one of the cluster-related shutdown options. | Refer to Section 10.6 for a description of the shutdown options. |
| Previous | Next | Contents | Index |