|
HP OpenVMS Systems Documentation |
|
HP OpenVMS Version 8.2 New Features and Documentation Overview
6.9.2 How to Assign an HBMM Policy to a Shadow SetYou can assign a policy, named or unnamed, to a shadow set. To assign an existing named policy, use the following command:
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:
In this example, the default bitmap reset value of 50,000 blocks takes
effect because the RESET_THRESHOLD keyword was omitted.
HBMM is automatically activated on a shadow set under the following conditions:
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.
To disable HBMM on a shadow set, use the following command:
Reasons for disabling HBMM on a shadow set include:
HBMM remains disabled until you either re-enable it or define a new
policy for the 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:
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.
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.
You can delete a named policy with the /DELETE qualifier, as shown in the following example:
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.
6.9.8 How to Apply a Changed DEFAULT PolicyThe 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:
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:
You can apply the redefined DEFAULT policy to DSA20 by using the following commands:
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:
6.9.9 How to Display PoliciesYou can display policies with the SHOW SHADOW command. You can display:
Displaying the Policy of a Specific Shadow Set
To display the policy associated with a specific shadow set, issue the following command:
An example of the resulting output follows:
Displaying the Definition of a Named Policy
To display the definition of a named policy, issue the following command:
The following display shows the definition of the PEAKS_ISLAND policy:
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:
The following display results from this command:
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:
The named policies are displayed in the order in which they were created. The following display results from this command:
6.9.10 How to Display the Merge Status of Shadow SetsYou 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:
An example of the display produced by the SHOW SHADOW/MERGE DSAn command follows:
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:
6.9.11 How to Prevent Merge Operations on a SystemYou can prevent merge operations on a system in two ways:
6.9.12 Considerations for Multiple-Site OpenVMS Cluster SystemsOnly 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 The following definition of a DEFAULT policy would provide for up to two HBMM master bitmaps at each site:
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:
6.10 New System Parameters That Affect HBMM
Two new system parameters are introduced in this version:
SHADOW_REC_DLY and SHADOW_HBMM_RTC.
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.
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.
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:
6.12 Prioritizing Merge and Copy OperationsStarting 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:
6.12.1 Default Management of Merge and Copy OperationsIf 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:
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.
6.12.2 Hierarchy of Transient State OperationsShadow set operations for a specific shadow set are performed in the following order:
6.12.3 Assigning PrioritiesWhen 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.
6.12.4 Displaying Priority ValuesYou can display the priority of a shadow set on a specific system by issuing the following command:
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:
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:
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.
|