VERITAS Volume Manager 4.1 Administrator's Guide

Administering Cluster Functionality
Cluster Initialization and Configuration
Chapter 10362
fails I/O in progress to shared disks, and stops access to shared disks and
the vxclustd daemon. The vxclustd daemon invokes the cluster
monitor command to halt the cluster on this node.
When a clean node shutdown is performed, vxclustd waits until kernel
cluster reconfiguration completes and then exits.
NOTE If MC/ServiceGuard is the cluster monitor, it expects the vxclustd
daemon registration to complete within a given timeout period. If
registration times out, MC/ServiceGuard aborts cluster initialization and
fails cluster startup.
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 cooperate to perform such operations. The vxconfigd
daemons (see “vxconfigd Daemon” on page 363) 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 cooperate 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.