HP OpenVMS Systems Documentation

HP OpenVMS Version 8.2 New Features and Documentation Overview

You can assign a policy, named or unnamed, to a shadow set. To assign an existing named policy, use the following command:

$ SET SHADOW DSAn:/POLICY=HBMM=policy-name

To assign an unnamed policy to a shadow set, use the same command, but in place of the policy name, specify the attributes of the policy you want to use. For example:

$ SET SHADOW DSA1:/POLICY=HBMM=(MASTER_LIST=(NODE1, NODE2, NODE3), COUNT=2)

In this example, the default bitmap reset value of 50,000 blocks takes effect because the RESET_THRESHOLD keyword was omitted.

6.9.3 How to Activate HBMM on a Shadow Set

HBMM is automatically activated on a shadow set under the following conditions:

• An HBMM policy exists for a given shadow set and that shadow set is then mounted on one or more systems defined in the master list.
• An HBMM policy is created for a mounted shadow set and at least one system that has it mounted is defined in the master list.

You can also activate HBMM with the SET SHADOW/ENABLE=HBMM command, provided a policy exists and the shadow set is mounted on a system defined in the master list of the shadow set policy, and the count has not been exceeded.

6.9.4 How to Disable HBMM on a Shadow Set

To disable HBMM on a shadow set, use the following command:

$ SET SHADOW DSAn:/DISABLE=HBMM

Reasons for disabling HBMM on a shadow set include:

• To change the policy associated with it.
• To delete the policy associated with it.
• To mount the shadow set on a system that does not support HBMM. You must disable HBMM first and then dismount it from all the HBMM capable systems on which it is mounted before you can mount it on a system that does not support HBMM.

HBMM remains disabled until you either re-enable it or define a new policy for the shadow set.

6.9.5 How to Remove a Policy Association from a Shadow Set

Before removing a policy association from a shadow set, HBMM must be disabled, if active. Then you can remove a policy association from a shadow set by entering the following command:

$ SET SHADOW DSAn:/POLICY=HBMM/DELETE

This command removes any policy that had been set for this shadow set, making the shadow set eligible for the DEFAULT policy. If a DEFAULT policy exists, it will be assigned the next time the shadow set becomes eligible for a policy, for example, at the end of a merge or when you issue the SET SHADOW/ENABLE=HBMM command.

6.9.6 How to Change a Policy Assignment of a Shadow Set

To change a policy assigned to a shadow set, you must first disable HBMM, as described in Section 6.9.4, and then assign another policy to the shadow set. To apply a different policy, specify one by name or specify policy attributes (thereby creating an "unnamed" policy), as described in Section 6.9.2. Specifying a new policy (or policy attributes) for a shadow set replaces the prior policy. The use of the command shown in Section 6.9.5 is not required when you are changing the policy assignment.

6.9.7 How to Delete a Named Policy from the Cluster

You can delete a named policy with the /DELETE qualifier, as shown in the following example:

$ SET SHADOW /POLICY=HBMM/NAME=policy-name/DELETE

This command deletes the policy whose name you specified and takes effect across the cluster. It does not delete the policy from any shadow set to which it was already assigned.

The DEFAULT policy can be changed at any time. However, if a previous definition of the DEFAULT was associated with a shadow set, a subsequent change to the definition of the DEFAULT policy is not retroactively applied to that shadow set. In this regard, the DEFAULT policy behaves just like any other named policy.

This section shows how to apply a changed DEFAULT policy.

Initially, the following DEFAULT policy was associated with DSA20 when it was mounted:

$ SET SHADOW/POLICY=HBMM=(MASTER=(NODE1,NODE2,NODE3),COUNT=2)/NAME=DEFAULT
$ MOUNT/SYSTEM DSA20:/SHADOW=($1$DGA20,$1$DGA21) VOL_20

Subsequently, the DEFAULT policy is redefined by the following command. This redefined policy allows any node in the cluster to be eligible for an HBMM master bitmap:

$ SET SHADOW/POLICY=HBMM=(MASTER=*,COUNT=2)/NAME=DEFAULT

You can apply the redefined DEFAULT policy to DSA20 by using the following commands:

$ SET SHADOW DSA20:/DISABLE=HBMM
$ SET SHADOW DSA20:/POLICY=HBMM/DELETE
$ SET SHADOW DSA20:/ENABLE=HBMM

Note that you must explicitly delete the HBMM policy associated with DSA20 in order for DSA20 to become eligible for the current DEFAULT policy. This step is required because, when HBMM is disabled on DSA20, the policy (MASTER=(NODE1,NODE2,NODE3),COUNT=2) remains associated with DSA20.

An alternative way to apply the updated DEFAULT policy to DSA20 is to take advantage of the fact that the DEFAULT policy is a named policy. This method requires only two commands, as shown next:

$ SET SHADOW DSA20:/DISABLE=HBMM
$ SET SHADOW DSA20:/POLICY=HBMM=DEFAULT

You can display policies with the SHOW SHADOW command. You can display:

• The policy associated with a specified shadow set
• The definition of a named policy
• All shadow sets in a cluster with policy assignments, together with the definition of each policy
• All named policies and their definitions that exist on a cluster

Displaying the Policy of a Specific Shadow Set

To display the policy associated with a specific shadow set, issue the following command:

$ SHOW SHADOW DSAn:/POLICY=HBMM

An example of the resulting output follows:

$ SHOW SHADOW DSA999:/POLICY=HBMM
HBMM Policy for device _DSA999:
 HBMM Reset Threshold: 50000
 HBMM Master lists:
  Up to any 2 of the nodes: NODE1,NODE2,NODE3
  Any 1 of the nodes: NODE4,NODE5
  Up to any 2 of the nodes: NODE6,NODE7,NODE8

Displaying the Definition of a Named Policy

To display the definition of a named policy, issue the following command:

$ SHOW SHADOW/POLICY=HBMM/NAME=policy-name

The following display shows the definition of the PEAKS_ISLAND policy:

$ SHOW SHADOW/POLICY=HBMM/NAME=PEAKS_ISLAND
HBMM Policy PEAKS_ISLAND
 HBMM Reset Threshold: 50000
 HBMM Master lists:
  Up to any 2 of the nodes: NODE1,NODE2,NODE3
  Any 1 of the nodes: NODE4,NODE5
  Up to any 2 of the nodes: NODE6,NODE7,NODE8

Displaying All Shadow Sets with Policy Assignments

To display all shadow sets in a cluster with policy assignments, along with the definition of each policy, use the following command:

$ SHOW SHADOW/POLICY=HBMM

The following display results from this command:

$ SHOW SHADOW/POLICY=HBMM
HBMM Policy for device _DSA12:
 HBMM Reset Threshold: 50000
 HBMM Master lists:
  Up to any 2 of the nodes: NODE1,NODE2
 HBMM bitmaps are active on NODE1,NODE2
 Modified blocks since bitmap creation: 254

HBMM Policy for device _DSA30:
 HBMM Reset Threshold: 50000
 HBMM Master lists:
  Up to any 2 of the nodes: FLURRY,FREEZE,HOTTUB

HBMM Policy for device _DSA99:
 HBMM Reset Threshold: 50000
 HBMM Master lists:
  Up to any 2 of the nodes: NODE1,NODE2,NODE3
  Any 1 of the nodes: NODE4,NODE5
  Up to any 2 of the nodes: NODE6,NODE7,NODE8

HBMM Policy for device _DSA999:
 HBMM Reset Threshold: 50000
 HBMM Master lists:
  Up to any 2 of the nodes: NODE1,NODE2,NODE3
  Any 1 of the nodes: NODE4,NODE5
  Up to any 2 of the nodes: NODE6,NODE7,NODE8

Displaying All Named Policies on a Cluster

To display the named policies that exist on a cluster, along with their definitions, issue the following command:

$ SHOW SHADOW/POLICY=HBMM/NAME

The named policies are displayed in the order in which they were created. The following display results from this command:

$ SHOW SHADOW/POLICY=HBMM/NAME
HBMM Policy DEFAULT
    HBMM Reset Threshold: 50000
    HBMM Master lists:
      Up to any 6 nodes in the cluster

HBMM Policy PEAKS_ISLAND
 HBMM Reset Threshold: 50000
 HBMM Master lists:
  Up to any 2 of the nodes: NODE1,NODE2,NODE3
  Any 1 of the nodes: NODE4,NODE5
  Up to any 2 of the nodes: NODE6,NODE7,NODE8

HBMM Policy POLICY_1
 HBMM Reset Threshold: 50000
 HBMM Master lists:
  Up to any 2 of the nodes: NODE1,NODE2,NODE3
  Any 1 of the nodes: NODE4,NODE5

HBMM Policy ICE_HOTELS
 HBMM Reset Threshold: 50000
 HBMM Master lists:
  Up to any 2 of the nodes: QUEBEC,ICELND,SWEDEN
  Any 1 of the nodes: ALASKA,GRNLND

You can check the merge status of each shadow set member by issuing the SHOW SHADOW/MERGE DSAn command. The /MERGE qualifier returns one of the following messages:

• Merge is not required.
• Merge is pending.
• Merge is in progress on node node-name.

An example of the display produced by the SHOW SHADOW/MERGE DSAn command follows:

$ SHOW SHADOW/MERGE
  Device      Volume Name   Status
  _DSA1010      FOOBAR        Merging (10%)

If a copy operation (instead of the merge operation) is currently active, the display shows the percentage of the merge that has completed and the percentage of the copy that has completed with the designation "Copy Active," as follows:

$ SHOW SHADOW/MERGE
  Device      Volume Name   Status
  _DSA1010    FOOBAR        Merging (23%), Copy Active  (77%) on CSGF1

You can prevent merge operations on a system in two ways:

• Set SHADOW_MAX_COPY to 0
• Set the priority for merge and copy operations to zero for every shadow set mounted on the system using the SET SHADOW/PRIORITY=0 DSAn for each shadow set.

Only the systems that have an HBMM master bitmap for a particular shadow set are able to perform HBMM recovery on that shadow set. If a merge recovery is required on a shadow set and no systems in the cluster have an HBMM master bitmap for that shadow set, a full merge will be performed.

Therefore, to minimize the need to perform a full merge, you should use policies that attempt to maintain at least one HBMM master bitmap at each site in a multiple-site OpenVMS Cluster system. The ability to specify multiple master lists in an HBMM policy is expressly designed for this purpose. You should specify a separate MASTER_LIST for each site.

For example, consider a 3-site OpenVMS Cluster system with 12 cluster members:

Site 1: Member systems NYN1, NYN2, NYN3, and NYN4
Site 2: Member systems CTN1, CTN2, CTN3, and CTN4
Site 3: Member systems NJN1, NJN2, NJN3, and NJN4

The following definition of a DEFAULT policy would provide for up to two HBMM master bitmaps at each site:

$ SET SHADOW/NAME=DEFAULT/POLICY=HBMM=( -
_$ (MASTER_LIST=(NYN1,NYN2,NYN3,NYN4), COUNT=2), -
_$ (MASTER_LIST=(CTN1,CTN2,CTN3,CTN4), COUNT=2), -
_$ (MASTER_LIST=(NJN1,NJN2,NJN3,NJN4), COUNT=2))

Specifically, this policy requests master bitmaps at any two of the systems in the first master list, any two of the systems in the second master list, and any two of the systems in the third master list.

Note that you cannot accomplish this type of distribution by listing the systems in a particular order within a single MASTER_LIST. This is because the order in which the systems are specified in a master list does not affect the order in which the systems are considered when HBMM master bitmaps are created. When an event occurs that warrants the creation of an HBMM master bitmap, the creation of these bitmaps is done in random order by the systems that have the shadow set mounted. In the following example, the likelihood of system NYN1 getting a master bitmap is the same for either POLICY_A or POLICY_B:

$ SET SHADOW/NAME=POLICY_A/POLICY=HBMM=( -
_$ (MASTER_LIST=(NYN1,CTN1,NJN1,NYN2,CTN2,NJN2),COUNT=3))

$ SET SHADOW/NAME=POLICY_B/POLICY=HBMM=( -
_$ (MASTER_LIST=(NJN2,CTN2,NYN2,NJN1,CTN1,NYN1),COUNT=3))

Two new system parameters are introduced in this version: SHADOW_REC_DLY and SHADOW_HBMM_RTC.

6.10.1 SHADOW_REC_DLY Parameter

SHADOW_REC_DLY governs system behavior after a system failure or after a shadow set is aborted. The value of the SHADOW_REC_DLY parameter is added to the value of the RECNXINTERVAL parameter to determine how long a system waits before it attempts to manage a merge or copy operation on any shadow sets that it has mounted.

SHADOW_REC_DLY can be used to better predict which systems in an OpenVMS Cluster will perform recovery operations. This is done by setting lower values of SHADOW_REC_DLY on systems that are preferred to handle recovery operations and higher values of SHADOW_REC_DLY on the remaining systems.

SHADOW_REC_DLY is a dynamic parameter; its range is 0 to 65535 seconds. The default value is 20 seconds.

For more information about controlling which systems perform the merge or copy operations, see Section 6.12.5.

6.10.2 SHADOW_HBMM_RTC Parameter

SHADOW_HBMM_RTC is used to specify, in seconds, how frequently the modified block count of the HBMM bitmap is compared with the reset threshold. If the modified block count exceeds the reset threshold, the bitmap is zeroed.

The reset threshold is specified by the RESET_THRESHOLD keyword in the /POLICY qualifier of the SET SHADOW command. This comparison is performed for all shadow sets mounted on the system that have HBMM bitmaps.

When the comparison is made, the modified block count might exceed the reset threshold by a small increment or by a much larger amount. The difference depends on the write activity to the volume and the setting of SHADOW_HBMM_RTC.

SHADOW_HBMM_RTC is a dynamic parameter; its range is 60 to 65535 seconds. The default value is 150 seconds.

You can view the reset threshold setting and the modified block count, since the last reset, in the SHOW SHADOW display. For guidelines for setting reset threshold values and a sample SHOW SHADOW display, see Section 6.8.2. For a SHOW SHADOW display that includes a modified block count greater than the reset threshold value, see Example 9 for SHOW SHADOW in HP OpenVMS DCL Dictionary.

6.11 Use of /DEMAND_MERGE When HBMM Is Enabled

If a shadow set is HBMM enabled and is actively using HBMM, then the SET SHADOW/DEMAND_MERGE DSAn: command causes a minimerge operation to occur. To force a full merge instead of a minimerge operation, you must disable HBMM on the shadow set before issuing the SET SHADOW/DEMAND_MERGE DSAn: command. For information about disabling HBMM, see Section 6.9.4.

The /DEMAND_MERGE qualifier of the SET SHADOW command is used primarily to force a merge operation on shadow sets that were created with the INITIALIZE/SHADOW command without specifying the /ERASE qualifier. The /DEMAND_MERGE qualifier ensures that all blocks on the shadow set are the same, including those blocks that are not currently allocated to files. System managers can use this command at their convenience during off-peak demands on their computing environment.

If the /ERASE qualifier was not used when the shadow set was created with the INITIALIZE/SHADOW command, and the SET SHADOW/DEMAND_MERGE DSAn: command has not been executed, then the overhead of a full merge operation on this shadow set is even higher than is normally encountered after a system failure.

System managers can also use the SET SHADOW/DEMAND_MERGE DSAn: command for the following reasons:

• If the ANALYZE/DISK/SHADOW command found differences between the members of the shadow set. For more information, refer to the ANALYZE/DISK/SHADOW command description in the HP Volume Shadowing for OpenVMS manual.
• If they want to measure the impact that a minimerge or a full merge has on their I/O throughput.

Starting with this version of Volume Shadowing, greater control is available to system managers for managing merge and copy operations. This greater control is made possible by two new qualifiers to the SET SHADOW command, /PRIORITY=n and /EVALUATE=RESOURCES, and a new system parameter, SHADOW_REC_DLY. With 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.
• Make changes to the SHADOW_MAX_COPY system parameter, which take effect immediately.

If a system fails or if it aborts a shadow set, most commonly through mount verification, such an action is termed 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. Then every system can reallocate its resources to newer, higher-priority work.

After a predetermined delay, each system with a nonzero 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 Section 6.12.5.) Every system allocates available SHADOW_MAX_COPY resources based on a shadow set's priority.

A shadow set is said to be in a steady state when none of the following operations is pending or active:

• Minimerge
• Minicopy
• Full copy
• Full merge

If a shadow set has one or more of these 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, suppose 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.

Shadow set operations for a specific shadow set are performed in the following order:

1. Minimerge
2. Copy (either minicopy or full copy)
3. Full merge

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 this command to override the default priority assignment on a system.

A priority level of 0 has a unique meaning. It means the shadow set is not considered for merge or copy operations on this system.

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 following 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 are occurring 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 how many source members are in each shadow set. If members are being added via a copy operation, this is indicated by +1 or +2. So, 2+1 indicates two source members and one member being added. The notation 1+2 indicates only 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 those 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 HP OpenVMS DCL Dictionary.