Filter
Top Products
408 Administering cluster functionality
Overview of cluster volume management
Guidelines for choosing detach and failure policies
In most cases it is recommended that you use the global detach policy, and
particularly if any of the following conditions apply:
■ If you are using the VCS agents that monitor the cluster functionality of
Veritas Volume Manager, and which are provided with Veritas Storage
Foundation
TM
for Cluster File System HA and Veritas Storage Foundation for
databases HA. These agents do not notify VCS about local failures.
■ When an array is seen by DMP as Active/Passive. The local detach policy
causes unpredictable behavior for Active/Passive arrays.
■ For clusters with four or fewer nodes. With a small number of nodes in a
cluster, it is preferable to keep all nodes actively using the volumes, and to
keep the applications running on all the nodes, rather than keep the
redundancy of the volume at the same level.
■ If only non-mirrored, small mirrored, or hardware mirrored volumes are
configured. This avoids the system overhead of the extra messaging that is
required by the local detach policy.
The local detach policy may be suitable in the following cases:
■ When large mirrored volumes are configured. Resynchronizing a reattached
plex can degrade system performance. The local detach policy can avoid the
need to detach the plex at all. (Alternatively, the dirty region logging (DRL)
feature can be used to reduce the amount of resynchronization that is
required.)
■ For clusters with more than four nodes. Keeping an application running on a
particular node is less critical when there are many nodes in a cluster. It may
be possible to configure the cluster management software to move an
application to a node that has access to the volumes. In addition, load
balancing may be able to move applications to a different volume from the
one that experienced the I/O problem. This preserves data redundancy, and
other nodes may still be able to perform I/O from/to the volumes on the
disk.
If you have a critical disk group that you do not want to become disabled in the
case that the master node loses access to the copies of the logs, set the disk
group failure policy to leave. This prevents I/O failure on the master node
disabling the disk group. However, critical applications running on the master
node fail if they lose access to the other shared disk groups. In such a case, it
may be preferable to set the policy to dgdisable, and to allow the disk group to
be disabled.