snapmiror auto resize

[nadavassa]

Hello,

We have volumes with XDP snapmiror relationship. (ontap 9.3)

when we resize the source volume we should resize also the destination volume? 

also, what is the differences between XDP to DP?

Thank you for your help

[christsai]

Hi @nadavassa 

when we resize the source volume we should resize also the destination volume? 

During a data protection mirror transfer, the destination volume grows automatically in size if the
source volume has grown, provided there is available space in the aggregate that contains the volume.

also, what is the differences between XDP to DP?

Starting with ONTAP 9.3, SnapMirror extended data protection (XDP) mode replaces SnapMirror
data protection (DP) mode as the SnapMirror default.

Until ONTAP 9.3, SnapMirror invoked in DP mode and SnapMirror invoked in XDP mode used
different replication engines, with different approaches to version-dependence.

• SnapMirror invoked in DP mode used a version-dependent replication engine in which the
ONTAP version was required to be the same on primary and secondary storage.

• SnapMirror invoked in XDP mode used a version-flexible replication engine that supported
different ONTAP versions on primary and secondary storage.

https://library.netapp.com/ecm/ecm_get_file/ECMLP2811525

[nadavassa]

Hello,

Thank you for your reply, but I didn't properly understand the auto grow concept.

We have XDP snapmiror relationship between 2 volumes. after resizing the source vol (manually)  the des vol didn't grow automatically (many snapmiror reps/updates occur).

we have enough space in the aggr.

so what is the reason for this situation?

Thanks

[christsai · Accepted solution]

Hi @nadavassa 

I think your snapmirror type is XDP.

1.If the SnapMirror relationship is a "type-DP":
Modify the desired value (size, max inodes, etc.) on the source volume. After a SnapMirror Update\Resync operation from the destination, the value will be reflected on the destination volume as well.

2.If the SnapMirror relationship is a "type-XDP":

By default, a type-XDP destination volume may not match the source volume total size, but will auto-grow and auto-shrink as-needed based on total used space. This is controlled via the autosize-mode of the destination volume which is set to grow_shrink by default. For more information see volume autosize command in the manual pages. You can still increase the destination volume manually through the vol size command, if desired.

https://kb.netapp.com/app/answers/answer_view/a_id/1073852/loc/en_US

[nadavassa]

Thank you for your help!

[DrJoSchu]

Thanks for these infos, but to be honest, we ran into the same problem as we come from DP to XDP for a whole SVM and the source volumes were not set to grow_shrink and lost for some while the replikation without any obvious hint on one of the Dashboard. After three month the number of snapshots for replikation on the target come to 1024, so that also the snapshots for the users were not created, without someone recognised.

In addition, the ndmp Backup of the target (and that was our luck) failed, so we regognized, that there might be a problem, if we had done them on the target, every backup-strategy would have been failed without any obvious hint for that problem!

We are selling the volume to our customers, so If we have to switch over to the destination filer (for what kind of reason), we will loose the correct setting for the size. Also I see a problem coming up, as there is a grow threshold,

So NetApp, please:

- add a warning to the dashboard, if any of the DR fails!

- always replicate the correct (new) size and set the grow_shrink in addition on the target, so that the target has (nearly) the same settings as the source an a resize (let say doubling) will not bring us in trouble, as the source only grows up to 100%+ag%

[TMADOCTHOMAS]

Yes, this. I have been wondering why target volumes have extremely oddball sizes and why we get "volume full" alerts on target volumes all the time which makes no sense. This new approach taken by XDP has been disruptive in that way. I have to manully resize target volumes all the time now when I never had to previously.