Veritas Volume Manager 5.0 Administrator's Guide (September 2006)

397Administering cluster functionality
Overview of cluster volume management
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.
The default settings for the detach and failure policies are global and dgdisable
respectively. You can use the
vxdg command to change both the detach and failure
policies on a shared disk group, as shown in this example:
# vxdg -g diskgroup set diskdetpolicy=local dgfailpolicy=leave
Effect of disk connectivity on cluster reconfiguration
The detach policy, previous I/O errors, or access to disks are not considered when a new
master node is chosen. When the master node leaves a cluster, the node that takes over as
master of the cluster may already have seen I/O failures for one or more disks. Under the
local detach policy, if a node was affected before reconfiguration, and this node then
becomes the master, the failure is treated as described in “Connectivity policy of shared
disk groups” on page 393. Some failure scenarios do not result in a disk group failure
policy being invoked, but can potentially impact the cluster. For example, if the local disk
detach policy is in effect, and the new master node has a failed plex, this results in all
nodes detaching the plex because the new master is unaffected by the policy.
The detach policy does not change the requirement that a node joining a cluster must have
access to all the disks in all shared disk groups. Similarly, a node that is removed from the
cluster because of an I/O failure cannot rejoin the cluster until this requirement is met.
Limitations of shared disk groups
Note: The boot disk group (usually aliased as bootdg) cannot be made cluster-shareable.
It must be private.
Only raw device access may be performed via the cluster functionality of VxVM. It does
not support shared access to file systems in shared volumes unless the appropriate
software is installed and configured.
The cluster functionality of VxVM does not support RAID-5 volumes, or task monitoring
for cluster-shareable disk groups. These features can, however, be used in private disk
groups that are attached to specific nodes of a cluster.