RLP LUN Selection - How Is It Determined

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

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

It is the Lun ID. The Raid Group ID does not factor into the selection at all.

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!

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

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.