The Asynchronous Mirroring feature differs from the Synchronous Mirroring feature in one essential way: it captures the state of the source volume at a particular point in time and copies just the data that has changed since the last image capture.

With synchronous mirroring, the state of the primary volume is not captured at some point in time, but rather reflects all changes that were made on the primary volume to the secondary volume. The secondary volume is identical to the primary volume at every moment because, with this type of mirror, each time a write is done to the primary volume, a write is done to the secondary volume. The host does not receive an acknowledgment that the write was successful until the secondary volume is successfully updated with the changes that were made on the primary volume.

With asynchronous mirroring, the remote storage array is not fully synchronized with the local storage array, so if the application needs to transition to the remote storage array due to a loss of the local storage array, some transactions could be lost.

Comparison between mirroring features:

When you are selecting a primary volume for a mirrored pair, a list shows all the eligible volumes.

Any volumes that are not eligible to be used do not display in that list. Volumes might not be eligible for any of the following reasons:

When you are selecting a secondary volume on the remote storage array, a list shows all the eligible volumes for that mirrored pair.

Any volumes that are not eligible to be used, do not display in that list. Volumes might not be eligible for any of the following reasons:

You configure mirrored pairs in the SANtricity Unified Manager interface, and then manage the pairs in SANtricity System Manager.

Before creating a mirrored pair, follow these guidelines:

The synchronization priority defines how much processing time is allocated for synchronization activities relative to system performance.

The controller owner of the primary volume performs this operation in the background. At the same time, the controller owner processes local I/O writes to the primary volume and associated remote writes to the secondary volume. Because the resynchronization diverts controller processing resources from I/O activity, resynchronization can have a performance impact to the host application.

Keep these guidelines in mind to help you determine how long a synchronization priority might take and how the synchronization priorities can affect system performance.

These guidelines roughly approximate the differences between the priorities.

Volume size and host I/O rate loads affect the synchronization time comparisons.

Manual resynchronization is recommended because it lets you manage the resynchronization process in a way that provides the best opportunity for recovering data.

If you use an Automatic resynchronization policy and intermittent communication problems occur during resynchronization, data on the secondary volume could be temporarily corrupted. When resynchronization is complete, the data is corrected.