A man's got to know his limitations

[#1]

I am in a design phase of the replicate-failover-failback procedure using VSM (volume snapmirror) or QSM (qtree snapmirror) - initialize, update, break, resync, break, resync, ...  The VSM resync is limited to two controllers being in the same ONTAP version and QSM resync is limited to source and destination being a qtree and not a volume.

In general case I will have two controllers with different ONTAP versions and the source data in a volume and not in a qtree.

In this situation the VSM cannot be used since ‘resync’ will fail when trying to reverse the VSM direction to the older ONTAP source. Not much luck with QSM either since it does not allow to ‘resync’ back from the qtree to the volume (the /- syntax).

The only strategy that would sort of work for the ‘general case’ (different ONTAP versions and source data in the volume not qtree) is to use QSM and move the volume data in the source volume to a new qtree before setting up replication.  Still forcing this move of data to a qtree that later can be ‘resynced’ is a major pain and is intrusive for CIFS/NFS configuration of the source.

Did anybody come across this VSM (ONTAP version) and QSM (source being qtree) limitations and got a better idea?

[#2]

Hi there:

Preferably or best practice: Have both the source and destination on the same rev or versions. You will not have issues(resync or initialize or break or update) when the both the source and destinations at same versions. Source version can be lower than the destination filer version but you may have issues depending on the data ontaps versions of source and destinations.

Best Practice: When performing VSM, please do the volume to volume instead the qtree on the destination. If performing QSM, it is qtree.

thank you,

AK G

[#3]

AK G, Thanks for confirming what I stated in the original question.  Any ideas to address the issue?

[#4]

What about this: in my understanding the VSM cannot be reversed (resync) back to the old version of the ONTAP because after the 'snapmirror break' the newer ONTAP destination controller will perform optimization of the old WAFL filesystem. That changes or upgrades of WAFL will not be supported on older ONTAP and resync back will fail.

What if we found the way not to make changes to the destination volume after replication and leaving it exactly as it was received - in the older ONTAP version?  This could be a new volume option "do-not-upgrade" and the ONTAP would leave it as is.

[#5]

Peter Ziobrzynski wrote:
The only strategy that would sort of work for the ‘general case’ (different ONTAP versions and source data in the volume not qtree) is to use QSM and move the volume data in the source volume to a new qtree before setting up replication.  Still forcing this move of data to a qtree that later can be ‘resynced’ is a major pain and is intrusive for CIFS/NFS configuration of the source.

You can mange how the CIFS/NFS shares are exported after you move the data into the qtree. Done it a few times and it works just fine for the end users, i.e. they see the shares/exports as before, no change

- Stop access to these shares (unexport /delete cifs share).

- create qtree

- move the data from the root of the voluime into the qtree.

- reexport cifs shares by including the qtree name in the path.

- for nfs exports use -actual option to mask the qtree name in exports

[#6]

gopinathp:

Good point with -actual option approach for NFS clients. This minimizes the impact. Still the procedure is quite intrusive on the primary site CIFS/NFS clients.

[#7]

If planned well you can do that in under few minutes   

Moving data from the root of the volume to a qtree should be quick, as it won't actually copy the data, just moves them.

https://kb.netapp.com/support/index?page=content&id=3011968