This post is more than 5 years old
5 Practitioner
•
274.2K Posts
0
7568
RecoverPoint Journal Design
A frequent question I see is, "Can I use SATA Drives for the Journal?". The short, glib abswer is, "Yes". The more meaningful answer is, "Yes, if you can configure the SATA drives to provide the performance your Journal will require."
The Journal is a very busy fellow. He does an average of three I/Os for every write to the production volume. When calculating Journal performance requirements, you should take the peak write rate of your application and triple it as a starting point. Next you should add in the I/Os that you will generate when doing logged acces of the replica, for all those writes get logged also. That can be a harder number to come. A good rule of thumb is to double the I/Os. A good practice would be to add 10-20 % more for the unknown.
This is a lot of I/Os which could translate into a lot of spindles to be able to handle the workload. All is not lost, however. Production I/O Block size is on the order of 16 KB. The RecoverPoint Journal uses large sequential I/O. While the block size will vary, for the purpose of sizing, the recommended average Journal I/O Block size to use is 600 KB.
If you have been using the RecoverPoint Calculator or the BCSD Modeling tool, you may have wondered why it reported performance numbers in MB/sec. Now you know. 64 MB/sec of write at 16 KB Blocks is ~4,000 IOPS. When you triple this number and use 600 KB Blocks for the Journal, the I/O is a much more manageable ~336 I/Os per second. Other factors come into play for Journal performance. Your don't want Journals on the same spindles as the production or replica as the workloads are really not compatible (Random small block versus Sequential large block). You'll likely have multiple Consistency groups, each with there own Journal. Be careful how many you stack on a set of spindles to again avoid contention.
So, circling back around to the question at the beginning of this discussion, "Can I use SATA Drives for the Journal?", the answer is , "Yes" but there are a lot of considerations that need to be taken into account. Another one of them is that while SATA drives are inexpensive, how many more of them will I need than say of FC drives? Does that difference in quantity negate the per disk drive advantage of SATA. Lots of questions that can only be answered on a per customer basis.
DA
117 Posts
0
March 5th, 2012 07:00
If your journal can't perform, you will most likely have a growing journal lag. In other words, the data will be written to the replica journal, but will not be distributed to the replica. The immediate impact is RTO: you will have to wait to access the latest image in logged/physical mode.
Eventually, the lag will reach the size of the journal and you will lose all your snapshots.
If the journal is extremely slow, I believe you may immediately enter high load state, where replication will pause. In that scenario, your RPO is affected: your data is not making it to the replica at all, until you exit the high load.
CrazyEarl
7 Posts
0
January 30th, 2012 11:00
As a storage admin, I have to do a bit of ad-hoc measuring to determine Journal size because I don't know how busy an application will be if it's new. My basic formula is the journal size should equal 15% of the total amount of disk being replicated, which will give me 24 hours of recovery in the journal. i.e. 1 TB of replicated data will require me to make a 150 GB journal.
Of course, I understand that 1 TB of SQL data for a particular financial app could produce 2x the amount of "changes" that 1 TB of Exchange might produce. I just offer up my opinion as a basic methodology for storage admins out there that don't get the information ahead of time but have to decide the size of the journal in spite of it.
I have a great scripting team where I work that runs a journal size script and logs it away for me so we can study journal usage over time to adjust as needed. I can say that for the most part; I don't change the size of too many journals.
Hope this helps.
Clustor
57 Posts
0
March 4th, 2012 06:00
that's great info!
but the thing i want to know is what will actually happen if you don't follow these best practices regarding journal performance?
What will happen to your application performance? (how is it impacted?)
I'm pretty much ok with explaining what's needed and why (1:3 write ratio etc.) , but i'm not sure about the consequences when not followed..