![[Digital logo]](../../IMAGES/DIGITAL-LOGO.GIF){kind=logo}
![[HR]](../../IMAGES/REDBAR.GIF)
In a booting sequence for the configuration in Figure 8-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 7.7.6 for information about extended LANs.
Use the information in Table 8-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. |
| Less hardware and software expense. | More hardware and software expense, especially if disks are shadowed. |
| Less expense for system management time and experience. | More expense for system management time and experience. |
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.
The following are the most frequently used and manipulated OpenVMS Cluster environment files:
Reference: For more information about managing these files, see OpenVMS Cluster Systems.
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 8-1. The benefits of this strategy are:
For an OpenVMS Cluster in which every node share the same system disk and environment, most common environment files are located in the SYS$SYSTEM directory.
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 8-3 shows an example of a separate, common disk.
If you move environment files such as SYSUAF.DAT to a separate, common disk, SYSUAF.DAT will not be located in its default location of SYS$SYSTEM:SYSUAF.DAT.
Reference: See OpenVMS Cluster Systems for procedures to ensure that every node in the OpenVMS Cluster can access SYSUAF.DAT in its new location.
Multiple environments can vary from node to node. You can set up an individual node or a subset of nodes to:
Figure 8-4 shows an example of a multiple environment.
Figure 8-4 Multiple-Environment OpenVMS Cluster
In Figure 8-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.
This section describes additional multiple-environment strategies, such as using multiple SYSUAF.DAT files and multiple queue managers.
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.
Be careful about security with multiple SYSUAF.DAT files. The OpenVMS VAX and OpenVMS Alpha operating systems do not support multiple security domains.
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, Digital 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.
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: Essentials for examples and commands to implement multiple queue managers.
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:
Each OpenVMS Cluster system can include only one quorum disk. The disk cannot be a member of a shadow set, but it can be the system disk.
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.
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 8-4 describes four options from which to choose.
| Strategy Option&185; | Description |
|---|---|
| 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 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 CI or DSSI nodes for both nodes to both 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. |
Reference: For more information about quorum disk management, see OpenVMS Cluster Systems.
OpenVMS Cluster state transitions occur when a system joins or leaves an OpenVMS Cluster system and when the OpenVMS Cluster recognizes a quorum-disk state change. The connection manager handles these events to ensure the preservation of data integrity throughout the OpenVMS Cluster.
State transitions should be a concern only if systems are joining or leaving an OpenVMS Cluster system frequently enough to cause disruption.
A state transition's duration and effect on users and applications is determined by the reason for the transition, the configuration, and the applications in use. By managing transitions effectively, system managers can control:
The following guidelines describe effective ways of dealing with transitions so that you can minimize the actual transition time as well as the side effects after the transition.
| Parameter | Description |
|---|---|
| QDSKINTERVAL | Specifies the quorum disk polling interval. |
| RECNXINTERVL | Specifies the interval during which the connection manager attempts to restore communication to another system. |
| TIMVCFAIL | Specifies the time required for detection of a virtual circuit failure. |
Reference: For more detailed information about OpenVMS Cluster transitions and their phases, system parameters, quorum management, see OpenVMS Cluster Systems.
OpenVMS Alpha Version 7.1 and OpenVMS VAX Version 7.1 provide two levels of support for mixed-version and mixed-architecture OpenVMS Cluster systems. These two support types are warranted and migration.
Warranted support means that Digital has fully qualified the two versions coexisting in an OpenVMS Cluster and will answer all problems identified by customers using these configurations.
Migration support is a superset of the Rolling Upgrade support provided in earlier releases of OpenVMS and is available for mixes that are not warranted. Migration support means that Digital has qualified the versions for use together in configurations that are migrating in a staged fashion to a newer version of OpenVMS VAX or to OpenVMS Alpha. Problem reports submitted against these configurations will be answered by Digital. However, in exceptional cases, Digital may request that you move to a warranted configuration as part of answering the problem.
Migration support will help customers move to warranted OpenVMS Cluster version mixes with minimal impact on their cluster environments. Figure 8-5 shows the level of support provided for all possible version pairings.
Figure 8-5 OpenVMS Cluster Version Pairings
Note that Digital does not support the simultaneous use of Version 7.1 with Version 6.1 (or earlier versions) in an OpenVMS Cluster. In many cases, mixing Version 7.1 with versions prior to Version 6.2 will operate successfully, but Digital cannot commit to resolving problems that occue in such configurations.
OpenVMS Alpha and OpenVMS VAX systems can work together in the same OpenVMS Cluster to provide both flexibility and migration capability. You can add Alpha processing power to an existing VAXcluster, enabling you to utilize applications that are system specific or hardware specific.
Figure 8-5 depicts the OpenVMS version pairs for which Digital provides migration and warranted support.
OpenVMS Alpha Version 7.1 and OpenVMS VAX Version 7.1 enable VAX boot nodes to provide boot service to Alpha satellites and Alpha boot nodes to provide boot service to VAX satellites. This support, called cross-architecture booting, increases configuration flexibility and higher availability of boot servers for satellites.
Two configuration scenarios make cross-architecture booting desirable:
You cannot perform OpenVMS operating system and layered product installations and upgrades across architectures. For example, you must install and upgrade OpenVMS Alpha software using an Alpha system. When you configure OpenVMS Cluster systems that take advantage of cross-architecture booting, ensure that at least one system from each architecture is configured with a disk that can be used for installations and upgrades.
System disks can contain only a single version of the OpenVMS operating system and are architecture specific. For example, OpenVMS VAX Version 7.1 cannot coexist on a system disk with OpenVMS Alpha Version 7.1.
In any system, hardware and electrical failures as well as human errors occur. All important data must be backed up to limit the effects of these errors. You can do this in a number of ways, depending on the time and resources available.
| Step | Description |
|---|---|
| 1 | Decide how much lost work is acceptable in the event of a failure. This determines how often the data needs to be backed up. |
| 2 | Decide how long the data can remain unavailable while it is being backed up. This determines the methods of backup. |
| 3 |
Establish a backup schedule, including the frequency and times of the
day and week that backups will occur.
Determine:
|
| 4 | Make sure that sufficient backup media are available. Determine both the initial amount of backup media needed and its growth rate. |
| 5 | Determine if your backup strategy requires backup media to be stored off site. |
Table 8-6 describes ways to provide a copy of data for backup.
| Type of Data | Backup Method |
|---|---|
| Database is continually changing; transactions cannot be lost. |
Use a combination of database backup (at a time when it is known to be
static) and journaling transactions to the database.
Reference: See the following manuals for additional information:
|
| Data must be accessible at all times, including nights and weekends. | Use Volume Shadowing for OpenVMS software to accomplish rapid disk backup. Remove a member from a three-member shadow set by dismounting the shadow set, remounting the shadow set with two members, and copying the third disk to magnetic tape. After this, the third disk can be included again in the shadow set. |
| Data can be unavailable for an extended period of time for backup. |
Use the OpenVMS Backup utility (BACKUP) to make an image backup of a
volume or a file-by-file copy of specified sets of files. BACKUP can
make a copy to another disk (or set of disks) or to magnetic tape.
Restoring from an image copy requires that the entire image be written
to a disk. When you restore specific files, they are copied from the
restored disk to the intended destination.
On the other hand, an image copy is faster than a file-by-file copy, which copies files one at a time. Restoring a single file from the backup copy is easy. Also, a file-by-file restore greatly reduces fragmentation of the restored disk. |
| Data is static. | Archiving copies of the data on magnetic tape and excluding the online files from other backup procedures may be sufficient. Examples are program sources, documentation files, and distribution kits. |
| Scratch files and intermediate files. | You can choose not to provide any backup for these files. |
Backup tape storage provides the least expensive storage medium. Tapes are the most common medium for offline storage and provide a range of capacities, cost, and shelf life. In general, tape storage is removable and generally off line.
Backup procedures are described in detail in the following manuals:
With current tape-drive technology, you can initiate a large backup operation that completes without operator intervention (that is, changing tapes). Such unattended backups can save significant time and reduce staffing costs. Cartridge tape loaders with tape magazines, such as the Tx8x7 or the TA91, allow unattended backups of up to nearly 42 GB of online storage. Backups can also be performed on robot-accessible media, such as the StorageTek® 4400 ACS through the TC44 interconnect adapter, which provides terabyte capacity for backup archives.
Archive/Backup System for OpenVMS is a replacement for the Storage Library System (SLS). Archive/Backup provides lower system management costs, reduced equipment costs, and data security. It uses the POLYCENTER Media Library Manager (MLM) and the POLYCENTER Media Robot Manager (MRM) to move data to inexpensive tapes, and allows you to find and restore backed up and archived data easily. POLYCENTER MLM and MRM are the first Digital products to provide OpenVMS users secure, highly reliable, fully automated access to tape and optical removable media through cost-effective media robots, such as the Odetics 5480 and the Tx8x7 family.
You can attach the StorageTek 4400 ACS, a storage silo, to either an HSC using the TC44 adapter or directly to the XMI bus of a system using a KCM44 adapter. The StorageTek Silo automates access to a library of IBM 3480 compatible cartridge tapes. The library can contain up to 16 library storage modules. Each module can hold up to 1.2 TB of data in 6000 tape cartridges. A robotic arm can find and mount a requested tape within 45 to 90 seconds. Data movement for tape applications, such as the OpenVMS Backup utility, is performed the same way as with a TA90 tape drive.
Table 8-7 describes the performance and capacity of various tape drives and the interconnects to which they attach.
| Interconnect | Description |
|---|---|
| CI (STI tapes) | The TA92 can transfer at a rate of 2.6 MB/s. Its magazine of IBM 3480 compatible cartridge tapes lets it back up 38 GB unattended. To achieve highest performance, connect the TA92 through a KDM70 controller or configure it with multiple CI adapters, so that the path to the tape drives is separate from the path to the disk drives. |
| DSSI | The TF867 offers the best tape performance. Its magazine of half-inch cartridge tapes can hold up to 42 GB of data for unattended backup. Its transfer rate is 0.8 MB/s. The TF857 can read TK50 and TK70 tapes, and its magazine can hold up to 18 GB of data. |
| SCSI | The TSZ07 allows SCSI configurations to access 9-track reel-to-reel tapes. It has a capacity of 140 MB per reel and a 750 KB/s transfer rate. The TZK10 offers a less expensive but slower-performing tape solution for SCSI configurations. It uses a quarter-inch cartridge that holds 525 MB and can transfer at a rate of 200 KB/s. |
One of the benefits of OpenVMS Cluster systems is that multiple computers can simultaneously access storage devices connected to a OpenVMS Cluster storage interconnect. Together, these systems provide high performance and highly available access to storage.
6318P008.HTM OSSG Documentation 26-NOV-1996 11:20:23.12
Copyright © Digital Equipment Corporation 1996. All Rights Reserved.