HP Volume Shadowing for OpenVMS: OpenVMS Version 8.4 > Chapter 8 Host-Based Minimerge (HBMM) Overview of HBMMHBMM 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:
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. 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:
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. An HBMM policy specifies the following attributes for one or more shadow sets:
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 ”. |