A page for research/notes/lessons-learned on converting a primary/DR SVM pair from volume snapmirror relationships to an SVM-DR (or SnapMirror for SVM) relationship.
- Key link from the ONTAP 9 documentation:
Notes from the above:
- Each volume (except SVM root) is being replicated
- Each volume on the source (including SVM root) has same name as on destination
- use volume rename when SnapMirror is idle
- use snapmirror resync after rename
- Create SVM replication as per: Replicate an entire SVM configuration
- snapmirror create ... -identity-preserve true
- Stop destination SVM: vserver stop -vserver SVMB
- snapmirror resync -source-path SVMA: -destination-path SVMB: -type DP|XDP -schedule SCHEDULE -policy POLICY
Q&A
Q: What does identity-preserve preserve?
A: See: About SnapMirror SVM replication #configurations-replicated-in-svm-dr-relationships
Q: DP or XDP?
A: XDP (it is the default from ONTAP 9.4)
Q: What policy options?
A: async-mirror (SnapMirror DR) or mirror-vault (Unified Replication)
Q: Can you SVM-DR Flexgroups?
A: Yes, beginning ONTAP 9.9.1. See: Create an SVM disaster recovery relationship for FlexGroup volumes.
Q: What about SnapMirror Business Continuity?
A: NetApp SnapMirror Business Continuity (SM-BC) is a continuously available storage. solution with application-level granularity Note: SnapMirror Business Continuity offers application-level granularity for SAN workloads only.
Notes from #configurations-replicated-in-svm-dr-relationships:
The key thing is that SVM-DR isn't super useful for SAN (still useful for replicating an entire SVM for DR purpose) as we see if we look at the things that are not replicated with -identity-preserve true (updated 11/11/2022):
- Not replicated with -identity-preserve true:
- Network: SAN LIFs, Broadcast domain, Subnet, IPspace
- Root volume: User data, Qtrees, Quotas, File-level QoS, Attributes
- Fibre Channel (FC): No
- iSCSI: No
- LUNs: igroups, portsets, Serial numbers
Other reading
- Jan 4, 2020: SnapMirror Protect (from ONTAP 9.3) with SVM-DR (from ONTAP 9.7)
- Mar 24, 2016: SVM-DR/SnapMirror for SVM Super (Short) Express Guide (8.3.1)
Other Links
- Prerequisites for cluster peering
- Key thing is that each node in the cluster (source and destination clusters) must have an intercluster IP address. SnapMirror requires a full mesh to work (so if you have 2 nodes at the source, 2 nodes at the destination, you need minimum 4 IPs and routing from source to destination cluster and vice versa.)
- A bit on configuring SVM DR using the GUI is covered here:
Comments
Post a Comment