If other nodes boot from the upgraded disk, the OpenVMS upgrade procedure automatically upgrades and runs AUTOGEN on each node when it is booted. The procedure for booting other nodes from the upgraded disk differs based on whether the upgraded disk has been made a shadow set.
Once you have successfully upgraded the system or systems and you have completed other postupgrade work (such as layered product installations), perform the following steps:
Generally, users and applications access a shadow set through the virtual unit. Occasionally, you may want to change the data on an individual shadow set member and then pass the changed data to other shadow set members.
The following series of commands demonstrates how you can dissolve and recreate the shadow set to perform specialized processes on one shadow set member and transfer the change to the other shadow set members.
The following command mounts a shadow set with three shadow set members:
$ MOUNT DSA9:/SHADOW=($45$DUA2:,$45$DUA4:,$45$DUA8:) LURK1
The following command dissolves the shadow set mounted in the previous command and makes the individual shadow set members available:
$ DISMOUNT/NOUNLOAD DSA9:
The following command mounts one former shadow set member as a disk volume outside of the shadow set:
$ MOUNT/OVERRIDE=SHADOW_MEMBERSHIP $45$DUA2: LURK1
In this command, in order to have write access, you must use the /OVERRIDE=SHADOW_MEMBERSHIP qualifier to erase the shadow set generation number. At this point, the disk is mounted as a nonshadowed volume and can be modified as required.
Before creating a new shadow set, dismount the $45$DUA2 physical disk, as follows:
$ DISMOUNT/NOUNLOAD $45$DUA2 $ MOUNT DSA9:/SHADOW=$45$DUA2: LURK1
The second command recreates the shadow set with $45$DUA2 as the only member.
Note that mounting $45$DUA2 with the /OVERRIDE=SHADOW_MEMBERSHIP qualifier automatically erased the volume shadowing generation number. If you were to mount all the former members of the shadow set at the same time, the MOUNT command would consider $45$DUA2 an unrelated volume and would determine that it requires a copy operation. This would overwrite the modifications performed earlier.
To save the current contents of $45$DUA2, add the other two former shadow set members to the new shadow set with a subsequent MOUNT command:
$ MOUNT DSA9:/SHADOW=($45$DUA4:,$45$DUA8:) LURK1
In this command, $45$DUA4 and $45$DUA8 are added to the shadow set DSA9. This recreates the original shadow set, except that each shadow set member now has the benefit of the changed data that was done to the single shadow set member.
You should think of a shadow set as a single, highly available disk unit. As such, backup techniques for nonshadowed disks apply to shadow set virtual units. However, to preserve the consistency and integrity of the shadow set, avoid removing a physical member of the shadow set without dismounting the virtual unit. If you leave some disk members of a shadow set active during the backup operation, data integrity is compromised because some disks in the shadow set may have files open. If you dismount the entire shadow set by dismounting the virtual unit, files are properly closed and, after the backup, any member of the shadow set can be used as the source of a valid backup operation.
The following list describes options that are available when backing up shadow sets that are not available with nonshadowed disks.
HSC BACKUP and RESTORE techniques are not recommended for saving and restoring the contents of a shadow set member. These HSC utilities are applicable to the disk geometry only, not to the OpenVMS file system. Although HSC BACKUP and RESTORE techniques save and restore the contents of an entire disk volume (including blocks that may not be in use by the file system on that volume), they do not save and restore specific files, groups of files, directories, or subdirectories. In addition, these utilities do not defragment a disk. Moreover, the utilities cannot restore the context of a shadow set virtual unit.
The following sections describe several approaches to shadow set backup operations.
On VAX systems, Digital does not support accessing of shadow sets from standalone BACKUP. The command procedures supplied by Digital for building standalone BACKUP kits make every effort to prevent standalone BACKUP from using volume shadowing improperly. However, these checks can easily be overridden by a well-informed and sufficiently privileged user.
Note the following restrictions for standalone BACKUP on VAX systems that use volume shadowing:
On Alpha computers, the same restrictions apply. You cannot use the standalone, menu-driven procedure included on the OpenVMS Alpha operating system distribution compact disc to perform BACKUP operations on shadow sets.
This example shows how to use volume shadowing copy operations to create an offline identical disk volume that you can then use as a backup of your shadow set. The following command creates a shadow set with one shadow set member:
$ MOUNT/SYSTEM DSA0:/SHADOW=$1$DUA10: SHADOWFACTS %MOUNT-I-MOUNTED, SHADOWFACTS mounted on _DSA0: %MOUNT-I-SHDWMEMSUCC, _$1$DUA10: (DISK01) is now a valid member of the shadow set
The following command adds a second member, $1$DUA11, to the shadow set:
$ MOUNT/SYSTEM DSA0:/SHADOW=$1$DUA11: SHADOWFACTS %MOUNT-I-SHDWMEMCOPY, _$1$DUA11: (DISK02) added to the shadow set with a copy operation
At this point you must wait for the copy operation to complete before dismounting the shadow set. When the copy operation is complete, messages are sent to the system console and to any operators enabled to receive them.
The following command dismounts the shadow set, leaving $1$DUA10 and $1$DUA11 with logically identical volumes:
$ DISMOUNT DSA0:
At this point you can re-create the shadow set with one of the volumes and keep the other as a backup, or use it as a source for the backup operation.
Generally you can use the OpenVMS Backup utility (BACKUP) with shadow sets as you do with regular volumes. (See the OpenVMS System Manager's Manual: Essentials for a description of how to back up volumes.) You can create BACKUP save sets or copies from shadow sets by using the shadow set virtual unit name instead of a physical device name as the input specifier. However, you cannot always restore to a shadow set by listing the virtual unit name as an output specifier. The main restriction to any backup restoration is that you cannot mount the target volume with the /FOREIGN qualifier. The proper procedure for a BACKUP/IMAGE restoration is described in Section 7.3.4.
The format for a BACKUP command is as follows:
BACKUP input-specifier output-specifier
The format is the same as for any BACKUP operation. The following command, for example, designates a virtual unit for the input specifier:
$ BACKUP/RECORD DSA2:[*...]/SINCE=BACKUP MTA0:23DEC.BCK
$ BACKUP/RECORD DSA2:[*...]/SINCE=BACKUP MTA0:23DEC.BCK
This command saves all files on the shadow set DSA2 that have been created or modified since the last backup and records the current time as their new backup date.
You must take special precautions when you restore a shadow set from a BACKUP/IMAGE save set. (See the OpenVMS System Manager's Manual: Essentials and OpenVMS System Management Utilities Reference Manual: A--L for a description of BACKUP/IMAGE operations with physical volumes.) A BACKUP/IMAGE operation marks the target volume as more current than the other shadow set members. This designates it as the source of copy operations if you re-create the shadow set with it.
Although you can create BACKUP save sets or copies from shadow set virtual units, you cannot mount your shadow set with the /FOREIGN qualifier to allow a BACKUP/IMAGE restoration.
You should either restore to a physical disk and then re-create the shadow set with the restored disk as a shadow set member (Example 2) or, if the save operation was a copy to a compatible disk, re-create the shadow set with that disk as a member (Example 3). The target of the BACKUP/IMAGE operation becomes the source of copy operations if you re-create the shadow set with it.
Example 1
This example shows how to perform a backup on a former shadow set member after you rebuild the shadow set.
$ MOUNT DSA0:/SHADOW=($1$DUA10:, $1$DUA11:) GHOSTVOL %MOUNT-I-MOUNTED, GHOSTVOL mounted on _DSA0: %MOUNT-I-SHDWMEMSUCC, _$1$DUA10: (DISK01) is now a valid member of the shadow set %MOUNT-I-SHDWMEMSUCC, _$1$DUA11: (DISK02) is now a valid member of the shadow set
The previous command mounts the shadow set DSA0. Make sure all copy operations are finished before you dismount the shadow set by using the following command:
$ DISMOUNT DSA0:
This command dismounts the shadow set.
$ MOUNT/SYSTEM DSA0/SHADOW=$1$DUA10: GHOSTVOL %MOUNT-I-MOUNTED, GHOSTVOL mounted on _DSA0: %MOUNT-I-SHDWMEMSUCC, _$1$DUA10: (DISK01) is now a valid member of the shadow set
This command puts the shadow set back on line without $1$DUA11. You can now perform the backup to tape while the shadow set is on line.
$ MOUNT $1$DUA11: GHOSTVOL %MOUNT-W-VOLSHDWMEM, mounting a shadow set member volume volume write locked %MOUNT-I-MOUNTED, GHOSTVOL mounted on _$1$DUA11: $ MOUNT/FOREIGN MTA0: %MOUNT-I-MOUNTED, ...
These two commands mount the former shadow set member and a magnetic tape in preparation for a BACKUP command.
$ BACKUP/IMAGE $1$DUA11: MTA0:SAVESET.BCK
This command produces a BACKUP/IMAGE save set from $1$DUA11 while the shadow set is on line with $1$DUA10.
Example 2
This example shows how to restore a shadow set from an image save set. Digital does not support restoring an image save set directly to a shadow set because the BACKUP output medium (the shadow set) must be mounted as a foreign volume.
$ DISMOUNT DSA0: $ MOUNT/FOREIGN MTA0: %MOUNT-I-MOUNTED, ... $ MOUNT/FOREIGN/OVERRIDE=SHADOW_MEMBERSHIP $1$DUA10: %MOUNT-I-MOUNTED, ...
These two commands mount the save-set magnetic tape as the input specifier and the former shadow set member as the output specifier for the restore operation.
$ BACKUP/IMAGE MTA0:SAVESET.BCK $1$DUA10:
This command restores $1$DUA10 from the save set.
$ DISMOUNT/NOUNLOAD $1$DUA10:
This command dismounts the restored volume in preparation for mounting into a shadow set.
Note
Do not attempt to add the restored volume to an existing shadow set without first dissolving the original shadow set. Mounting a restored volume into an existing shadow set will result in a copy operation erasing the restored disk.
$ MOUNT/SYSTEM DSA0/SHADOW=($1$DUA10:, $1$DUA11:) GHOSTVOL %MOUNT-I-MOUNTED, GHOSTVOL mounted on _DSA0: %MOUNT-I-SHDWMEMSUCC, _$1$DUA10: (DISK01) is now a valid member of the shadow set %MOUNT-I-SHDWMEMCOPY, _$1$DUA11: (DISK02) added to the shadow set with a copy operation
This command mounts the shadow set with the restored shadow set member. The output of the image backup operation has a newer generation number than other previous members of the shadow set. Therefore, $1$DUA10 (the restored volume) is the source of a copy operation when you form the shadow set.
Example 3
This example illustrates a BACKUP/IMAGE copy operation on a shadow set. The image backup operation stores output files contiguously, eliminating disk fragmentation. Because you must mount the output device of such operations with the /FOREIGN qualifier, you must take special steps as shown with the following commands:
$ MOUNT DSA0:/SHADOW=($1$DUA10:,$1$DUA11:) MEANDMY %MOUNT-I-MOUNTED, MEANDMY mounted on _DSA0: %MOUNT-I-SHDWMEMSUCC, _$1$DUA10: (DISK03) is now a valid member of the shadow set %MOUNT-I-SHDWMEMSUCC, _$1$DUA11: (DISK04) is now a valid member of the shadow set $ MOUNT/FOREIGN $1$DUA20: %MOUNT-I-MOUNTED, ...
The first command mounts the shadow set DSA0. The second command mounts, on $1$DUA20, the volume to be the output of the BACKUP/IMAGE operation. The /FOREIGN qualifier is required.
$ BACKUP/IMAGE/IGNORE=INTERLOCK DSA0: $1$DUA20:
This command performs the image backup using the virtual unit name as the input specifier. The image backup copy of a shadow set has a newer backup revision number than the existing members in the shadow set.
$ DISMOUNT $1$DUA20: $ DISMOUNT DSA0:
These commands dismount the target of the image backup and the shadow set, in preparation for re-creating the shadow set. Note that when you re-create the shadow set, you can lose some of the data written to the shadow set between the start of the backup operation and dismounting.
$ MOUNT/SYSTEM DSA0/SHADOW=($1$DUA10:,$1$DUA11:,$1$DUA20:) MEANDMY %MOUNT-I-MOUNTED, MEANDMY mounted on _DSA0: %MOUNT-I-SHDWMEMSUCC, _$1$DUA20: (DISK05) is now a valid member of the shadow set %MOUNT-I-SHDWMEMCOPY, _$1$DUA10: (DISK03) added to the shadow set with a copy operation %MOUNT-I-SHDWMEMCOPY, _$1$DUA11: (DISK04) added to the shadow set with a copy operation
This command rebuilds the shadow set with the image backup disk as one of the shadow set members. The other former shadow set members receive copy operations.
If a multiple-member system disk shadow set is mounted and the system crashes, the resulting crash dump information is initially written to the dump file on only one of the shadow set members. Once the dump operation has successfully completed, the unit number of the member with the written dump file is printed on the console device. Error messages display if the dump cannot be written (for example, because the path to the dump unit is unavailable or is unsuitable).
Note
The crash dump file is normally written to the original boot device, provided that it is available and on line. If that device has been removed from the shadow set, the dump file is written to the current master member of the shadow set, provided that it is available and on line.
Once the system is rebooted, the shadowing software automatically begins a merge operation. This merge operation automatically propagates the dump file to all of the other members and also corrects any other inconsistencies caused by the system crash.
You can reboot the system from either the original boot device or the current master member device. At boot time, if the paths to all of the members of the shadow set are on the same type of adapter, the shadowing software correctly designates the current master and dump device on all of the booting nodes. At boot time, several OPCOM messages display information about the status of the dump device and the reboot condition of the system.
You cannot reboot the system unless the boot device is a current member of the shadow set. When a multiple member system disk shadow set loses its boot device, a warning is printed on the console device, and an OPCOM message is displayed.
Caution
Do not add shadow set members to an existing system disk shadow set in any startup command procedure. Upon system reboot, all of the data, including the dump file, can be overwritten and therefore lost if volume shadowing automatically performs a copy operation.
On some systems, you can stipulate that multiple devices be members of the same system disk shadow set. Please refer to the system-specific manual for further details.
If you use the System Dump Analyzer (SDA) to access the dump file on the virtual unit during the merge operation, you can enter the SDA command ANALYZE/CRASH to examine the dump while the shadow set is undergoing a merge operation. If SDA accesses portions of the dump file that have not yet been merged, SDA resolves inconsistent data across the shadow set.
You can also use the Crash Log Utility Extractor (CLUE) commands to access the dump file on the virtual unit during a merge operation. CLUE commands can automatically create a footprint of the crash to a .LIS file and store it for future reference.
Volume Shadowing for OpenVMS is designed primarily to be a data availability product and not a performance product. Recognizing that the topics of performance and data availability cannot be completely separated from each other, this chapter discusses the performance effects that can result on systems using Volume Shadowing for OpenVMS. Several factors affect the performance of a shadow set, including the following:
The following sections examine how the state of a shadow set and its configuration can affect resource utilization and performance. Some guidelines for controlling the use of system resources are also provided in Section 8.3. Because there is no significant difference in the performance of a nonshadowed disk and a one-member shadow set, all discussions that follow apply to multiple-member shadow sets.
A shadow set is in a steady state when all of its members are consistent and no copy operation or merge operation is in progress. Overall, the performance of a shadow set in a steady state compares favorably with that of a nonshadowed disk. Read and write I/O requests processed by a shadow set utilize a very small amount of extra CPU processing time as compared with a nonshadowed disk. A shadow set often can process read requests more efficiently than can a nonshadowed disk because it can use the additional heads to respond to multiple read requests simultaneously.
For a shadow set in a steady state, the shadowing software handles read and write operations in the following manner:
Even though the read performance of a shadow set in steady-state has the potential for better performance, the primary purpose of volume shadowing is to provide data availability. It is not appropriate to use volume shadowing as a means to increase the read I/O throughput of your applications (by explicitly increasing the I/O work load). This is because the same level of performance cannot be expected during situations when copy or merge operations must take place to add new members or preserve data consistency, or when members are removed from the shadow set. Section 8.2 discusses performance considerations when the shadow set is in a transient state.
A shadow set is in a transient state when some or all of its members are undergoing a copy or merge operation. During merge operations, Volume Shadowing for OpenVMS ensures consistency by reading the data from one member and making sure it is the same as the data contained in the same LBNs on the other members of the shadow set. If the data is different, the shadowing software updates the LBN on all members. For copy operations, the shadowing software reads data from a source member and writes the data to the same LBN on target members.
At the same time it performs a merge or copy operation, the shadowing software continues to process application and user I/O requests. The I/O processing necessitated by a copy operation can result in decreased performance as compared with the possible performance of the same shadow set under steady-state conditions. However, if your shadow set members are configured on controllers that support the shadowing assisted copy and assisted merge operations, you can significantly improve the speed with which a shadow set performs a copy or merge operation. Volume Shadowing for OpenVMS supports both assisted and unassisted merge and copy operations.
The following list describes how the performance of a shadow set might be affected while an unassisted merge or copy operation is in progress. See Chapter 6 for a description of assisted copy and merge operations.
There are two types of performance assist: the merge assist and the copy assist. The merge assist improves performance by using information that is maintained in controller-based write logs to merge only the data that is inconsistent across a shadow set. When a merge operation is assisted by the write logs, it is referred to as a minimerge. The copy assist reduces system resource usage and copy times by enabling a direct disk-to-disk transfer of data without going through host node memory.
5423P007.HTM OSSG Documentation 22-NOV-1996 13:03:46.46
Copyright © Digital Equipment Corporation 1996. All Rights Reserved.