Remeber to mark this topic Answered once you feel you have the correct information.

glen

Of course, but what is the etiquette of the forum in regards to whom do you set the correct answer flag when several people participate and were very helpful in a long discussion?

I wouldn't set the update interval less than 10 minutes to start. Set it to 10 minutes from the end of the last update. Anything shorter and you might see some performance issues.

glen

That's as difficult as your original question 

I guess you pick the person that came closest to answering your question - the correct answer is not always perfect, but it does help when someone is searching the forum for answers - also, Ernes and Richard provided a lot of good information and sooner - they probably should get the points (Richard needs some).

glen

Hello guys again,

Based on the table below, taken from a week of Analyzer data, if the numbers are correct, updating to a remote image every 15 minutes the array should theoretically use the amount of data in the last column, right? Then I’d like to understand why the .2% requirement of the primary LUN in the scenario.

Can I start with several 3-5 GB LUNs and try it out?

The reason I started the thread was the error on the remote array stating lack of cache LUNs, then if the data on the table denotes the amount of data being replicated to the remote size, why my mirrors would be fracturing with the error "Unable to create protective snap session on secondary array. Snapview returned an error on an attempt to create a protective snap session due to lack of free cache LUN's on secondary array. As a result of the error the mirror will be admin fractured. Add more cache LUN's on the secondary array and retry the sync request. (0x7152863e)".

Best Regards,

Manu.

.2% is the overhead. Don't create RLP LUNs with sizes of 20% off of the source LUN especially since you are running the MV sync every 15 minutes. You can start with 5GB LUNs, nothing will keep your from starting at 5GB. If you write more then 5GB worth of data within the 15 minutes then the next available RLP will be chosen.

I would also recommend you look at write bandwidth and not just write iops. Write iops will help you size the number of drives an RLP should contain but it will not help you size the RLP in GB. Write bandwidth will help you with that. You can use a combination of both, write iops and write bandwidth if you want to really determine the "exact" RLP size. It will not be exact per say but you will be very close to it.

Also, don't look at averages. Calculate the 95% and also take into concern the maximums. At this point you really might be doing too much work. So maybe start with 10gb rlp luns and make sure you have at least the number of rlp luns as you have source luns.

Hello Ernes,

That was exactly my problem. I had at least (25) 3 and 5 GB LUNs available on the primary and secondary arrays and still my mirrors were fracturing.

I’m confused with these free LUNs and mirrors still fracturing.

Regards,

Manu.

I'm not really sure why the mirrors are failing. It should pick the next available RLP lun. Did you open a case with EMC support by any chance? Maybe something else is going on

Ernes, I contacted EMC support and thry referenced me to emc111716.

I'll try one more time to configure the new RLP with sizes around 5 -10 GB.

I'll let you know how it works out.

Thanks!,

Sounds good

What about the size of the secondary array RLP?

On those should I stick to the 20%? or the data from the table above can help me to determine the rate of change?

Thanks!

The data can help you determine the change rate. Make sure you keep maximums in mind as well. Also, if your load does change so will your RLP. Depending on that you might either want to size it or stick to the 20%

Do you mind taking a look to my bandwidth sizes?

Thanks!

That will take some time and I unfortunatly don't have cycles right now