SVMs and data protection, SVM-DR and env's with and without MetroCluster

[dkorns]

This is one of those questions where it would be fair to ask "what are you trying to do" but right now I am still in a stage of figuring out "what we can and can't potentially do" so as to avoid any road blocks in some automation enhancements (WFA and PoSH) being considered.

My customer has WFA workflows that create SVMs and volumes within them.

• The svm-creation-workflow can create a secondary-SVM with it's own LIFs and peer to it (a regular SVM, not a formal SVM-DR).
• The vol-creation workflow allows a vol-snapmirror to also be automatically setup to the 'other' secondary SVM at vol-create time. This vol-creation workflow does not 'yet' create exports or shares on the secSVM (and we need to address that).

For the next version of these workflows there is an interest in:

1. Determing if SVM-DR might be a better approach for the svm-creation-workflow ... to either switch all secondary SVM creation to be SVM-DRs or provide an option for one (regular secSVM) or the other (SVM-DR secSVM). (thou I prefer one or the other)
2. Also, in the same environment, this customer has some MetroClusters. Right now the svm and vol creation workflows are not MC-aware and part of the next phase will be to allow the svm-creation-workflow to let the user select if they desire sync-mirror-level DR (aka MC) or async-mirror-level, and depending on the choice, determine which clusters offer that level of service and place the SVM on appropriate cluster: A) on a MC cluster, B) on another non-MC cluster. 
3. Lastly, we'd like the svm-creation and vol-creation workflows to support off-MC data protection to a cluster beyond the MetroCluster (maybe only SnapVault, but maybe SnapMirror too).

Now to my question: There is a statement in the ONTAP 9.0 (maybe in 8.3.1 too) SVM DR Express Preparation guide (http://nt-ap.com/2h2hry7) in the 'Deciding whether to use this guide' section that says "The source or destionation cluster is not a MetroCluster Configuration". My question is: Is that warning just saying that 'express guide" doesn't go into the details of how to setup an SVM-DR config when a MC is involved, -OR- that SVM-DR absolutely can not be used when either src or dst SVM live on a MetrocCluster.

Either answer is fine and I understand that one might ask what do you need SVM-DR on top of MC for anyway (our added use-case might be to have have SnapVaults to an off-MC SVM for backup)  ... I'm just trying to collect the config facts for the overall discussion and decision in determining if a move to SVM-DR makes sense or should we enhance our use of tradition SVM peering with vol-level SM (and adding SV support and secSVM export/share setup for failover). 

PS: additional question might be: any difference in the answer between ONTAP 8.3.1, 9.0 or 9.1 (I don't think so, but ...)

[ekashpureff]

dkorns -

A long post to ask a short question !

There's nothing about MetroCluster I know of that would restrict you from setting up SnapMirror or Snap vault to a remote destination.

We teach it as reference architecture in our C-Mode Data Protection class.

Reason to do it is to protect data beyond the 300km limit of MC.

There's one gotcha I can think of for implementing your WFA workflows.

They might want to put in logic to ensure the DP destination is NOT the MetroCluster partner cluster.

No changes I know of in 9.X that would affect these workflows.

Would love to come teach our new 'Creating Custom Workflows with WFA' for your customer, if we haven't done so already!

🙂

I hope this response has been helpful to you.

At your service,

Eugene E. Kashpureff, Sr.
Independent NetApp Consultant http://www.linkedin.com/in/eugenekashpureff
Senior NetApp Instructor, FastLane US http://www.fastlaneus.com/
(P.S. I appreciate 'kudos' on any helpful posts.)

[aborzenkov]

---

ekashpureff wrote: 

There's nothing about MetroCluster I know of that would restrict you from setting up SnapMirror or Snap vault to a remote destination.

---

SnapMirror relationship is between specific peer clusters. After switchover resources are now hosted on different cluster. What process updates SnapMirror destination to pull data from new peer?

I'm going to setup this and test ...

[dkorns]

Thanks Eugene, thanks for the reply

Yes, I was a bit wordy but I was trying to zero in a specific combination of features. I'm aware I can SnapMirror and Vault to a remote peered standard SVM on another cluster. My question is strictly focused on the (new in 8.3.1) SVM-DR style SnapMirror of a complete SVM (living on a MetroCluster aka MC). As I said, one of the Express Guides explicitly says SVM-DR'ing of a MetroCluster is not covered (in the manual) ... and my question is: 'Is it disallowed in general'. I'm beginning to believe it is disallowed and you can't combine MC and SVM-DR because both MC and SVM-DR share the use of MDV_CRS_ volumes to replicate SVM data (i.e.; MC replicating from subtype 'sync-source' to 'sync_destination' SVM) and SVM-DR replicating from subtype 'default' to 'dp-destination' in the remote cluster case)

I think since SVM-DR is really only for SnapMirror use (no vaulting allowed and is really intended for DR only) that this is NOT a major use-case hole. They both provide easy DR setup and the need to layer one on top of the other would be a stretch case ... and even if you do need it (teriary DR somewhere off the MetroCluster), you can still build it using standard peered SVMs, SnapMirror, and customer specific replication of what metadata (exports, shares, etc) is needed.

But if you have the ability to test SVM-DR off a MC, try it and let us know otherwise. I'm just trying to confirm a negative and the literature is a bit fuzzy.   

[Sebastian_Goetze · Accepted solution]

As far as I know, at least in 8.3.1, both SVM DR and MetroCluster use the same Configuration Replication Service and are therefore incompatible.

I'm trying to dig into the 9.1 documentation to find, if it has changed: the SVM DR prep express guide still says, no metrocluster...

[dkorns]

Thanks Sabastion, that confirms other sources.