Unsolved
This post is more than 5 years old
26 Posts
0
1520
RLP LUN Selection - How Is It Determined
Can anyone shed some light on how MirrorView/A selects LUN's from the RLP on the target system?
I am trying to empty a traditional raid group of private LUN's that are currently used as RLP LUN's in a MirrorView/A configuration. I have built a bunch of new LUN's on the target system in a handful of traditional raid groups that are going to remain on the target array. I have added these LUN's to the RLP and have seen that several of these "new" RLP LUN's have been allocated and are being used but the majority of the RLP LUN's that continue to be used are the LUN's that have been assigned and used by the RLP prior to my adding the new.
Can you influence which RLP LUN will be selected by MirrorView/A processing? If so, how is this done?
I don't want to destroy the mirrors and have to resync so I was hoping that by adding new LUN's to the RLP I could eventually get the old LUN's out and run on the new.
Any assistance/thoughts would be appreicated.
All the best!
Dave
Anirudh_Banerje
59 Posts
1
January 4th, 2012 04:00
Hi Dave,
I would suggest you to go through EMC Whitepaper: Mirrorview Knowledgebook as to know how RLP works in case of Mirrorview/A.
Please check page - 50.
download the document from the below link..
http://powerlink.emc.com/km/live1/en_US/Offering_Technical/White_Paper/h2417-mirrorview_knowledgebook-flare-wp.pdf?mtcs=ZXZlbnRUeXBlPUttQ2xpY2tTZWFyY2hSZXN1bHRzRXZlbnQsZG9jdW1lbnRJZD0wOTAxNDA2NjgwNWVmNDJhLGRhdGFTb3VyY2U9RENUTV9lbl9VU18w
sunking1
26 Posts
0
January 4th, 2012 12:00
Mike,
Thank you for the response to my question. Can you please clarify what is the important factor in RLP selection? Is it the LUN number or the raid group that the RLP LUN is built in?
For example, let's say that I have LUN3500 built in Raid Group 1and I also have LUN100 in Raid Group 5. The next request for an RLP would pull LUN100 due to the low LUN number? Or would it pull LUN3500 due to the raid group? Does SP ownership play any part in the selection process?
I also now understand what you are suggesting regarding building the LUN's across multiple raid groups (100, 102, 104 in RG1 and 101, 103, 105 in RG2).
Thanks again!
Kind regards,
Dave
Anonymous
5 Practitioner
5 Practitioner
•
274.2K Posts
1
January 4th, 2012 12:00
Hi Dave, I looked at the knowledge book reference and didn't see the answer I think you may be looking for. That is, Reserve Luns for Mirrorview / A are selected based on the lowest available Lun ID. So if yoiu are trying to spread the load across two different raid groups you should have Raid Group 1 with RL's 100, 102,104,106,108 and Raid Raid Group 2 with RL's 101,103,105,107,109. So each new Mirror that is looking for a Reserve Lun will pick from alternating Raid groups. First Lun 100 will be used then Lun 101 then lun 102 and so on,(103,104,105) then if Lun 100 is released it will be next in lin rather than let's say Lun 106. So you cannot perfectly balance the load between the RLP's this way but it;s the best way I've found to spread them out. Lot's of smaller RLP's better than fewer larger ones.
Regards,
Mike
Anonymous
5 Practitioner
5 Practitioner
•
274.2K Posts
0
January 4th, 2012 13:00
It is the Lun ID. The Raid Group ID does not factor into the selection at all.
sunking1
26 Posts
0
January 4th, 2012 13:00
Mike,
Thanks for the continued feedback and understood
Perhaps you can help me understand why I am seeing this in my RLP. Below, you will see that I have LUN's 3585 through 3649 that I have built in the raid groups that I want my RLP's to live in. At this time, LUN's 3585 through 3618 have been allocated by the MirrorView. LUN's 3619 through 3649 have not been selected. Beyond these newly created LUN's I have old RLP LUN's that I want to get off of that continue to be used even though they are a higher LUN number. Is it just that MirrorView has not yet cycled off of these old LUN's to use the new LUN's?
Thanks again for the feedback!
Storagesavvy
474 Posts
0
January 4th, 2012 13:00
Each data LUN that has an associated snapshot (or Mirrorview/A session, which uses snapshot sessions) starts by grabbing one RLP LUN -- at a minimum, 1 RLP LUN per Data LUN. As far as I remember, as long as one snapshot session remains on the data LUN, that first RLP LUN will remain allocated. You can delete all of the snapshot sessions to free up the last RLP LUN but that won’t release the Mirrorview/A sessions. I can’t remember for sure, but Admin Fracturing the mirrors might clear out the MV/A snap sessions.
Richard J Anderson
Anonymous
5 Practitioner
5 Practitioner
•
274.2K Posts
0
January 4th, 2012 14:00
Sorry I missed the fact that this was the Target array, in which case I believe Richard is on the right track, if you have Snaps of the MV/A Secondaries they may be holding the RLP's and can be cleared by deleteing ALL sessions.
Any RLP's held by the MV/A Target sessions should release at the end of each async update.
RLP's help by MV/A Source Luns will not release until secondary image is removed, thus requiring a full sync.