Document revision date: 15 July 2002 | |
Previous | Contents | Index |
This chapter describes the minicopy feature of Compaq Volume Shadowing for OpenVMS introduced in OpenVMS Version 7.3. Minicopy and its enabling technology, write bitmaps, are fully implemented on OpenVMS Alpha systems. OpenVMS VAX nodes can write to shadow sets that use this feature but they can neither create master write bitmaps nor manage them with DCL commands. In a mixed-architecture OpenVMS Cluster system, only one Alpha system is required in order to use minicopy.
The primary purpose of minicopy is to shorten the time it takes to
return a shadow set member to the shadow set. The shadow set member is
typically removed for the purpose of backing up the data and is then
returned to membership in the shadow set.
7.1 What Is Minicopy?
A minicopy operation is a streamlined copy operation. Minicopy ensures that the data on a shadow set member, when returned to the shadow set, is identical to the data in the shadow set.
A write bitmap tracks writes to a shadow set and is used to direct a minicopy operation when a shadow set member is returned to the shadow set.
Prior to the removal of a shadow set member, application writes are sent directly to the shadow set (also known as the virtual unit), as shown in Figure 7-1.
Figure 7-1 Application Writes to a Shadow Set
If you specify the minicopy qualifier (/POLICY=MINICOPY[=OPTIONAL]) when you dismount a shadow set member, a write bitmap is created. Subsequent writes to the shadow set are recorded by the write bitmap. Note that the write bitmap records only the logical block numbers (LBNs) of the associated writes, not the contents. The address is noted by setting one or more bits in a write bitmap; each bit corresponds to a range of 127 disk blocks.
When data is written to any block in the range of 127 blocks, the bit in the write bitmap that corresponds to that range is set. After the bit or bits are set, the data is written to the shadow set, as shown in Figure 7-2.
Figure 7-2 Application Writes to a Write Bitmap
When the member is returned to the shadow set, the write bitmap is used to direct the minicopy operation, as shown in Figure 7-3. While the minicopy operation is taking place, the application continues to read and write to the shadow set.
Figure 7-3 Member Returned to the Shadow Set (Virtual Unit)
With the minicopy function, a full copy is no longer required when a member is returned to its shadow set, provided that the system managers follow the guidelines provided in Section 7.12. Note that, in this chapter, copy and full copy mean the same thing.
Several DCL commands can be used to manage write bitmaps. System
parameters are provided for managing the write bitmap updates in an
OpenVMS Cluster system and for setting an upper limit on shadow sets
per node.
7.2 Different Uses for Copy and Minicopy
Prior to the introduction of minicopy, the copy operation was used for two purposes: to add members to a virtual unit, and to restore a member to the shadow set from which it was removed. In order for a member to rejoin the shadow set, its data must be made to match the data on the shadow set.
The copy operation remains the only method for creating a multiple member shadow set. The minicopy operation is now the preferred method for returning a member to a shadow set.
Typically, the reason for removing a shadow set member is to back up the data onto tape or disk.
To use a shadow set member to perform a backup operation, a system manager must perform the following steps:
For detailed information about the conditions under which this form of backup is supported, see Section 7.12. |
The minicopy operation can be used at the discretion of the system manager and at a time chosen by the system manager.
Because minicopy can significantly reduce the time it takes to return a member to a shadow set, it gives system managers greater flexibility in scheduling the removal and return of a shadow set member, and it improves availability.
The time needed to perform a minicopy is proportional to the amount of change that occurred to a shadow set in the disk's absence. A shorter copy time gives sites more flexibility in managing backups.
Table 7-1 shows the results from one series of tests, comparing full copy and minicopy times for shadow sets over a spectrum of write activity. The results presented in Table 7-1 and Table 7-2 should be used only as an indication of the performance gain you may experience using minicopy.
Percentage of Bits Set | Time for Full Copy (seconds) | Time for Minicopy (seconds) | Minicopy Time as Percentage of Full Copy Time |
---|---|---|---|
100% | 4196.09 | 3540.21 | 84.4% |
90% | 3881.95 | 3175.92 | 81.8% |
80% | 3480.50 | 2830.47 | 81.3% |
75% | 3290.67 | 2614.87 | 79.5% |
70% | 3194.05 | 2414.03 | 75.6% |
60% | 2809.06 | 2196.60 | 78.2% |
50% | 2448.39 | 1759.67 | 71.9% |
40% | 2076.52 | 1443.44 | 69.5% |
30% | 1691.51 | 1039.90 | 61.5% |
25% | 1545.94 | 775.35 | 50.2% |
20% | 1401.21 | 682.67 | 48.7% |
15% | 1198.80 | 554.06 | 46.2% |
10% | 1044.33 | 345.78 | 33.1% |
5% | 905.88 | 196.32 | 21.7% |
2% | 712.77 | 82.79 | 11.6% |
1% | 695.83 | 44.90 | 6.5% |
Table 7-2 shows the results from another series of tests, comparing performance times of a hardware assisted copy (using MSCP disk copy data (DCD) commands on an HSJ controller) with a minicopy over a spectrum of write activity.
Percentage of Bits Set | DCD Copy Time (seconds) | Minicopy Time (seconds) | Minicopy Time as Percentage of DCD Copy Time |
---|---|---|---|
100% | 1192.18 | 1181.61 | 99.1% |
90% | 1192.18 | 1097.03 | 92.0% |
80% | 1192.18 | 979.06 | 82.1% |
70% | 1192.18 | 862.66 | 72.4% |
60% | 1192.18 | 724.61 | 60.8% |
50% | 1192.18 | 627.24 | 52.6% |
40% | 1192.18 | 490.70 | 41.2% |
30% | 1192.18 | 384.45 | 32.3% |
20% | 1192.18 | 251.53 | 21.1% |
10% | 1192.18 | 128.11 | 10.7% |
5% | 1192.18 | 71.00 | 6.0% |
0% | 1192.18 | 8.32 | 0.7% |
To use the minicopy operation:
$ MOUNT DSA42/SHAD=$4$DUA42 volume-label |
$ MOUNT DSA42/SHAD=$4$DUA42 volume-label/POLICY=MINICOPY |
For a detailed description of how to use /POLICY=MINICOPY[=OPTIONAL]
with the MOUNT and DISMOUNT commands, see Section 7.6 and
Section 7.7.
7.5 Minicopy Restrictions
The following restrictions apply to the use of minicopy:
%DISM-F-SRCMEM, only source member of shadow set cannot be dismounted |
The DCL commands DISMOUNT and MOUNT are used for creating write
bitmaps. The MOUNT command is used for starting a minicopy operation
using a write bitmap (see Section 7.7).
7.6.1 Creating a Write Bitmap With DISMOUNT
To create a write bitmap, you must specify the /POLICY=MINICOPY[=OPTIONAL] qualifier with the DISMOUNT command. If you specify /POLICY=MINICOPY=OPTIONAL, a write bitmap is created if there is sufficient memory. The disk is dismounted, regardless of whether a write bitmap is created.
The following example shows the use of the POLICY=MINICOPY=OPTIONAL qualifier with the DISMOUNT command:
$ DISMOUNT $4$DUA1 /POLICY=MINICOPY=OPTIONAL |
This command removes $4$DUA1 from the shadow set and starts logging writes to a write bitmap, if possible.
If you specify /POLICY=MINICOPY only (that is, if you omit =OPTIONAL)
and there is not enough memory on the node to create a write bitmap,
the dismount fails.
7.6.2 Creating a Write Bitmap With MOUNT
You can create a write bitmap with the MOUNT command under the following conditions:
The write bitmap created with this command is used for a minicopy operation when you later mount one of the former members of the shadow set into the set.
If you specify the /POLICY=MINICOPY=OPTIONAL qualifier and the shadow
set is already mounted on another node in the cluster, the MOUNT
command succeeds but a write bitmap is not created.
7.7 Starting a Minicopy Operation
If a write bitmap exists for a shadow set member, a minicopy operation starts by default when you specify the MOUNT command to return a shadow set member to the shadow set. This is equivalent to using the /POLICY=MINICOPY=OPTIONAL qualifier to the MOUNT command. If a write bitmap is not available, a full copy occurs.
An example of using the /POLICY=MINICOPY=OPTIONAL qualifier with the MOUNT command follows:
$ MOUNT DSA5/SHAD=$4$DUA0/POLICY=MINICOPY=OPTIONAL volume_label |
If the shadow set (DSA5) is already mounted and a write bitmap exists for this shadow set member ($4$DUA0), the command adds the device $4$DUA0 to the shadow set with a minicopy operation. If a write bitmap is not available, this command adds $4$DUA0 with a full copy.
To ensure that a MOUNT command succeeds only if a minicopy can take
place, specify /POLICY=MINICOPY only (that is, omit =OPTIONAL). If a
write bitmap is not available, the mount will fail.
7.8 Master and Local Write Bitmaps
In an OpenVMS Cluster system, a master write bitmap is created on the node that issues the DISMOUNT or MOUNT command that creates the write bitmap. When a master write bitmap is created, a local write bitmap is automatically created on all other nodes in the cluster on which the shadow set is mounted, provided the nodes have sufficient memory.
A master write bitmap contains a record of all the writes to the shadow set from every node in the cluster that has the shadow set mounted. A local write bitmap tracks all the writes that the local node issues to a shadow set.
Note that if a node with a local bitmap writes to the same logical block number (LBN) of a shadow set more than once, only the LBN of the first write is sent to the master write bitmap. The minicopy operation uses the LBN for the update, not the number of changes to the same LBN.
When there is not enough memory on a node to create a local write
bitmap, the node sends a message for each write directly to the master
write bitmap. This will degrade application write performance.
7.9 System Parameters for Managing Write Bitmap Messages and Shadow Set Limit
System parameters are available for managing the update traffic between a master write bitmap and its corresponding local write bitmaps in an OpenVMS Cluster system. Another new system parameter controls whether write bitmap system messages are sent to the operator console and if they are to be sent, the volume of messages. These system parameters are dynamic, that is, they can be changed on a running system. They are shown in Table 3-3.
In addition, a new volume shadowing system parameter, SHADOW_MAX_UNIT, is provided for specifying the maximum number of shadow sets that can exist on a node. This parameter is described in Table 3-1.
The system parameters for managing write bitmap message traffic control whether the messages are buffered and then packaged in a single SCS message to update the master write bitmap or whether each one is sent immediately. The system parameters are used to set the upper and lower threshholds of message traffic and a time interval during which the traffic is measured.
The writes issued by each remote node are, by default, sent one by one in individual SCS messages to the node with the master write bitmap. This is known as single-message mode.
If the writes sent by a remote node reach an upper threshhold of messages during a specified interval, single-message mode switches to buffered-message mode. In buffered-message mode, the messages (up to nine) are collected for a specified interval and then sent in one SCS message. During periods of increased message traffic, grouping multiple messages to send in one SCS message to the master write bitmap is generally more efficient than sending each message separately.
Previous | Next | Contents | Index |
privacy and legal statement | ||
5423PRO_010.HTML |