The answer is:
NO. 7 to C
SnapMirror initialization can run at the same time as scheduled 7 to 7 updates*.
If you want to see
a proof, keep reading with our simple lab example...
We have a simple lab. Two 8.1.2P4 7-Mode systems - NAFAS1
and NAFAS2 - are SnapMirror-ing to each other. And we’ll setup a TDP Mirror
(Transition Data Protection Mirror) to a CDOT 8.2.1 single-node cluster - NACLU1 - with a
Storage Virtual Machine (SVM) NASVM1.
We have a 10g volume called testvol on NAFAS1, with a
share called testshare. This volume starts off empty whilst we setup the 7 to 7
Volume SnapMirror relationship from NAFAS1 to NAFAS2, and 7 to C relationship
(but we don’t initialize it) from NAFAS1 to NASVM1. Then we’ll add ~2.5GB worth
of data into the volume (since we’re running in a SIMBOX, this is plenty of
data for the experiment), trigger a 7 to C SnapMirror initialize, followed
right-after by a 7 to 7 SnapMirror update, and see if the 7 to 7 SnapMirror
update is held up.
Image: Overview of
the Lab Setup
Note: This uses the
lab setup of previous posts. MSADM1 is an admin server that here we simply use
for mapping shares to.
NAFAS1: Create
Volume and Share
vol
create testvol aggr1 10g
cifs
shares -add testshare /vol/testvol
snap
sched testvol 0 0 0
snap
reserve testvol 0
NAFAS2: Create
Volume and SnapMirror Relationship
vol
create testvol aggr1 10g
vol
restrict testvol
wrfile
-a /etc/snapmirror.conf NAFAS1:testvol NAFAS2:testvol - - - - -
snapmirror
initialize NAFAS2:testvol
snapmirror
update NAFAS2:testvol
NASVM1: Create
Volume and SnapMirror Relationship (but don’t initialize)
vol
create -vserver NASVM1 -volume testvol -aggregate aggr1 -size 10g -type DP
vserver
peer transition create -local-vserver NASVM1 -src-filer-name NAFAS1
snapmirror
create -source-path NAFAS1:testvol -destination-path NASVM1:testvol -type TDP -policy
DPDefault
Note: Since we specify
no schedule it has none.
MSADM1: Map share and
fill with 2.5 GB data
net use T: \\FS1\testshare
Add ~2.5GB worth of random data.
NASVM1: Initialize
SnapMirror
snapmirror
initialize NASVM1:testvol
snapmirror
show
NAFAS2: Trigger
SnapMirror Update (and see what happens to it)
snapmirror
update NAFAS2:testvol
snapmirror
status NAFAS2:testvol
What happens to
the SnapMirror Update?
Initialize the 7 to
C SnapMirror and see the 7 to C SnapMirror transferring.
NACLU1::>
snapmirror initialize NASVM1:testvol
Operation
is queued: snapmirror initialize of destination "NASVM1:testvol".
NACLU1::>
snapmirror show
Source Destination Mirror
Relationship Total Last
Path Type
Path State Status
Progress Updated
-----------
---- ------------ ------- -------------- -------- --------
NAFAS1:testvol
TDP
NASVM1:testvol
Uninitialized
Transferring 0B 05/05 21:34:51
NACLU1::>
snapmirror show
Progress
Source Destination Mirror
Relationship Total Last
Path Type
Path State Status
Progress Updated
-----------
---- ------------ ------- -------------- -------- --------
NAFAS1:testvol
TDP
NASVM1:testvol
Uninitialized
Transferring 247.3MB 05/05 21:35:02
Then we kick off a
7 to 7 SnapMirror update, and see that the 7 to 7 SnapMirror update is proceeding
at the same time as the 7 to C SnapMirror is initializing.
NAFAS2>
snapmirror update NAFAS2:testvol
Transfer
started.
NAFAS2>
snapmirror status NAFAS2:testvol
Source Destination State Lag Status
NAFAS1:testvol NAFAS2:testvol Snapmirrored 00:28:12
Transferring (143 MB done)
NAFAS2>
snapmirror status NAFAS2:testvol
Source Destination State Lag Status
NAFAS1:testvol NAFAS2:testvol Snapmirrored 00:28:21
Transferring (243 MB done)
NAFAS2>
snapmirror status NAFAS2:testvol
Source Destination State Lag Status
NAFAS1:testvol NAFAS2:testvol Snapmirrored 00:28:27
Transferring (298 MB done)
We see testvol on
the source has 3 “busy” SnapMirror snapshots.
NAFAS1>
snap list testvol
date name
------------ --------
May
05 21:34 NAFAS2(4221225673)_testvol.3
(busy,snapmirror)
May
05 21:34 NASVM1(4082368507)_testvol.1
(busy,snapmirror)
May
05 21:06 NAFAS2(4221225673)_testvol.2
(busy,snapmirror)
The 7 to C SnapMirror
initialization finishes.
NACLU1::>
snapmirror show
Progress
Source Destination Mirror
Relationship Total Last
Path Type
Path State Status
Progress Updated
-----------
---- ------------ ------- -------------- -------- --------
NAFAS1:testvol
TDP
NASVM1:testvol
Uninitialized
Transferring 2.49GB 05/05 21:36:54
NACLU1::>
snapmirror show
Progress
Source Destination Mirror
Relationship Total Last
Path Type
Path State Status
Progress Updated
-----------
---- ------------ ------- -------------- -------- --------
NAFAS1:testvol
TDP
NASVM1:testvol
Snapmirrored
Idle - -
The 7 to 7
SnapMirror update finishes.
NAFAS2>
snapmirror status NAFAS2:testvol
Source Destination State Lag Status
NAFAS1:testvol NAFAS2:testvol Snapmirrored 00:31:19
Transferring (2550 MB done)
NAFAS2>
snapmirror status NAFAS2:testvol
Source Destination State Lag Status
NAFAS1:testvol NAFAS2:testvol Snapmirrored 00:03:18
Idle
Our source has two
SnapMirror snapshots - one for NASVM1, the other for NAFAS2.
NAFAS1>
snap list testvol
Volume
testvol
working...
%/used
%/total date name
---------- ----------
------------ --------
0% ( 0%)
0% ( 0%) May 05 21:34 NAFAS2(4221225673)_testvol.3 (snapmirror)
0% ( 0%)
0% ( 0%) May 05 21:34 NASVM1(4082368507)_testvol.1 (snapmirror)
*Other
Considerations
“1) Each 7-Mode
controller can only support a certain number of concurrent replication
operations. Please refer to the Data ONTAP Data Protection Online Backup and
Recovery Guide for more details about the limits.
“2) If the source
7-Mode controller is already serving the maximum supported current replication
operations, the next subsequent requests will fail till current replication
operations have finished.
“3) You can use
‘rsm show_limits’ to know the current status of replication operations on the
7-Mode controller.”
In the below example of running ‘rsm show_limits’ on the
simple Data ONTAP 8.1.2 7-Mode Simulator “SIMBOX”, we have 16 tokens, and when
we run a 7 to C SnapMirror update, see that one of the MP VSM SRC replication types is running consuming 4 tokens, which
leaves only 12 tokens (and a maximum 3 more transfers of cost 4 tokens.)
NAFAS1>
rsm show_limits
Model:
SIMBOX
Tokens
total: 16
Replication_Type
Cost Sys_Max Running Avail_Tokens Possible
VolCopy SRC 4
4 0 16 4
VolCopy DST 4
4 0 16 4
Legacy VSM SRC 4
4 0 16 4
Legacy VSM DST 4
4 0 16 4
MP VSM SRC 4
4 0 16 4
MP VSM DST 4
4 0 16 4
Sync SM SRC 4
4 0 16 4
Sync SM DST 4
4 0 16 4
Legacy QSM SRC 4
4 0
16 4
Legacy QSM DST 4
4 0 16 4
QSM SRC 4
4 0 16 4
QSM DST 4
4 0 16 4
Legacy SV SRC 4
4 0 16 4
Legacy SV DST 4
4 0 16 4
SV SRC 4
4 0 16 4
SV DST 4
4 0 16 4
NAFAS1>
rsm show_limits
Model:
SIMBOX
Tokens
total: 12
Replication_Type
Cost Sys_Max Running Avail_Tokens Possible
...
MP VSM SRC 4
4 1 12 3
...
Comments
Post a Comment