Veritas Storage Foundation 5.1 SP1 Cluster File System Administrator"s Guide (5900-1738, April 2011)

Example Scenario I
Figure 7-2 scenario could cause similar symptoms on a two-node cluster with one
node shut down for maintenance. During the outage, the private interconnect
cables are disconnected.
Figure 7-2
Example scenario I
Node 0
Node 1
Coordinator Disks
First - Network
interconnect severed.
Node 0 wins coordinator
race.
Third - Node 0 has key
registered on all coordinator
disks.
Second Node 1
panics and reboots
Finally- Node 1 boots up
and finds keys registered
for non-member. Prints
error message and exits.
In example scenario I, the following occurs:
Node 0 wins a coordinator race following to a network failure.
Node 1 panics and reboots.
Node 0 has keys registered on the coordinator disks. When Node 1 boots up,
it sees the Node 0 keys, but cannot see Node 0 in the current GAB membership.
It senses a potential preexisting split brain and causes the vxfen module to
print an error message to the console. The vxfen module prevents fencing
from starting, which, in turn, prevents VCS from coming online.
Suggested solution: Shut down Node 1, reconnect the cables, and restart Node
1.
Example Scenario II
Similar to example scenario I, if private interconnect cables are disconnected in
a two-node cluster, Node 1 is fenced out of the cluster, panics, and reboots. If
before the private interconnect cables are fixed and Node 1 rejoins the cluster,
Node 0 reboots and remote (or just reboots). No node can write to the data disks
until the private networks are fixed. This is because GAB membership cannot be
formed, therefore the cluster cannot be formed.
Suggested solution: Shut down both nodes, reconnect the cables, restart the nodes.
Example Scenario III
Similar to example scenario II, if private interconnect cables are disconnected in
a two-node cluster, Node 1 is fenced out of the cluster, panics, and reboots. If
177Troubleshooting SFCFS
Troubleshooting fenced configurations