Sun Storage 3510 FC Array
 
Sun Storage 3310 Array
 
Sun Storage 3511 SATA Array
 
Sun Storage 3320 SCSI Array
 

GCS>Sun Microsystems>Storage - Disk>Modular Disk - 3xxx Arrays
 

The simultaneous run, caused the two Sun StorEdge[TM] 3510 array to which the hosts were connected, to hang.

Symptoms observed were:

1. The Controller LED's displayed the following, on one of the dual controller
arrays:
- Upper controller was solid green.
- Lower controller switched between amber and solid green every five minutes.

   The other dual controller array, displayed the following:
- Upper controller was solid green.
- Lower controller was solid amber.

2. Neither of the arrays were accessible by:
- Serial interface.
- telnet interface.
- Out-of-band sccli.

3. Inconsistent results were obtained when sccli was run from the hosts using
in-band connection(**Refer to the Additional Notes section**).

4. The Explorer scripts also hung. In particular, they were stuck running the
se3kxtr.

5. As a result of the array not responding, host logs showed events
"disappeared from fabric" on all hosts.

The problem described above was seen on the Sun StorEdge 3510, but it could
also happen on any of the Sun StorEdge 3310/3320/3511 arrays.

WARNING:

Implement the Temporary Workaround ONLY if the situation exactly matches the
description above(meaning all conditions must be met).

Power cycling the array with data in cache, will cause that data to be flushed
out, without being written to the disks, and this leads to potential data loss.

If the array is truly hung, meeting all of the conditions above, and there is
data in cache, then this data loss cannot be avoided. The cache lights on the
back of the controller(s) can be checked to see if the cache is dirty.

All attempts should be made to ensure that all I/O to the array is stopped and
the array has had time to de-stage the data from the cache to the disks, before
the power cycle is done.

Power-cycle the Sun StorEdge[TM]3310/3320/3510/3511 Array.

1. The Sun StorEdge 3310/3320/3510/3511 Arrays can be managed by a command line
   interface, which comes as part of the SUNWsccli package, and can be invoked
   by running "/opt/SUNWsscs/sbin/sccli".
2. The management of Sun StorEdge 3310/3320/3510/3511 Arrays can be "in-band"(using
   the SCSI interface), or "out-of-band"(using ethernet interface).
3. "se3kxtr" is a Sun StorEdge 3000 Series Extractor, using sccli commands to
   gather necessary information from the array.
4. se3k is a tool packaged as part of an explorer script(build 4.4), and uses
   the sccli commands to gather the same information that the "se3kxtr" does.
5. The following, are a sample of inconsistent sccli command outputs seen in the
   field(Refers to Problem Statement point 3.):

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
root@takere # sccli
Available devices:

 1. /dev/es/ses0 [SUN StorEdge 3510 SN#00XX9F] (Primary)
2. /dev/rdsk/c7t600C0FF00000000007XXXXXXXXXXXX00d0s2 [SUN StorEdge 3510 SN#0XXXD4] (Primary)
3. /dev/rdsk/c7t600C0FF00000000007XXXXXXXXXXXX01d0s2 [SUN StorEdge 3510 SN#0XXX15] (Secondary)

Please enter selection: 3
sccli> show redun
sccli: this operation is only supported on RAID primary controllers
sccli> q
root@takere # sccli
Available devices:

 1. /dev/es/ses0 [SUN StorEdge 3510 SN#0XXX9F] (Primary)
2. /dev/rdsk/c7t600C0FF0000000000XXXXXXXXXXXX100d0s2 [SUN StorEdge 3510 SN#0XXXD4] (Primary)
3. /dev/es/ses2 [SUN StorEdge 3510 SN#0XXX15] (Primary)

Please enter selection: 3
sccli> show redun
Primary controller serial number: XXXXXXX
Primary controller location: Upper
Redundancy mode: Active-Active
Redundancy status: Enabled
Secondary controller serial number: XXXXXXX
sccli> q
root@takere # sccli
Available devices:

 1. /dev/rdsk/c7t600C0FF00000000000XXXXXXXXXXXX01d0s2 [SUN StorEdge 3510 SN#00XXXF] (Secondary)
2. /dev/rdsk/c7t600C0FF00000000007XXXXXXXXXXXX00d0s2 [SUN StorEdge 3510 SN#0XXXX4] (Primary)
3. /dev/rdsk/c7t600C0FF00000000007XXXXXXXXXXXX01d0s2 [SUN StorEdge 3510 SN#0XXXX5] (Secondary)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

As seen above, inconsistency was seen in the list of manageable devices seen
by sccli.

The problem described above was seen on the Sun StorEdge 3510, but it could
also be seen on any of the Sun StorEdge 3310/3320/3511 arrays.

================================================

In the Sun StorEdge 3000 Series Extractor (se3kxtr) documentation the following is stated in the KNOWN ISSUES:

o It is recommended to run only a single instance of this 'se3kxtr' script

at a time on the same SE3xxx unit. It has been observed that running

multiple, concurrent sccli commands on the same SE3xxx unit can cause

availability issues on the array.

This solution has no attachment