While setting up SRM with NetApp 6290 at a customer site, my customer was using Qtrees and Qtree SnapMirror which caused us few issues. If you are setting up SRM and using NetApp Qtree SnapMirror, there is quite few warnings, limitations, and best practices that you will need to be aware of. I have listed the most common ones below, though for a more complete list you should check the following document: http://www.netapp.com/us/media/tr-4064.pdf
– Avoid using hidden Qtrees as that seems to cause problems with several versions of the NetApp SRM SRA. One of the most common errors caused by such configuration is:
Error: Failed to sync data on replica device ‘/vol/volume_name/lun#. Device found is neither of SAN type nor of the NAS type. Ensure that the device exists on the storage array and is of type NAS or SAN.
– If you have configured qtrees as NFS datastores, you must create an NFS export for each qtree in order for SRM to be able to discover the NFS datastore. If you export only the volume that contains the qtrees, so that there is only one export line for the volume in the /etc/exports file, SRM will not be able to discover the qtree NFS datastores.
– If you are using qtrees in an SRM environment and if you configure multiple qtrees in the same volume, mounting each qtree separately as a different NFS datastore, NetApp recommends using qtree-level SnapMirror with SRM.
– If you are using qtrees in an SRM environment, and if you configure multiple qtrees in the same volume with each qtree containing a LUN that is a different VMFS datastore, NetApp recommends using qtree-level SnapMirror with SRM.
Best Practice
– If you are using qtrees, with multiple qtrees in one volume as separate datastores in the VMware environment, the level at which you mirror data should match the level at which you configured the datastores. Meaning, if you are using different qtrees in the same volume to store different datastores, use qtree-level SnapMirror for each qtree. If you are storing each datastore in its own volume, use volume-level SnapMirror for each volume.22 Deploying VMware vCenter Site Recovery Manager 5 with NetApp FAS/V-Series Storage Systems
– SRM 5 has the capability to failover a datastore from the protected site to the recovery site, reverse that replication, and fail back to the primary site. If you’ve configured multiple qtrees as individual datastores in the same volume and are using volume-level SnapMirror, SRM will not be able to reverse replication for one of the qtrees in that volume without reversing replication for all the qtrees in that volume
If you are using SRM with NetApp Qtree then the above warnings and best practices are definitely worth checking out.
2 responses to “Qtree SnapMirror warnings and limitations with SRM”
Hi,
Thanks for the article, very useful!
I was wondering if you experienced any issues completing a SRM test failover against a datastore using qtrees? We are experiencing an issue where the test fails complaining about flexclone licensing (flexclone licenses are in place)
An actual failover works okay.
Kind regards
Olly
Hi Olly, it might be something with the way you have configured flexclone. Please note SRM does not use flexclone for an actual failover where it only use it for a test failover which explain why a real failover work for you but not a test failover.