Configuring and Managing HBMM

How to Define an HBMM Policy

The SET SHADOW/POLICY=HBMM command is used to define HBMM policies. You can define multiple policies for your environment. The following examples show how to define two policies, a DEFAULT policy and POLICY_1, a named policy.

To define the policy named DEFAULT:

$ SET SHADOW/POLICY=HBMM=(MASTER_LIST=*)/NAME=DEFAULT

In this example, a DEFAULT policy is created for the cluster. The use of the asterisk wildcard (*) means that any system can host a master bitmap. The omission of the keyword COUNT=n means that up to six systems (the default value and the current maximum supported) can host a master bitmap. The DEFAULT policy is inherited at mount time by shadow sets that have not been assigned a named policy.

The following example defines a named policy (POLICY_1), specifies the systems that are eligible to host a master bitmap, limits to two the number of systems to host a master bitmap, and specifies a higher threshold (default is 1,000,000 blocks) to be reached before clearing the bitmap.

$ SET SHADOW /POLICY=HBMM=( -
_$ (MASTER_LIST=(NODE1,NODE2,NODE3), COUNT=2), -
_$ RESET_THRESHOLD=1250000) -
_$ /NAME=POLICY_1

In OpenVMS Version 8.4, if you are using the DISMOUNT keyword, you can have up to 12 HBMM master bitmaps. For DISMOUNT keyword examples, see the “Examples of Multiuse and Dismount”.

For the complete DCL syntax of the SET SHADOW/POLICY=HBMM command, see the HP OpenVMS DCL Dictionary.

How to Assign an HBMM Policy to a Shadow Set

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 1,000,000 blocks takes effect because the RESET_THRESHOLD keyword is omitted.

How to Activate HBMM on a Shadow Set

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

You can also activate HBMM using 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.

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:

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

How to Remove a Policy Assignment from a Shadow Set

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

$ SET SHADOW DSAn:/POLICY=HBMM/DELETE

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

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 “How to Disable HBMM on a Shadow Set”, and then assign another policy to the shadow set. To apply a different policy, specify the policy name or specify the policy attributes (thereby creating an “unnamed” policy), as described in “How to Assign an HBMM Policy to a Shadow Set”. Specifying a new policy (or policy attributes) for a shadow set replaces the previous policy. The use of the command shown in “How to Remove a Policy Assignment from a Shadow Set” is not required when you are changing the policy assignment.

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 specified policy, which takes effect across the cluster. It does not delete the policy from any shadow set to which it is already assigned.

	NOTE: You cannot delete the NODEFAULT policy.

How to Apply a Changed DEFAULT Policy

The DEFAULT policy can be changed at any time. However, if a previous definition of the DEFAULT policy is assigned to 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 is assigned to DSA20 when it is mounted, as shown by the following example:

$ 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 using the following commands:

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

	NOTE: you must explicitly delete the HBMM policy assigned to 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 assigned to 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:

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

How to Display Policies

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

Displaying the Policy of a Specific Shadow Set

To display the policy assigned to a specific shadow set, issue the following command:

$ SHOW SHADOW DSAn:/POLICY=HBMM 

An example of the resulting output:

$ SHOW SHADOW DSA999:/POLICY=HBMM
HBMM Policy for device _DSA999:
 HBMM Reset Threshold: 1000000
 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: 750000
 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: 1000000
 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: 1000000
 HBMM Master lists:                                         
  Up to any 2 of the nodes: FLURRY,FREEZE,HOTTUB

HBMM Policy for device _DSA99:
 HBMM Reset Threshold: 1000000
 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: 1000000
 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: 1000000
    HBMM Master lists:
      Up to any 6 nodes in the cluster

HBMM Policy PEAKS_ISLAND
 HBMM Reset Threshold: 1000000
 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: 1000000
 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: 1000000
 HBMM Master lists:
  Up to any 2 of the nodes: QUEBEC,ICELND,SWEDEN
  Any 1 of the nodes: ALASKA,GRNLND

How to Display the Merge Status of Shadow Sets

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:

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

$ 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

How to Prevent Merge Operations on a System

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

Considerations for Multiple-Site OpenVMS Cluster Systems

Only 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 is performed.

Therefore, to minimize the need to perform a full merge, you must use policies that 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 designed for this purpose. You must specify a separate MASTER_LIST for each site.

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

The following definition of a DEFAULT policy provides 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. If an event occurs that requires the creation of an HBMM master bitmap, the bitmap is created in a random order by 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) )