ServerNet Cluster Manual

Troubleshooting and Replacement Procedures
ServerNet Cluster Manual—520575-003
7-25
Automatic Fail-Over for Two-Lane and Four-Lane
Links
HP does not recommend stopping and starting the ServerNet cluster subsystem to
repair ServerNet connectivity. The SCF STOP SUBSYS $ZZSCL command is used
primarily to ensure the orderly removal of a node from the cluster. The SCF STOP
SUBSYS $ZZSCL command normally is used prior to:
•
Physically disconnecting a node from the cluster.
•
Halting the processors on a node, possibly in preparation for a system load to a
new version of the operating system.
•
Aborting the SNETMON process pair for the purpose of upgrading the SNETMON
software, unless recommended otherwise by HP.
Aborting and Restarting SNETMON to Repair Connectivity
Problems
You can also use the following sequence of commands to repair connectivity problems:
SCF ABORT PROCESS $ZZKRN.#ZZSCL
SCF START PROCESS $ZZKRN.#ZZSCL
Using this sequence of commands aborts the SNETMON process pair (SNETMON
ceases to exist). However, ServerNet cluster connectivity is left intact. When the
SNETMON process is started again, it queries all processors in the node to find the
state of ServerNet connections to all other nodes. If it finds any connections that are
down, it initiates a sequence to bring the connections to an online state. The outcome
is therefore similar to issuing an SCF PRIMARY PROCESS $ZZSCL command, but
there is a key difference.
The Expand-over-ServerNet line-handler processes tolerate only temporary absences
of the SNETMON process. After three minutes of absence, the Expand-over-ServerNet
line-handler processes declare the lines to other nodes to be down. Consequently,
aborting and starting SNETMON must be used with caution. Because of the possibility
of Expand-over-ServerNet lines going down (in case the SNETMON process pair is not
running for more than three minutes), HP recommends using the SCF PRIMARY
PROCESS $ZZSCL command to repair ServerNet cluster connectivity.
Automatic Fail-Over for Two-Lane and Four-Lane Links
Clusters using the split-star or tri-star topologies with G06.14 software (or G06.13 and
the release 3 SPRs) support automatic fail-over of ServerNet traffic on the two-lane or
four-lane links. With link fail-over, internode paths stay up on both fabrics as long as at
least one lane between the cluster switches is functional.
If a lane fails, the traffic that would normally use that lane is automatically redirected to
the next available lane. If a lane is repaired, it is automatically brought online again
after it has passed neighbor checks.
In clusters using the tri-star topology, if a lane fails, traffic is redirected to the other lane
of the same two-lane link.