HP OpenVMS Systems Documentation
Guidelines for OpenVMS Cluster Configurations
10.8.7 Volume Shadowing
The Volume Shadowing for OpenVMS product ensures that data is available to applications and end users by duplicating data on multiple disks. Although volume shadowing provides data redundancy and high availability, it can affect OpenVMS Cluster I/O on two levels:
|Decreased boot times||
A single system disk can be a bottleneck when booting three or more
Boot times are highly dependent on:
|Increased system and application performance||
If your OpenVMS Cluster has many different applications that are in
constant use, it may be advantageous to have either a local system disk
for every node or a system disk that serves fewer systems. The benefits
are shorter image-activation times and fewer files being served over
Reference: See Section 10.7.5 for more information.
|Reduced LAN utilization||
More system disks reduce LAN utilization because fewer files are served
over the LAN. Isolating LAN segments and their boot servers from
unnecessary traffic outside the segments decreases LAN path contention.
Reference: See Section 11.2.4 for more information.
|Increased OpenVMS Cluster availability||A single system disk can become a single point of failure. Increasing the number of boot servers and system disks increases availability by reducing the OpenVMS Cluster's dependency on a single resource.|
Arranging system disks as shown in Figure 11-3 can reduce booting time and LAN utilization.
Figure 11-3 Multiple System Disks in a Common Environment
Figure 11-3 is an OpenVMS Cluster with multiple system disks:
The use of multiple system disks in this configuration and the way that
the LAN segments are divided enable the booting sequence to be
efficient and timely.
11.2.4 Dividing an OpenVMS Cluster System
In the workstation server examples shown in Section 10.7, OpenVMS Cluster reboots after a failure are relatively simple because of the small number of satellites per server. However, reboots in the larger, OpenVMS Cluster configuration shown in Figure 11-3 require careful planning. Dividing this OpenVMS Cluster and arranging the system disks as described in this section can reduce booting time significantly. Dividing the OpenVMS Cluster can also reduce the satellite utilization of the LAN segment and increase satellite performance.
The disks in this OpenVMS Cluster have specific functions, as described in Table 11-2.
|Common disk||All environment files for the entire OpenVMS Cluster||
Environment files such as SYSUAF.DAT, NETPROXY.DAT, QMAN$MASTER.DAT are
accessible to all nodes---including satellites---during booting. This
frees the satellite boot servers to serve only system files and root
information to the satellites.
To create a common environment and increase performance for all system disks, see Section 11.3.
|System disk||System roots for Alpha 1, Alpha 2, and Alpha 3||High performance for server systems. Make this disk as read-only as possible by taking environment files that have write activity off the system disk. The disk can be mounted clusterwide in SYLOGICALS.COM during startup.|
|Satellite boot servers' system disks||System files or roots for the satellites||Frees the system disk attached to Alpha 1, Alpha 2, and Alpha 3 from having to serve satellites, and divide total LAN traffic over individual Ethernet segments.|
|Page and swap disks||Page and swap files for one or more systems||Reduce I/O activity on the system disks, and free system disk space for applications and system roots.|
In a booting sequence for the configuration in Figure 11-3, make sure that nodes Alpha 1, Alpha 2, and Alpha 3 are entirely booted before booting the LAN Ethernet segments so that the files on the common disk are available to the satellites. Enable filtering of the Maintenance Operations Protocol (MOP) on the Ethernet-to-FDDI (10/100) bridges so that the satellites do not try to boot from the system disks for Alpha 1, Alpha 2, and Alpha 3. The order in which to boot this OpenVMS Cluster is:
Reference: See Section 10.7.6 for information about
11.2.5 Summary: Single Versus Multiple System Disks
Use the information in Table 11-3 to determine whether you need a system disk for the entire OpenVMS Cluster or multiple system disks.
|Single System Disk||Multiple System Disks|
|Node may have to wait longer for access to a file on the system disk.||Node does not have to wait for access to the system disk and has faster processor performance.|
|Contention for a single resource increases.||Contention for a single resource decreases.|
|Boot time for satellites increases.||Boot time for satellites decreases.|
|Only one system disk to manage.||More than one system disk to manage.|
|Less complex system management.||More complex system management, such as coordinating system parameters and files clusterwide.|
|Lower hardware and software costs.||Higher hardware and software costs, especially if disks are shadowed.|
|Lower cost of system management because less time and experience required to manage a single system disk.||Higher cost of system management because more time and experience required to manage mutliple system disks.|
Depending on your processing needs, you can prepare either a common environment, in which all environment files are shared clusterwide, or a multiple environment, in which some files are shared clusterwide and others are accessible only by certain OpenVMS Cluster members.
Reference: For more information about managing these
files, see OpenVMS Cluster Systems.
11.3.1 Common Environment
A common OpenVMS Cluster environment is an operating environment that is identical on all nodes in the OpenVMS Cluster. A common environment is easier to manage than multiple environments because you use a common version of each system file. The environment is set up so that:
The simplest and most inexpensive environment strategy is to have one system disk for the OpenVMS Cluster with all environment files on the same disk, as shown in Figure 11-1. The benefits of this strategy are:
However, you may want to move environment files to a separate disk so that you can improve OpenVMS Cluster performance. Because the environment files typically experience 80% of the system-disk activity, putting them on a separate disk decreases activity on the system disk. Figure 11-3 shows an example of a separate, common disk.
Reference: See OpenVMS Cluster Systems for procedures to ensure
that every node in the OpenVMS Cluster can access SYSUAF.DAT in its new
11.3.3 Multiple Environments
Multiple environments can vary from node to node. You can set up an individual node or a subset of nodes to:
Figure 11-4 shows an example of a multiple environment.
Figure 11-4 Multiple-Environment OpenVMS Cluster
In Figure 11-4, the multiple-environment OpenVMS Cluster consists of two system disks: one for VAX nodes and one for Alpha nodes. The common disk contains environment files for each node or group of nodes. Although many OpenVMS Cluster system managers prefer the simplicity of a single (common) environment, duplicating environment files is necessary for creating multiple environments that do not share resources across every node. Each environment can be tailored to the types of tasks users perform and the resources they use, and the configuration can have many different applications installed.
Each of the four DSSI nodes has its own page and swap disk, offloading
the Alpha and VAX system disks on the DSSI interconnect from page and
swap activity. All of the disks are shadowed across the DSSI
interconnects, which protects the disks if a failure occurs.
11.4 Additional Multiple-Environment Strategies
This section describes additional multiple-environment strategies, such
as using multiple SYSUAF.DAT files and multiple queue managers.
11.4.1 Using Multiple SYSUAF.DAT Files
Most OpenVMS Clusters are managed with one user authorization (SYSUAF.DAT) file, but you can use multiple user authorization files to limit access for some users to certain systems. In this scenario, users who need access to all systems also need multiple passwords.
Reference: See OpenVMS Cluster Systems for the list of fields that need to be the same for a single security domain, including SYSUAF.DAT entries.
Because Alpha systems require higher process quotas, system managers
often respond by creating multiple SUSUAF.DAT files. This is not an
optimal solution. Multiple SYSUAF.DAT files are intended only to vary
environments from node to node, not to increase process quotas. To
increase process quotas, Compaq recommends that you have one SYSUAF.DAT
file and that you use system parameters to override process quotas in
the SYSUAF.DAT file with system parameters to control resources for
your Alpha systems.
11.4.2 Using Multiple Queue Managers
If the number of batch and print transactions on your OpenVMS Cluster is causing congestion, you can implement multiple queue managers to distribute the batch and print loads between nodes.
Every OpenVMS Cluster has only one QMAN$MASTER.DAT file. Multiple queue managers are defined through multiple *.QMAN$QUEUES and *.QMAN$JOURNAL files. Place each pair of queue manager files on different disks. If the QMAN$MASTER.DAT file has contention problems, place it on a solid-state disk to increase the number of batch and print transactions your OpenVMS Cluster can process. For example, you can create separate queue managers for batch queues and print queues.
Reference: See OpenVMS System Manager's Manual, Volume 1: Essentials for examples and commands
to implement multiple queue managers.
11.5 Quorum Strategies
OpenVMS Cluster systems use a quorum algorithm to ensure synchronized access to storage. The quorum algorithm is a mathematical method for determining whether a majority of OpenVMS Cluster members exists so that they can "vote" on how resources can be shared across an OpenVMS Cluster system. The connection manager, which calculates quorum as a dynamic value, allows processing to occur only if a majority of the OpenVMS Cluster members are functioning.
Quorum votes are contributed by:
The connection manager knows about the quorum disk from "quorum
disk watchers," which are any systems that have a direct, active
connection to the quorum disk.
11.5.1 Quorum Strategy Options
At least two systems should have a direct connection to the quorum disk. This ensures that the quorum disk votes are accessible if one of the systems fails.
When you consider quorum strategies, you must decide under what failure circumstances you want the OpenVMS Cluster to continue. Table 11-4 describes four options from which to choose.
|Continue if the majority of the maximum "expected" nodes still remain.||Give every node a vote and do not use a quorum disk. This strategy requires three or more nodes.|
|Continue with only one node remaining (of three or more nodes).||
This strategy requires a quorum disk.
By increasing the quorum disk's votes to one less than the total votes from all systems (and by increasing the value of the EXPECTED_VOTES system parameter by the same amount), you can boot and run the cluster with only one node as a quorum disk watcher. This prevents having to wait until more than half the voting systems are operational before you can start using the OpenVMS Cluster system.
|Continue with only one node remaining (two-node OpenVMS Cluster).||
Give each node and the quorum disk a vote.
The two-node OpenVMS Cluster is a special case of this alternative. By establishing a quorum disk, you can increase the availability of a two-node OpenVMS Cluster. Such configurations can maintain quorum and continue to operate in the event of failure of either the quorum disk or one node. This requires that both nodes be directly connected to storage (by CI, DSSI, SCSI, or Fibre Channel) for both to be quorum disk watchers.
|Continue with only critical nodes in the OpenVMS Cluster.||Generally, this strategy gives servers votes and gives satellites none. This assumes three or more servers and no quorum disk.|