Optimum Update Type Settings for Consistency Groups

Hi Hessler - what product are we talking about here?

CX3-20c

Navisphere 6

I was hoping someone would jump in on this -- I'm going to move the thread over to the support forums to try and get your question answered. -Gina

Good call Gina - I've moved the question as you've suggested.

I'm assuming you are using consistency groups for MirrorView/A replication...

FYI, the update settings for a consistency group override the individual settings in the Mirrors themselves.

The update interval is the number of minutes between mirrorview updates so the smaller the number, the more often the mirror will update.  The way MirrorView/A works is as follows..

• Before MirrorView starts an update, when a block is changed, MirrorView tracks the change in a bitmap, no snapshot operation occurs, no data is moved.

• When an update starts, MirrorView marks the changed blocks that it tracked in the bitmap for snapshot protection and starts copying those blocks.  If the marked blocks are changed during the update, a copy-on-first-write operation occurs, moving the original block to the Reserve LUN Pool so that MirrorView can still read it for the update.

• During the update, if unmarked blocks are modified, the bitmap is used to track those changes for the next update -- No COFW occurs.

• Once the update completes, the blocks that were updated are unmarked, protected blocks from that update are cleared from the Reserve LUN Pool and MirrorView waits until the next scheduled update.

So, knowing this, you can probably see that the performance hit occurs DURING the update, not between updates.  The more often updates occur, the more potential for COFW operations, and hence the more chance of a performance impact. If you have very little write activity on the source LUN, then updates will have very little impact on performance.  If your application is constantly writing all over the LUN, completely random, an update will have much more impact. 

The good thing is that the copy-on-first-write operation only occurs, as it's name implies, on the first write to the same block.  So if your application writes to the same block many times, the impact is very little..

In general I recommend using the "End of Last Update" option and starting with at least 30 minutes.  You can monitor performance with Analyzer and adjust up or down to balance RPO (Recovery Point Objective, ie: amount of data loss in a disaster) with production performance.  End of Last Update is the number of minutes that MirrorView waits to start a new update after the previous update completed.  Your RPO will be equal to the duration of the update + the interval setting.  (Example: End of Last Update is set to 30, and each update takes 8 minutes, your RPO = 38 minutes.)

With the Start of Last Update option, if you set it to 30 minutes but the update takes 40 minutes, the next update will start immediately after the previous one completes, there will be no delay.

If you need a low RPO, but your performance is suffering as a result, use Analyzer to check the physical disk performance for the Reserve LUN Pool disks, changing to a faster RAID type (ie: RAID10 vs RAID5), or adding more or faster spindles to the RLP can help improve performance.

I hope my explanation helped and it answers your question.  If not, feel free to ask more questions, or for explanation.