Continuing from the SVM-DR/SnapMirror for SVM Super (Short) Express Guide (8.3.1) from 2016 (yes, really 7 years ago) a few more notes.
##########################################
## SVM-DR EXPRESS (based on above link) ##
##########################################
## Preparation ##
BOTH::> cluster peer show
BOTH::> system license show
BOTH::> job schedule cron show # IMPORTANT: Create the same custom schedules on the destination cluster!
BOTH::> storage aggregate show
## Creating a destination SVM ##
CLU2::> vserver create -vserver SVM1-DR -subtype dp-destination
CLU2::> vserver show -vserver SVM1-DR
## Create the SVM peer relationship ##
CLU2::> vserver peer create -vserver SVM1-DR -peer-vserver SVM1 -applications snapmirror -peer-cluster CLU1
CLU1::> vserver peer accept -vserver SVM1 -peer-vserver SVM1-DR
BOTH::> vserver peer show
## Creating a SnapMirror Relationship ##
CLU2::> snapmirror create -source-vserver SVM1 -destination-vserver SVM1-DR -policy MirrorAllSnapshots -schedule hourly -identity-preserve true
CLU2::> snapmirror show -destination-vserver SVM1-DR
CLU2::> snapmirror initialize -destination-vserver SVM1-DR
CLU2::> snapmirror show -destination-vserver SVM1-DR
#######################
## CONVERT TO SVM-DR ##
#######################
http://www.cosonok.com/2023/04/ontap-convert-to-svm-dr-research.html
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:
Convert volume replication relationships to an SVM replication relationship
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
####################
## SVM-DR CUTOVER ##
####################
https://docs.netapp.com/us-en/ontap/data-protection/make-svm-destination-volumes-writeable-task.html
If you set -identity-preserve true when you created the SVM replication relationship, stop the source SVM:
cluster_src::> vserver stop svm1
cluster_dst::> snapmirror quiesce -source-path svm1: -destination-path svm_backup:
cluster_dst::> snapmirror abort -source-path svm1: -destination-path svm_backup:
cluster_dst::> snapmirror break -source-path svm1: -destination-path svm_backup:
cluster_dst::> vserver start svm_backup
Then:
cluster_dst::> snapmirror delete -source-path svm1: -destination-path svm_backup:
cluster_src::> snapmirror release -source-path svm1: -destination-path svm_backup:
#####################################################
## DISABLING CIFS SESSIONS BEFORE THE FINAL UPDATE ##
#####################################################
If you're doing an SVM-DR cutover of a CIFS enabled SVM, you really want to have no CIFS sessions running before your final update.
https://kb.netapp.com/onprem/ontap/da/NAS/How_to_terminate_CIFS_or_close_a_specific_session_for_a_volume_in_ONTAP
Examples of what you can do in ONTAP 9:
cluster_src::>
vserver cifs session close -node NODE
vserver cifs session close –vserver VSERVER
vserver cifs session close –session-is SESSION_ID
vserver cifs session close –connection-id CONNECTION_ID
vserver cifs session close –lif-address INCOMING_LIF_IP
vserver cifs session close –auth-mechanism AUTH_MECHANISM
vserver cifs session close –windows-user WIN_USER
vserver cifs session close –unix-user UNIX_USER
vserver cifs session close –protocol-version PROTOCOL_VERSION
vserver cifs session close –continuously-available {CIFS Open File Protection}
vserver cifs session close –is-session-signed {true|false}
Or you could just do it really quickly (update SnapMirror, stop source vserver, break) and no one will probably notice.
You can also do SVM-DR cutovers in ONTAP System Manager.
Comments
Post a Comment