Asset ID: |
1-72-1011457.1 |
Update Date: | 2010-08-26 |
Keywords: | |
Solution Type
Problem Resolution Sure
Solution
1011457.1
:
Sun StorEdge[TM] 6130/Sun StorageTek[TM] 6140/6540: Secondary Array in Remote Replication Pair Logs Alarm Against Primary Volume
Related Items |
- Sun Storage 6540 Array
- Sun Storage 6130 Array
- Sun Storage 6140 Array
|
Related Categories |
- GCS>Sun Microsystems>Storage - Disk>Modular Disk - 6xxx Arrays
|
PreviouslyPublishedAs
215699
SymptomsAfter creating a remote replication set(repset), the secondary array throws the
following alarm in Common Array Manager(CAM):
Alarm Id : alarm1965
Severity : Critical
Type : 6140.ProblemEvent
Topic : REC_REMOTE_NO_LUN
Event Code : 57.66.1054
Date : 2007-04-05 13:33:38
Device : spine6140[SUN.54065460150.0648AWF0D0]
Description : Unable to contact remote volume dcretekdr_v6 on a reachable array.
ResolutionThe problem is that the heartbeat being sent to the primary array is somehow being rejected.
To resolve this issue:
- Attempt to delete the repset and recreate it
- Delete all repsets from the primary, and deactivate/activate Remote Replication. Then recreate the repsets
If the above fails, please contact Sun Services for further help in
resolving this issue.
Additional InformationCreating a repset in the reverse direction results in an alarm similar to:
Alarm ID : alarm17
Description: Unsynchronized mirror error, local: testrep1, remote: NDF
Severity : Critical
Element : 600A0B800029838800006AA3461B641C
GridCode : 57.66.1053
Date : 2007-04-10 13:42:32
ProductSun StorageTek 6540 Array
Sun StorageTek 6140 Array
Sun StorageTek 6130 Array (SATA)
Sun StorageTek 6130 Array
Internal Comments
The most common symptom of this issue is the Destination Driver event below:
Date/Time: Tue Apr 10 01:44:56 EDT 2007
Sequence number: 220838
Event type: 1012
Event category: Error
Priority: Informational
Description: Destination driver event
Event specific codes: 5000205/25/0
Component type: Drive
Component location: None
Logged by: Controller in slot A
Raw data:
4d 45 4c 48 02 00 00 00 a6 5e 03 00 00 00 00 00
12 10 11 10 58 24 1b 46 13 00 00 00 00 00 00 00
06 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00
01 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 04 7c 00 00
20 00 12 01 05 02 00 05 25 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
03 46 0b ec 20 00 12 81 00 00 00 00 ff 01 01 04
ee ee ee ee 00 00 05 00 02 52 25 00 02 94 05 00
02 52 25 00 07 44 05 03 20 00 12 81 02 b4 06 06
09 d8 05 03 02 b4 06 06 0c 6c 05 01 ff 06 00 00
0f 00 05 01 ff 09 00 00 00 00 00 00 0c 00 12 81
00 00 00 00 00 00 00 00 00 00 00 00
This DDE occurs on both A and B controllers, and appears to indicate:
5000205/25/0
05 cc
00 dd
02 ss
05 Sense
25 ASC
0 ASCQ
byte 175= 04
channel 5
detected by target
failed command
last error
illegal request
logical unit not supported
This DDE only occurs while a replication set is enabled on the secondary array.
If you delete all active replication sets(primary and secondary) for the array
pair, the DDE will no longer occur, since there is no further replication
activity taking place.
Experience with this problem has dictated that if the array is suffering from
this condition, a simple delete and create will not fix this issue. Since
we cannot reproduce the issue, we would want new instances tracked by an escalation. The escalation engineer should employ the following technique to
gather more data on the problem:
1. Delete all RVM sets
2. On both controllers(on BOTH ARRAYS) set the following options in VKI_EDIT_OPTIONS
actToDq=1
traceOn 5,3
traceOn 24,3
3. Attempt to create RVM Mirror
4. If the mirror is not successful dump active trace(from each controller on both arrays).
dqprint "trace"
5. After log data is collected, escalate to LSI, providing the following additional command set
luall 0x14
luall 0x13
luall
ionShow 99
spmShow
6. Based on customer necessity, the resolution may be provided as either
clearing stable storage, or resetting the array to factory defaults via
sscs(1M).
NOTE 1: Clearing stable storage removes lun mappings, array licenses, and any user created pool and profile associations with volumes. All of these will need to be put back after performing this process. It does not remove any data volumes or vdisks, nor does it change the FEID on the array(which would invalidate the current customer licenses).
NOTE 2: System reset(sscs reset -a arrayname array) resets the array back to factory defaults, much like the "sysWipe" command. This removes data partitions, mappings, pools, and profiles. It does not affect licensing.
NOTE 3: Replication will have to be re-activated after this procedure.
6130, 6140, 6540, RVM, alarm, CAM, repset, replication
Previously Published As
89108
Change History
Date: 2007-04-29
User Name: 31620
Action: Approved
Comment: Verified Metadata -
Verified Keywords -
Verified still correct for audience - currently set to contract
Audience left at contract as per FvF at
http://kmo.central/howto/content/voyager-contributor-standards.html
Checked review date - currently set to 2008-04-20
Checked for TM - ok as presented
Publishing under the current publication rules of 18 Apr 2005:
Version: 4
Date: 2007-04-27
User Name: 31620
Action: Accept
Comment:
Version: 0
Attachments
This solution has no attachment