Veritas Storage Foundation 5.0.1 Cluster File System Administrator's Guide Extracts for the HP Serviceguard Storage Management Suite on HP-UX 11i v3

To the cmvx daemon, all nodes are the same. VxVM objects configured within shared disk groups
can potentially be accessed by all nodes that join the cluster. However, the cluster functionality
of VxVM requires one node to act as the master node; all other nodes in the cluster are slave
nodes. Any node is capable of being the master node, which is responsible for coordinating
certain VxVM activities.
NOTE: You must run commands that configure or reconfigure VxVM objects on the master
node. Tasks that must be initiated from the master node include setting up shared disk groups
and creating and reconfiguring volumes.
VxVM designates the first node to join a cluster as the master node. If the master node leaves
the cluster, one of the slave nodes is chosen to be the new master node. In the preceding example,
node 0 is the master node and nodes 1, 2 and 3 are slave nodes.
Private and Shared Disk Groups
There are two types of disk groups:
• Private (non- CFS) disk groups, which belong to only one node. A private disk group is only
imported by one system. Disks in a private disk group may be physically accessible from
one or more systems, but import is restricted to one system only. The root disk group is
always a private disk group.
• Shared (CFS) disk groups, which are shared by all nodes. A shared (or cluster-shareable)
disk group is imported by all cluster nodes. Disks in a shared disk group must be physically
accessible from all systems that may join the cluster.
Disks in a shared disk group are accessible from all nodes in a cluster, allowing applications on
multiple cluster nodes to simultaneously access the same disk. A volume in a shared disk group
can be simultaneously accessed by more than one node in the cluster, subject to licensing and
disk group activation mode restrictions.
You can use the vxdg command to designate a disk group as cluster-shareable. When a disk
group is imported as cluster-shareable for one node, each disk header is marked with the cluster
ID. As each node subsequently joins the cluster, it recognizes the disk group as being
cluster-shareable and imports it. You can also import or deport a shared disk group at any time;
the operation takes places in a distributed fashion on all nodes. See “Cluster File System
Commands” (page 25) for more information.
Each physical disk is marked with a unique disk ID. When cluster functionality for VxVM starts
on the master node, it imports all shared disk groups (except for any that have the noautoimport
attribute set). When a slave node tries to join a cluster, the master node sends it a list of the disk
IDs that it has imported, and the slave node checks to see if it can access all of them. If the slave
node cannot access one of the listed disks, it abandons its attempt to join the cluster. If it can
access all of the listed disks, it imports the same shared disk groups as the master node and joins
the cluster. When a node leaves the cluster, it deports all of its imported shared disk groups, but
they remain imported on the surviving nodes.
Reconfiguring a shared disk group is performed with the co-operation of all nodes. Configuration
changes to the disk group happen simultaneously on all nodes and the changes are identical.
Such changes are atomic in nature, which means that they either occur simultaneously on all
nodes, or not at all.
Whether all members of the cluster have simultaneous read and write access to a cluster-shareable
disk group depends on its activation mode setting as described in Table 2-2: “Activation Modes
for Shared Disk Groups”. The data contained in a cluster-shareable disk group is available as
long as at least one node is active in the cluster. The failure of a cluster node does not affect access
by the remaining active nodes. Regardless of which node accesses a cluster-shareable disk group,
the configuration of the disk group looks the same.
20 Cluster File System Architecture