When a system fails, the volume information is left in a state that
shows that each shadow set member was not properly dismounted. If you
issue the MOUNT command again after the node reboots, the shadowing
software automatically performs a merge operation on the shadow set.
| Example 6-4 Merge Operation: Rebuilding a
Shadow Set |
$ SHOW DEVICE DSA42:
Device Device Error Volume Free Trans Mnt
Name Status Count Label Blocks Count Cnt
DSA42: Mounted 0 ATHRUZ 565997 1 1
$4$DUA2: (MYNODE) ShadowMergeMbr 0 (merging DSA42: 0% merged)
$4$DUA42: (YRNODE) ShadowMergeMbr 0 (merging DSA42: 0% merged)
|
Chapter 7
Using Minicopy for Backing Up Data (Alpha)
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:
- Using the SHOW DEVICE command, verify that the virtual unit is not
marked for a merge operation.
- Stop the application I/O
The method for doing this is specific
to the application and the computing environment.
- Remove a shadow set member
- Reactivate the application
- Back up the data of the shadow set member to disk or tape
While the backup is progressing, the application is writing data to the
remaining members of the shadow set.
- Return the shadow set member to the shadow set when the backup is
complete.
Note
For detailed information about the conditions under which this form of
backup is supported, see Section 7.12.
|
7.3 Why Use Minicopy?
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.
Table 7-1 Comparison of Minicopy and Full Copy Performance
| 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.
Table 7-2 Comparison of Minicopy and Hardware-Assist (DCD) Copy Performance
| 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%
|
7.4 Procedure for Using Minicopy
To use the minicopy operation:
- Start a write bitmap.
A write bitmap is started by specifying the new qualifier
/POLICY=MINICOPY[=OPTIONAL] to the DISMOUNT command when removing a
member from a shadow set.
You can also start a write bitmap with the MOUNT command when mounting
a shadow set less one or two members, as described in Section 7.6.2.
- Use the write bitmap for a minicopy operation when you return the
shadow set member to the shadow set.
If a write bitmap exists for
the shadow set, a minicopy operation is invoked by default by the
following MOUNT command:
$ MOUNT DSA42/SHAD=$4$DUA42 volume-label
|
To guarantee that only a minicopy takes place, use the
/POLICY=MINICOPY qualifier, as shown in the following example:
$ MOUNT DSA42/SHAD=$4$DUA42 volume-label/POLICY=MINICOPY
|
If a write bitmap does not exist for a minicopy, the mount fails.
When a minicopy operation is completed, the write bitmap associated
with the disk is deleted.
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:
- Minicopy can be used in an OpenVMS Cluster only when all nodes in
the cluster are running OpenVMS Version 7.3 (or later). The exception
to this rule is for nodes running OpenVMS Version 7.2-xx for
which an upgrade will be made available soon after the release of
OpenVMS Version 7.3. The upgrade will contain support for minicopy.
- The write bitmap can be used only once.
For example, if you
dismount a three-member shadow set consisting of D1, D2, and D3, and
you then mount only D1 with the /POLICY=MINICOPY[=OPTIONAL] qualifier,
a write bitmap is created. When you mount either D2 or D3 back into the
shadow set, a minicopy is performed. When you mount the remaining
member into the shadow set, a full copy is performed.
To avoid the
requirement of a full copy on the second member, dismount shadow set
members one at a time, using /POLICY=MINICOPY for each. In that way,
you will have a write bitmap for each shadow set member. When you
return each disk to the shadow set, you will be able to do a minicopy
for each.
- You cannot prioritize which member is updated by a minicopy
operation if you specify two members in the same MOUNT command.
To
ensure that the minicopy occurs immediately, specify only one shadow
set member in each MOUNT command. Wait for the minicopy to start, then
add the next member with another MOUNT command.
- If a shadow set is already marked by the volume shadowing software
for a merge operation, the merge operation occurs, and a write bitmap
is not created.
- Unused write bitmaps for a virtual unit remain in memory when the
virtual unit is dismounted. When the virtual unit is mounted again,
they are automatically deleted.
You can delete excess write bitmaps
with the DELETE command, as described in Section 7.10.4.
- Misleading error message
When you attempt to start a write
bitmap and dismount a shadow set member (with
DISMOUNT/POLICY=MINICOPY[=OPTIONAL]), the following error message is
displayed if the shadow set member is in a merge operation or is a copy
target:
%DISM-F-SRCMEM, only source member of shadow set cannot be dismounted
|
A more meaningful error message is planned for a future version of
minicopy.
- If a node with one or more master bitmaps shuts down or crashes,
the bitmaps on the node are deleted. Therefore, the shadow sets whose
master bitmaps were deleted will not be able to use a minicopy
operation. Instead, a full copy will be performed.
- If a shadow set member leaves the set because of an error or
timeout, a write bitmap will not be available. A write bitmap is only
available for a minicopy when a shadow set member is explicitly
dismounted.
- If you intend to use the minicopy feature in a mixed-architecture
OpenVMS Cluster system, Compaq advises you to set the SHADOW_MAX_COPY
system parameter to zero on all VAX systems. This setting prevents a
copy from being performed on a VAX when the intent was to perform a
minicopy on an Alpha. In a mixed-architecture cluster, it is possible,
although highly unlikely, that a VAX system could be assigned the task
of adding a member to a shadow set. Because a VAX system cannot perform
a minicopy, it would perform a full copy instead. Fo information about
SHADOW_MAX_COPY, see Section 3.2.
- Additional steps are required to access the dump file from a system
disk shadow set in which a minicopy operation was used to return a
member to the shadow set. For more information, see Section 1.4.2.1.
