Month: April 2015

EMC VNX – MirrorView configuration

Last week I have written a short post about introduction to MirrorView. This week I would like to write a little bit more about MirrorView configuration, terminology and usage. Let’s start with terminology

VNX MirrorView Key Terminology

Primary Image – LUN containing production data and the contents of which is replicated to secondary image.
Secondary Image  – LUN containing a mirror of the primary image LUN residing on a different VNX (secondary site)
Image condition – Provides additional information about the status of updates for a secondary image.
State – Remote mirror states and image states.
Consistency Group – Set of mirrors that are managed as a single entity and whose secondary images always remains in a consistent and recoverable state with the primary image and each other.
Consistency Group State – Indicated the current state of the consistency group.
Fracture – Condition in which I/O is not mirrored to the secondary image. Manually initiated by the administrator or by the system when it determines the secondary image is unreachable.
Promote – changes an image’s role from secondary to primary.

 Basic MirrorView Configuration

MirrorView allows for a large amount of topologies and configuration. The primary and secondary images must have the same server-visible capacity (user capacity), because they are allowed to reverse roles for fail-over and fail-back (see Promote definition above). But Primary Image and Secondary Image can reside on different RAID configuration. In order to use MirrorView, the software need to be loaded on both (primary and secondary) VNX arrays. Secondary LUNs are not accessible to hosts during the mirroring. Bi-directional mirroring (VNX array can be both primary and secondary site) is supported, as long as the primary and secondary images within mirror reside on different storage systems.

Consistency Groups

Consistency Groups allow all LUNs that are belonging to a give application to be treated as a single entity and managed as a whole. This helps to ensure that the remote images are consistent. As a result, the remote images are always re-startable copies of the local images. When a mirror is part of a Consistency Groups, most operations on individual members are prohibited (for example fracture, or synchronize can only be executed for the Consistency Group).

Site Level Fan-In

MirrorView supports 4:1 Fan-In ratio. It means that one VNX array can be a destination (secondary site) for 4 (different) primary VNX arrays. It’s a common configuration when remote VNX Array is used for consolidated backups, simplified failover or consolidated remote processing activities. The 4:1 Fan-In ratio is applicable to both MirrorView/S and MirrorView/A

LUN Level Fan-Out

Fan-out mirroring may be used to replicate data from one primary LUN to up-to-two secondary LUNs residing on different arrays. (MirrorView/S 1:2 Fan-out ratio). This configuration enables administrator to synchronously mirror one primary image to two different secondary images. In case of MirrorView/A, one primary image can be mirrored only to single secondary image (MirroView/A 1:1 Fan-out ratio).

 Port configuration

MirrorView ports are automatically assigned when the system is initialized. All MirrorView traffic goes through one dedicated port of each connection type (FC or iSCSI) per Storage Processor. For VNX that have FC and iSCSI systems, one FC port and one iSCSI are available for MirrorView traffic (per SP).

A path must exist between the MirrorView ports of SP-A of the primary and SP-A of a secondary system. Same relationship must exist for Storage Processor B. MirrorView ports may be shared with host I/O, but that might cause performance issues.

 Mirrored Image States

Once an image has been mirrored, the image may be in one of three availability states:

  • Inactive – inactive mirrored states means that the Administrator has stopped mirroring.
  • Active – an active status is considered a normal state, where all I/Os are allowed on the image.
  • Attention – this state indicated that something has happened to the mirrored image and action by an Admin is required.

In terms of the mirrored image consistency and relationship with the source image, MirrorView contains five data states

  • Out-of-Sync – means that a full sync is in order
  • In-Sync – indicate that the primary and secondary contains identical data and the operation is in progress
  • Rolling Back – the act of returning a primary to a predefined point-in-time.
  • Consistent – the mirroring has been stopped and a write intent or fracture log is needed to continue the mirroring
  • Synchronizing – the operation of synchronizing is in progress.

MirrorView Common Operations


Synchronization is a copy operation MirrorView performs during newly-created mirrors or to reestablish existing mirrors after an interruption. Initial synchronization is used to create a baseline copy of the primary image to the secondary. Primary images remain online during the sync process and until the synchronization is complete, the secondary image is unusable.


A secondary image is promoted to the role of primary when it is necessary to run production applications at the disaster recovery site. A promotion can only occur if the secondary image is in the consistent or synchronized state.


A fracture stops MirrorView replication from the primary image to the secondary mirror. Administrative fractures are usually initiated to suspend replication, as opposed to a system fracture which is initiated by the MirrorView software. A system fracture typically means a communication failure between the primary and secondary systems.

With MirrorView/S writes continue to the primary image but are not replicated to the secondary during a fracture. Replication can resume when the user issues a synchronize command.

With MirrorView/A the current updates stop during a fracture and no futher updates will start until a synchronize request is issued.


EMC VNX – MirrorView introduction

MirrorView offers block-based replication features for EMC VNX. There are two remote mirroring modes:

  • MirroView/S (Synchronous)
  • MirrorView/A (Asynchronous)

The MirrorView is a technology that mirrors and active block data set to a remote VNX system. It’s a great solution for a disaster recovery replication. MirrorView is LUN centric which means the replication is from a primary LUN (on our primary VNX) to a secondary remote LUN (typicaly our disaster recovery site).


MirrorView/S provides synchronous replication over a short distances.  Since it’s synchronous solution, the RPO (Recovery Point Objective) is zero. The data flow of MirrorView/S is:

  1. Host attached to the primary VNX system initiates a write;
  2. The primary VNX replicates the data to the secondary VNX system;
  3. The secondary VNX acknowledges the write as complete back to the primary VNX;
  4. The primary VNX acknowledges the write as complete back to the host.

It is important to understand the data flow of MirrorView/S. As a consequence the RTT (Round Trip Time) between the two VNX system should be less (or equeal) than 10ms. If the RTT is high, then the host will higher response time, because it will take longer time to acknowledge the write request.


MirrorView/A provides replication over long distances. It can be used for replication between VNX arrays, where RTT (Round Trip Time) is high, but should not be higher then 200ms. MirrorView Asynchronous works on a periodic update model that tracks changes on the primary side, and then applies those changes to the secondary at a user-determined RPO (Recovery Point Objective) interval.

With MirrorView/A replications, writes are acknowledged back to the host once the primary VNX receives them, which basically gives no impact on the production environment (whereas with MirrorView/S all writes has to be acknowledged by primary and secondary VNX system).

The dataflow of MirrorView/A is:

  1. Host attached to the primary VNX system initiates a write;
  2. Primary VNX system sends and acknowledge to the host;
  3. Primary VNX system tracks the changes and replicates the data to the secondary VNX system using the user-defined RPO;
  4. Secondary VNX system receives the data and sends an ack back to the primary VNX.

Consistency groups

Both MirrorView/S and MirrorView/A supports consistency groups. Consistency groups are used when a set of LUNs require a consistent write ordering. For example, if you have a VMware datastore build upon 6 LUNs, it would require for all 6 of them to be in a consistent state in relation to each other for proper functionality.