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 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:
$ SHOW DEVICE/BITMAP DSA12
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 ”.