Monday, 5 May 2014

Does 7 to C SnapMirror Initialization Hold Up Scheduled 7 to 7 Updates?

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.

Image: The “testshare” 
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
...

No comments:

Post a Comment