This post is more than 5 years old
4 Posts
0
6420
Journal volumes in RP
Is there any best practice for the size and quantity of journal volumes in RP? I am about to build a CG with 1x800gb and 1x300gb vmax on the prod side and the same amount/size luns on a CX4 at the DR side. Thanks in advance for your response.
RickBrunner1
117 Posts
0
March 2nd, 2011 15:00
Good question.
Yes in general we recommend that you standardize your journal size so that as you require more journal space, you can easily add additional luns of the same size to allow RecoverPoint to optimize the journal usage and as a best practice you should add in pairs so you get consistent performance. The reason behind this is that RecoverPoint has some sophisticated logic that it utilizes to strike a balance between being able to add journal capacity on the fly and performance optimization.
When you add a journal to an existing consistency group in order to retain the journal history RecoverPoint will concatenate the space. If you add a pair of the same size or within 85% of the same size of each other, then RP will concatenate the existing journals with the new pair, but stripe across the new pair. If the existing journal was striped you get consistent performance, i.e multiple striped pairs concatenated together.
Anytime your disable the CG or change replication direction RecoverPoint will re-optimize the journal usage and will stripe evenly across all the journal luns for this CG, giving even better performance. If the luns in use are within 85% of each other in size then RP will use the smallest lun size truncates all larger luns and stripe across(note you loose space). If the Luns are not within 85% then you it will concatenate them together sacrificing performance, for capacity.
Summary: Choose a size that best fits your journal capacity requirements; add in pairs of the same size.
Hope this helps with your planning and implementation.
-rick
EhudKaldor
29 Posts
0
March 2nd, 2011 15:00
Hi,
there is no simple answer to this question. RecoverPoint does not store the whole disk image on the journal (this is maintained on the actual targets) but rather the deltas coming in before they are applied to the target, and more importantly - the deltas that were changed on the target, so RP can revert to a previous point in time. so, the 2 factors that are meaningful for this question are:
based on these you can roughly and simplistically calculate a journal size: if your source generates 10MB/s, and you have a 10GB journal space (after discarding the undo buffer and internal data), customer have a retention window of 1000 seconds. you can play with the numbers to get to your wanted parameters, but adding snapshot consolidation only makes this calculation a bit less trivial.
the good news, after this long explanation, is that the BCSD tool can help, based on some information, give you a good estimate of what your journal should be. your TC should have access to BCSD.
or, if you just want a simple arbitrary number, 25% of the total CG capacity sounds like a respectable neighborhood
SprinkleJames
23 Posts
0
June 17th, 2011 09:00
Does RP take into account which physical disks the journal LUNs are on? Based on the info I can find, if I assign 2 same-size journal LUNs from the same RAID group, RP will stripe across those. Couldn't that hurt performance, striping on the same RAID group?
Russ_Cook
9 Posts
1
January 19th, 2017 06:00
To cut down on head movement I would create the CG Journal LUNS next to each other if putting them in the same RG