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

393Administering cluster functionality
Overview of cluster volume management
Note: The activation mode of a disk group controls volume I/O from different nodes in the
cluster. It is not possible to activate a disk group on a given node if it is activated in a
conflicting mode on another node in the cluster. When enabling activation using the
defaults file, it is recommended that this file be made identical on all nodes in the cluster.
Otherwise, the results of activation are unpredictable.
If the defaults file is edited while the vxconfigd daemon is already running, the
vxconfigd process must be restarted for the changes in the defaults file to take effect.
If the default activation mode is anything other than off, an activation following a cluster
join, or a disk group creation or import can fail if another node in the cluster has activated
the disk group in a conflicting mode.
To display the activation mode for a shared disk group, use the
vxdg list diskgroup
command as described in “Listing shared disk groups” on page 408.
You can also use the vxdg command to change the activation mode on a shared disk group
as described in “Changing the activation mode on a shared disk group” on page 412.
For a description of how to configure a volume so that it can only be opened by a single
node in a cluster, see “Creating volumes with exclusive open access by a node” on
page 413 and “Setting exclusive open access to a volume by a node” on page 413.
Connectivity policy of shared disk groups
A shared disk group provides concurrent read and write access to the volumes that it
contains for all nodes in a cluster. A shared disk group can only be created on the master
node. This has the following advantages and implications:
■ All nodes in the cluster see exactly the same configuration.
■ Only the master node can change the configuration.
■ Any changes on the master node are automatically coordinated and propagated to the
slave nodes in the cluster.
■ Any failures that require a configuration change must be sent to the master node so
that they can be resolved correctly.
■ As the master node resolves failures, all the slave nodes are correctly updated. This
ensures that all nodes have the same view of the configuration.
The practical implication of this design is that I/O failure on any node results in the
configuration of all nodes being changed. This is known as the global detach policy.
However, in some cases, it is not desirable to have all nodes react in this way to I/O
failure. To address this, an alternate way of responding to I/O failures, known as the
detach policy, was introduced in release 3.2 of VxVM.