Document revision date: 30 March 2001

You must take special precautions when you restore a shadow set from a BACKUP/IMAGE save set. (See the OpenVMS System Manager's Manual, Volume 1: 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. Restoring an image save set directly to a shadow set is not supported 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.

$ 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.

$ 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.

8.4 Crash Dumping to a Shadowed Disk

If a multiple-member system disk shadow set is mounted and the system fails, 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).

You can enable a minimerge on shadowed system disks and write a dump to a nonshadowed, nonsystem disk of your choice by doing the following:

• Set the SHADOW_SYS_DISK system parameter to 4097
• Set the DUMPSTYLE system parameter to the appropriate setting for your system for a nonshadowed, nonsystem disk of your choice.
• Configure a disk for dump off system disk (DOSD), as described in the System Manager's Manual: Tuning, Monitoring, and Complex Systems manual

If you accidentally enable a minimerge to a system disk that receives a crash dump and you have not set up DOSD, you may be able to recover if you know which disk contains the valid dump. Remove that member, remount it, and remove the dump from that member.

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 failure.

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.

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, shadowing resolves inconsistent data across the shadow set before the read is returned to SDA.

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:

• I/O access path (local versus remote)
• Size of I/O requests
• Data access patterns (random or sequential)
• Read-to-write ratio
• Shadow set configuration
• State of a shadow set (steady or transient)
• Whether or not you use the shadowing copy and merge performance assists (see Section 9.2.2)
• Whether or not you use the minicopy operation (see Chapter 7)
• Other work load on the system utilizing common resources (CPUs, disks, controllers, interconnects)
• Striping (RAID) implementation

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 9.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.

9.1 Performance During Steady State

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 devices 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:

• Write I/O requests are issued concurrently to all members of the shadow set. Because each member must be updated before the I/O request is considered complete, the overall completion time for a write operation is determined by the member unit with the longest access time from the node issuing the write request. Depending on how the shadow set is configured and the access paths to the individual member units, you might observe a slight increase in the time it takes to complete write I/O requests. The steady state performance is generally better to a member that is locally connected because the access path is shorter and more direct than the access path to a served member. For example, you might notice degraded write performance on shadow sets that include some members that are accessed through an MSCP server across a network link, where each member is locally connected to a separate node.
• Read I/O requests are issued to only one member unit. Volume Shadowing for OpenVMS attempts to access the member unit that can provide the best completion time. In terms of I/O throughput, a two-member shadow set can satisfy nearly twice as many read requests as a nonshadowed disk (and even more throughput is possible with a three-member shadow set). The shadow set can use the additional disk read heads to respond to multiple read requests at the same time. Thus, a steady-state shadow set can provide better performance when an application or user reads data from the disk. However, the performance gains occur mainly when the read requests queued to the shadow set come in batches such that there are as many read requests as there are member units.

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 9.2 discusses performance considerations when the shadow set is in a transient state.

9.2 Performance During Copy and Merge Operations

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 before returning the I/O request. 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.

• Copy operations
  A copy operation is started on a two- or three-member shadow set either when you mount the shadow set to create it or to add a new member to an existing shadow set. During a copy operation, members that are targets of the operation cannot provide data availability until the operation completes. Therefore, the shadowing software performs the copy operation as quickly as possible to make the shadow set fully available.
  During a copy operation, the shadowing software gives equal priority to user and application I/O requests and to I/O requests necessary to complete the copy operation. The performance of a shadow set during a copy operation is reduced because:
  • The shadowing software must follow special protocols for user read and write I/O requests during a copy operation.
  • Copy operation I/O requests are large in size and have the same priority as user and application I/O requests.
  
  In addition, other system resources are utilized during a copy operation. Depending on the access path to the individual shadow set members, these resources could include the disk controller, interconnects, interconnect adapters, and systems.
  Because you explicitly start copy operations when you mount a new shadow set or add members to an existing set, you can control when the shadowing software performs a copy operation. Therefore, you can minimize the effect on users and applications in the system by limiting the number of copy operations that occur at the same time. For example, when you create new sets or add new members, try to add the sets or members during periods of low system activity, and do not mount several sets at the same time.
  You can further minimize the effect on users and applications in the system by using the minicopy operation, introduced with OpenVMS Version 7.3. The minicopy operation can significantly reduce the time it takes to return a shadow set member to shadow set. By the use of write bitmap technology, the minicopy operation copies only the data that was changed while the member was dismounted. For more information, see Chapter 7.
• Merge operations
  In contrast to copy operations, merge operations are not under the control of a user or program. The shadowing software automatically initiates a merge operation on a shadow set as a result of the failure of a node on which the shadow set is mounted.
  As in the case of a copy operation, the volume shadowing software ensures that all I/O requests to the shadow set follow appropriate protocols to ensure data consistency. However, when a shadow set is undergoing a merge operation, full data availability exists in the sense that individual members of the set are valid data sources and are accessible by applications and users on the system. Therefore, it is not urgent for the shadowing software to finish the merge operation, especially when the system is being heavily used. Because of this major distinction from a copy operation, the shadowing software implicitly places a higher priority on user activity to the shadow set. Volume Shadowing for OpenVMS does this by detecting and evaluating system load, and then dynamically controlling or throttling the merge operation so that other I/O activity can proceed without interference.
  Because the merge throttle slows merge operations when there is heavy application and user I/O activity on the system, the merge operation can take longer than copy operations. The merge throttle allows application and user activity to continue unimpeded by the merge operation when heavy work loads are detected.
  On the other hand, the read performance of a shadow set during a merge operation is reduced because the shadowing software must perform data integrity checks on all members for every read request. The volume shadowing software reads the data from the same LBN on all members of the shadow set, compares the data, and repairs any inconsistencies before returning the read data to the user.

Because read performance during a shadow set unassisted merge operation is reduced, a mechanism is provided to control the throttle on the merge I/O rate. Two logical names are available to vary the unassisted merge multiplication factor used for a virtual unit on a per-node and per-virtual unit basis.

These logicals must be defined in the system table and should be defined on each node in the cluster. The valid range for the multiplication factor is 100 to 100,000. Any value outside of this range causes the factor to default to 200. This value of 200 is displayed at the start of a shadow set merge, in the %SHADOW_SERVER-I-SSRVINIMRG message, following the word Factor .

The two logical names are:

• SHAD$MERGE_DELAY_FACTOR_DSAnnnn
  This logical is specific to a virtual unit, where nnnn represents the virtual unit number. If any important virtual units need to be merged without regard to the impact on application I/O, values as high as 100,000 can be defined.
• SHAD$MERGE_DELAY_FACTOR
  This logical applies to all shadow sets that do not have a virtual unit specific logical defined.

These two logical names are evaluated again after 100,000 merge I/Os have completed. Therefore, the factor can be adjusted while a merge is in progress.

	privacy and legal statement
5423PRO_012.HTML