IBM Storwize V7000 Maintenance Manual page 151

Table of Contents

Advertisement

diagnostics the system provides to diagnose
problems on SAS cables and expansion enclosures.
4. If a quorum disk on an external storage system is
shown as missing, find the storage control and
confirm that the LUN is available, check the Fibre
Channel connections between the storage controller
and the 2076 are working and that any changes
made to the SAN configuration and zoning have
not effected the connectivity. Check the status of the
Fibre Channel ports on the node and resolve any
issues.
5. If all nodes have either node error 578 or 550,
attempt to reestablish a cluster by following the
service procedures for the nodes showing node
error 578. If this is not successful, follow the cluster
recovery procedures.
556
A duplicate WWNN has been detected.
Explanation: The node canister has detected another
device that has the same World Wide Node Name
(WWNN) on the Fibre Channel network. A WWNN is
16 hexadecimal digits long. For a Storwize V7000, the
first 11 digits are always 50050768020. The last 5 digits
of the WWNN are given in the additional data of the
error. The Fibre Channel ports of the node canister are
disabled to prevent disruption of the Fibre Channel
network. One or both node canisters with the same
WWNN can show the error. Because of the way
WWNNs are allocated, a device with a duplicate
WWNN is normally another Storwize V7000 node
canister.
User response: Follow troubleshooting procedures to
configure the WWNN of the node:
1. Find the Storwize V7000 node canister with the
same WWNN as the node canister reporting the
error. The WWNN for a Storwize V7000 node
canister can be found from the node Vital Product
Data (VPD) or from the node canister details shown
by the service assistant. The node with the duplicate
WWNN need not be part of the same cluster as the
node reporting the error; it could be remote from
the node reporting the error on a part of the fabric
connected through an inter-switch link. The two
node canisters within a control enclosure must have
different WWNNs. The WWNN of the node canister
is stored within the enclosure chassis, so the
duplication is most likely caused by the
replacement of a control enclosure chassis.
2. If a Storwize V7000 node canister with a duplicate
WWNN is found, determine whether it, or the node
reporting the error, has the incorrect WWNN.
Generally, it is the node canister that has had its
enclosure chassis that was recently replaced or had
its WWNN changed incorrectly. Also consider how
the SAN is zoned when making your decision.
3. Determine the correct WWNN for the node with the
incorrect WWNN. If the enclosure chassis has been
replaced as part of a service action, the WWNN for
the node canister should have been written down. If
the correct WWNN cannot be determined contact
your support center for assistance.
4. Use the service assistant to modify the incorrect
WWNN. If it is the node showing the error that
should be modified, this can safely be done
immediately. If it is an active node that should be
modified, use caution because the node will restart
when the WWNN is changed. If this node is the
only operational node in an enclosure, access to the
volumes that it is managing will be lost. You should
ensure that the host systems are in the correct state
before you change the WWNN.
5. If the node showing the error had the correct
WWNN, it can be restarted, using the service
assistant, after the node with the duplicate WWNN
is updated.
6. If you are unable to find a Storwize V7000 node
canister with the same WWNN as the node canister
showing the error, use the SAN monitoring tools to
determine whether there is another device on the
SAN with the same WWNN. This device should not
be using a WWNN assigned to a Storwize V7000, so
you should follow the service procedures for the
device to change its WWNN. Once the duplicate
has been removed, restart the node canister.
Possible Cause-FRUs or other:
v None
562
The nodes hardware configuration does
not meet the minimum requirements.
Explanation: The node hardware is not at the
minimum specification for the node to become active in
a cluster. This may be because of hardware failure, but
is also possible after a service action has used an
incorrect replacement part.
User response: Follow troubleshooting procedures to
fix the hardware:
1. It is not possible to service parts within the node
canister. Reseat the existing node canister to see
whether the problem fixes. If it does not, use the
hardware node canister remove and replace
procedures to change the node canister.
Possible Cause-FRUs or other:
v Node canister (100%)
564
Too many software crashes have
occurred.
Explanation: The node has been determined to be
unstable because of multiple resets. The cause of the
resets can be that the system encountered an
unexpected state or has executed instructions that were
not valid. The node has entered the service state so that
diagnostic data can be recovered.
Chapter 9. Event reporting
556 • 564
135

Advertisement

Table of Contents
loading

Table of Contents