VERITAS Volume Manager 3.1 Administrator's Guide

Cluster Functionality
Cluster Functionality Overview
Chapter 7 303
Volume Reconfiguration
Volume reconfiguration is the process of creating, changing, and
removing the Volume Manager objects in the configuration (such as disk
groups, volumes, mirrors, etc.). In a cluster, this process is performed
with the cooperation of all nodes. Volume reconfiguration is distributed
to all nodes; identical configuration changes occur on all nodes
simultaneously.
NOTE Volume reconfiguration is initiated and coordinated by the master node,
so the system administrator must run the utilities that request changes
to Volume Manager objects on the master node.
The vxconfigd daemons play an active role in volume
reconfiguration.For the reconfiguration to succeed, the vxconfigd
daemons must be running on all nodes.
The utility on the master node contacts its local vxconfigd daemon,
which performs some local checking to make sure that a requested
change is reasonable. For instance, it will fail an attempt to create a new
disk group when one with the same name already exists. The vxconfigd
daemon on the master node then sends messages with the details of the
changes to the vxconfigd daemons on all other nodes in the cluster. The
vxconfigd daemons on each of the slave nodes then perform their own
checking. For example, a 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 all of the vxconfigd daemons on all nodes agree that the
proposed change is reasonable, each vxconfigd daemon notifies its
kernel and the kernels then cooperate to either commit or abort the
transaction. Before the transaction can commit, all of the kernels ensure
that no I/O is underway. The master is responsible for initiating a
reconfiguration and coordinating the transaction commit.
If a vxconfigd daemon on any node goes away during a reconfiguration
process, 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 leaves the cluster, the new master (which was a slave
previously) either completes or fails the operation. This depends on
whether or not it received notification of successful completion from the
previous master. This notification is done in such a way that if the new
master does not receive it, neither does any other slave.