|
 HP Volume Shadowing for OpenVMS |
 Ensuring Shadow Set Consistency |
|
|
| |
The DCL command MOUNT initiates a copy operation when a diskis added to an existing shadow set. A copy operation is simple innature: A source disk is read and the data is written to the targetdisk. This is usually done in multiple block increments referredto as LBN ranges. In an OpenVMS Cluster environment, all systemsthat have the shadow set mounted know about the target disk andinclude it as part of the shadow set. However, only one of the OpenVMSsystems actually manages the copy operation.
Two complexities characterize the copy operation:
Volume Shadowing for OpenVMS handles these situations differentlydepending on the operating system version number and the hardwareconfiguration. For systems running software earlier than OpenVMS Version5.5-2, the copy operation is performed by an OpenVMS nodeand is known as an unassisted copy operation(see Unassisted Copy Operations).
With Version 5.5-2 and later, the copy operationincludes enhancements for shadow set members that are configuredon controllers that implement new copy capabilities. These enhancementsenable the controllers to perform the copyoperation and are referred to as assisted copies(see Assisted Copy Operations).
OpenVMS Version 7.3 introduced the host-based minicopy operation.Minicopy and its enabling technology, write bitmaps, are fully implementedon OpenVMS Alpha systems. OpenVMS VAX systems can write to shadowsets that use this feature. For more information about the minicopyoperation, see Using Minicopy for Backing Up Data (Alpha).
Volume Shadowing for OpenVMS supports both assisted and unassistedshadow sets in the same cluster. Whenever you create a shadow set,add members to an existing shadow set, or boot a system, the shadowing softwarereevaluate's each device in the changed configuration to determinewhether the device is capable of supporting the copy assist.
Unassisted Copy Operations
Unassisted copy operationsare performed by an OpenVMS system. The actual transfer of datafrom the source member to the target is done through host node memory.Although unassisted copy operations are not CPU intensive, theyare I/O intensive and consume a small amount of CPU bandwidth onthe node that is managing the copy. An unassisted copy operationalso consumes interconnect bandwidth.
On the system that manages the copy operation, user and copyI/Os compete evenly for the available I/O bandwidth. For other nodesin the cluster, user I/Os proceed normally and contend for resourcesin the controller with all the other nodes. Note that the copy operationmay take longer as the user I/O load increases.
The volume shadowing software performs an unassisted copyoperation when it is not possible to use the assisted copy feature(see Assisted Copy Operations). Themost common cause of an unassisted copy operation is when the sourceand target disk or disks are not on line to the same controllersubsystem. For unassisted copy operations, two disks can be activetargets of an unassisted copy operation simultaneously, if the membersare added to the shadow set on the same command line. Disks participating inan unassisted copy operation may be on line to any controller anywherein a cluster.
During any copy operation, a logical barrier is created thatmoves across the disk, separating the copied and uncopied LBN areas.This barrier is known as a copy fence. Thenode that is managing the copy operation knows the precise locationof the fence and periodically notifies the other nodes in the clusterof the fence location. Thus, if the node performing the copy operationshuts down, another node can continue the operation without restartingat the beginning.
Read I/O requests to either side of the copy fence are servicedonly from a source shadow set member.
Write I/O requests before or at the fence are issued in parallelto all members of the shadow set.
Write I/O requests, after the fence, are completed first tosource members, then to copy target members.
The time and amount of I/O required to complete an unassistedcopy operation depends heavily on the similarities of the data onthe source and target disks. It can take at least two and a halftimes longer to copy a member containing dissimilar data than itdoes to complete a copy operation on a member containing similardata.
Assisted Copy Operations
Unlike an unassistedcopy, an assisted copy does not transfer data through the host nodememory. The actual transfer of data is performed within the controller,by direct disk-to-disk data transfers, without having the data passthrough host node memory. Thus, the assisted copy decreases theimpact on the system, the I/O bandwidth consumption, and the timerequired for copy operations.
Shadowset members must be accessed from the same controller in order totake advantage of the assisted copy. The shadowing software controlsthe copy operation by using special MSCP copy commands, called disk copydata (DCD) commands, to instruct the controller to copy specificranges of LBNs. For an assisted copy, only one disk can be an activetarget for a copy at a time.
For OpenVMS Cluster configurations, the node that is managingthe copy operation issues an MSCP DCD command to the controllerfor each LBN range. The controller then performs the disk-to-diskcopy, thus avoiding consumption of interconnect bandwidth.
By default, the Volume Shadowing for OpenVMS software (beginningwith OpenVMS Version 5.5-2) and the controller automaticallyenable the copy assist if the source and target disks are accessedthrough the same HSC or HSJ controller.
Shadowingautomatically disables the copy assist if:
See Controlling HSC Assisted Copy and Minimerge Operations forinformation about disabling and reenabling the assisted copy capability.
|
|
