Skip to main content
NetApp Knowledge Base

What is the potential impact of using quick-resync parameter?

  1. Last updated
    Nov 16, 2023
  2. Save as PDF
Views:
452
Visibility:
Public
Votes:
0
Category:
snapmirror
Specialty:
dp
Last Updated:
11/16/2023, 4:18:29 AM

Applies to

  • ONTAP 9
  • SnapMirror
  • Data Warehouse (DW)
    • The Data Warehouse includes metadata critical in maintaining deduplication savings from the source volume
  • Storage Efficiency (SIS)

Answer

Here's a high-level example of the potential impact of using quick-resync:
  • SnapMirror relationship starts A->B (Prod->DR).
  • ONTAP SIS finds blocks on A and dedupes them.
  • These blocks and savings are replicated to the B.
    • When a new block is written on A that is deduped to an existing shared block, this block does not need to be transferred to B as the DW file recognizes it has an entry for that already-deduped-block.
    • This means quicker transfer time.
  • SnapMirror is broken, and new data was added to B.
  • Reverse resync is issued using quick-resync 
    ::> snapmirror resync -source-path B -destination-path A -quick-resync true
    • Only the delta written to B is replicated to A
    • Even if a block is written to B that is deduped, there's no DW file on (A) that maps to it because quick-resync was used.
    • This means that the entire block has to be transferred to A (and typically would be deduped there).
    • This is what they mean by command doc of snapmirror resync describing "When this parameter is specified, resync does not preserve the storage efficiency of the new data with existing data over the wire and on the destination.".
  • Now after that block is replicated over, a new entry is added to the B->A DW file. So if the same block-that-gets-deduped occurs again, SnapMirror doesn't have to transfer the block again.

Additional Information

  • snapmirror resync 
     [-quick-resync <true>] - Quick Resync

    This parameter is only supported for extended data protection (XDP) relationships. This parameter is not supported for relationships with non-Data ONTAP endpoints. It is not supported for relationships with a policy of type strict-sync-mirror and sync-mirror . Specifying this optional parameter reduces the resync time because the resync does not incur storage efficiency overhead before the transfer of new data. Specifying this parameter is recommended if the source of the resync does not have volume efficiency enabled or if reducing resync time is more important than preserving all possible storage efficiency. When this parameter is specified, resync does not preserve the storage efficiency of the new data with existing data over the wire and on the destination.

  • SnapMirror relationships report a Preparing relationship status
    • If converting a SnapMirror relationship from type-DP to type-XDP, allow the Data Warehouse operation to complete as this is necessary to take advantage of all the features of a Type-XDP SnapMirror relationship.
  • Using quick-resync for volumes with large deduplication savings can result in future updates not preserving some or all storage efficiency savings from the source volume (i.e. deduplicated blocks are re-replicated)
  • Any performance and space penalties from using quick resync will reduce as normal SnapMirror updates proceed after the resync
  • Enabling additional deduplication on the destination volume can reduce potential space penalties from using quick resync
  • The impact of these penalties depend on controller resources and the filesystem of the volume in question, but any noticeable impact is rare
  • A higher deduplication percentage is a good indicator of the impact that -quick-resync could have
  • How to run SnapMirror reverse resync with "-quick-resync" parameter
  • Convert an existing DP-type relationship to XDP
  • Technical Report tr-4015 SnapMirror configuration and best practices guide for ONTAP 9
    ・Logical replication with storage efficiency (LRSE). 
    　LRSE uses block-level metadata and knowledge of the file system to determine differences between Snapshot copies at the indirect pointer level.
    　LRSE organizes the transfer of data from the source to the destination in two streams. 
    　− The data stream consists of data blocks that are transferred with specific volume block number (vvbn#) within the destination volume. 
    　　 This vvbn# helps identify the block number at which the data is stored on the source FlexVol volume, but without specifying a file context. 
    　　 On the destination, the data is written to the data warehouse (DW) file with a file block number (fbn#) which corresponds to the vvbn#. 
    　− The user files are transferred by reference using the user file inodes, which share blocks with the data warehouse file and do not use buffer trees that require parsing to reach a specific object. 
    　　 LRSE makes explicit requests to the block-sharing infrastructure of the DW blocks (the donors) with user files (recipients) while replication transfer is in progress. 
    　　 The mirror has a structure of logical block pointers to the original data set that has a completely different on-disk physical layout relative to the source. 
    　　 The SnapMirror relationship is created with -type XDP using the SnapMirror policy type async-mirror, vault or mirror-vault. 
    　　 LRSE preserves space efficiency over the wire and on the destination when replicating data in storage-efficient source volumes. 
    　　 Storage efficiency is an important part of LRSE because features such as block sharing and compression allow a volume to effectively hold far more data than the space used.
    　  This efficiency must be preserved during replication to avoid the replica growing to an intolerably large size, not to mention the time needed to transfer it. 
        LRSE also allows enablement of storage efficiency features on the secondary, independent of the primary storage settings. 
    　　 For more information, see Use deduplication, data compression and data compaction to increase storage efficiency – overview.
    　　 https://docs.netapp.com/us-en/ontap/...y-concept.html

 

NetApp provides no representations or warranties regarding the accuracy or reliability or serviceability of any information or recommendations provided in this publication or with respect to any results that may be obtained by the use of the information or observance of any recommendations provided herein. The information in this document is distributed AS IS and the use of this information or the implementation of any recommendations or techniques herein is a customer's responsibility and depends on the customer's ability to evaluate and integrate them into the customer's operational environment. This document and the information contained herein may be used solely in connection with the NetApp products discussed in this document.