Pillar Axiom 500 Storage System
 
Pillar Axiom 300 Storage System
 
Pillar Axiom 600 Storage System
 

PLA-Support>Sun Systems>DISK>Pillar Axiom>SN-DK: Ax600
 
.Old GCS Categories>Sun Microsystems>Storage - Disk>Pillar Axiom
 

In this Document

Goal

Fix

Created from <SR 3-5456018913>

Applies to:

Goal

What are customer options when receiving events related to a RAID Controller Fault?

Fix

A Brick’s RAID controller has encountered a fault. This is usually a recoverable event and the RAID controller should return to normal status. Since the faults can vary, logs need to be obtained to determine root-cause.
The Axiom has built in redundancy to handle a failed RAID controller even if the controller is not able to recover from this fault. The data serving will typically be handled by the surviving controller.

The handling of RAID Controller Fault Callhomes is done in 2 steps:

1) Check the state of the affected Brick and ensure the RAID Controllers are Normal in the GUI, and that the LED fault lights are off.
a) If Normal -- this is a healthy indication that the RAID Controller successfully recovered from the fault.
b) If other than Normal, a new RAID Controller can be shipped for replacement.

2) The customer may opt to have analysis be performed on the fault for root-cause. Factors that help determine this analysis need may be as follows:
a) If the RAID Controller recovered, then the need for an analysis may not be as critical due to the RAID Controller's inherent nature to recover from such faults.
b) Factors such as recurrence (over a short period of time) and unexpected data inaccess may weigh on the need for further analysis.
c) On occasion the corresponding Brick logs may not end up being bundled with the Event-driven Callhome logs received by Customer Support. Therefore a manual logset will be requested (with the appropriate Brick logs).

This solution has no attachment