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.
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).
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)".
.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.
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
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%
kelleg
4 Operator
•
4.5K Posts
0
September 20th, 2011 11:00
Remeber to mark this topic Answered once you feel you have the correct information.
glen
Elcade
52 Posts
0
September 20th, 2011 11:00
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?
kelleg
4 Operator
•
4.5K Posts
0
September 20th, 2011 11:00
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
Elcade
52 Posts
0
September 20th, 2011 11:00
I really appreciate y’all help in this issue.
I wouldn’t be able to figure it out without your help.
Thank you very much.
Manu.
kelleg
4 Operator
•
4.5K Posts
0
September 20th, 2011 11:00
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
Elcade
52 Posts
0
September 20th, 2011 14:00
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)".
1 Week Avg
15 min
1 Week Avg (KB)
15 min (MB)
@ 20% (GB)
Best Regards,
Manu.
etaljic81
1K Posts
0
September 20th, 2011 18:00
.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.
Elcade
52 Posts
0
September 21st, 2011 08:00
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.
etaljic81
1K Posts
0
September 21st, 2011 09:00
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
Elcade
52 Posts
0
September 21st, 2011 10:00
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!,
etaljic81
1K Posts
0
September 21st, 2011 11:00
Sounds good
Elcade
52 Posts
0
September 21st, 2011 13:00
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!
etaljic81
1K Posts
0
September 22nd, 2011 06:00
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%
Elcade
52 Posts
0
September 22nd, 2011 06:00
Do you mind taking a look to my bandwidth sizes?
Thanks!
etaljic81
1K Posts
0
September 22nd, 2011 07:00
That will take some time and I unfortunatly don't have cycles right now