VERITAS Volume Manager 4.1 Administrator's Guide

Administering Cluster Functionality
Upgrading Cluster Functionality
Chapter 10 367
Node Abort
If a node does not leave a cluster cleanly, this is because it crashed or
because some cluster component made the node leave on an emergency
basis. The ensuing cluster reconfiguration calls the VxVM abort function.
This procedure immediately attempts to halt all access to shared
volumes, although it does wait until pending I/O from or to the disk
completes.
I/O operations that have not yet been started are failed, and the shared
volumes are removed. Applications that were accessing the shared
volumes therefore fail with errors.
After a node abort or crash, shared volumes must be recovered, either by
a surviving node or by a subsequent cluster restart, because it is very
likely that there are unsynchronized mirrors.
Cluster Shutdown
If all nodes leave a cluster, shared volumes must be recovered when the
cluster is next started if the last node did not leave cleanly, or if
resynchronization from previous nodes leaving uncleanly is incomplete.
Upgrading Cluster Functionality
The rolling upgrade feature allows you to upgrade the version of VxVM
running in a cluster without shutting down the entire cluster. To install
the new version of VxVM running on a cluster, make one node leave the
cluster, upgrade it, and then join it back into the cluster. This operation
is repeated for each node in the cluster.
Each Volume Manager release starting with Release 3.1 has a cluster
protocol version number associated with it. The cluster protocol version
is not the same as the release number or the disk group version number.
The cluster protocol version is stored in the /etc/vx/volboot file.
During a new installation of VxVM, the vxdctl init command creates
the volboot file and sets the cluster protocol version to the highest
supported version.