Solved!
Go to SolutionMirrowView Async AdminFractured!!
Active Primary - CX-310c
1GB Fibre (<200Metres)
Passive DR - CX-310c
Flare 03.24.010.5.017
5x 500GB LUNs
MirrowView Async
Hello Guys
I discovered the Update Type on all our mirrors was set to Manual and last time updated was some conciderable time ago. The Update Type for Start of Last Update value was changed from Manual to a value of 60. Everything appears well, secondary copy was syncronising away -I left it at 20%. I came back a few hours later expecting to find everything looking good insted I found the below:
1. All Mirrors had a red F next to them with a status of [Async;Active]
2. The Secondary images all had a status of [AdminFractured; Consistent]
3. The status of Last Image Error is below:
The session for the mirror has failed because the secondary array has run out of cache. As a result of this error, the mirror will be adminfractured. Add more cache LUN's on the secondary array and retry the sync request. (0x7152819c)
I have already logged a support request, any ideas greatly appreciated....
Thanks
Zed
1GB Fibre (<200Metres)
Passive DR - CX-310c
Flare 03.24.010.5.017
5x 500GB LUNs
MirrowView Async
Hello Guys
I discovered the Update Type on all our mirrors was set to Manual and last time updated was some conciderable time ago. The Update Type for Start of Last Update value was changed from Manual to a value of 60. Everything appears well, secondary copy was syncronising away -I left it at 20%. I came back a few hours later expecting to find everything looking good insted I found the below:
1. All Mirrors had a red F next to them with a status of [Async;Active]
2. The Secondary images all had a status of [AdminFractured; Consistent]
3. The status of Last Image Error is below:
The session for the mirror has failed because the secondary array has run out of cache. As a result of this error, the mirror will be adminfractured. Add more cache LUN's on the secondary array and retry the sync request. (0x7152819c)
I have already logged a support request, any ideas greatly appreciated....
Thanks
Zed
396
0
Posted April 20th, 2009 09:00
Hey
I dont know if I am understanding your question ?
Will the mirror not start to resync once you have added more cache on your target array ?
Thanks396
0
Posted April 20th, 2009 10:00
The page in the MirrorView knowledgebook you want to take a look at is page 33 under the Cache section.
If you started all of your mirrors back up at the same time then there is a lot of data and changes to track and most likely this is why the error happened. All of the reserved luns became full. You can either sync just a few at a time and hope the reserved luns are not totally consumed, or the best thing to do is allocate more reserved luns on the secondary.
-Ryan396
0
Posted April 20th, 2009 13:00
RG ID, RAID LEVE, TOTAL, CAPACITY, TYPE, DISKS, QUANTITY, LUN NAME,
RG0 R5 402.72 402.47 FC 133.68 5
RG1 R5 534.59 34.59 FC 133.68 5 VMWARE DATA 1
RG2 R5 400.94 275.94 FC 133.68 4
RG3 R5 1073.48 73.48 FC 268.40 5 VMWARE DATA 2 + VMWARE DATA 3
RG4 R5 1073.48 573.48 FC 268.40 5 VMWARE DATA 4
RG5 R5 1073.48 573.48 FC 268.40 5 VMWARE DATA 5
RG6 UNBOUND 0.00 2292.82 SATAII 458.60 5
RG7 UNBOUND 0.00 2292.82 SATAII 458.60 5
RG8 UNBOUND 0.00 1834.25 SATAII 458.60 4
RG28 HOT SPARE 458.60 0.00 SATAII 458.60 1
RG29 HOT SPARE 268.40 0.00 FC 268.40 1396
0
Posted April 20th, 2009 13:00
Thank you for all your helpful comments guys and gals
Me (& a helpful lady from the EMC Boston officewere able to free up the space on RLP removing the secondary images on the mirrors - they were 12 month old and had a update Type of Manual!
RyanP, that is exactly what the plan - sync one at a time and then assess the situation,
I realise best practice is to have each LUN in RLP 20% of data LUN you are protecting but we do not have the additional FC storage available. I would rather not use the remaining free space across our production raid groups as when mirrorview kicks in (at 60mins) the IOP/s on our production LUNs will take a hit.
This brings me on brings me on nicely to my next question, what would you guys say if SATAII disks were used to add additional LUNs to the secondary RLP? Surely there wouldn¿t be too much of hit as we would be dealing with sequential write IOP/s right? We have SATAII storage currently unbound.
I have pasted the our disk layout, hopefully it will not be to badly formatted!254
0
Posted April 21st, 2009 00:00
You cannot add more cache to a Clariion.
Message was edited by:
RRR
I'm sure about it !396
0
Posted April 21st, 2009 07:00
We generally discourage the use of SATA for RLP - remember that with mirrorview/A the RLP are being used as a snapshot (both on the source side and on the DR side) - you're going to be doing a lot of Writes.
glen254
0
Posted April 21st, 2009 07:00
By adding more cache i think they mean, adding additional LUNs to the Reserve LUN Pool396
0
Posted April 21st, 2009 09:00
Thanks for the info Glen. I remember readed something similar in the RLP Best Practices guide, after I posted...
MirrorView A now working!!382
0
Posted April 21st, 2009 13:00
Glad to hear it's all working now. Remember to set the update time to a reasonable time - start out with a 10 minute interval from the end of the last update - if the update is taking longer to complete, try 20 minutes. If you have the time too short, you can impact performance because of the need to create all the snapshots for each mirror session.
glen
kelleg
6 Operator
•
4537 Posts
396
0
Posted April 20th, 2009 07:00
Please see the Mirrorview Knowledgebook on PowerLink for more information, also the White Paper on Reserve LUNs.
White Paper: MirrorView Knowledgebook: FLARE 28 - A Detailed Review
http://powerlink.emc.com/km/live1/en_US/Offering_Technical/White_Paper/H2417_clariion_mirrorview_asynch_dr_wp_ldv.pdf
White Paper: EMC CLARiiON Reserved LUN Pool Configuration Considerations - Best Practices Planning
http://powerlink.emc.com/km/live1/en_US/Offering_Technical/White_Paper/H1585_clariion_resvd_lun_wp_ldf.pdf
Glen