Filter
Top Products
404 Administering 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,
run the
vxconfigd -k command on all nodes to restart the process.
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 421.
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 425.
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 426 and “Setting exclusive open access to a volume by a node” on
page 426.
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