Capacity sizing for SnapMirror

[ThomasBebee]

Hello,

I have some basic questions on capacity sizing for Snapmirror and have looked at the TR's I could find, but did not see the detail I was looking for.

Basically, I am looking for the correct way to account for the space within a volume that will be needed for the SnapMirror snapshots that is need to be maintained while the source and destination are in sync.

My questions are:

1) if a block is locked because there is a snapshot on it, can the reason the snapshot exists be either because of SnapMirror and/or just a normal snapshot taken in a backup scenario? (is a snapshot just a snapshot regardless of how it was created) If this is the case, then that block would only be released once both the SnapMirror and backup snapshots had expired. Is this correct?

2) assuming that in sizing the volume the correct amount of space was added to hold regular backup snapshots (rate of change * number of snapshot copies to maintain) - what is the proper way to determine the additional space needed for SnapMirror based snapshots? Is it as simple as adding in additional space to represent the rate of change that will occur between the SnapMirror updates?

If there is documentation on this available, please just let me know and I will read that.

Thank you.

Tom Bebee

[adamfox]

First off, there's nothing really magical about a snapmirror snapshot. As far as WAFL is concerned a snapshot is a snapshot and it doesn't matter how it was created.

Because of that, I don't think there's a magic formula to tell you how much space you'll need. It depends on the type of snapmirror you are running. In the case of Volume-based SnapMirror, it would primarily depend on the interval between the updates. The longer the interval (and the more writes that occur during that interval), the more space you will need. All of the local snapshots on the source will exist on the destination so you'll need to compute that space + the possibly space for deltas between updates. With Qtree-based SnapMirror, you can have multiple SnapMirror Snapshots as you can have multiple qtrees being replcated to the destination, but the destination itself can have local snapshots, so you have to take those into account too. Again it will ultimately depend on how much write activity you have along with long long you keep snapshots around.

Hope this helps.

[tyeoman_swinton]

Along the lines of what Adam F has already commented on, I normaly workout the 'rate of change' by creating local snapshots and using the 'snap delta' command lets you work out the rate of change between the snapshots. I would always recommend sampling rate of change at different points during the lifecycle of the data you are storing in that particular volume. For example month end processes could have a large impact on the rate of change. This should then help you profile the capacity you need available for any particular snapmirror replication cycle.