Volume Shadowing on OpenVMS Version 8.3 and above,
provides greater control to system managers for managing merge and
copy operations. This is possible by
using the SET SHADOW command with the qualifiers
/PRIORITY=n and /EVALUATE=RESOURCES, and a new
system parameter, SHADOW_REC_DLY. Using these parameters, system managers
can:
Prioritize shadow sets
for merge and copy operations on a per-system basis.
Control which system performs
a merge or copy operation of a particular shadow set.
Modify the SHADOW_MAX_COPY
system parameter, which take effect immediately.
Default Management of Merge and Copy Operations |
 |
If a system fails or if it aborts a shadow set,
most commonly through mount verification, it is termed as a significant
event. When one of these significant events occurs, all systems in
the cluster are notified automatically. This notification causes all
shadow server processes to stop any full merge or full copy operations
and release all the resources performing these operations. Thus, every
system can reallocate its resources to newer, higher-priority work.
After a predetermined delay, each system with
a non-zero SHADOW_MAX_COPY setting begins to process the shadow sets
that are in a transient state, according to their priority. The predetermined
delay is governed by the new system parameter SHADOW_REC_DLY. (For
more information about SHADOW_REC_DLY, see Table 3-1 and “Controlling Which Systems Manage Merge and Copy Operations”.) Every system allocates the available
SHADOW_MAX_COPY resources based on a shadow set's priority.
A shadow set is in a steady state when it is known that all members contain identical data. If
a shadow set has one or more of the following operations pending,
or one operation active, it is said to be in a transient
state:
While a combination of these transient states
is valid, only one operation at a time can be performed. For example,
consider that HBMM is not enabled. After a device is added to a shadow
set, it is marked as being in a full copy transient state. If the
system on which this shadow set is mounted fails, the shadow set is
further marked as being in a full merge state. In this example, the
full copy operation is performed before the full merge is started.
|
| |
|
 | NOTE: The priority assigned to a shadow set does not
affect the hierarchy of transient state operations. |
|
| |
|
Hierarchy of Transient State Operations |
|
Shadow set operations for a specific shadow set
are performed in the following order:
Minimerge
Copy (either minicopy
or full copy)
Full merge
Assigning Priorities to Shadow Sets |
|
When first mounted on a system, every shadow set
is assigned a default priority of 5000. You can assign a unique priority
to every mounted shadow set on a per-system basis using the SET SHADOW/PRIORITY=n DSAn command. Every shadow set can have a unique priority
per system, or shadow sets can be assigned the same priority. Shadow
sets with the same priority are managed in a consistent way for each
release. However, the order in which shadow sets with the same priority
are managed may change from release to release because of changes
to the algorithm. Therefore, if the order is important, assign them
different priorities.
The valid range for priority values is 0 through
10,000. The higher the assigned value, the higher the priority. To
ensure that high-priority volumes are merged (or copied) before less
important volumes, use SET SHADOW/PRIORITY=n DSAncommand to override the default
priority assignment on a system.
A priority level of 0 has a unique meaning. It
means that the shadow set is not considered for merge or copy operations
on this system.
|
| |
|
| NOTE: After the notification of a significant event
and the allocation of a system's resources, it is not possible
to directly affect any of the current merge or copy operations on
the system by assigning a different priority level to one or more
shadow sets. If you have to re-prioritize one or more shadow sets,
you must use another technique, as described in “Managing Transient States in Progress”. |
|
| |
|
Displaying Shadow Set Priority Values |
|
You can display the priority of a shadow set on
a specific system by issuing the following command:
$ SHOW SHADOW/BY_PRIORITY DSAn: |
This command displays the current priority and
status of the specified shadow set. If any copy or merge operations
are in progress, the node on which the operation is progressing is
displayed, along with its progress. For example:
$ SHOW SHADOW DSA1104/BY_PRIORITY
Device Mbr Active
Name Cnt Priority Virtual Unit State on Node
_DSA1104: 2 5000 Merge Active (29%) MAX |
You can use the SHOW SHADOW/BY_PRIORITY command to display the priority level and the status for all of
the shadow sets that exist on the system. The status indicates whether
the shadow set is currently undergoing a copy or merge operation or
whether one is required. If either or both operations are underway,
the systems on which they occur are identified in the display, as
shown in the following example:
|
$ SHOW SHADOW/BY_PRIORITY
Device Mbr Active
Name Cnt Priority Virtual Unit State on Node
_DSA106: 2 10000 Steady State
_DSA108: 3 8000 Steady State
_DSA110: 3 8000 Steady State
_DSA112: 3 8000 Steady State
_DSA114: 1 7000 Steady State
_DSA116: 1 7000 Steady State
_DSA150: 2 7000 Steady State
_DSA152: 7000 Not Mounted on this node
_DSA154: 3 6000 Steady State
_DSA156: 1 6000 Steady State
_DSA159: 2 5000 Steady State
_DSA74: 3 5000 Merge Active (47%) CASSID
_DSA304: 2+1 5000 Merge Active (30%), Copy Active (3%) MAX
_DSA1104: 2 5000 Merge Active (29%) MAX
_DSA300: 2+1 5000 Merge Active (59%), Copy Active (0%) MAX
_DSA0: 1+2 5000 Copy Active (83%) CASSID
_DSA3: 2 3000 Steady State
_DSA100: 2 3000 Steady State
_DSA102: 1 3000 Steady State
_DSA104: 3 3000 Steady State
Total of 19 Operational shadow sets; 0 in Mount Verification; 1 not mounted
$ |
|
In this example, the 20 shadow sets on this system
are displayed in their priority order. In the event of a failure of
another system in the cluster that has these shadow sets mounted,
the shadow sets are merged in this order on the system.
The Mbr Cnt field shows the number of source members
in each shadow set. If members are being added via a copy operation,
this is indicated by +1 or +2. Therefore, 2+1 indicates two source
members and one member being added. The notation 1+2 indicates one
source member and two members being copied into the set.
The summary line provides the total number of
shadow sets that were found to be in the various conditions. “Operational
shadow sets” are shadow sets that are mounted with one or more
members and may or may not have copy or merge operations occurring.
These shadow sets are available to applications for reads and writes.
“Mount Verification” indicates the number of shadow
sets that are in some mount verification state. Shadow sets that have
exceeded their mount verification timeout times are also included
in this total.
For additional examples, see the SHOW SHADOW examples
in the HP OpenVMS DCL Dictionary.
Controlling Which Systems Manage Merge and Copy Operations |
|
When a system fails or aborts a shadow set, this
significant event causes every shadow set to be reassessed by all
other systems with that shadow set mounted. All active minimerge,
full merge, or copy operations cease at this time, returning their
resources to those systems. (However, if a system is performing a minicopy operation, that operation continues to completion.)
These systems wait a predetermined amount of time,
measured in seconds, before each attempts to manage any shadow set
in a transient state. This pause is called a significant-event recovery
delay. It is the total
of the values specified for two system parameters, SHADOW_REC_DLY and RECNXINTERVAL. (The default
value for each is 20 seconds.)
If the value of the significant-event recovery
delay is the same on all systems, it is not possible to predict which
systems manage which shadow set. However, by making the value of the
significant-event recovery delay different on all systems, you can
predict when a specific system begins to manage transient-state operations.
Managing Merge Operations |
|
A merge transient state is an event that cannot
be predicted. The management of merge activity, on a specific system
for multiple shadow sets, can be predicted if the priority level settings
for the shadow sets differ.
The following example illustrates how the priority
level is used to select shadow sets when only merge operations are
involved. In this example:
There are four shadow sets
The SHADOW_MAX_COPY parameter on this system is equal
to 1. (The value of 1 means that only one merge or copy operation
can occur at the same time.)
Two shadow sets are assigned a priority level and
two have the default priority level of 5000.
The four shadow sets DSA1, DSA20, DSA22, and DSA42
are mounted on two systems.
DSA20 and DSA42 are minimerge enabled.
$ SET SHADOW/PRIORITY=7000 DSA1:
$ SET SHADOW/PRIORITY=3000 DSA42:
! DSA20: and DSA22: are at the default priority level of 5000 |
When one of the systems in this example fails,
all shadow sets are put into a merge-required state. After the significant-event
recovery delay time elapses, this system evaluates the shadow sets,
and the operations are performed in the following order:
A minimerge operation
starts first on DSA20, even though its priority of 5000 is lower than
DSA1's priority of 7000. A minimerge operation always takes precedence
over other operations. DSA20 and DSA42 are both minimerge enabled,
but DSA20's higher priority causes its minimerge operation to
start first.
A minimerge operation
starts on DSA42. Its priority of 3000 is the lowest of all the shadow
sets, but a minimerge operation takes precedence over other operations.
Because there are no other
minimerge capable units, DSA1, with a priority level of 7000, is selected
to start a merge operation, and it runs to completion.
A merge operation starts
on DSA22, the one remaining shadow set whose priority is the default
value of 5000, and runs to completion.
Managing Copy Operations |
|
A copy transient state can be predicted by the
user because it is the result of direct user action. Therefore, a
full copy operation caused by adding a device to a shadow set is not
considered a significant event in the cluster. The copy operation
is managed by the first system that has an available resource.
In the following example, assume that there are
four shadow sets, and the SHADOW_MAX COPY parameter on this system
is equal to 1. Note that the for shadow sets that are not assigned
a specific level, a default priority level is assigned.
For the following example, assume that:
DSA1, DSA20, DSA22, and
DSA42 are mounted on multiple systems.
Only DSA42 is minimerge
enabled.
DSA22 is already in a
full copy state being managed on this system.
DSA1 has a priority level
of 7000.
DSA42 has a priority level
of 3000.
DSA20 has a priority level
of 3000.
DSA22 has a default priority
level of 5000.
The user adds a device to DSA1. This is not a
significant event, and this system does not interrupt the full copy
operation of the DSA22 in favor of performing the DSA1 full copy operation.
To expand on this example, assume that a system
fails (a significant event) before the copy operations have completed.
All shadow sets are put into a merge required state. Specifically,
DSA1, DSA20, and DSA22 are put into a full merge state, and DSA42
is put into a minimerge state.
After the significant event recovery delay expires,
this system begins to evaluate all the shadow sets in a transient
state. The operations take place in the following order:
A minimerge operation
starts on DSA42 and continues until completion. This operation takes
priority over other operations, regardless of its priority level.
A copy operation starts
on DSA1. The full merge operation is not started because a copy operation
takes precedence over a full merge operation.
A merge operation is started
and completed on DSA1.
A copy operation is started
and completed on DSA22.
A merge operation is started
and completed on DSA22.
A merge operation is started
and completed on DSA20.
Thus, in this example, the priority level is used
to direct the priority of merge and copy operations on this system.
Managing Transient States in Progress |
|
SHADOW_MAX_COPY is a dynamic system parameter
that governs the use of system resources by shadowing. Shadowing can be directed to immediately respond
to changes in this parameter setting using the following DCL command:
$ SET SHADOW/EVALUATE=RESOURCES |
This command stops all the current merge and copy
operations on the system on which it is issued. It then restarts the
work using the new value of SHADOW_MAX_COPY.
This command is also useful in other circumstances.
For example, if a shadow set has a priority level 0 or another low
value, the SET SHADOW /PRIORITY=n command can be used to increase the value. Then, using the /EVALUATE=RESOURCES
qualifier, the priority of shadow sets in a transient state is reevaluated.
The /PRIORITY and /EVALUATE=RESOURCES qualifiers
can be used on the same command line.
When a significant event occurs, all of the SHADOW_MAX_COPY
resources are applied. If the value of SHADOW_MAX_COPY is modified
using the SYSGEN SET and WRITE ACTIVE commands, and then a SET SHADOW/EVALUATE=RESOURCES is issued, the new value
of SHADOW_MAX_COPY has a direct and immediate affect.
To determine which system is controlling a transient
operation, enter the following command:
$ SHOW SHADOW/ACTIVE DSAn: |
To determine the priority values assigned to each
shadow set, enter the following command:
$ SHOW SHADOW/BY_PRIORITY DSAn: |
