Veritas Volume Manager 5.0.1 Administrator's Guide, HP-UX 11i v3, First Edition, November 2009

The fibre channel connectivity is multiply redundant to implement redundant-loop
access between each node and each enclosure. As usual, the two nodes are also
linked by a redundant private network.
A serial split brain condition typically arises in a cluster when a private
(non-shared) disk group is imported on Node 0 with Node 1 configured as the
failover node.
If the network connections between the nodes are severed, both nodes think that
the other node has died. (This is the usual cause of the split brain condition in
clusters). If a disk group is spread across both enclosure enc0 and enc1, each
portion loses connectivity to the other portion of the disk group. Node 0 continues
to update to the disks in the portion of the disk group that it can access. Node 1,
operating as the failover node, imports the other portion of the disk group (with
the -f option set), and starts updating the disks that it can see.
When the network links are restored, attempting to reattach the missing disks to
the disk group on Node 0, or to re-import the entire disk group on either node,
fails. This serial split brain condition arises because VxVM increments the serial
ID in the disk media record of each imported disk in all the disk group configuration
databases on those disks, and also in the private region of each imported disk.
The value that is stored in the configuration database represents the serial ID
that the disk group expects a disk to have. The serial ID that is stored in a disk’s
private region is considered to be its actual value.
If some disks went missing from the disk group (due to physical disconnection or
power failure) and those disks were imported by another host, the serial IDs for
the disks in their copies of the configuration database, and also in each disk’s
private region, are updated separately on that host. When the disks are
subsequently re-imported into the original shared disk group, the actual serial
IDs on the disks do not agree with the expected values from the configuration
copies on other disks in the disk group.
Depending on what happened to the different portions of the split disk group,
there are two possibilities for resolving inconsistencies between the configuration
databases:
■ If the other disks in the disk group were not imported on another host, VxVM
resolves the conflicting values of the serial IDs by using the version of the
configuration database from the disk with the greatest value for the updated
ID (shown as update_tid in the output from the vxdg list diskgroup
command).
Figure 4-2 shows an example of a serial split brain condition that can be
resolved automatically by VxVM.
223Creating and administering disk groups
Handling conflicting configuration copies