Copy Operations
| | |
| ||
| ||
The purpose of a copy operation is to duplicate data on a source disk to a target disk. At the end of a copy operation, both disks contain identical information, and the target disk becomes a complete member of the shadow set. Read and write access to the shadow set continues while a disk or disks are undergoing a copy operation.
The DCL command MOUNT initiates a copy operation when a disk is added to an existing shadow set. A copy operation is simple in nature: A source disk is read and the data is written to the target disk. This is usually done in multiple block increments referred to as LBN ranges. In an OpenVMS Cluster environment, all systems that have the shadow set mounted know about the target disk and include it as part of the shadow set. However, only one of the OpenVMS systems actually manages the copy operation.
Two complexities characterize the copy operation:
Handling user I/O requests while the copy operation is in progress
Dealing with writes to the area that is currently being copied without losing the new write data
Volume Shadowing for OpenVMS handles these situations differently depending on the operating system version number and the hardware configuration. For systems running software earlier than OpenVMS Version 5.5–2, the copy operation is performed by an OpenVMS node and is known as an unassisted copy operation (see “Unassisted Copy Operations ”).
OpenVMS Version 5.5–2 introduced enhancements to the copy operation for shadow set members that are configured on controllers that implemented new copy capabilities. These enhancements enabled the controllers to perform the copy operation and are referred to as assisted copies (see “Assisted Copy Operations (Alpha)”).
OpenVMS Version 7.3 introduced the host-based minicopy operation. Minicopy and its enabling technology, write bitmaps, are fully implemented on OpenVMS Integrity servers and OpenVMS Alpha systems. For more information about the minicopy operation, see Chapter 7.
Volume Shadowing for OpenVMS supports both assisted and unassisted shadow sets in the same cluster. Whenever you create a shadow set, add members to an existing shadow set, or boot a system, the shadowing software reevaluate's each device in the changed configuration to determine whether the device is capable of supporting the copy assist.
Unassisted copy operations are performed by an OpenVMS system. The actual transfer of data from the source member to the target is done through host node memory. Although unassisted copy operations are not CPU intensive, they are I/O intensive and consume a small amount of CPU bandwidth on the node that is managing the copy. An unassisted copy operation also consumes interconnect bandwidth.
On the system that manages the copy operation, user and copy I/Os compete evenly for the available I/O bandwidth. For other nodes in the cluster, user I/Os proceed normally and contend for resources in the controller with all the other nodes. Note that the copy operation may take longer as the user I/O load increases.
The volume shadowing software performs an unassisted copy operation when it is not possible to use the assisted copy feature (see “Assisted Copy Operations (Alpha)”). The most common cause of an unassisted copy operation is when the source and target disk or disks are not on line to the same controller subsystem. For unassisted copy operations, two disks can be active targets of an unassisted copy operation simultaneously, if the members are added to the shadow set on the same command line. Disks participating in an unassisted copy operation may be on line to any controller anywhere in a cluster.
During any copy operation, a logical barrier is created that moves across the disk, separating the copied and uncopied LBN areas. This barrier is known as a copy fence. The node that is managing the copy operation knows the precise location of the fence and periodically notifies the other nodes in the cluster of the fence location. Thus, if the node performing the copy operation shuts down, another node can continue the operation without restarting at the beginning. During a copy operation, the I/O requests are processed as follows:
Read I/O requests to either side of the copy fence are serviced only from a source shadow set member.
Write I/O requests before or at the fence are issued in parallel to all members of the shadow set
Write I/O requests, after the fence, are completed first to source members, then to copy target members.
The time and amount of I/O required to complete an unassisted copy operation depends heavily on the similarities of the data on the source and target disks. It can take at least two and a half times longer to copy a member containing dissimilar data than it does to complete a copy operation on a member containing similar data.
An assisted copy does not transfer data through the host node memory. The actual transfer of data is performed within the controller, by direct disk-to-disk data transfers, without having the data pass through host node memory. Thus, the assisted copy decreases the impact on the system, the I/O bandwidth consumption, and the time required for copy operations.
Shadow set members must be accessed from the same controller in order to take advantage of the assisted copy. The shadowing software controls the copy operation by using special MSCP copy commands, called disk copy data (DCD) commands, to instruct the controller to copy specific ranges of LBNs. For an assisted copy, only one disk can be an active target for a copy at a time.
For OpenVMS Cluster configurations, the node that is managing the copy operation issues an MSCP DCD command to the controller for each LBN range. The controller then performs the disk-to-disk copy, thus avoiding consumption of interconnect bandwidth.
By default, the Volume Shadowing for OpenVMS software (beginning with OpenVMS Version 5.5–2) and the controller automatically enable the copy assist if the source and target disks are accessed through the same HSC or HSJ controller.
Shadowing automatically disables the copy assist if:
The source and target disks are not accessed using the same controller.
In the case of dual-ported disks, you can use the $QIO SET PREFERRED PATH feature to force both disks to be accessed via the same controller. See the PREFER program in SYS$EXAMPLES and see the HP OpenVMS I/O User’s Reference Manual for more information about setting a preferred path.
The shadow set is mounted on a controller that does not support the copy assist.
The shadow set member is mounted on an HSC controller with the copy assist disabled. (HSC controllers are the only controllers on which you can disable copy assists.)
The number of assisted copies specified by the DCD connection limit, available only on HSC controllers, has been reached, at which point additional copies are performed unassisted.
See “Controlling HSC Assisted Copy and Minimerge Operations” for information about disabling and reenabling the assisted copy capability.