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

399Administering cluster functionality
Cluster initialization and configuration
be held up and restarted later. In most cases, cluster reconfiguration takes precedence.
However, if the volume reconfiguration is in the commit stage, it completes first.
For more information on cluster reconfiguration, see “Volume reconfiguration” on
page 399.
Volume reconfiguration
Volume reconfiguration is the process of creating, changing, and removing VxVM objects
such as disk groups, volumes and plexes. In a cluster, all nodes co-operate to perform such
operations. The vxconfigd daemons (see “vxconfigd daemon” on page 400) play an
active role in volume reconfiguration. For reconfiguration to succeed, a vxconfigd
daemon must be running on each of the nodes.
A volume reconfiguration transaction is initiated by running a VxVM utility on the master
node. The utility contacts the local vxconfigd daemon on the master node, which
validates the requested change. For example, vxconfigd rejects an attempt to create a
new disk group with the same name as an existing disk group. The vxconfigd daemon
on the master node then sends details of the changes to the vxconfigd daemons on the
slave nodes. The vxconfigd daemons on the slave nodes then perform their own
checking. For example, each slave node checks that it does not have a private disk group
with the same name as the one being created; if the operation involves a new disk, each
node checks that it can access that disk. When the vxconfigd daemons on all the nodes
agree that the proposed change is reasonable, each notifies its kernel. The kernels then co-
operate to either commit or to abandon the transaction. Before the transaction can be
committed, all of the kernels ensure that no I/O is underway. The master node is
responsible both for initiating the reconfiguration, and for coordinating the commitment of
the transaction. The resulting configuration changes appear to occur simultaneously on all
nodes.
If a vxconfigd daemon on any node goes away during reconfiguration, all nodes are
notified and the operation fails. If any node leaves the cluster, the operation fails unless the
master has already committed it. If the master node leaves the cluster, the new master
node, which was previously a slave node, completes or fails the operation depending on
whether or not it received notification of successful completion from the previous master
node. This notification is performed in such a way that if the new master does not receive
it, neither does any other slave.
If a node attempts to join a cluster while a volume reconfiguration is being performed, the
result of the reconfiguration depends on how far it has progressed. If the kernel has not yet
been invoked, the volume reconfiguration is suspended until the node has joined the
cluster. If the kernel has been invoked, the node waits until the reconfiguration is complete
before joining the cluster.
When an error occurs, such as when a check on a slave fails or a node leaves the cluster,
the error is returned to the utility and a message is sent to the console on the master node to
identify on which node the error occurred.