HP OpenVMS Systems Documentation

Content starts here Overview of HBMM
HP Volume Shadowing for OpenVMS: OpenVMS Version 8.4 > Chapter 8 Host-Based Minimerge (HBMM)

Overview of HBMM

HBMM depends on bitmaps and policies to provide the information required for minimerge operations. Depending on your computing environment, one HBMM policy, a DEFAULT policy that you specify, might be sufficient.

Before you can use HBMM for recovery of a shadow set, the following conditions must be in effect:

  • An HBMM policy exists.

  • An HBMM policy is assigned to a shadow set.

  • The shadow set is mounted on one or more systems that are specified in the HBMM policy.

When a policy is assigned to a shadow set and the shadow set is mounted on several systems, bitmaps specific to that shadow set are created.

The systems selected from the master list, as specified in the HBMM policy definition, can perform a minimerge operation because they possess the master bitmaps. All other systems on which the shadow set is mounted possess a local bitmap for each master bitmap.

Bitmaps: Master and Local

For a given bitmap, there is one master version on a system in the cluster and a local version on every other system on which the shadow set is mounted. A minimerge operation can occur only on a system with a master bitmap. For OpenVMS Version 8.3 and earlier, a shadow set can have up to six HBMM master bitmaps. Starting from OpenVMS Version 8.4, a shadow set can have up to 12 HBMM master bitmaps. Multiple master bitmaps for the same shadow set are equivalent but they do have different bitmap IDs.

The following example shows two master bitmaps for DSA12, one on RAIN and one on SNOW, each with a unique bitmap ID:


Device         BitMap    Size     Percent      Type of   Master  Active
Name            ID     (Bytes)   Populated     Bitmap     Node
DSA12:        00020007     8364        0%     Minimerge  RAIN      Yes
              00010008     8364        0%     Minimerge  SNOW     Yes

If only one master bitmap exists for the shadow set, and the system with the master bitmap fails or is shut down, the remaining local bitmap versions are automatically deleted. Local bitmaps cannot be used for recovery.

If multiple master bitmaps are created for the shadow set and at least one remains, that master bitmap can be used for recovery. HP recommends the use of multiple master bitmaps, especially for multiple-site cluster systems. Multiple master bitmaps increase the likelihood of an HBMM operation rather than a full merge in the event of a system failure.

Bitmaps require additional memory. The calculation is based on the shadow set volume size. For every gigabyte of storage of a shadow set mounted on a system, 2 KB of bitmap memory is required on that system for each bitmap. For example, a shadow set with a volume size of 200 GB of storage and 2 bitmaps uses 800 KB of memory on every system on which it is mounted.

HBMM Policies

An HBMM policy specifies the following attributes for one or more shadow sets:

  • Names of systems that are eligible to host a master bitmap.

  • Number of systems that host a master bitmap (not to exceed six). If this number is omitted in OpenVMS Version 8.3 and earlier, the first available six systems from the number of systems specified are selected. Starting from OpenVMS Version 8.4, you can have up to 12 systems in a shadow set and the first available 12 systems are used if the number is omitted.

  • Threshold (in 512-byte blocks) at which the bitmaps are reset. If omitted, the threshold defaults to 1,000,000 blocks.

You can assign a name to a policy. However, the reserved names DEFAULT and NODEFAULT have specific properties that are described in “Rules Governing HBMM Policies”. You can also create a policy without a name and assign it to a specific shadow set. An advantage of a named policy is that it can be reused by specifying only its name.

Multiple policies can be created to customize the minimerge operations in a cluster.

You can use the SET SHADOW/POLICY command with HBMM-specific qualifiers to define, assign, de-assign, and delete policies and to enable and disable HBMM on a shadow set. SET SHADOW/POLICY is the only user interface command for specifying HBMM policies. You cannot use the MOUNT command to define a policy.

You can define a policy before the shadow set is mounted. Policies can be assigned to shadow sets in other ways as well, as described in “Rules Governing HBMM Policies”.

Three system parameters, namely, SHADOW_REC_DLY, SHADOW_PSM_DLY, and SHADOW_HBMM_RTC support HBMM. For more information about these system parameters, see the “Volume Shadowing Parameters ”.