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 |
 |
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.
Assisted Copy Operations (Alpha) |
|
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.
