SnapMirror should be a class all itself. There are a lot of reasons a SnapMirror can fail, and a lot of ways to set it up to succeed.
One such failure I dealt with recently involved a simple SnapMirror with a daily schedule. The problem was that it was failing out about the same point—150GB—and then went into a non-SnapMirrored state. However, the hosting aggregate container had over 2TB of free space, and the volume itself had 162GB available . . . what in the world?
The answer lies in how the source and destination volumes were provisioned. Here is what NetApp Says in Technical Report 3563:
One such failure I dealt with recently involved a simple SnapMirror with a daily schedule. The problem was that it was failing out about the same point—150GB—and then went into a non-SnapMirrored state. However, the hosting aggregate container had over 2TB of free space, and the volume itself had 162GB available . . . what in the world?
The answer lies in how the source and destination volumes were provisioned. Here is what NetApp Says in Technical Report 3563:
Volume SnapMirror® replicates an entire FlexVol volume, most often used for disaster recovery. It is an efficient data replication product that transfers only the data present on the source system to the destination system during the initial baseline transfer. All transfers from that point forward only transfer modified data blocks to the destination. Volume SnapMirror seamlessly integrates with thin provisioning to
initially transfer and write to the destination only used data. — NetApp TR-3563
Here's the depiction that NetApp offers in technical report. It is a great way to understand the benefits of thin provisioning for disaster recovery replication.
But what about when the source is thick-provisioned? In our case here, the source volume was a Cisco Unified Communications datastore, and Cisco UC requires thick (eager-zeroed) provisioning. Ah, there's the rub.
Volume SnapMirror seamlessly integrates with thin provisioning to initially transfer and write to the destination only used data.
The problem is that from a "used data" perspective, the entire LUN is "used"—though NetApp System Manager will still report gigabytes and gigabytes of available space. So in this case, SnapMirroring from a thick-provisioned LUN to a thin-provisioned LUN of the same size failed right at the end every time, because the destination needed to be just a bit bigger than the source due to thick-provisioning. I added a few extra GBs for good measure, and wallah! SnapMirrored!
RSS Feed