Skip to main content
NetApp Knowledge Base

FAQ: E-Series ARVM Mirror Repositories and Initial Sync

  1. Last updated
  2. Save as PDF
Views:
513
Visibility:
Public
Votes:
0
Category:
e-series-systems
Specialty:
esg
Last Updated:

Applies to

E-Series storage

Answer

What is a Mirror Repository?

  • Special mirror repository volumes are used to manage mirror data synchronization. A mirror repository volume is required for each Primary and Secondary volume in a mirrored pair.
  • A mirror repository stores three types of data:
    1. A copy-on-write repository, structurally similar to the repository used for a Snapshot Image.
    2. A pair of Delta Logs, which are used to track regions of the Primary Mirror Volume that are written between synchronization intervals. Even though the Delta Logs are only used on the Primary side of the mirror, they must also be allocated on the Secondary side, since a role-reversal can occur at any time.
    3. A log that tracks synchronization statistics on a per mirror-pair basis.

What is the Primary Mirror Repository used for?

  • Used during a sync operation to 'freeze' the primary volume so that no data changes while it is being synced.
  • This is accomplished by using a copy-on-write repository (that is, Snapshot Image), which is created at the beginning of the sync.
  • The sync is carried out by reading from the snapshot image, which by definition does not change when new data is written to the primary mirror volume. 

What happens when the Primary Mirror Repository becomes full?

  • The only type of data that causes the Primary Mirror Repository to fill is the Snapshot Image.
  • The repository fills when host IO is written to the Primary Mirror Volume.
  • When enough writes come in to fill the repository, the Snapshot Image fails and is deleted. When this occurs:
    1. Incoming host writes are not affected, nor is the sync operation suspended.
    2. The sync operation continues to synchronize the Logical Block Address (LBA) regions, which are recorded in the delta log.
    3. Once all LBAs in the delta log have been synchronized successfully, a new Snapshot Image is created and another sync operation is automatically started.
    4. This new sync operation will synchronize the LBA regions which have changed since the start of the sync in which the Snapshot Image failed. 

What is the Secondary Mirror Repository used for?

  • The Secondary Mirror Repository is used during a sync operation to store all data that is being changed on the secondary mirror volume. This is accomplished by using a copy-on-write repository (that is, Snapshot Image), which is created at the beginning of the sync.
  • Before each LBA region on the Secondary Mirror Volume is updated with data from the primary, the LBA is first copied into the Secondary Mirror Repository. This is to safeguard against the need to resync the mirrored pair from scratch (go through another initial sync) in the event of an error during a sync.
  • If any errors occur during a sync, the snapshot image can be used to 'roll-back' the Secondary Mirror Volume to the state in which it was, before the sync began. After a roll-back is performed, another sync operation may be attempted. 

What happens when the Secondary Mirror Repository becomes full?

  • The only type of data that causes the secondary mirror repository to fill is the Snapshot Image.
  • The repository fills when IO is written to the Secondary Mirror Volume from the Primary Mirror Volume.
  • If there is more data to be synced than there is free capacity on the Secondary Mirror Repository, the repository will become full.
  • When the repository becomes full:
  1. The sync operation is suspended.
  2. For the sync to resume, either:
  • Option 1: The Secondary Mirror Repository must be expanded.
    • Pro: Allocates more capacity to be used for additional data to be synced and preserves the Snapshot Image.
    •  Con: Uses valuable free capacity to be consumed. Once a repository is expanded, it cannot be reduced in size.
  • Option 2: The Snapshot Image must be deleted (This is accomplished by resuming the AMG).
    • Pro: Does not require the Secondary Mirror Repository to be expanded.
    • Con: An error during the sync may require the mirrored pair to be re-synched from scratch (to go through another initial sync). 

What is Initial Synchronization?

  • When the mirror relationship is first established, the data from the Primary volume is copied in its entirety to the Secondary volume.
  • During the copy, the Primary volume is fully accessible for I/O operations by all host systems that would normally have access to it.
  • The initial sync is completed in two phases:
    • Phase 1:
      • The Primary Mirror Volume is copied in its entirety to the Secondary Mirror Volume (this may take several hours or days to complete).
      • There are no Snapshot Images created on the Primary or Secondary Mirror Volumes during Phase 1.
      • Once all of the data has been copied from the Primary Mirror Volume to the Secondary Mirror Volume, Phase 2 begins.
    • Phase 2:
      • A Snapshot Image is created on the Primary and the Secondary Mirror Volumes.
      • All LBAs that have changed on the Primary Mirror Volume since the start of Phase 1 are synced.

Note: Phase 1 will normally take much longer to complete than a normal scheduled sync operation. This may cause the Secondary Mirror Repository to become full during Phase 2. Increasing the Secondary Mirror Repository in this scenario may leave the repository unnecessarily large.

Can Dynamic Volume Expansion feature be used with mirroring?

  • Dynamic Volume Expansion (DVE) increases the capacity of a volume. The increase capacity is achieved by using the free capacity that is available on the volume group of the standard volume or the snapshot repository volume.
  • The new usable mirror capacity is limited by the smaller of the primary volume and secondary volume of the mirrored pair. Therefore, considerations need to be reviewed, in order that both volumes can be successfully expanded.
  • During the DVE, the Primary volume is fully accessible for I/O operations by all host systems that would normally have access to it.
  • You can perform a DVE operation on a primary volume or a secondary volume of a mirrored pair.  However, you cannot perform a DVE operation on a mirror repository volume.

Note: To perform a DVE operation, the remote volume mirror must be in an Optimal status. If the mirror relationship is not optimal, a full initial sync will need to complete before the expanded space would be observed on the host.

Additional Information

additionalInformation_text

 

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.