[an error occurred while processing this directive]

HP OpenVMS Systems Documentation
Content starts here Rules Governing HBMM Policies
HP Volume Shadowing for OpenVMS: OpenVMS Version 8.4 > Chapter 8 Host-Based Minimerge (HBMM)

Rules Governing HBMM Policies

spacerspacerspacer
spacer
spacer
  		 
 

The following rules govern the creation and management of HBMM policies. The rules are based on the assumption that a shadow set is mounted on a system that supports HBMM.

Policies and Their Attributes

  • A policy can be assigned to a shadow set by specifying only its attributes. The number of policies that you can assign in this way is limited only by the number of shadow sets that are supported on a system.

  • A shadow set can have only one HBMM policy assigned to it at a time.

  • Policies are in effect clusterwide.

  • Policy names must conform to the following rules:

    • A policy name can range from 1 to 64 characters in length and is case-insensitive.

    • Only letters, numbers, the dollar sign ($), and the underscore (_) are allowed.

  • A policy name must be specified in full; abbreviations are not allowed.

  • A named policy can be assigned to a shadow set only by the SET SHADOW/POLICY=HBMM=policy-name command.

  • The limit on user-defined, named policies is 128.

DEFAULT and NODEFAULT Policies

The named policies DEFAULT and NODEFAULT have special properties, as summarized in the following sections:

  • DEFAULT

    • A DEFAULT policy is useful if the majority of the shadow sets in a cluster are expected to use an identical policy.

    • You can create a DEFAULT policy by defining a named policy with the reserved name DEFAULT. No predetermined DEFAULT policy is provided by HP.

    • When a policy with the reserved name of DEFAULT is defined, this policy is assigned to a shadow set by any of the following operations:

      • Mount of a shadow set without an assigned policy

        The DEFAULT policy, if defined, is applied to a shadow set in the absence of an assigned policy (including the NODEFAULT policy). For example, when shadow set DSA1 is mounted on an HBMM-capable system, an attempt is made to apply an HBMM policy, if one exists, that is specific to DSA1. (To verify whether a device-specific policy exists and to display specific policies, see “How to Display Policies”.)

        If a policy is not defined specifically for DSA1, an attempt is made to apply the DEFAULT policy. If the DEFAULT policy exists, the attributes of that policy are applied to DSA1.

      • End of merge of a shadow set without an assigned policy

      • Use of SET SHADOW/ENABLE=HBMM command

    • If a shadow set has a policy assignment and that policy assignment is deleted, it is then eligible for the DEFAULT policy, if one is established for your cluster.

  • NODEFAULT Policy

    • The NODEFAULT policy specifies that the shadow set to which it is applied does not use HBMM; no HBMM bitmaps are created anywhere in the cluster for this shadow set.

    • In a cluster where a DEFAULT policy has been defined, the NODEFAULT policy can be used to prevent specific shadow sets from receiving the default policy.

    • The NODEFAULT policy cannot be deleted or redefined.

Assignment and Activation of a Policy

  • A policy can be assigned to a shadow set before the shadow set is mounted on any system in the cluster.

  • If a policy has been assigned, it is activated by the first mount of a shadow set on a bitmap master system.

  • Assigning a policy implicitly enables HBMM on a mounted shadow set if it is mounted on a system that can create a master bitmap. Consider DSA1 that is mounted on system MAPLE. When DSA1 is mounted, no HBMM policy is set for DSA1, nor is there a DEFAULT policy that can be applied. Later, the following command is used:

    $ SET SHADOW DSA1:/POLICY=HBMM=(MASTER=(MAPLE), COUNT=1)

    Because DSA1 is already mounted on system MAPLE, HBMM is enabled as a result of the policy assignment (see “How to Assign an HBMM Policy to a Shadow Set”).

  • Any attempt to enable HBMM using SET SHADOW DSAn /ENABLE=HBMM returns a failure if a shadow set is not mounted on a system that has a master bitmap, or if the policy has not been defined.

  • As new systems join the cluster, they inherit the policies in existence in that cluster.

Changes to Policies

  • Named policies can be created, changed, and deleted at will. Changes made to a named policy are not inherited by any mounted shadow set assigned the previous version of that named policy.

  • The assignment of a policy to a mounted shadow set cannot be changed while HBMM is enabled for that shadow set. HBMM must first be disabled on that shadow set, and then a different policy can be assigned to it.

  • Any policy change is clusterwide.

Life of a Policy

  • All policies remain in effect in a cluster as long as at least one system remains active. However, if all systems are shut down, all policy definitions and assignments are deleted. The policies must be defined and assigned again when the systems form the cluster. Therefore, HP recommends that you define your desired HBMM policies in your system startup procedures before you mount your shadow sets.

  • Policy assignments persist across the disabling of HBMM or the dismounting of the shadow set as long as at least one system in the cluster remains active.



HBMM Policy Specification Syntax
  		 


Guidelines for Establishing HBMM Policies