Subscribe

Best approach for dedupe + iSCSI LUNs + SnapMirror

Hello,

I am trying to determine the best approach for leveraging dedupe with iSCSI LUNs and SnapMirror.  If SnapMirror were out of the equation, it sounds like the best approach to maximize deduplication is:

- Volume space guarantee = none (thin provisioned)

- LUN space reserved = no (thin provisioned)

- Volume autosize = on

- Snap autodelete = on

This would essentially "transfer" the space savings back to the aggregate for everyone to enjoy.  However, the biggest problem I am seeing is that the volume autosize causes the SnapMirror replication to break all the time because the source volumes are growing larger while the destination volumes are not the same size or larger.  This requires manual intervention, and many hours or days of SnapMirror being down.  If I turn volume autosize off, I am now forced to create an unusually large volume to be able to hold the "worst-case scenario" of snapshots (user-created + SnapManager-created + SnapMirror-created).  Is there another way to simultaneously achieve space savings with dedupe while keeping source and destination volumes sized equally for SnapMirror to keep humming along?

Thanks,

Bill

Re: Best approach for dedupe + iSCSI LUNs + SnapMirror

create destination volume with very big size but set guarantee=none, so essentially once you establish SM relationship on destination only the blocks which are physical written will be in use and rest free blocks will be in the aggregate.