h2417 Mirrorview Know CX Series Flare WP LDV

MirrorView Knowledgebook: Releases 30 - 31.
5
A Detailed Review

Abstract
This white paper is a comprehensive guide for MirrorView
functionality, operations, and best practices. It

discusses the specifics of the synchronous (MirrorView/S) and asynchronous (MirrorView/A) products, and
compares them to help users determine how each is best deployed.

August 2011

MirrorView Knowledgebook: Releases 30 - 31.5
A Detailed Review 2
Copyright 2006, 2007, 2008, 2009, 2010, 2011 EMC Corporation. All rights reserved.
EMC believes the information in this publication is accurate as of its publication date. The information is
subject to change without notice.
THE INFORMATION IN THIS PUBLICATION IS PROVIDED AS IS. EMC CORPORATION
MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND WITH RESPECT TO THE
INFORMATION IN THIS PUBLICATION, AND SPECIFICALLY DISCLAIMS IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Use, copying, and distribution of any EMC software described in this publication requires an applicable
software license.
For the most up-to-date listing of EMC product names, see EMC Corporation Trademarks on EMC.com
All other trademarks used herein are the property of their respective owners.
Part Number H2417.7

A Detailed Review 3
Table of Contents
A Detailed Review .............................................................................................. 0
Executive summary ........................................................................................... 6
Introduction ....................................................................................................... 7
Audience ..................................................................................................................................... 8
Terminology ................................................................................................................................ 8
Remote replication overview ............................................................................ 8
Recovery objectives .................................................................................................................... 8
Recovery point objective ......................................................................................................... 9
Recovery time objective .......................................................................................................... 9
Replication models ...................................................................................................................... 9
Synchronous replication model ............................................................................................... 9
Asynchronous replication model(s) ....................................................................................... 10
MirrorView family ............................................................................................. 10
MirrorView configurations ......................................................................................................... 11
Bidirectional mirroring ............................................................................................................ 11
System level fan-in/fan-out .................................................................................................... 11
LUN level fan-out ................................................................................................................... 12
MirrorView over iSCSI ............................................................................................................... 12
MirrorView ports and connections ............................................................................................. 13
Common operations and settings ............................................................................................. 18
Synchronization ..................................................................................................................... 18
Promoting a secondary image ............................................................................................... 19
Fracture ................................................................................................................................. 21
Recovery policy ..................................................................................................................... 21
Minimum required images ..................................................................................................... 22
Interoperability .......................................................................................................................... 22
Storage-system based replication software ........................................................................... 22
Virtual LUNs .......................................................................................................................... 23
Block operating environment ................................................................................................. 25
Mirroring thin LUNs ................................................................................................................... 25
MirrorView/Synchronous ................................................................................ 27
Data protection mechanisms .................................................................................................... 27
Fracture log ........................................................................................................................... 27
Write intent log ...................................................................................................................... 28
Fracture log persistence ........................................................................................................ 29
Synchronization ........................................................................................................................ 29
Thin LUN secondary images ................................................................................................. 30
Link requirements ..................................................................................................................... 30
Limits ........................................................................................................................................ 31
MirrorView/Asynchronous .............................................................................. 32
Data protection mechanisms .................................................................................................... 33
Tracking and transfer maps ................................................................................................... 33
Delta set ................................................................................................................................ 34
Gold copy (protective snapshot) ............................................................................................ 35
Reserved LUNs ..................................................................................................................... 35
Initial synchronization ................................................................................................................ 36
Link requirements ..................................................................................................................... 37

A Detailed Review 4
Limits ........................................................................................................................................ 37
Storage-system-based consistency groups .................................................. 38
Benefits of storage-system-based consistency groups ............................................................. 38
MirrorView/S .......................................................................................................................... 39
MirrorView/A .......................................................................................................................... 40
Managing storage-system-based consistency groups .............................................................. 41
Consistency group promote options.......................................................................................... 42
MirrorView management ................................................................................. 43
Required storage system software............................................................................................ 43
Management topology .............................................................................................................. 43
Management network connectivity ........................................................................................ 43
Unisphere domains ............................................................................................................... 44
Management software .............................................................................................................. 45
MirrorView Wizard ................................................................................................................. 46
Mirror LUN properties ............................................................................................................ 47
Remote mirror configuration .................................................................................................. 47
Consistency group configuration ........................................................................................... 48
Storage Group configuration ................................................................................................. 48
Write intent log configuration (MirrorView/S) ......................................................................... 49
Reserved LUNs (MirrorView/A) ............................................................................................. 50
Advanced dialogs .................................................................................................................. 51
Unisphere Analyzer ................................................................................................................... 53
MirrorView failure recovery scenarios ........................................................... 55
Primary component failure and recovery .................................................................................. 55
Path failure between server and primary image .................................................................... 55
Primary image LUN failure .................................................................................................... 55
Storage processor (SP) controlling primary image failure ..................................................... 56
Primary image storage system failure ................................................................................... 56
Secondary component failure and recovery .............................................................................. 58
Secondary image LUN failure ................................................................................................ 58
Storage processor (SP) controlling secondary image failure ................................................. 58
Secondary image storage system (or link) failure .................................................................. 58
Full reserved LUN (MirrorView/A only) ...................................................................................... 59
On the primary storage system ............................................................................................. 59
On the secondary storage system ......................................................................................... 59
Using SnapView with MirrorView ................................................................... 59
LUN eligibility ......................................................................................................................... 60
Limit dependencies ............................................................................................................... 61
Instant restore ....................................................................................................................... 61
Clone state Clone Remote Mirror Synching ........................................................................ 61
Automation and reporting software ............................................................... 62
VMware vSphere and Site Recovery Manager (SRM) .......................................................... 62
EMC Replication Enabler for Microsoft Exchange Server 2010 ............................................ 63
EMC Data Protection Advisor (DPA) ..................................................................................... 63
MirrorView/Cluster Enabler (MV/CE) ..................................................................................... 63
Replication Manager ............................................................................................................. 63
AutoStart ............................................................................................................................... 64
VNX for File and Celerra ....................................................................................................... 64
Sybase Mirror Activator ......................................................................................................... 64
Disk drive technologies and advanced data services ................................... 64

A Detailed Review 5
iSCSI connections ........................................................................................... 67
Conclusion ....................................................................................................... 71
References ....................................................................................................... 71
White papers ............................................................................................................................. 71
Product documentation ............................................................................................................. 71
Appendix A: Remote mirror conditions and image states............................ 73
Mirror states .............................................................................................................................. 73
Secondary image states ........................................................................................................... 73
Image condition......................................................................................................................... 74
Appendix B: Consistency group states and conditions ............................... 75
Consistency group states .......................................................................................................... 75
Consistency group conditions ................................................................................................... 75
MirrorView/S .......................................................................................................................... 75
MirrorView/A .......................................................................................................................... 76
Appendix C: Storage-system failure scenarios ............................................. 77
Appendix D: Data protection roles ................................................................. 79

A Detailed Review 6
Executive summary
EMC
MirrorView
software offers two complementary storage-system-based remote mirroring products:

MirrorView/Synchronous (MirrorView/S) and MirrorView/Asynchronous (MirrorView/A). For the VNX
series, both MirrorView products are included in the Remote Protection Suite, the Total Protection Pack,
and the Total Efficiency Pack. For CX4 series and prior systems, the synchronous and asynchronous
products are licensed separately or can be purchased as the MirrorView bundle. These products are
designed as block-based storage-system disaster recovery (DR) solutions for mirroring local production
data to a remote/disaster recovery site. They provide end-to-end data protection by replicating the contents
of a primary volume to a secondary volume that resides on a different VNX series or CLARiiON series
storage system. MirrorView data protection is defined as end-to-end because, in addition to performing
replication, it protects the secondary volume from tampering or corruption by only making the volume
available for server access when initiated through MirrorView.
MirrorView/S is a synchronous product that mirrors data in real time between local and remote storage
systems. MirrorView/A is an asynchronous product that offers extended-distance replication based on a
periodic incremental-update model. It periodically updates the remote copy of the data with all the changes
that occurred on the primary copy since the last update.
MirrorView also offers consistency groups, a unique consistency technology for the midrange market that
replicates write-order dependent volumes. Using this technology, MirrorView maintains write ordering
across secondary volumes in the event of an interruption of service to one, some, or all of the write-order
dependent volumes.
Data replication for both MirrorView/A and MirrorView/S is supported over VNX series and CLARiiONs
native Fibre Channel (FC) and iSCSI ports. Several distance extension technologies such as Dense Wave
Division Multiplexing (DWDM) and FC over Internet Protocol (IP) are supported for use with MirrorView.
Consult the EMC Support Matrix (ESM) for supported products.
Business requirements determine the structure of a DR solution. The business will decide how much data
loss is tolerable, if any, and how soon the data must be accessible again in the event of a disaster. It is
common for businesses to classify their applications and employ a DR strategy for each application,
balancing service levels with cost.

MirrorView/S offers a zero data loss option, while MirrorView/A offers an alternative when minutes of
data loss may be tolerable. Consistency groups enable both MirrorView products to offer application
restart. That is, applications with write-ordered dependent volumes, like databases, can resume operating
on the secondary image with little to no maintenance required. This is compared to application recovery,
which typically entails restoring from an older copy, such as a backup, and applying changes to bring the
application to its state before the disaster.

RecoverPoint (including RecoverPoint/SE) is an appliance-based DR solution that supports both local and
remote replication. A RecoverPoint/SE license is also included in the Remote Protection Suite, the Total
Protection Pack, and the Total Efficiency Pack.

RecoverPoint performs write journaling; as a result several very granular points of recovery are available. It
supports local replication with full binary copies. It supports remote replication with zero data loss
synchronous and asynchronous options. You should consider RecoverPoint when you need a solution that:

Provides very granular recovery points updates are made every few seconds as opposed to
minutes
upports heterogeneous and/or non-EMC storage systems. (RecoverPoint/SE supports the platform
with which it is sold. For example, if it is purchased with a VNX it supports local and remote
replication with VNX platforms.)
Can switch between synchronous and asynchronous replication on the fly
Supports a recovery point objective (RPO) of seconds
Requires a large number of replicas (100s to 1,000s)

A Detailed Review 7

RecoverPoint offers many other benefits such as supporting WAN optimization features like compression
and deduplication. For more information, see the white paper EMC RecoverPoint Family Overview on
Powerlink
.

SAN Copy
is another storage-system-based remote replication product. It is designed as a multipurpose

replication product for migrations, data mobility, content distribution, and DR. However, SAN Copy does
not provide the complete end-to-end protection that MirrorView provides; instead it provides an efficient
replication mechanism that can be used as part of a DR strategy. SAN Copy is made available at no
additional cost to VNX customers.

SAN Copy typically plays a complementary role with other software to form a robust DR solution.
Applications such as Replication Manager can be used in conjunction with SAN Copy to manage
application integration and consistency across volumes. Table 1 is a comparison of MirrorView,
RecoverPoint, and SAN Copy.
Table 1. MirrorView, RecoverPoint, and SAN Copy use case comparison
Product MirrorView RecoverPoint SAN Copy
Storage system
support
Replication between VNX
and/or CLARiiON primary
and secondary systems
Replication between
VNX, CLARiiON,
Symmetrix
, and non-
EMC systems
Replication between
VNX, CLARiiON,
Symmetrix, and non-
EMC systems
Software location Storage-system-based Appliance-based (Splitter
software supported on
VNX or CLARiiON SP)
Storage-system-based
Replication modes Sync and async supported
at storage-system level.
Either sync or async at
LUN level
Replication mode at
LUN level can be
dynamically switched
between sync and async
Full copy or incremental
copy
Site level fan
out/fan in
4:1 1:2 cascade (stretched
CDP + CRR)
1:100
LUN level fan out 1 primary to 1 secondary
async; 2 secondaries sync
(1:1 with con groups)
1 primary to 1 secondary
async
1 source copied to up to
100 targets
Data protection Access to secondary
volumes controlled by
MirrorView. SnapView
can be used to access a
replica of secondary image.
Access to secondary
volumes controlled by
RecoverPoint
Remote copy is available
for server access.
SnapView recommended
for data access
Consistency across
volumes
Native consistency group
support
Native consistency group
support
Consistency managed by
the user (Example: hot
backup mode) or another
application (Example:
Replication Manager)
Space reclamation
(thick to thin
replication)
Limited support thin
attributes are not
maintained in many
recovery scenarios
Supported Supported in remote pull
configuration Ideal for
space reclamation during
migration
Introduction
This white paper provides an overview for MirrorView software and discusses key software features,
functions, and best practices. Also refer to the References section of this white paper for related
information, including help files, administrator guides, and white papers.

A Detailed Review 8
Audience
This white paper is intended for systems integrators, systems administrators, customers, and members of
the EMC and partners professional services community. It is assumed that the audience is familiar with
VNX series and CLARiiON storage systems.
Terminology
Terminology, operations, and object statuses are the same for both MirrorView products. The following is
a list of frequently used terms and conditions. A more comprehensive list is available in the product
documentation.
Primary image The LUN containing production data and the contents of which are replicated to the
secondary image. Also referred to as the primary.
Secondary image A LUN that contains a mirror of the primary image LUN. Also referred to as the
secondary. This LUN must reside on a different storage system than the primary image.
Image Condition
1
The condition of a secondary image provides additional information about the
status of updates for the image. Values include normal, administratively fractured, system
fractured, queued to be synchronized, or synchronizing.
State Remote mirror states and image states. The remote mirror states are: Active and Attention.
The image states are: Synchronized, Consistent, Synchronizing, and Out-of-Sync.
Consistency group A set of mirrors that are managed as a single entity and whose secondary images
always remain in a consistent and recoverable state with respect to their primary image and each other.
Consistency Group State Indicates the current state of the consistency group: Synchronized,
Consistent, Synchronizing, Out-of-Sync, Scrambled, Empty, Incomplete, or Local.
Consistency Group Condition Displays more detailed information about the consistency group,
including whether the group is active, inactive, admin fractured, system fractured, waiting on
admin, or invalid.
Fracture A condition in which I/O is not mirrored to the secondary image; this can be caused when
you initiate the fracture (Admin Fracture) or when the system determines that the secondary image is
unreachable (System Fracture).
Promote The operation by which the administrator changes an images role from secondary to
primary. As part of this operation, the previous primary image becomes a secondary image. If the
previous primary image is unavailable when you promote the secondary image (perhaps because the
primary site suffered a disaster), the software does not include it as a secondary image in the new
mirror. A secondary image can be promoted if it is in either the Synchronized state or the Consistent
state. An image cannot be promoted if it is out-of-sync or synchronizing.
Remote replication overview
It is a requirement that critical business information always be available. To protect this information, it is
necessary for a DR plan to be in place to safeguard against any disaster that could make the data at the
primary site unavailable.
Recovery objectives
Recovery objectives are service levels that must be met to minimize the loss of information and revenue in
the event of a disaster. The criticality of business applications and information defines the recovery
objectives. The terms commonly used to define the recovery objectives are recovery point objective (RPO)
and recovery time objective (RTO).

1
A complete list of mirror and image states and conditions are listed in Appendix A: Remote mirror
conditions and image states.

A Detailed Review 9
Recovery point objective
Recovery point objective (RPO) defines the amount of acceptable data loss in the event of a disaster. The
business requirement for RPO is typically expressed as duration of time. For instance, application A may
have zero tolerance for loss of data in the event of a disaster. This is typical for financial applications where
all completed transactions must be recovered. Application B may be able to sustain the loss of minutes or
hours worth of data. RPO determines the required update frequency of the remote site. The rate of change
of the information determines how much data needs to be transferred. This, combined with the RPO, has a
significant impact on the distance, protocol, and bandwidth of the link between remote sites.
Recovery time objective
RTO is defined as the amount of time required to bring the business application back online after a disaster
occurs. Mission-critical applications may be required to be back online in seconds, without any noticeable
impact to the end users. For other applications, a delay of a few minutes or hours may be tolerable.
Figure 1 shows an RPO and RTO timeline. Stringent RPO and RTO requirements can add cost to a DR
solution. Therefore, it is important to distinguish between absolutely critical business applications and all
other applications. Every business application may have different values for RPO and RTO, based on the
criticality of the application.

Figure 1. RPO and RTO timeline
Replication models
There are a number of replication solutions available to replicate data from the primary (production) to the
secondary (remote) site. These replication solutions can be broadly categorized as synchronous and
asynchronous.
Synchronous replication model
In a synchronous replication model, each server write on the primary side is written concurrently to the
secondary site. The primary benefit of this model is that its RPO is zero, since the transfer of each I/O to
the secondary occurs before acknowledgement is sent to the server. Figure 2 depicts the data flow of
synchronous replication. In case of a disaster at the primary site, data at the secondary site is exactly the
same as data at the primary site at the time of disaster.

Limited distance
Primary

Secondary
1
4
3
2

A Detailed Review 10
Figure 2. Synchronous replication data flow
The main consideration of the synchronous model is that each server I/O is affected by the time it takes to
replicate the data to the remote storage system. Therefore, the distance of the replication may be limited by
the applications tolerance for latency. Secondly, the link between the primary and remote systems must be
able to handle peak workload bandwidths, which can add cost to the link.
Asynchronous replication model(s)
There are a few general approaches to asynchronous replication and each implementation may vary to some
degree. At the highest level, all asynchronous replication models decouple the remote replication of the I/O
from the acknowledgement to the server. The primary benefit of this is that it allows longer distance
replication because application write response time is not dependent on the latency of the link. The trade
off is that RPO will be greater than zero.
In classic asynchronous models, writes are sent to the remote system as they are received from the server.
Acknowledgement to the server is not held for a response from the secondary, so if writes are coming into
the primary faster than they can be sent to the remote system, multiple I/Os may be queued up on the
source system awaiting transfer.

Figure 3. Asynchronous (periodic update) replication data flow
Periodic update models, as shown in Figure 3, track changes on the primary side and then apply those
changes to the secondary at a user-determined frequency. By tracking data areas that change, it is possible
to send less data if writes occur to the same areas of the volume between updates. Updates are smoothed
out over the entire update period, regardless of bursts of writes to the source LUN allowing for a low
bandwidth and low-cost link between sites.
MirrorView family
Since it is storage-system-based software, MirrorView does not consume server resources to perform
replication. It can take advantage of Fibre Channel SANs, IP extended SANs, and TCP/IP networks for the
transfer medium. Two complementary products are offered in the MirrorView family.
MirrorView/Synchronous (MirrorView/S) for synchronous replication
MirrorView/Asynchronous (MirrorView/A) for asynchronous replication, which uses the periodic
update model
Both products run on all available storage system platforms, including the VNX, CX4, CX3, and CX series,
and the AX4-5 FC. MirrorView is not available on the VNXe series, CX300 or the AX4-5 iSCSI. For
maximum protection of information, both products have advanced features, including:
Bidirectional mirroring. Any one storage system can host both primary and secondary images as long
as the primary and secondary images within any one mirror reside on different storage systems.
Extended
distance
Primary
Secondary
4
Delta
Setpoin
t-in-
time
3
Secondary
Primary
2
1

The ability to have both synchronous and asynchronous mirrors on the same storage system.
Consistency groups for maintaining data consistency across write-order dependent volumes.
Mirroring between supported VNX and CLARiiON storage system models.
The ability to mirror over Fibre Channel and iSCSI front-end ports. VNX, CX4 and CX3 series storage
systems with FC and iSCSI front-end ports can mirror over Fibre Channel ports to some storage
systems, while mirroring over iSCSI front-end ports to other storage systems.
MirrorView configurations
MirrorView allows for a large variety of topologies and configurations. In all configurations, the primary
and secondary images must have the same server-visible capacity (user capacity), because they are allowed
to reverse roles for failover and failback.

Servers have access to all of the capacity of a traditional LUN. You set thick LUN and thin LUN user
capacity during the LUN creation process. You set a metaLUNs server-visible capacity using the user
capacity parameter. When mirroring between LUN types, the user capacities of the two LUNs in the mirror
(whether it is traditional-LUN capacity, metaLUN-user capacity, thin LUN, or thick LUN) must be the
same.

The following sections describe configuration options between primary and secondary storage systems and
primary and secondary images.
Bidirectional mirroring
Storage systems running MirrorView can simultaneously house primary volumes for some applications and
secondary volumes for others. Each mirrored relationship can run in either Synchronous or Asynchronous
mode. In such instances, system sizing considerations should be well thought out in case either site has to
run both primary and secondary applications during an outage.

Figure 4. Bidirectional mirroring
System level fan-in/fan-out
MirrorView supports connections to up to four other MirrorView systems. Each system can have primary
images and/or secondary images with any of the systems with which it has a MirrorView connection. Each
one of the primary/secondary pairs can be synchronously or asynchronously mirrored allowing for specific
levels of protection at the application level.

P
P S
S


Figure 5. MirrorView 4:1 fan-out/fan-in ratio
LUN level fan-out
MirrorView/S allows for a 1:2 fan-out ratio. Each primary volume mirrored synchronously can have one or
two secondary images. The secondary images are managed independently, but must reside on separate
storage systems. No secondary image can reside on the same storage system as its primary image. When
using consistency groups, MirrorView/Ss LUN fan-out ratio is 1:1.

Figure 6. MirrorView/S 1:2 fan-out

MirrorView/A allows for one secondary image per primary image as depicted in Figure 7.
.
Figure 7. MirrorView/A 1:1 fan-out
MirrorView over iSCSI
MirrorView over iSCSI is supported between FC/iSCSI systems. FC/iSCSI storage systems include all
VNX series, CX4 series systems and the CX3-10 through CX3-40. The storage systems must also be
P
S
S
P
P
S
1

S
2

P
S
P
S
P
S
P
S
Centralized
Data Center
Distributed Locations

running a minimum of release 26 FLARE code. It is possible to have iSCSI connections between FC/iSCSI
systems and CX300i and CX500i storage systems, but those connections are only valid for SAN Copy use.

The connection type (Fibre Channel or iSCSI) is determined for each storage system pair. A system can
mirror over iSCSI to one or more storage systems while mirroring over Fibre Channel to other storage
systems. Any combination of iSCSI and Fibre Channel MirrorView connections is possible within the 4:1
storage system fan-out ratio discussed in the LUN level fan-out section.

The MirrorView Wizard supports both Fibre Channel and iSCSI connections. If Fibre Channel and iSCSI
connectivity are both present, you can simply choose which connection type to use in the wizard. If
connectivity exists over the preferred link, the wizard performs all setup and configuration steps. The
MirrorView Wizard is discussed in detail in the MirrorView Management section of this paper.
MirrorView ports are discussed in the MirrorView ports and connections section. Additional information
for advanced users is available in the iSCSI Connections section.
Although VNXe storage systems support iSCSI, replication is not achieved using MirrorView or SAN
Copy. With the use of Replication Manager, the native remote replication capability of VNXe systems can
be used to replicate iSCSI LUNs and file shares between other VNXe systems or between VNXe and VNX
series systems. The technote Replication VNXe iSCSI to VNX using Replication Manager is available on
PowerLink for more information.
MirrorView ports and connections
MirrorView operates over discrete paths between SPs of the primary system and secondary system. All
MirrorView traffic goes through one port of each connection type (FC and/or iSCSI) per SP. For systems
that only have FC ports, MirrorView traffic goes through one FC port of each SP. For FC/iSCSI systems,
there is one FC port and one iSCSI port available for MirrorView traffic. A path must exist between the
MirrorView ports of SPA of the primary and SPA of the secondary system. The same relationship must be
established for SP B.

The MirrorView ports are automatically assigned when the system is initialized. Systems shipped from the
factory with FC and/or iSCSI I/O modules will arrive with their MirrorView ports persisted. MirrorView
port designations do not change, even if additional I/O modules are added at a later time. For systems that
add the first FC or iSCSI I/O module after the initial configuration, the MirrorView port for that protocol is
designated as the new I/O module is persisted. For instance, when adding the first iSCSI I/O module to a
system that has only FC connectivity, the MirrorView port is assigned automatically as the iSCSI I/O
module is persisted.

VNX series systems assign the lowest logical port number of each supported type (FC or iSCSI) for use by
MirrorView. For the VNX5100, VNX-5300, and VNX-5500, logical ports SPA 0 and SPB 0 will be the FC
MirrorView port and correspond to physical port 2 of the embedded mezzanine ports. The iSCSI
MirrorView port will be assigned once an iSCSI IO module is persisted in IO module slot 0 or 1.

Connectivity is highly customizable for VNX 5700 and VNX 7500 systems. Out of a total of 5 I/O module
slots, up to 4 can be available for protocol assignment by the user. There is a minimum of one SAS I/O
module in slot 0 that is used for back-end SAS connectivity to disk enclosures. As the first FC I/O module
or iSCSI I/O module is persisted, the MirrorView port is assigned as the lowest logical port number of each
type. The physical location will depend on which slot the I/O module is installed. For example, if a unified
VNX 5700 is ordered from the factory with FC and iSCSI IO modules for SAN host attaches, the port
assignment would be the following:

Table 2. I/O Module slot and MirrorView port assignments of a sample VNX 5700
configuration
I/O Slot A0/B0 - SAS A1/B1 - FC A2/B2 - iSCSI A3/B3 - Empty A4/B4 - FC
Slot Use Connection to Physical Port 0 Physical port 0 Open slot for FC xBlade

disk enclosures (A0/B0) is the FC
MV port
(A4/B4) is the
iSCSI MV port
future expansion connections
for NAS.

Slot 0 is allocated to the SAS I/O module that is required for back end disk connectivity. Slot 1 contains the
first FC I/O module which has the lowest numbered FC ports (SPA 0/SPB 0), and are designated as the MV
ports. Slot 2 has the first iSCSI module, and thus contains the lowest numbered iSCSI ports. Physical port 0
on the I/O module will correspond to logical ports SPA4/SPB4, because the FC I/O module has three ports
(SPx0 -SPx3). Therefore SPA4/SPB4 are the iSCSI MirrorView ports.

The CX4 series also offers flexibility in the number and type of front-end ports on each system. The
MirrorView port is assigned to the highest-numbered port of each type. Like VNX systems, MirrorView
ports based are automatically designated on the initial port configuration. The MirrorView ports will not
change, even if additional ports are added at a later time.

For example, the base configuration for a CX4-960 is four Fibre Channel and two iSCSI front-end (FE)
ports per SP. This represents ports 0-3 for Fibre Channel and ports 4-5 for iSCSI. If the customer orders the
base configuration, the Fibre Channel MirrorView port is port 3 and the iSCSI MirrorView port is port 5.
If an additional four Fibre Channel ports and/or an additional two iSCSI ports are added to the system at a
later time, the MirrorView ports remain the same, port 3 and port 5. Table 3 lists the base FE port
configurations for the CX4 series and the MirrorView ports.

Table 3. CX4 series base configuration front-end port numbering and MirrorView ports
Model FC ports iSCSI ports FC MV port iSCSI MV port
CX4-960 0-3 4-5 3 5
CX4-480 0-3 4-5 3 5
CX4-240 0-1 2-3 1 3
CX4-120 0-1 2-3 1 3

If a CX4 system is ordered from the factory with a configuration other than the base configuration, then the
MirrorView port assignment is based on that specific configuration. For example, if a CX4-960 is ordered
with eight Fibre Channel FE ports (ports 0-7) and two iSCSI FE ports (ports 8-9), then the MirrorView
ports will be port 7 for Fibre Channel and port 9 for iSCSI. These MirrorView port assignments will not
change, even if additional ports are added to the system at a later time.

The VNX and CX4 series offer several FE connectivity options. A 4-port I/O module is available for 8
Gb/s FC connectivity. 4-port 1 Gb/s and 2-port 10 Gb/s I/O modules are available for iSCSI connectivity. A
2-port FCoE module is also available for host connectivity, but is not supported for use by MirrorView.

I/O modules in CX4 series systems can be upgraded to newer and faster I/O modules. 4 Gb/s FC (not
offered for VNX series) I/O modules can be upgraded to 8 Gb/s modules. Also,1 Gb/s iSCSI I/O modules
can be upgraded to 10 Gb/s I/O modules. This allows users to upgrade connectivity options for
MirrorView.

For the CX3 series, CX series, and AX4-5 FC, MirrorView operates over one predetermined Fibre Channel
port and/or one predetermined iSCSI port per storage processor (SP). The MirrorView port assignments are
always the same for these systems. Table 4 lists the MirrorView port assignments for each CX3 series
system and the AX4-5 FC.

Table 4. Front-end port numbering and MirrorView port by system type
Model FC MV port iSCSI MV port
CX3-80, CX700, CX600 FC 3 --

CX3-40*, CX3-20*, CX500, CX400 FC 1 --
CX3-20, CX3-40 FC/iSCSI 5 3
CX3-10 FC/iSCSI 3 1
AX4-5 FC 1 --
*The MirrorView port (port 1) is the same across all CX3-20 and CX3-40 Fibre Channel-only models.

You can use Unisphere to view MirrorView ports. In Release 30 (Unisphere 1.0), you can see MirrorView
ports in the System > Hardware view. For Release 31 (Unisphere 1.1 and higher), you can also see
MirrorView ports in the <Storage System Name > Settings > Network Settings for Block view. The
MirrorView port is displayed with a unique icon as shown in Error! Reference source not found.. In this
case, the system is a VNX5300, so the FC MirrorView ports are physically located on Onboard Port 2 of
each SP. These ports equate to Logical Port 0 (A-0, B-0). Physical ports 0 and 1 are SAS backend ports.
The lower arrow points to a port in I/O module slot 0, where a 4-port iSCSI module is installed. Physical
port 0 is the lowest numbered iSCSI port in the I/O module. In this case, it equates to logical port 4.

Figure 8. Physical and Logical Port assignments viewed in Unisphere.

The same information is available through the Navisphere Secure CLI ioportconfig list command. Port
usage is one of the fields returned for each port. If the port is used for host I/O, port usage is Normal. If
the port is used by MirrorView, port usage is Special. Figure 9 shows output of the ioportconfig list
command for the system shown in Figure 8. (The display of the output has been manipulated to better fit
the figure, but the values are unchanged.)

The information about each I/O module(s) on SPA is as follows:

SP ID: A
I/O Module Slot: Onboard I/O Module Slot: 0
I/O Module Type: Multi Protocol I/O Module Type: iSCSI

I/O Module State: Present I/O Module State: Present
I/O Module Substate: Good I/O Module Substate: Good
I/O Module Power state: N/A I/O Module Power state: On
I/O Carrier: No I/O Carrier: No

The information listed about each port on this I/O module is as follows:

Physical Port ID: 2 Physical Port ID: 0
Port Role: FE Port Role: FE
Logical Port ID: 0 Logical Port ID: 4
Port Usage: Special Port Usage: Special
Port Type: Fibre Channel Port Type: iSCSI
Port State: Enabled Port State: Enabled
Port Substate: Good Port Substate: Good
Is Persisted: Yes Is Persisted: Yes
Figure9. Output of naviseccli ioportconfig list command

Host attach protocols are unrelated to the protocol used for MirrorView replication. Therefore, the protocol
used to attach the hosts to the primary/secondary volumes can be either Fibre Channel, FCoE, or iSCSI,
regardless of the protocol used by MirrorView.

Ports used by MirrorView can be shared with server traffic; adding traffic over this port, however, may
impact the performance of MirrorView and vice versa. Therefore, when possible, EMC recommends you
dedicate a port to MirrorView. The MirrorView port cannot be shared with either SAN Copy or the
RecoverPoint array-resident splitter. RecoverPoint only supports FC connections to the storage system.
SAN Copy and the array resident RecoverPoint splitter can run on any FC front-end port(s) other than the
MirrorView ports. RecoverPoint host-based or SAN-based splitters can share the FC MirrorView port as all
I/O is considered host traffic.

Connections should exist between SPA MirrorView ports and SPB MirrorView ports, but they should not
be cross connected. For Fibre Channel SANs, place the SP A MirrorView port and SP B MirrorView port
in separate zones. If there are servers zoned across SPs and storage systems, create multiple zones for each
server initiator so that SP A and SP B MirrorView ports remain separated. Furthermore, iSCSI connections
should be made separately between SPA MirrorView ports and SPB MirrorView ports. However, this is
handled by the MirrorView Wizard.

EMC also recommends that for high-availability configurations, connectivity for SP A and SP B reside in
separate physical networks, whether it is a Fibre Channel SAN or a TCP/IP network. This is illustrated in
Figure 10, which depicts a VNX 5700 mirrored to a VNX 5700 storage system, Site 1 and Site 2. The
Site 1 and Site 2 systems have both Fibre Channel and iSCSI connectivity between them. These systems
are used in several figures and examples throughout this paper.

Figure 10. Example of MirrorView port zoning
SP A
SP B
SP A
SP B SAN/
Network B
SAN/
Network A
VNX 5300 Site 2 VNX-5500 Site 1

SP ownership of the mirror is determined by the ownership of the primary image. Secondary images have
the same SP ownership on the secondary storage system as the primary image has on the primary storage
system. Therefore, connections for both SPs must be defined to allow failover from one SP to the other.
Failover is discussed in detail in the section MirrorView failure recovery scenarios.

Individual SP port connectivity can be verified in the Connectivity Status dialog box in Unisphere. The
Connectivity Status dialog box shows all initiators logged in to the systems front-end ports. There are
separate tabs for viewing initiator records of hosts, mirrored storage systems, and SAN Copy connected
storage systems. The Connectivity Status dialog box for the Site 1 storage system (using the system names
shown in the above figure) is illustrated in more detail in Figure 11.

The first two entries in the dialog box show that Site 2s Fibre Channel SPA-0 and SPB-0 ports are logged
in and registered to the Site 1s FC MirrorView ports SPA-0 and SPB-0.. The second two entries show that
there are also iSCSI connections between the iSCSI MirrorView ports. PortsA4/B4 of Site 2 are logged into
ports A4/B4 of Site 1.

Figure 11. Connectivity Status dialog box
The Initiator Name column shows the 8-byte WWN and 8-byte WWPN combination for Fibre Channel
initiators and the IQN number for iSCSI initiators logged in to the Site 1 system. You can compare these
with the initiator ports of the Site 2 system. You can verify the WWPN and IQN numbers in the Settings
for Block view within Unisphere as shown in Figure 8.

After connectivity is established, MirrorView connections can be created to specify which connected arrays
have mirrored relationships. MirrorView connections are automatically created when connectivity exists
and you create the first mirror between storage systems using the MirrorView Wizard (launched from the
Replicas page in Unisphere).

You can also create MirrorView connections in the Unisphere Manage Mirror Connections (more
commonly called the MirrorView Connections) dialog box or in the Command Line Interface (CLI). You
can open the Manage Mirror Connections dialog box in Unispheres Data Protection > Mirrors and
Replications > LUN Mirrors page by selecting Manage Mirror Connections in the Protection task
menu. The following Navisphere CLI commands enable and disable MirrorView connections:

Naviseccli mirror enablepath pathSPHost <-connectiontype fibre|iSCSI>

Naviseccli mirror disablepath pathSPHost <-connectiontype fibre|iSCSI>

(For simplicity, the required credentials and SP name/IP Address for Naviseccli not shown in these
commands.)

Figure 12 shows the Manage Mirror Connections dialog box for the storage system named Site 1, which
has a MirrorView connection configured with the Site 2 storage system. The systems shown in Figure 11
are both zoned in a Fibre Channel SAN and have iSCSI connections defined. By looking at the Type
column and the Logged-In Status columns, you can see that the MirrorView ports of SPA and SPB are
logged in to one another.

Figure 12. Manage Mirror Connections dialog box

If both connectivity types exist, users can switch between Fibre Channel and iSCSI mirror connections with
relatively little impact. Mirrors will be able to incrementally synchronize on the new link type after the
change. A full synchronization is not required.

At the time the change is made, MirrorView/A mirrors must be Admin Fractured, while MirrorView/S
mirrors will fracture automatically. An explicit Synchronize command is needed to make MirrorView/A
resume replication. MirrorView/S will synchronize on the new link if the Automatic Recovery Policy is
set. If the mirror is set to Manual Recovery, an explicit Synchronize command is required to resync to
mirrors.

It should be noted that if the MirrorView connection is over iSCSI, iSCSI connections are created prior to
the enabling of MirrorView connection. iSCSI connections establish the initiator/target relationship and
login behavior between the iSCSI MirrorView ports. However, iSCSI connections are automatically
created for the user when the first MirrorView connection is created by the wizard and/or the Manage
Mirror Connections (MirrorView Connections) dialog box. Therefore, there are a very limited number of
instances where the user will explicitly configure iSCSI connections for MirrorView. Explicit iSCSI
connection management is discussed in the iSCSI connections section of this paper.
Common operations and settings
The following sections outline aspects of common operations for MirrorView/S and MirrorView/A. More
specific information for either product is included in the product-specific sections if necessary.
Synchronization
Synchronization is a copy operation MirrorView performs to copy the contents of the primary image to the
secondary image. This is necessary to establish newly created mirrors or to re-establish existing mirrors
after an interruption.


Initial synchronization is used for new mirrors to create a baseline copy of the primary image on the
secondary image. In almost all cases, when a secondary image is added to a mirror, initial synchronization
is a requirement. In the special case where the primary and secondary mirror LUNs are newly created and
have not been assigned to a server, the user has the option of deselecting the initial sync required option,
which is selected by default. In this case, MirrorView software considers the primary and secondary mirror
to be synchronized. Use this option with caution and under restricted circumstances. If there is any doubt
that the primary LUN is modified, use the default setting of initial sync required.
Primary images remain online during the initial synchronization process. During the synchronization,
secondary images are in the synchronizing state. Until the initial synchronization is complete, the
secondary image is not in a usable state. If the synchronization were interrupted, the secondary image
would be in the out-of-sync state indicating the secondary data is not in a consistent state.
After the initial synchronization, MirrorView/S and MirrorView/A have different synchronization
behaviors due to the nature of their replication models. MirrorView/S synchronizes only after an
interruption, because under normal conditions all writes are sent to the secondary as they occur. After the
initial synchronization, MirrorView/A images do not return to the synchronizing state under normal
operating conditions. Secondary images are in the updating condition while incremental updates are in
progress.

Synchronization rate
Synchronization rate is a mirror property that sets the relative value (Low, Medium, or High) for the
priority of completing updates. The setting affects initial synchronizations, MirrorView/S
resynchronizations, and MirrorView/A updates. Medium is the default setting, but can be changed at any
time.

Low and Medium settings have low impact on storage system resources such as CPU and disk drives, but
may take longer to complete a transfer. Synchronizations at the high setting will complete faster, but may
affect performance of other operations such as server I/O or other storage system software.
Promoting a secondary image
A secondary image is promoted to the role of primary when it is necessary to run production applications at
the DR site. This may be in response to an actual disaster at the primary site, part of a migration strategy, or
simply for testing purposes. A secondary image can be promoted if it is in the consistent or synchronized
state. The definitions for consistent and synchronized image states are:

Synchronized -- The secondary image is identical to the primary image. This state persists only
until the next write to the primary image, at which time the image state becomes consistent. After
promoting an image in the synchronized state, replication is reversed and synchronization is not
needed.

Consistent The secondary image is identical to either the current primary image or to some
previous instance of the primary image. This means that the secondary image is available for
recovery when promoted. After promoting a secondary image in the consistent state, a full
synchronization is needed from the new primary image to the new secondary image (old primary).

When a promote occurs, the secondary image is placed in a new mirror as a primary image. The new mirror
has the same mirror name, but a different mirror ID. The existing mirror is either maintained or destroyed
depending on the nature of the failure and whether in-band communication remains between the primary
and secondary images. Note that it is not necessary or recommended to fracture a mirror prior to promoting
a secondary image.

Also note that the image state is dictated by the storage system that has the primary image. If using
Navisphere CLI to check the secondary image state, direct the command to the primary storage system

whenever possible. If the primary storage system is not available, the image state can be obtained from the
secondary storage system.
Table 5. Mirror attributes before and after promote
Mirror state Before promote After promote
Mirror name XYZ XYZ
Mirror ID aaa bbb
Primary image LUN xxx LUN yyy
Secondary image LUN yyy LUN xxx

The promote options based on these conditions are:

Normal promote The storage system executes a normal promote when the promote command is issued
to a secondary image in the synchronized state and an active link exists between the primary and
secondary images. Images in the synchronized state are exact, block-for-block copies of the primary image.
When promoted, the secondary image becomes the primary image for the new mirror and the original
primary becomes the secondary image. The old mirror is destroyed, so the user is left with a mirror of the
same name, whose images have opposite roles than the original mirror. I/O can then be directed to the new
primary image, and no synchronization is required.

Force promote Force promote is used when a normal promote fails. A normal promote may fail for a
variety of reasons, including that the secondary image is in the consistent state, the mirror is fractured,
and/or there is no active link between images. Active primary images often have corresponding secondary
images in the consistent state. Images in the consistent state are in a recoverable/usable state but are not
exact copies of the primary. Therefore, if the original primary is placed in the new mirror as a secondary, a
full synchronization is necessary.

If there is an active link, force promote places the original primary in the new mirror as a secondary image.
The original mirror is destroyed, so there is only one mirror with the original mirror name. The user would
then issue a synchronize command to start the full synchronization.

If the secondary image state is synchronized or consistent when the promote is issued, but the link between
them is not active, force promote does not place the original primary as a secondary of the new mirror.
Instead, the original secondary is placed in a new mirror as a primary, but with no secondary image. The
original primary remains in the original mirror, but there is no secondary image. The mirrors have the same
name, but different mirror IDs. Both primaries remain available for host access, and when the link is back
up, secondary images can be added to one or both images.

Local only promote - Like force promote, this option promotes the secondary without adding the original
primary as a secondary image. The original mirror and the new mirror exist with primary images. However,
local only promote also allows this type of promote with an active link. Use this option to recover changes
made since the last update to the original primary. This option is available for individual MirrorView/A
mirrors, MirrorView/A consistency groups, and MirrorView/S consistency groups. It is not available for
individual MirrorView/S mirrors.

Promoting with MirrorView/S
When promoting with MirrorView/S, if the image state and link conditions are met for a normal promote, a
normal promote is executed. If the conditions for normal promote are not met, MirrorView/S will execute a
force promote.

MirrorView/Synchronous uses the Quiesce Threshold setting to determine when an image moves from the
consistent state to the synchronized state. The Quiesce Threshold setting defines the amount of time, in
seconds, MirrorView waits before transitioning the secondary image from the consistent state to the
synchronized state when there is no write activity. It should be set to the amount of time it takes a server to
flush its buffers to disk when write activity is halted. The Quiesce Threshold is a property of the mirror and
can be changed at any time. Its default value is 60 seconds.


To perform a controlled failover to the secondary site and fail back without conducting a full
synchronization, you must:

1. Quiesce I/O to the primary image.
2. Wait for the secondary image to become Synchronized.
3. Promote the secondary image.
4. Resume I/O to the new primary image (the previous secondary).

Promoting with MirrorView/A
A secondary image will be in the synchronized state if I/O is stopped and a subsequent update is started
and completed before I/O resumes to the primary image. This occurs in a controlled failover case, such as
a data migration or a DR site test.

MirrorView/A secondaries are usually in the consistent state when the primary is active. A delta between
primary and secondary images is expected in an asynchronous model. Therefore, users should expect to
promote a secondary in the consistent state in the event of a disaster.

The following steps outline how to conduct a normal promote to fail over to the secondary site and fail
back to the primary without requiring a full synchronization:

1. Quiesce I/O to the primary image (an unmount recommended).
2. Perform an update, so that the secondary becomes synchronized.
3. Promote the secondary image.
4. Resume I/O to the new primary (previous secondary) image.

In cases where a MirrorView/A update is in progress at the time of a site failure, the secondary can still be
recovered. This is possible because MirrorView/A maintains a protective snapshot (gold copy) of the
secondary image. When the promote command is issued to the secondary, MirrorView/A rolls the contents
of the gold copy back to the secondary image, and makes the secondary image available for access. The
rollback only occurs if the image is promoted. In cases where the primary is recovered and the secondary is
not promoted, the update will be allowed to continue. The gold copy process is discussed in detail in the
Data protection mechanisms section of this paper.
Fracture
A fracture stops MirrorView replication from the primary image to the secondary mirror image.
Administrative (Admin) fractures are initiated by the user when they wish to suspend replication as
opposed to a system fracture, which is initiated by MirrorView software when there is a communication
failure between the primary and secondary systems.

For MirrorView/S, this means that writes continue to the primary image, but are not replicated to the
secondary. Replication can resume when the user issues the synchronize command. For MirrorView/A, the
current update (if any) stops, and no further updates start until a synchronize request is issued. The last
consistent copy remains in place on the secondary image if the mirror was updating.

Although not required, Admin fracture may be used to suspend replication while conducting preventive
maintenance, such as software updates to connectivity elements and/or storage arrays. It is common to have
components restart and/or run in degraded mode for some portion of the maintenance. During this time,
users may choose to minimize the number of concurrent operations in the environment. After the
maintenance is complete, a synchronization can be conducted to resume steady state operations.
Recovery policy
The recovery policy determines MirrorViews behavior in recovering from link failure(s). The policy is
designated when the mirror is created but can be changed at any time. There are two settings.

Auto Recovery Option to have synchronization start as soon as a system-fractured secondary image
is reachable. Does not require human intervention to resume replication and is the default setting.
Manual Recovery Option to have MirrorView wait for a synchronization request from the user
when a system-fractured secondary image is reachable. Intervention may be desired for several
reasons. Users may choose to control link usage in a degraded link situation and/or to coordinate the
synchronization with other operations like starting snapshots, fracturing clones, and so on.
MirrorView will automatically set the recover policy to Manual after a promote is executed. The policy is
set to manual to give users control over full synchronization when it is required.
Minimum required images
Minimum required images specifies the number of secondary images that must be active for the mirror
not to enter the Attention State. Possible values are 0, 1, or 2 for MirrorView/S and 0 or 1 for
MirrorView/A. The default value is 0. Mirroring continues while in the attention state if there are any
active secondaries. Users can set up alerts through Navispheres Event Monitor feature (Event Code
0x71050129) to alert them if a mirror enters the Attention State.
Interoperability
MirrorView can be used with many storage system based replication and migration products. The following
sections address common interoperability questions at a high level. For each case, there are documents that
provide more specific and detailed implementation guidelines. Those documents should always be
consulted when designing a solution.
Storage-system based replication software
MirrorView can be used with other storage system based replication software. For example, SnapView
snapshots and clones are often used for local replication of MirrorView images. The tables below
summarize storage-system-based replication software interoperability with MirrorView. For a
comprehensive description of interoperability, see the EMC VNX Open Systems Configuration Guide and
the EMC CLARiiON Open Systems Configuration Guide for CX4 Series, CX3 Series, CX Series, and AX4-5
Series Storage Systems on EMC Powerlink.

Table 6. Storage system replication software interoperability
LUN Type Potential usages
Make a
snapshot of it?
Make a clone
of it?
Use as source
for
MirrorView?
Use as source
for full SAN
Copy?
Use as source
for
incremental
SAN Copy?
LUN,
metaLUN,
thick LUN, or
thin LUN not
yet replicated
1,2

Yes Yes Yes
MV/A or MV/S,
not both
Yes Yes
Clone Yes No No Yes Yes
Snapshot No No No Yes No
MV primary Yes Yes
3
No Yes Yes
MV secondary Yes Yes
3
No No Yes
Notes:
1. Includes any LUN used as a destination for either a full or incremental SAN Copy session.
2. Thin LUNs may only be remotely replicated to storage systems running release 29 or later.
3. For AX4-5, you cannot make a clone of a mirror.

Virtual LUNs
Pool LUNs
Virtual LUNs can be deployed as RAID group (traditional) LUNs or pool-based (thick and thin) LUNs.
RAID group LUNs offer a high degree of control of data placement and are used for environments that
demand high performance. Pool-based LUNs offer intelligent and automated data placement, auto tiering,
and capacity on demand. Any or all LUN types can coexist in a storage system. Virtual LUN technology
allows each LUN type to be migrated to different physical disks and/or LUN types, while remaining online
for applications. For detailed information on pool-based LUNs, refer to the EMC VNX Virtual Provisioning
and EMC CLARiiON Virtual Provisioning white papers on Powerlink.

Pool-based LUNs consist of thick LUNs and thin LUNs. Pools offer automatic implementation of best
practices and automation of basic capacity-allocation tasks. The consumed capacity of a pool LUN defines
the amount of physical capacity that has been allocated to the LUN. User capacity represents the server-
visible capacity of a pool LUN. Thick LUNs consume their total user capacity plus a minimal amount for
metadata from the pool when they are created. Therefore, thick LUNs are the pool-based equivalent of
traditional RAID-group LUNs. Thick LUNs are intended for applications with higher performance
requirements, while offering the ease-of-management features that pool-based LUNs offer. Thick LUNs are
available in release 30, and are supported by all VNX block-based and CLARiiON replication products.

Thin LUNs use a capacity-on-demand model for allocating physical disk capacity. Subscribed capacity is
the total user capacity for all LUNs in a pool. Subscribed capacity can exceed the total physical capacity of
the pool when thin LUNs are deployed. When creating a mirror of a thin LUN, the user capacity is used to
determine which LUNs are eligible for source/destination pairs. When replicating from a thin-LUN primary
to a thin-LUN secondary, only the consumed capacity of the thin LUN is replicated.

It is possible to replicate a thin LUN to a thick LUN, traditional LUN, or a metaLUN. The user capacity for
a thin LUN must be equal to the user capacity of the target LUN. When a thin LUN is replicated with
MirrorView to other LUN types, the thin LUN initially retains its thin properties. Zeros are written to the
destination for areas of the thin LUN that have yet to be allocated. However, the thin LUN becomes fully
consumed if a failback performs a full synchronization from the secondary image to the (thin) primary
image.

It is also possible to mirror a traditional LUN or metaLUN to a thin LUN. In this case, the thin LUN
becomes fully consumed when a full synchronization is performed from the primary image to the (thin)
secondary image. You can prevent this at the initial synchronization; this is described in the
Synchronization section. However, a full sync may not be avoidable in some failover and failback cases.

MetaLUNs
MetaLUNs have two capacity attributes: total capacity and user capacity. Total capacity is the maximum
capacity of the metaLUN in its current configuration. Additional capacity can be added to a metaLUN to
increase its total capacity. User capacity is the amount of the total capacity that is presented to the server.
Users have control of how much of the total capacity is presented to the server as user capacity. When the
total capacity is increased, user capacity also can be increased. MirrorView looks at user capacity to
determine which LUNs can be in a mirrored relationship.

LUN shrink and LUN expansion
LUN shrink and LUN expansion operations are supported on all LUN types. LUN shrink is available for
Windows 2008 servers and requires Solutions Enabler to coordinate file system activities with the
reduction in LUN capacity. LUN expansion is performed via metaLUNs for RAID-group-based LUNs. In
release 30 and higher, pool-based LUNs can be expanded on the fly. Any increase in pool LUN capacity is
available almost instantaneously. For thick LUNs, expansion only involves assigning additional 1 GB slices
to the LUN. For thin LUN expansion, the system simply increases the LUNs user capacity while
consumed capacity is unaffected by the operation.

When expanding a LUN that is using MirrorView, SnapView, or SAN Copy, user capacity cannot be
increased until the replication software is removed from the LUN. Since metaLUNs allow for separate
control of total capacity and user capacity, the total capacity can be increased while the replica is in place.

For example, assume that a user wants to stripe-expand a LUN using metaLUNs. When a LUN is stripe
expanded, data is restriped over added disks before the additional user capacity is available. You can
minimize the time the LUN is not being mirrored by allowing the striping operation to complete before
removing the mirror from the LUN to increase user capacity. Increasing metaLUN user capacity is a nearly
instantaneous process.

Once user capacity is increased, the mirror can be re-created on the LUN. To use the same secondary
image, user capacity has to be increased to the same user capacity as the primary image.

If I/O continues while the mirror is removed, a full synchronization is required when the mirror is re-
created. A full synchronization can be avoided if I/O can be quiesced while the mirror is removed and user
capacity is increased. The following steps are recommended to avoid a full synchronization.
1. Quiesce I/O and remove either the host or LUNs from the storage group. You must make sure that
there is no I/O or discovery of the new capacity while there is no mirror in place.
2. Ensure the secondary image is in the synchronized state as reported by the primary storage
system. For MV/S, wait for the image to become synchronized once I/O is quiesced. For
MirrorView/A, perform an update after I/O is quiesced.
3. Remove the secondary image and destroy the mirror.
4. Increase user capacity of the primary and secondary images to the exact same value.
5. Re-create the mirror and clear the Initial Sync Required option when adding the secondary
image.
6. Add hosts or LUNs back into the storage group for discovery of new capacity and resume I/O.

For more information on LUN expansion with metaLUNs, see the white paper EMC CLARiiON
MetaLUNs: Concepts, Operations, and Management on EMC.com and Powerlink.

LUN migration
LUN migration can be used with MirrorView images under certain conditions. LUN migration is supported
to and from any LUN type, therefore, if requirements are met, it is possible to leave existing mirrors in
place during the migration. Table 7 outlines the conditions under which MirrorView LUNs can and cannot
be migrated. For more information on LUN migration, see UnisphereHelp and the white paper EMC
Virtual LUN Technology A Detailed Review on EMC.com and Powerlink.

Table 7. LUN migration rules for mirror images

LUN type Migrate to same size LUN Migrate to larger LUN
Primary image Can be migrated
2
Remove secondary image(s) and
destroy mirror before migration
Secondary image Can be migrated
2
Remove secondary image from
mirror
Write intent log LUN (MV/S) Cannot be migrated
Reserved LUN (MV/A) Cannot be migrated

Notes:
1. A mirror cannot be created on a LUN that is migrating.

2. In release 26 and higher, a migration can be started on a MV/S primary or secondary if the secondary is
synchronizing. In prior versions, migration was only possible if the secondary image was in the consistent
or synchronized state.
Block operating environment
EMC recommends that storage systems replicating LUNs between one another run the latest release of the
base operating environment. We recommend this for both the VNX for Block Operating Environment for
the VNX series and the FLARE operating environment for legacy CLARiiON systems. When mirrored
systems are running the same version of the operating environment, its noted as Preferred in the table
below. Release 31.5 is the latest release for VNX series systems. Release 30 is the latest release for all CX4
models. Release 26 is the latest release for all CX3 models, the CX700, and CX500. Release 23 is the
current release for AX4-5 systems.

Depending on the model types used, it is not always possible to run the latest version of the operating
environment. For example, release 26 is the latest release for the CX3 series. It is also possible for a new
storage system to be added to an environment with older systems that cannot be upgraded immediately.
Therefore, EMC supports running MirrorView between storage systems whose releases are one version
apart. This relationship is designated as Supported in the table.
If users cannot maintain a minimum difference of one release between storage systems during an upgrade,
mirrors should be fractured prior the upgrade. A partial synchronization can be performed once the storage
systems are on interoperable versions. If it is not possible to upgrade older systems, the mirrors should be
fractured until upgrades have been performed to both storage systems. MirrorView interoperability is
provided in the table (N stands for not supported.).
Table 8. Software version interoperability

Secondary
R31, 31.5
(VNX
series)
R30 (CX4
series)
R29 (CX4
series)
R28 (CX4
series)
R26 (CX3
series,
CX700,
CX500)
R24 (CX3
series,
CX700,
CX500)
R23
(AX4-5
FC)
P
r
i
m
a
r
y

R31, 31.5 (VNX) Preferred Preferred Supported N Preferred N Preferred
R30 (CX4 series Preferred Preferred Supported N Supported Supported Supported
R29 (CX4 series) Supported Supported Preferred Supported Supported Supported Preferred
R28 (CX4 series) N N Supported Preferred Preferred Supported Preferred
R26 (CX3 series,
CX700, CX500)
Preferred Supported Supported Preferred Preferred Supported Preferred
R24 (CX3 series,
CX700, CX500)
N Supported Supported Supported Supported Preferred Supported
R23 (AX4-5 FC) Preferred Supported Preferred Preferred Preferred Supported Preferred

Under normal conditions, when software versions are within one release of one another, it is not necessary
to fracture the mirrors to perform a code upgrade. While upgrading storage systems containing secondary
images, mirrors will system fracture while the owning SP of the secondary image reboots. When the
owning SP of a primary image reboots, an SP trespass is performed. MirrorView/S will continue
replicating. MirrorView/A updates are automatically held by the system until the upgrade is complete.
Mirroring thin LUNs
When mirroring a thin LUN to another thin LUN, only consumed capacity is replicated between storage
systems. This is most beneficial for initial synchronizations. For traditional LUNs, all data, from the first
logical block address to the last, is replicated in an initial sync. Since thin LUNs track the location of
written data, only the data itself is sent across the link. No whitespace is replicated. Steady state replication
remains similar to mirroring traditional LUNs since only new writes are written from the primary storage

system to the secondary system. Figure 13 shows an async mirror (LUN 269) that has thin LUNs as
primary and secondary image LUNs.

Figure 13. Mirroring thin LUNs asynchronously

Figure 13 shows the Mirrors and Consistency Group page in Unisphere. As you can see, if you select
Mirror of ESX5 LUN 269 in the upper pane, details about the primary and secondary images are listed in
the lower pane. You can also see the LUN Properties dialog boxes for the primary image, LUN 269, and
the secondary image (the image of ESX5 LUN 269). The user capacities, as you might expect, are the
same. Consumed Capacity is 8 GB for the primary image, and 5 GB for the secondary image. This
indicates that changes made to the primary images have not been replicated to the secondary image yet.
The secondary images Consistent state also indicates that changes have been made to the primary since
the last update. Having the secondary image LUN lag behind the primary image LUN is expected for
asynchronous replication with MirrorView/A.

In the case of a synchronous mirror, it is expected that the consumed capacities of the primary and
secondary image remain the same. Figure 14 illustrates this point. All changes to the primary are made to
the secondary before acknowledgement is provided to the server.


Figure 14. Mirroring thin LUN synchronously

MirrorView/Synchronous
MirrorView/Synchronous (MirrorView/S) follows the replication model outlined in the Replication
models section for synchronous replication. MirrorView software writes new data to both the primary and
secondary volumes before the write is acknowledged to the server. The following sections describe the
software MirrorView/S software.
Data protection mechanisms
MirrorView/S has mechanisms to protect data loss on the primary and/or secondary image. The fracture log
protects primarily against loss of communication with the secondary image. The write intent log protects
primarily against interruptions to the primary image. Use of the write intent log is optional. Both of these
structures exist to enable partial synchronizations in the event of interruptions to the primary and secondary
images.
Fracture log
The fracture log is a bitmap held in the memory of the storage processor that owns the primary image. It
indicates which physical areas of the primary have been updated since communication was interrupted with
the secondary.

The fracture log is automatically invoked when the secondary image of a mirror is lost for any reason and
becomes fractured. The mirror is fractured (system fractured) by MirrorView software if the secondary is
not available or it can be administratively fractured through Navisphere Manager or CLI. MirrorView/S
system fractures an image if an outstanding I/O to the secondary is not acknowledged within 10 seconds.
While fractured, the primary pings the secondary every 10 seconds to determine if communication has been
restored.

The fracture log tracks changes on the primary image for as long as the secondary image is unreachable. It
is a bitmap that represents areas of the primary image with regions called extents. The amount of data
represented by an extent depends on the size of the mirror images. Since the fracture log is a bitmap and
tracks changed areas of the primary image, it is not possible to run out of fracture log capacity. It may be
necessary, depending on the length of the outage and the amount of write activity, to resynchronize the
entire volume.

When the secondary LUN returns to service, the secondary image must be synchronized with the primary.
This is accomplished by reading those areas of the primary addressed by the fracture log and writing them
to the secondary image. This activity occurs in parallel with any writes coming into the primary and
mirrored to the secondary. Bits in the fracture log are cleared once the area of the primary marked by an
extent is copied to the secondary. This ability to perform a partial synchronization can result in significant
time savings.

By default, the fracture log is stored in memory. Therefore, it would be possible for a full resynchronization
to be required if a secondary image is fractured and an interruption in service occurs on the primary SP.
The write intent log protects against such scenarios.
Write intent log
The write intent log is a record stored in persistent memory (disk) on the storage system on which the
primary LUN resides. The write intent log consists of two 128 MB LUNs, one assigned to each SP in the
storage system. Each 128 MB LUN services all the mirrors owned by that SP that have the write intent log
enabled. When the write intent log LUNs are assigned to the SP, they become private LUNs and are under
the control of MirrorView software. Write intent log LUNs must reside on RAID-group-based LUNs. If all
eligible disks in a storage system are deployed in pools, then the write intent log LUNs may be placed on
the system drives (first five drives in the enclosure).

During normal operation, the write intent log tracks in-flight writes to both the primary and secondary
images in a mirror relationship. Much like the fracture log, the write intent log is a bitmap composed of
extents indicating where data is written. However, the write intent log is always active and the fracture log
is only enabled when the mirror is fractured.

When in use, MirrorView makes an entry in the write intent log of its intent to update the primary and
secondary images at a particular location, and then proceeds with the attempted update. After both images
respond that data has been written (governed by normal LUN access mechanisms, for example, written to
write cache), it clears previous write intent log entries. For performance reasons, the write intent log is not
cleared immediately following the acknowledgement from the primary and secondary images; it will be
cleared while subsequent write intent log operations are performed.

In a recovery situation, the write intent log can be used to determine which extents must be synchronized
from the primary storage system to the secondary system. For instance, if a single SP becomes unavailable
(for example during a reboot or failure), there may be in-flight writes that were sent to the secondary, but
not acknowledged before the outage. These writes will remain marked in the write intent log.

Then server software, such as PowerPath
, trespasses the LUN to the peer SP. The remaining SP directly

accesses the unavailable SPs write intent log and recovers the recent modification history. The SP then
resends the data marked by the extents in the write intent log. This allows for only a partial
resynchronization, rather than a full resynchronization because it ensures that any writes in process at the
time of the failure are acknowledged by the secondary image. If the entire array becomes unavailable (for
example, due to a power failure), then the write intent log is used similarly to facilitate a partial
resynchronization from primary to secondary, once the primary array is recovered.

Use of the write intent log is optional on CX3 series and lower models. On these systems, the maximum
number of mirrors that can use the write intent log is less than the maximum number of configurable
mirrors. Details are provided in the Limits section.


There were also performance considerations when using the write intent log on these systems. However,
releases 26 and later have optimizations that improve performance when using the write intent log. The
optimizations are implemented in SP write cache. In versions prior to release 26, performance would
degrade if the storage system write cache neared full. In release 26, there is no impact at lower workloads
and only a slight impact (10%) on response time at high workloads. Therefore, use of the write intent log
should be maximized. If FAST Cache is enabled at the system level, it should be disabled for write intent
log LUNs. Optimal performance is achieved when write intent log LUNs are fronted only by SP write
cache.

The write intent log is automatically used on all mirrors on VNX series and CX4 series systems. Both
series of systems allow all mirrors to have the write intent log allocated up to the maximum allowable
number of mirrors on the system. The performance improvements previously made in release 26 allow
write intent log use with negligible performance impacts under normal operating conditions. Therefore, the
write intent log is configured on all mirrors by default.

The storage system that owns the primary image controls the write intent log for the mirror. If a VNX
series and/or CX4 systems are mirrored to a storage system that does not support as many write intent log
enabled mirrors (for example, the CX3 series), all of the mirrors can use the write intent log if the primary
image resides on the CX4.

As secondary images are promoted, the write intent log is enabled for as many mirrors as the secondary
storage system supports. When this number is exceeded, subsequent mirrors do not use the write intent log.
Fracture log persistence
The fracture log resides in SP memory. By itself, it cannot withstand outages, such as an unplanned SP
reboot (for example physically removing an SP during normal operation). However, mirrors with the write
intent log enabled are able to reconstruct the fracture log in SP memory if there is an outage. Since the data
structures in the write intent log achieve a persistent record of the areas on the primary image that have
been written to, when the write intent log is enabled, it also provides fracture log persistence but only for
those mirrors with the write intent log enabled. In this case, users get the benefit of partial
resynchronization after an unplanned outage.

For example, if a mirror is fractured when a failure occurs on the primary system, a partial
resynchronization is still possible if the write intent log is enabled. With fracture log persistence, changes to
regions on the primary after the mirror is fractured are captured on persistent media, and can be read by the
storage processors when they are recovered. Without the benefit of fracture log persistence, changes to the
primary since the mirror was fractured are lost and a full resynchronization will be necessary. If the SP is
rebooted in a controlled manner through Unisphere, the fracture log is preserved by sending it to the other
SP before the reboot.

Fracture log persistence, along with improved performance in release 26, is why the write intent log should
be enabled on as many mirrors as possible. In cases where more mirrors exist than can be write intent log
enabled, prioritize mirrors based on preference for resynchronization in the instance of an unplanned
outage.
Synchronization
There are full synchronizations and partial synchronizations. Initial synchronization is a full
synchronization. Partial synchronization occurs after a connectivity failure to the secondary is resolved.
Synchronizations can be initiated on all secondary images either by the user or by MirrorView software
when the Automatic recovery policy is set.

The number of concurrently running synchronizations depends on the image synchronization rates used.
Since images with synchronization rates set to high have the most impact on host I/O, the storage system
will not run as many of these concurrently as it would images with medium or low synchronization rates.


Images waiting to be synchronized remain in a queued-to-be-synchronized image condition until some of
the current synchronizations are completed. As each secondary image finishes its synchronization, the
storage system determines if the next image queued to be synchronized can be started. If all images have
the same synchronization rate, the next image in the queue starts its synchronization each time a
synchronization completes. If there is a mix of sync rates, then the number of images started is based on the
resources made available. For example, if a synchronization with a high sync rate finishes, the storage
system can start several synchronizations at medium or low.

The synchronization progress is tracked in the fracture log. Bits of the fracture log are cleared as the areas
they represent are copied to the secondary. You can view progress in Navisphere in the Mirror Properties
dialog box by clicking the Secondary Image tab.
Thin LUN secondary images
Before starting the synchronization of the mirror or consistency group, MirrorView/S determines if the
secondary pool has enough capacity to accept all of the synchronization data. For example, in the case of an
individual mirror, if there is 25 GB of synchronization data to be sent, MirrorView/S verifies that there is at
least 25 GB of free capacity in the secondary image LUN storage pool.

For example, assume a consistency group has three mirrors. The first two mirrors have secondary image
LUNs in Pool A and have 20 GB and 40 GB of sync data, respectively. The third has its secondary image
LUN in Pool B on the same array and has 30 GB of sync data. MirrorView/S will verify that Pool A has at
least 60 GB of free capacity and that Pool B has at least 30 GB of free capacity before starting the
synchronization.

If enough capacity does not exist in a secondary image LUN storage pool, the mirror and/or consistency
group becomes administratively fractured. An error will be returned to the user and an event will be logged
in the SP event log. The events are:

0x71058269 Synchronization cannot start due to insufficient space in the remote systems pool
0x710589B4 consistency group cannot sync due to insufficient pool space for at least one of its
members

Checking available pool capacity does not guarantee that all of the synchronizations will be accommodated
by the secondary LUNs pool. It does ensure that the capacity is available at the beginning of the
synchronization; however, it is possible for other thin LUN activity in the same pool to consume pool
capacity while the synchronization is in progress.
Link requirements
MirrorView/S is qualified for a large variety of SAN topologies that include high-speed Fibre Channel
SANs, distance extension solutions including longwave optics, FC/IP converters, and native iSCSI. For
comprehensive guidance on supported topologies, see the Topology Resource Center available within the
E-Lab Interoperability Navigator. Within the Resource Center there are techbooks for Fibre Channel,
iSCSI, Extended Distance Technologies and more.

It is expected that bandwidth and latency requirements will be governed by the application, since each write
I/O traverses the link. Under these conditions, links are typically high bandwidth lines with low latency.
There are no bandwidth requirements enforced by MirrorView software. However, there are functional
requirements for latency, since MirrorView/S will fracture a secondary image if it has an I/O outstanding to
the secondary for 10 seconds.

The graph in Figure 15 illustrates the effect of latency on transaction response time plotted against the write
component of the transactions. An OLTP simulator was run, where each OLTP transaction consisted of 21
reads and nine writes. The load was generated using 8-KB I/O over 12 data LUNs and 1 log LUN on a
CX3-80. The link is 1000 Mb with compression and fast write enabled through an FC/IP device.


Individual results vary for transaction response times in an end-user environment depending on a wide
variety of factors, including application concurrency, server hardware and software, connectivity
components, storage system model, number of disks, and so on. The graph does not represent any
MirrorView or system limits, but simply illustrates the effects of latency with all other things equal across
the configuration.

Figure 15. Effects of link latency on transaction response times
When going over short distances with low latency lines, performance differences between using native
iSCSI connectivity and using FC/IP devices should not be very great. As distance and latency are
increased, FC/IP devices that offer advanced features such as compression and fast write will have
performance advantages over native iSCSI connections.
Limits
Table 9 lists the MirrorView/S limits for VNX series and CX4 series systems. For the latest and most
comprehensive limits, consult the EMC MirrorView/ Synchronous release notes.

Network Delay
8 KB I/O over 1000 Mb LAN McData 1620 with Fast Write
and compression enabled

Table 9. VNX series and CX4 series MirrorView/S storage system limits

Parameter
Storage system
VNX7500
CX4-960
VNX5700
CX4-480

VNX5500
CX4-240
VNX5300
VNX5100
CX4-120
Maximum allowed mirror images per
storage system
1

1024 R30+
512 Pre-R30
512 256 128
Maximum allowed mirrors per storage
system with write intent logs
1024 R30+
512 Pre-R30
512 256 128
Maximum synchronous consistency
groups
2

64 64 64 64
Maximum mirrors per synchronous
consistency groups
3

64 64 32 32

Notes:
1. Images include primary and secondary images.
2. The max number of consistency groups per storage system for VNX series and CX4 series systems is
shared between MirrorView/S and MirrorView/A. The total for the shared limit is 64, and can be
divided however the user wishes between MirrorView/S and MirrorView/A, provided that the max
combined number of Consistency Groups does not exceed 64, and also provided that the max number
of Consistency Groups for MirrorView/A does not exceed 50.
3. Release 29 increases the mirrors per group limit from 32 (960/480) and 16 (240/120) in release 28

Table 10 lists the MirrorView/S limits for the AX4-5, CX3 series, and CX400-CX700.
Table 10. CX3, CX, and AX4 series MirrorView/S storage system limits

Parameter
Storage system
CX3-80,
CX3-40,
CX700
CX600 CX3-20,
CX500
AX4-5, CX3-10,
CX400
Maximum allowed mirror images per
storage system
1,2

200 100 100 50
Maximum allowed mirrors per storage
system with write intent logs
100 50 50 25
Maximum synchronous consistency
groups
16 16 8 8
Maximum mirrors per synchronous
consistency groups
16 16 8 8

Notes:
1. Images include primary and secondary images.
2. In release 24 and later, MirrorView/S and SnapView clone limits are independent of each other. In
previous releases, MV/S images and SnapView clones were counted together against a storage system
image count limit. Note that the highest release available for the AX4-5 is release 23 and highest
release for the CX400 and CX600 is release 19.
MirrorView/Asynchronous
MirrorView/A uses a periodic update model for transferring write data to the secondary image. Between
updates, areas written to are tracked by MirrorView/A. During an update, the data represented by these
areas is transferred to the secondary image. The set of data that is transferred is referred to as a delta set.


A delta set may be smaller than the aggregate number of writes that occurred to the primary image, since
areas in a bitmap are marked to denote a change occurred to a particular location of the image. If more than
one write occurs to the same area, only the current data is sent when the update is started. SnapView
technology is used to preserve a point-in-time copy of the delta set during the update.

MirrorView/A is designed to enable distance solutions over lower bandwidth and higher latency lines than
would be possible with a synchronous solution. Solutions are often implemented over T3 type lines or the
equivalent bandwidth within a larger link. Replication distances can range from 10s to 1000s of miles.

RPO is determined by the frequency and duration of updates. There are three methods for defining the
frequency of updates.
Manual Each update is initiated by the user
Start of Last Update MirrorView starts updates at user defined intervals
End of Last Update MirrorView starts updates after a user defined rest period from the completion of
the last update

User defined intervals are specified in minutes, with an input range of 0 40,320 (28 days). However,
typical update intervals range from 15 minutes to hours.
Data protection mechanisms
MirrorView/A uses SnapView technology for data protection on the primary and secondary storage
systems. On the primary storage system, SnapView tracks changes on the primary image and creates a
point-in-time image that is the source for the delta set transfer.

On the secondary storage system, SnapView creates a protective copy of the secondary image during the
update. The protective copy, referred to as the gold copy, ensures that there is a usable copy on the
secondary storage systems at all times.

All of MirrorViews use of SnapView is autonomous and does not need be managed by the user. Therefore,
a SnapView license is not required to use MirrorView/A.
Tracking and transfer maps
MirrorView/A uses two bitmaps on the primary image. For each update, one bitmap (the tracking map)
tracks changes between updates, and the other bitmap (the transfer map) tracks the progress of the update
when transferring to the secondary. Each bitmap is used in a revolving fashion, first as the tracking map
between updates and then as the transfer map for the subsequent update.
The tracking and transfer maps are persistently stored on a reserved LUN on a per-mirror basis. As soon as
a MirrorView/A mirror is created on a primary image, a reserved LUN is assigned to the image to store the
tracking and transfer maps. The reserved LUN is assigned to the source for as long as the mirror exists.
The bits within the tracking and transfer maps represent chunks of the primary image. Chunks are a fixed
size, so the number of chunks varies depending on the size of the LUN. Changes to the primary image are
tracked at a 2 KB granularity.
This granularity allows smaller inter-site links (T1/T3) to be used efficiently by transferring a data set
closer in size to the amount of data changed. MirrorView/A can also coalesce writes for adjacent LUN
locations into one write, up to 64 KB, when transferring it to the secondary. For example, two separate
4 KB writes that occur on contiguous block locations on the LUN can be transferred as one 8 KB write
from the primary to the secondary.
Between periodic updates, only the bitmap acting as the tracking map is active. When a servers write I/O
changes a region for the first time since the last update, a bit is set in the tracking map indicating the
change. Any changed regions are transferred to the secondary site during the next periodic update.

The transfer bitmap keeps track of the progress of the transfer of data from the primary to the secondary
image. At the start of an update, the tracking map and transfer map switch roles, so that the tracking map
becomes the transfer map for the update. It already contains the set bits indicating where changes occurred
since the last update, so the same information is used to monitor the delivery of the data to the secondary
image. At the same time, the existing transfer map becomes the new tracking map for the next update. Each
time an update is started, this switching of roles occurs.
As the areas of the LUN represented by the set bits in the transfer map are sent, the bits are cleared from the
transfer map. This way, at the end of a successful update, the transfer map is cleared of any set bits.
During the transfer, if a server write is initiated to the primary image for a location not yet transferred, the
data area will be copied into the reserved LUN before accepting the write. This preserves the point-in-time
image of the changed data from the time the update was initiated. This only occurs the first time a write is
initiated into the primary for a location that has not been transferred. This is referred to as copy-on-first-
write protection. If a write comes into the primary for an area already transferred, no-copy-on-first-write
occurs. The area is marked only in the tracking map and is transferred in the next update cycle.
Delta set
A delta set is a virtual object that represents the regions on the primary mirror LUN that need to be
transferred to the secondary mirror LUN. A SnapView snapshot, managed by MirrorView/A, is used as the
source of the transfer to maintain a point-in-time image of the delta set for the duration of the transfer.
Ultimately, the size of the delta set will depend on the number of writes between updates and the locality of
those writes on the LUN. Some applications that are random in nature may have to replicate most of the
writes that occurred between updates. Other applications, which have high locality, may write to the same
location several times between updates and result in small delta sets. Results can vary greatly by
application and implementation.
For example, Figure 16 shows expected delta set behavior for a consistent workload. The delta set size
peaks before the first update. While the update progresses, I/O continues to the primary volume, so some
data lag exists throughout the update process. Delta set peaks remain consistent in this test because of the
steady workload.

Figure 16. Data lag trend for Oracle 9i RAC test over T3 (50 ms latency)
Update End
Update Start

The data for this test was generated using an Oracle Database. Replication was conducted over a T3 line
with a 50 ms delay to simulate long-distance replication. The bottleneck for update bandwidth in this test
was the T3 link.
Gold copy (protective snapshot)
A gold copy is a virtual point-in-time copy (snapshot) of the secondary image that is initiated before the
update begins. It ensures that there is a known good copy on the secondary during an update. The gold copy
is managed entirely by MirrorView/A software and is not directly available for server access. Users can
take additional snapshots of the secondary image for a usable point-in-time copy of the secondary.
If the update from primary to secondary is interrupted due to a catastrophic failure at the primary site,
MirrorView/A uses the gold copy to roll back the partial update on the secondary LUN if the secondary is
promoted for use. If the secondary is not promoted, the gold copy is maintained so that the update may
complete when the interruption is rectified.
Reserved LUNs
Reserved LUNs are a resource used by SnapView snapshots to store copy-on-first-write data. In cases
where SnapView technology is used for point-in-time management, such as in incremental SAN Copy and
MirrorView/A, the reserved LUNs also store the tracking and transfer bitmaps necessary to manage the
updates.
Reserved LUN resources must be allocated on the primary and secondary storage systems when using
MirrorView/A. Reserved LUNs on the primary side are used for storing the bitmaps associated with delta
sets and for storing any copy-on-first-write data that is created during the update. On the secondary side,
they are used for storing copy-on-first-write data to maintain the gold copy.
When sizing the reserved LUNs for the primary image, consider how much data will change during an
update. MirrorView/A maintains optimized copy on first write protection during an update, where only
those blocks that havent been transferred to the secondary are copy on first write protected. Additional
consideration needs to be given if there are user initiated SnapView snapshots on the primary image. For
standard snapshots, the entire volume is copy-on-first-write protected for as long as the snapshot exists. So
it is expected that capacity requirements for user initiated snapshots are greater than those needed by
MirrorView/A.
When sizing the reserved LUNs for the secondary image, the rate of change must be known. Since the
primary image is sending only areas that change, every update write from the primary storage system is
copied on the first write protect to the secondary. It is best to assume no locality and provide enough
reserved LUN capacity to, at the minimum, accommodate the largest number of aggregate writes for any
one period. The aggregate number of writes can easily be measured by OS-based tools such as I/O Stat and
Perfmon or array-based tools such as Navisphere Analyzer. If MirrorView/A is being considered for an
application that is not yet running, a rule of thumb of 20 percent of the Primary image capacity is
commonly used.
Additional space beyond the maximum aggregate writes should also be considered in case there is an
interruption to the update process. If I/O continues to the primary image during the interruption, the
subsequent delta set after the interruption will be larger than over a normal period. Some additional
considerations for MirrorView/A reserved LUN configuration are:

Place the reserved LUNs on different physical drives than the primary images. Since it is possible
to have tracking and/or copy on first write activity associated with a server write, it is best not to
have all of the activity queued up for the same set of disks. Often times, several reserved LUNs are
configured on their own RAID group or pool.
Use high performance SAS or FC drives for the reserved LUNs. Its common to have several
reserved LUNs on the same drives. The tracking and copy on first write activity is a critical
component for write response time, so it is important to avoid I/O contention on these drives. flash
drives do not provide a significant performance advantage over SAS or FC drives when used for
reserved LUNs. Therefore, we recommend that you place reserved LUNs on write-cache enabled

LUNs on SAS or FC drives. For more information, see the Disk drive technologies section of
this white paper.
Use the same configuration on the primary and secondary side. Some end users consider cutting
costs on the DR side by using fewer drives or lower-cost drive technology. However, the reserved
LUNs plays an important role in copy-on-first-write protecting the secondary images during an
update. Its also expected that in a recovery situation, the applications will run with similar
performance when failed over to the DR site.

For a more comprehensive look at reserved LUN guidelines for MirrorView and other replication
applications, see the white paper CLARiiON Reserved LUN Pool Configuration Considerations on EMC
Powerlink.
Initial synchronization
The transfer map is used to track initial synchronization. When an initial sync is required, all of the bits in
the transfer map are set to indicate transfer. The bits of the transfer map are cleared as the areas they
represent are copied to the secondary.
All mirrors can synchronize simultaneously. Resources are shared among active mirrors to evenly
distribute bandwidth during the synchronization period.
There is no gold copy (so no protective snapshot) during the initial sync, since there is no usable copy of
data until the initial sync is complete. If the initial sync is interrupted, the secondary will be in an out-of-
sync state and cannot be promoted.
MirrorView/A is intended to operate over lower bandwidth lines. In implementations where the delta set
would consume most or all of the link capacity, it can be difficult to perform the initial synchronization.
This is prevalent in implementation with large volumes (multiple TBs) and relatively smaller change rates
(GBs) over the update period.
Often in these scenarios, the secondary system is brought to the same site as the primary for the initial
synchronization and then shipped to the remote site, where an incremental update is performed. The general
process to do this is:

1. With primary and secondary on the local SAN, create mirrors, add secondary images, and perform
initial synchronization.
2. Admin fracture the mirrors. An incremental update is optional before the fracture to get the very last
possible changes.
3. Remove the secondary system from the Unisphere/Navisphere domain.
4. Transport secondary and install at final site including any zoning and IP address changes. Changing IP
addresses and resulting SP reboot do not affect the MirrorView configuration.
5. Bring the secondary either back into the Unisphere/Navisphere domain or manage it with the Multi-
Domain Management feature of the UI if in a different domain.
6. Re-establish the MirrorView connections and synchronize the Mirrors.
In Release 24 and later, MirrorView/A uses the Bulk Copy feature of SAN Copy for the initial
synchronization. The bulk copy process is an advanced feature of SAN Copy that minimizes SnapView
operations during the initial synchronization. It also provides check pointing, so that initial
synchronizations can resume if a link outage occurs.
The Bulk Copy process is completely managed by MirrorView/A software, so there are no changes to user
operations. MirrorView/A performs a bulk copy and an immediate incremental update as part of the initial
synchronization process. Users may see improved performance during the initial synchronization when
compared with prior versions.

Link requirements
MirrorView/A does not have stringent bandwidth and latency requirements. A minimum bandwidth of 128
KB/s is required. This is very likely to be much lower than any practical implementation would require.
MirrorView/A will system fracture during an update if it does not receive acknowledgement from the
secondary in five to six minutes. Since server I/O is decoupled from the transfer of data from the primary to
the secondary, it is not as important to system fracture within the same time as a synchronous solution.
MirrorView/A is commonly replicated over TCP/IP links to enable long distance replication. Table 10
shows nominal bit rates and bandwidths for commonly used link types. When determining the required link
type also factor in TCP/IP overhead, which can lower the effective payload by about 20 percent.
Table 11. Nominal link speeds
Link type Nominal bit rate (Mb/s) MB/s GB/h
T1 1.5 0.18 0.63
T3 45 5.4 18.9
100 Mb 100 11.9 41.9
OC3 155 18.5 65.0

As distance increases, advanced features such as compression and support of large TCP window sizes can
often help to optimize link utilization. These features are offered on FC/IP conversion devices, and they are
not offered on the native iSCSI ports. So for very long distance replication, like coast to coast of the
continental U.S. (~3,000 miles), users may opt to employ FC/IP devices, depending on their workload as
compared to the links bandwidth and latency.
Limits
Table 12 lists the MirrorView/A limits for VNX series and CX4 series storage systems. For the CX4 series,
Release 29 offers a significant increase in scalability compared to release 28.

Table 12. VNX series and CX4 series MirrorView/A limits
Parameter
Storage system
VNX7500/VNX5700
CX4-960/CX4-480
VNX5500/VNX5300
CX4-240/CX4-120
VNX5100

Maximum images per storage
system
1

256 256 128
Maximum async consistency
groups
2

64 64 64
Mirrors per async con groups 64 32 32
Notes:
1. MirrorView/A source limits are shared with SAN Copy incremental-session and SnapView snapshot
source limits.
2. The max number of consistency groups per storage system for VNXseries and CX4 series systems is
shared between MirrorView/S and MirrorView/A. The total for the shared limit is 64, and can be
divided however the user wishes between MirrorView/S and MirrorView/A.

Table 13. CX4 MirrorView limits for release 28
Parameter
Storage system
CX4-960/CX4-480 CX4-240/CX4-120
Maximum images per storage system
1
100 100
Maximum async consistency groups
2
50 50
Mirrors per async con groups 16 8
Notes:
1. MirrorView/A source limits are shared with SAN Copy incremental-session and SnapView snapshot
source limits.
2. The max number of Consistency Groups per storage system for CX4 series systems is shared between
MirrorView/S and MirrorView/A. The total for the shared limit is 64, and can be divided however the
user wishes between MirrorView/S and MirrorView/A, provided that the max combined number of
Consistency Groups does not exceed 64, and also provided that the max number of Consistency
Groups for MirrorView/A does not exceed 50.

Table 14 lists the MirrorView/A limits for the AX4-5, CX3 series, and CX400-CX700. For the most recent
limits guidelines, consult the EMC MirrorView/ Asynchronous Release Notes

Table 14. CX3, CX, and AX4 series MirrorView/A system limits
Parameter
Storage system
CX3-80, CX3-40,
CX700, CX600
CX3-20, CX500,
CX400
AX4-5,
CX3-10
Maximum images per storage system 100 50 25
Maximum async consistency groups 16 8 8
Mirrors per async con groups 16 8 8
Note: MirrorView/A source limits are shared with SAN Copy incremental-session and SnapView snapshot
source limits.
Storage-system-based consistency groups
MirrorView (both /S and /A) includes the storage-system-based consistency groups feature. A storage-
system-based consistency group is a collection of mirrors that function together as a unit within a storage
system. All operations, such as synchronization, promote, and fracture, occur on all the members of the
consistency group. Once a mirror is part of a consistency group, most operations on individual members are
prohibited. This is to ensure that operations are atomically performed across all the member mirrors.
The members of a consistency group can span across the Storage Processors, but all of the member mirrors
must be on the same storage system. A consistency group cannot have mirrors that span across the storage
systems. In addition, although consistency groups are supported for both synchronous and asynchronous
mirrors, all of the mirrors in each group must be same type of mirror.
Benefits of storage-system-based consistency groups
Managing all write-order dependent volumes as one entity ensures that there is a restartable copy of the
application on the secondary system. The copies are restartable because all the volumes are as current as
the solutions RPO will allow. Other replication strategies may yield a recoverable copy of data at the DR
site. Recoverable copies typically require more operations to bring them back online. Consider the example
of a DBMS application. When using log shipping in the event of a disaster, data files are restored to a
previous point in time (for example, a backup) and then made current by applying logs replicated more
frequently.

Restartable copies offer shorter RTOs than recoverable copies in terms of access to current data. A trade-
off is that more data may be replicated to constitute restartable copies as both logs and data files are being
replicated on a regular basis, as opposed to only replicating the logs.
Consistency groups protect against data corruption in the event of partial failures, for example on one SP,
LUN, or disk. With partial failures, it is possible for the data set at the secondary site to become out of
order or corrupt.
For example, assume an interruption prevents only one SP from communicating with its secondary volume.
If the log volumes reside on the interrupted SP and the database volumes reside on the other SP, it is
possible for updates to be written to the database secondaries, but not the log secondaries.
The following sections discuss specific benefits of consistency groups as they pertain to MirrorView/S and
MirrorView/A.
MirrorView/S
For MirrorView/S, consistency groups are crucial to performing consistent fracture operations. Figure 17
shows a database where SP A owns the log components and SP B owns the data files. Without consistency
groups, an interruption in communication on SP A invokes the fracture log on the log LUNs, and then I/O
continues to the log LUNs and the data LUNs. Since there is no outage on SP B, I/O to the data LUNs
would still be mirrored to the secondary. If an outage occurs on the primary system during this time, there
would not be a usable copy because data would be ahead of the logs at the secondary site.

Figure 17. Partial fracture with no consistency groups
Figure 18 shows the same scenario with consistency groups. If one member of the group fractures, then all
of the members of the group fracture, and data integrity is preserved across the set of secondary images.
At the time of the interruption, MirrorView fractures all of the mirrors in the consistency group due to the
communication failure of those mirrors on SP A. This allows I/O to continue to the primary volumes, but
not to the secondary volumes. While MirrorView performs the fracture operation, it briefly holds write I/Os
to members of the consistency group until that particular member is fractured. After each member is
fractured, I/O is allowed to continue to that volume.

Remote Site (Newark)
Primary Site (NYC)
SPA
SPB
SPA
SPB
Log Trgt 1
Log Trgt 2
Data Trgt 1
Data Trgt 2
F
F
Log Src 2
Data Src 1
Data Src 2
Log Src 1
?


Figure 18. Consistency group fracture with partial interruption
For a database application, as the fracture log is invoked on the log LUN, the storage system acknowledges
the log write to the server. The server then issues the subsequent write to the data volume. If the data
volume write request is issued to the storage system before it is fractured, the storage system holds the I/O
until the fracture of the data LUN can occur. Once fractured, the storage system acknowledges the write to
the server.
MirrorView/A
In addition to managing fractures, consistency groups for MirrorView/A play a key role in the update
process. At the start of an update, a point-in-time copy is created that serves as the source for the point-in-
time transfer. When there is a set of write-order-dependent volumes, the point-in-time copy must be started
simultaneously across all volumes.
As shown in Figure 19, at the start of an update, I/O is held by the system for each mirror until the point-in-
time session has been established for that volume. Once the point-in-time session is created, I/O resumes.
Similarly, before updates are applied to the secondary images, a gold copy is created for all secondary
mirrors. These gold copies remain in place until members of the consistency group complete the transfer of
the delta set. This ensures that changes are applied to all the secondary images or none of them, and that
there is always a consistent point-in-time image available to promote. If the secondary images are promoted
with gold copies in place, MirrorView rolls the contents of the gold copies back to the secondary images
and makes them available for direct server access as primary images. The rollback process has instant
restore capabilities, which means that users have access to their data while the rollback process runs in the
background.

Remote Site (Newark)
(Newark)
Primary Site (NYC)
(NYC)
SPA
SPB
SPA
SPB

Log Src 2
Data Src 1
Data Src 2
Log Trgt 1
Log Trgt 2
Data Trgt 1
Data Trgt 2
Log Src 1
F
F
F
F


Figure 19. MirrorView/A storage-system-based consistency group atomic operations
Managing storage-system-based consistency groups
You can manage consistency groups using Unisphere or Navisphere CLI. Figure 20 illustrates how to
perform operations such as synchronization, fracture, and so forth from Unisphere.

Figure 20. Using Unisphere to manage MirrorView/A storage-system-based consistency
groups

To automate consistency group operations, you can use Navisphere CLI. Figure 21shows the Naviseccli
CLI syntax.

Figure 21. Using Navisphere CLI to manage MirrorView storage-system-based
consistency groups
Consistency group promote options
Like individual mirrors, consistency groups have conditions (normal, admin fractured) and states
(synchronized and consistent). Consistency group conditions and states depend on the condition and states
of the member mirrors. For a consistency group to be in the synchronized state, all of its members must be
in the synchronized state. The group will transition to synchronized after all of the mirrors in the group
have transitioned to this state. A complete list of consistency group conditions and states is available in
Appendix B for reference.
If using Navisphere Secure CLI, verify the state of the consistency group with the storage system that owns
the primary images. If the storage system that owns the primary images is not available, the state of the
consistency group can be obtained from the secondary storage system.
Consistency groups can be promoted if they are in the synchronized or consistent states. The various
promote options are as follow:
Normal promote When promoting the secondary images of a group, MirrorView determines if
connectivity exists between the primary and secondary storage systems, and then checks to see if all
the mirrors within are synchronized. If these conditions are met, the promote proceeds and the current
set of primaries become secondaries of the group. If there is no connectivity or MirrorView determines
that any of the primaries do not match the secondaries, then it will fail and the user can select from the
other promote options listed below. Unlike individual mirrors, a new consistency group is not created
for the promote. Therefore, after a normal promote, the consistency group ID is the same before and
after the promote.
Force promote Force promote is used if the conditions for normal promote are not met. It is a brute
force promote that ignores most errors preventing a normal promote, such as the secondary image
state being consistent, the mirror being in a fractured state (admin or system fracture), a failed link, and
so forth. In cases where connectivity still exists between the primary and secondary storage systems,
the secondary images are placed as primary images of the same consistency group. The original
primaries are placed in the group as secondary images. A full synchronization is then required from the
new primary (old secondary) images to the new secondary (old primary) images. If connectivity does
not exist, force promote acts like Local Only promote.
Local only promote This promotes the consistency group on the secondary site without adding the
primary images as secondary images of the mirrors. A new group is created on the secondary storage
system, and the original secondary images are placed in the new consistency group as primary images.
The primary images on the primary storage system remain in the original consistency group. Both
consistency groups will be in the Local Only state. Although this option is not available for individual
MirrorView/S mirrors, it is available for MirrorView/S consistency groups.
Cancel Do not proceed with the promote.

MirrorView management
Required storage system software
MirrorView runs within the VNX Operating Environment for Block on VNX systems. The MirrorView/A
and MirrorView/S enablers are included in the Remote Protection Suite, the Total Protection Pack and the
Total Efficiency Pack. MirrorView runs within the FLARE operating environment on CLARiiON and
Unified NS series systems.. MirrorView/A and MirrorView/S are separately licensed products for these
systems. Figure 22 shows the presence of various enablers in the Storage System Properties dialog box.

Figure 22. Storage System Properties (Software tab)
Once the enabler is installed, all relevant menus and dialogs become available to the user within Unisphere,
and the storage systems will respond to feature specific CLI commands.
Management topology
Management network connectivity
Network connectivity requirements for configuring MirrorView are determined by Unisphere and/or CLI.
Unisphere and Navisphere CLI communicate with the storage systems using ports 80/443 or alternately,
2162/2163. Furthermore, network connectivity between systems on these ports is required to set up and
configure mirrors. Once configured, MirrorView communicates in-band, via the data path, between the
storage systems; any communication needed, such as to facilitating a promote operation, occurs in-band.

For example, assume a user stops I/O to a primary volume that is replicated with MirrorView/S until the
secondary image is in the synchronized state. A command can then be issued to the secondary storage
system to promote the secondary image. This command is sent through the secondary storage systems
management LAN port. MirrorView on the secondary system then communicates in-band with MirrorView
on the primary system to reverse the image roles. The process could then be reversed by issuing the
promote command to the current secondary (former primary) storage system.

Although MirrorView communicates in-band after initial configuration, we recommend that
communication between storage system network ports always be available. That way, you can recover from
all failure scenarios (like force promote) without having to first reconfigure the management LAN to allow
connectivity.

Unisphere domains
MirrorView can be used between systems in the same Unisphere domain and/or with systems that are not in
the same Unisphere domain. Unisphere has a multi-domain management feature that allows management of
discrete Unisphere domains in one user interface. Figure 23 shows Unisphere configured to manage
multiple domains.

Figure 23. Unisphere 1.1.25 multidomain management
Each domain is mutually exclusive and has its own set of users and user credentials. MirrorView can be
configured between systems in different domains provided the user has the proper rights in each of the
systems domains that they wish to configure.

VNX series systems running VNX OE for Block release 31.5 can have multiple VNX series systems in a
single domain. All VNX series systems in the domain must be running release 31.5 or later. Unisphere
client 1.1.25 was released in support of Release 31.5, and adds multi-domain management for VNX series
and prior generation systems. Unisphere client 1.1.25 can manage VNX series systems running VNX OE
for Block R31.5 and R31 as well as legacy systems like CLARiiON (FLARE release 23 and higher) and
Celerra running DART 6.0.

VNX OE for Block release 31 (Unisphere 1.1), supports only one system per domain, however, Unisphere
client 1.1.25 can be used to manage several of these systems in a multi-domain management configuration.
Therefore, users are not required to upgrade the VNX Operating Environment to take advantage of multi-
domain management. For more information regarding Unisphere Domains, see the whitepaper Multi-
Domain Management with VNX Storage Systems on PowerLink.

VNX series and legacy CLARiiON/NS series domains have slightly different user role definitions. Some of
the user roles are data protection specific. The data protection roles allow storage administrators to give
users specific privileges for managing replicas, without giving them the rights for other storage operations.
Examples include allowing application administrators or service providers to start and refresh local copies
(SnapView), remote copies (SAN Copy), and DR copies (MirrorView), and perform restore and recovery
operations. The VNX Data Protection roles are listed below with the analogous CLARiiON/NS series roles
in parenthesis:

Local Data Protection (Local Replication) Allows the user to perform basic operation for
snapshots and clones, such as session start/activate and clone sync/fracture.

Data Protection (Replication) Allows the user to perform Local Replication operations, plus
basic operations for SAN Copy sessions and MirrorView mirrors.
Data Recovery (Replication/Recovery) Allows the user to perform Local Replication and
Replication operations, plus operations such as restoring replicas back to production LUN (Snap
rollback, clone reverse sync, MirrorView promote).

None of these roles allow users to create new replication objects such as snapshots, clones, SAN Copy
sessions, or mirrors, nor do they allow users to delete objects. Users can only control existing replica
objects with these roles. All three roles have view-only privileges in the domain for object types outside of
their control, so that they can understand the context of the replica object. A detailed list of management
rights for each role is listed in Appendix B: Consistency group states and conditions Protection Roles.

Data protection user roles are created and managed in the same manner as all other user roles. However,
when data protection roles are employed, all of the storage systems in the domain must be running a
minimum of release 29 software for legacy CLARiiON/NS systems. Data protection roles users can be
assigned a local, global, or LDAP scope in the same manner as traditional user roles.
Management software
Unisphere is introduced in release 30 as the replacement for Navisphere Manager. It offers users a task-
based approach to management while still offering many of the object-based menus available in
Navisphere. A menu of tasks is presented to the user. From this menu users can launch dialog boxes to
perform specific tasks or to launch a wizard. One wizard in this suite is the MirrorView Wizard. Figure 24
shows the Navisphere Task Bar with the Replicas tab selected.

Figure 24. MirrorView Wizard launch from the task pane

The MirrorView Wizard uses a task-oriented approach to guide users through the process of creating
mirrors. Along with creating the mirrors, the wizard automatically performs any needed setup operations

such as creating iSCSI connections and MirrorView connections, and creating/assigning write intent log
and reserved LUNs.

Explicit dialog boxes for creating mirror connections, creating mirrors, adding secondary images, and so
forth are still available for advanced users. Advanced users who have very specific requirements or have a
set of conditions that are not covered by the wizard may use this approach.

Navisphere CLI offers a command line approach. All configuration options are available through the CLI
and all security features for authentication, authorization, privacy, and audit are shared with Navisphere
Manager.

For a comprehensive description of management operations, the following documents and white papers are
available on EMC.com and Powerlink except where noted:

Unisphere Manager Help (Powerlink only)
EMC VNX for Block Command Line Interface(CLI)Reference
Security Configuration Guide for VNX for Block whitepaper
CLARiiON Security Configuration Guide white paper

The following sections discuss the features, benefits, and assumptions of the MirrorView Wizard, object-
based management, and CLI.
MirrorView Wizard
The MirrorView Wizard uses a server-centric approach. This ease-of-use feature changes the traditional
approach to storage management, which is to manage the environment from the storage system out to the
server. The basic steps for the wizards are select a server > select a storage system > select a LUN(s) >
perform an action. So the first assumption is that a server will be attached and a LUN assigned prior to
using the MirrorView Wizard.
Before using the wizard, physical connections must be established between the two storage systems. This
includes proper LAN preparation, SAN zoning, and Unisphere Domain configuration, tasks that are not
included in the MirrorView Wizard.
In the wizard, the user is first guided through the LUN selection process by selecting the desired server and
storage system. One or many LUNs may be selected. Then, the wizard performs the following discrete
operations based on user input and existing conditions:
1. Select the remote storage system.
2. If necessary, create iSCSI connections.
3. Select the MirrorView connection type if both iSCSI and Fibre Channel exist.
4. If necessary, create a MirrorView connection.
5. Select a mirror-type: synchronous or asynchronous.
6. Select or create a storage pool for the secondary image(s). The wizards preference is to create the
same LUN type as the primary image, be it RAID-group-based or pool-based.
7. Bind secondary image LUN(s) on the remote storage system.
8. Configure the remote mirror.
9. If multiple source LUNs are selected, perform consistency group configuration.
10. Assign the mirror LUN to a secondary server.
11. Configure the write intent log (in MirrorView/S) or the reserved LUN (in MirrorView/A).
Write intent log LUNs are supported on RAID groups only.

Reserved LUNs are created as thick LUNs by default. Placing reserved LUNs in the same pool as
server-visible LUNs or mirror images is avoided whenever possible. More information is provided
in the Reserved LUNs (MirrorView/A) section of this paper.
Other than selecting the source LUN, remote storage system, and the secondary image storage pool, the
wizard requires minimal input from the user. To simplify the process, there is a default naming convention
for objects created by the wizard, based on the storage system and source LUN names. Users can edit these
names in the wizard on the fly.
Mirror LUN properties
The wizard binds a secondary LUN in all instances. The wizard sets all secondary LUN properties to match
those properties of the source LUN, including LUN type. The default name for the mirror LUN is
Image Of <primary_server_ name><primary LUN name>. The default name may be changed simply by
modifying the default name in the Secondary LUN Name field in the wizard, as shown in Figure 25.

Figure 25. Mirror LUN name
Remote mirror configuration
The remote mirror wizard creates and configures the remote mirror with minimal input from the user. In
fact, there are only two or three parameters the user may alter based upon the type of mirror chosen, as
shown in Table 15.

Table 15. Remote mirror user configurable properties
Mirror property Default value Mirror type
Sync rate Medium Both
Mirror name Mirror of <primary server> <primary LUN> Both; See Figure 25
Update interval 4 hours Asynchronous only
Consistency group name Group of <primary server> <primary LUN1>
<primary LUN2> primary LUN3>
Both; only when multiple
LUNs are selected

Additional parameters are automatically configured by the wizard with no user input, as listed in Table 16.
In addition, the contents of the primary LUN are automatically copied to the secondary LUN upon
completion of the wizard.
Table 16. Default remote mirror properties
Mirror property Default value Mirror type
Minimum required images 0 Both
Quiesce threshold 60 Synchronous only
Use write intent log Selected Synchronous only
Recovery policy Automatic Both
Assumption Hidden property values are not commonly changed by customers.
Implication Customers that require specific settings for these hidden properties may not change
them using the wizard.
Alternative Modify the property value after mirror creation with the wizard or use the traditional,
object-based method to configure a mirror.
Consistency group configuration
The MirrorView Wizard automatically configures a consistency group when you select multiple primary
LUNs. The consistency group default name is listed in Table 15 and may be modified by the user in the
wizard. The wizard automatically creates the consistency group with the selected name and adds each
remote mirror to the group.
Storage Group configuration
The MirrorView Wizard optionally allows the user to assign the secondary LUN to a server, for example,
for DR preparedness. The wizard automatically performs the storage group operations if the user selects a
secondary server as shown in Figure 26.


Figure 26. Select the server for a secondary image

The specific steps performed by the wizard vary based on the existence of a storage group for the selected
server.
The server is already configured in a storage group The wizard places the newly bound LUNs in the
servers storage group.
The server is not configured in a storage group The wizard creates a storage group for the server,
places the server in the storage group, and places the newly bound LUNs in the storage group. In this
case, the wizard automatically creates a storage group named SG_<server name>. If you need a
specific storage group name, you may change it using the traditional Storage Group Properties
dialog box.
Write intent log configuration (MirrorView/S)
The MirrorView Wizard checks for the existence of the write intent log LUNs on the system and will bind
them on both storage systems appropriately if needed, based on the following policy.
The RAID group used for each write intent log LUN is determined by the following criteria:
Does not contain the source LUN
Contains the fewest server-visible LUNs
Contains the fewest clones and mirror images

Contains the most free space
Contains the fewest LUNs

The general Default Owner property is assigned based on the RAID group from which the write intent
LUN is bound:
For even-numbered RAID groups, the default owner is SP-A.
For odd-numbered RAID groups, the default owner is SP-B.

The naming convention used is virtual disk sequence_number, where the sequence number is generated
based on the existing LUN names in the storage system. Sequence number generation uses the following
formula:
The number starts from the largest number found at the end of existing LUN names. For example,
if the existing LUNs in the storage system have names LUN 0 to LUN 10, LUN 50 to LUN 59,
then the sequence number starts at 60, giving the first LUN the name "Virtual Disk 60.
Each time the wizard is run, the above method is used to find a new starting sequence number, if
necessary.
If no trailing numbers exist in the LUN names (for example, if all LUN names were changed to
not include a number), the sequence numbering starts at 0.
Reserved LUNs (MirrorView/A)
Reserved LUNs are required for both the primary and secondary LUNs in an asynchronous mirror
relationship. The MirrorView Wizard automatically configures the reserved LUNs on both storage systems
with no input from the user.
The following attributes are used to create the LUNs:
Reserved LUN capacity for the primary and secondary images is set at 20 percent of the image
LUN size.
Two Reserved LUNs are bound for each primary and secondary LUN selected in the wizard.
The total overhead storage space is divided evenly among the number of Reserved LUNs.
By default, reserved LUNs are configured as thick LUNs using this algorithm:
1. It configures thick LUNs in pools that do not contain server-visible LUNs or mirror
images, and contain the least number of reserved LUNs.
2. If the conditions in step 1 cannot be met, the system tries to create a new storage pool
(three- or five-disk RAID 5 or two-disk RAID 1/0) for the thick LUNs. It then configures
the reserved LUNs on this pool.
3. If there no disks are available to create a new storage pool, it places the reserved LUNs in
an existing pool that has enough capacity.
4. If there is not an existing pool with enough capacity, it evaluates RAID groups using
steps 1 to 4.
5. If it cannot find an acceptable RAID group, the process fails.

Reserved LUNs created in pools typically alternate SP ownership. By default two reserved LUNs are
created per source, one owned by SP A and the other by SP B. When created on a RAID group, the Default
Owner property is assigned based on the RAID group from which the reserved LUN is bound:
For even-numbered RAID groups, the Default Owner is SP-A.
For odd-numbered RAID groups, the Default Owner is SP-B.
The naming convention used is the same as for write intent log LUNs: Virtual Disk sequence_number
For example, assume a user wants to create a mirror of LUN 12, which has a capacity of 200 GB. Existing
LUNs on both systems range in LUN number and name from LUN 0 LUN 50. The wizard will configure

the reserved LUN pool on the primary storage system with two 20 GB LUNs and secondary storage system
with two 20 GB LUNs. The reserved LUN names on both arrays will be Virtual Disk 51 through Virtual
Disk 54.
The wizard always creates two new Reserved LUNs for each source LUN and never uses unallocated
LUNs in the pool. Two Reserved LUNs for each source LUNs allow the reserved snapshots to expand over
time.
Advanced dialogs
Dialogs to perform specific tasks such as creating a mirror, adding a secondary, and so on are available in
Unisphere. These dialogs can be launched from the task menu pane or from the right-click object menu of a
specific object. Additional configuration options are available in these dialogs. They can be used to create
mirrors as well as change the mirror properties of any mirror regardless of which method was used to create
it.

Figure 27 shows right-click menu from which mirror-related operations can be launched. Other
MirrorView object menus are available on the LUN and remote mirror objects in the tree structure.

Figure 27. MirrorView task menu and right-click menu options in Unisphere
Creating a mirror in this manner is a two-step operation. First, create the mirror while selecting the primary
image LUN. Then, add a secondary image to the mirror. Figure 28 shows the object-based dialogs for
creating a sync mirror and adding a secondary image. Here users have the option to specify values other
than default for Minimum Required Images, Quiesce Threshold, use of the write intent log, initial sync
required, and Recovery Policy.


Figure 28. Create Remote Mirror and Add Secondary Image dialog boxes

Figure 29 shows the object menus for creating an asynchronous mirror and adding a secondary image. For
asynchronous mirrors, users can configure minimum required images, initial sync required, recovery
policy, and the update type in the object dialog boxes, where these items are shown in the wizard.

Figure 29. Create Remote Mirror and Add Secondary Image dialog boxes

Consistency groups have similar dialogs as shown in Figure 30. Note that for asynchronous mirrors, you
can designate the Recovery Policy and Synchronization rate at the consistency group level. Values set at
the consistency group level override the same settings for individual mirrors in the consistency group. For
synchronous mirrors, you set the recovery policy at the consistency group level, but you set the
synchronization rate at the individual mirror level.


Figure 30. Create Group dialog boxes for synchronous and asynchronous mirrors
Unisphere Analyzer
Unisphere Analyzer is optional performance-monitoring software that operates within Unisphere. It
provides detailed performance statistics for disks, RAID groups, LUNs, metaLUNs, thin LUNs, SnapView
sessions, MirrorView/A mirrors, front-end ports, and SPs. Users can view the statistics in real time or log
the metrics in a Unisphere Analyzer archive (.nar) file for later viewing. There are no specific statistics for
MirrorView/S. The following performance metrics are available for MirrorView/A mirrors:

Total Bandwidth Total update bandwidth, from the primary image to the secondary image, of an
async mirror.
Total Throughput Writes per second, from the primary image to the secondary image, of an
async mirror.
Average Transfer Size Average write size of the MirrorView/A update.
Time Lag (minutes) The time difference between the point in time of the secondary image and
the primary image.
Data Lag (MB) The amount of writes that have been tracked on the primary image, but have yet
to be sent to the secondary image.
Cycle Count The number of updates that completed within the Unisphere Analyzer polling
period
Average Cycle Time The average time duration of the MirrorView/A updates that have
completed within the Unisphere Analyzer polling period.

Figure 29 shows sample charts for total bandwidth and time lag. There are two mirrors in the charts, Edrive
and Fdrive. The mirror, Edrive, is set to start updates 15 minutes after the start of the previous update. The
Fdrive mirror is set to update 20 minutes after the start of each update.


Figure 31. Unisphere Analyzer charts for total bandwidth and time lag

MirrorView/A and MirrorView/S replicated data is included in the front-end port statistics for the
secondary storage system; it is not in frond-end port statistics for the primary storage system. If the
MirrorView port for the secondary storage systems is dedicated to MirrorView, then all traffic shown by
Analyzer will be MirrorView activity. However, it is important to remember that if the port is also used for
servers or other host traffic, the traffic shown by Analyzer will include all of that traffic, not just
MirrorView traffic.

MirrorView failure recovery scenarios
When a failure occurs during normal operations, MirrorView and the base operating environment
implement several actions to facilitate recovery. MirrorView tries to achieve three goals in the recovery of
failures: minimize the duration of data unavailability, preserve data integrity, and when possible, complete
a recovery transparent to the user.
The following sections describe various failure scenarios of primary components and secondary
components. In these scenarios, failures may occur in the path between the production server and the
primary storage system, to the primary or secondary image LUN itself
2
, to a single SP, or to an entire
storage system. For the purpose of these discussions, the term primary storage system refers to the storage
system containing the primary image and secondary storage system refers to the storage system containing
the secondary image. Appendix C: Storage-system failure scenarios contains much of the same
information in a table format for quick reference.
Primary component failure and recovery
Failures in the production server to storage system path, primary image(s), or primary storage system affect
application performance and availability. The nature of the failure may dictate that little corrective action is
needed. It may also dictate that the secondary image be promoted and used as the production image until
the primary site (or image) can be repaired. The following sections describe various failure scenarios within
the primary storage system and its components.
Path failure between server and primary image
If a server loses its I/O path(s) to a storage processor, LUNs are trespassed to the alternate SP. This is
typically enacted by server-based path management software such as PowerPath. With SP ownership
changed, the primary storage system will send a request to the secondary storage system to trespass the
secondary image. This way, SP ownership is consistent between the mirrored pairs on the primary and
secondary storage systems. Between updates, MirrorView/A may not trespass the secondary volume until
the start of the next update. Once trespassed, the update proceeds.
Primary image LUN failure
VNX series and legacy CLARiiON/NS systems (Release 26 and later) have internal I/O redirection features
that make them more resilient to certain types of LUN failures than previous releases. When a failure
prevents an SP from accessing its LUNs on the back end, I/O is internally redirected to the other SP,
provided that the other SP can access the LUNs. The benefit is that back-end failures affecting just one SP
(for example an LCC failure) do not result in a LUN trespass by the host failover software. Once the failure
is corrected, the original SP resumes control of back-end I/O to the LUN.
Masking the back-end failure internally provides a faster and less complex failover and recovery process.
Server I/O and mirroring traffic remain balanced across the connectivity environment. Also, there is no
interruption to the mirroring process, which reduces the number of fractures and resynchronizations.
If the LUN failure occurs in such a way that neither SP can access the LUNs, then the mirror will become
fractured and server I/O to the LUN is rejected until the LUN becomes available again. During this process,
the user may choose to promote the secondary image, and redirect server I/O to the secondary image.
If the secondary image state is consistent and/or fractured at the point in time of the failure on the primary
image, a full resynchronization of the originally-primary-now-secondary image would be required, since
there would be no other way to guarantee byte-for-byte synchronicity.
For MirrorView/A, if the primary image fails during an update and the user promotes the secondary image,
any changes to the secondary are rolled back from the protective snapshot. If the user fixes the error on the
primary without promoting the secondary, the update continues from the point it was interrupted.

2
Many media failures are themselves automatically detected and corrected by lower-level CLARiiON
software, so this scenario is probably the least likely.

Storage processor (SP) controlling primary image failure
If the SP owning the primary image fails, the MirrorView LUN trespasses to the surviving SP on the
primary storage system per direction of the server failover software. At the same time, MirrorView on the
primary system will issue a trespass command to the secondary to trespass the secondary image.
For MirrorView/S, the write intent log is used to avoid a full resynchronization. Mirrors not using the write
intent log will have to do a full synchronization. For MirrorView/A, a full synchronization is not required
since tracking/transfer data is stored on persistent media.

Figure 32. Before the SP failure: Both images are controlled by SP A

Figure 33. Following the SP failure: Both images are trespassed to SP B
Primary image storage system failure
If the storage system containing the primary image fails, server I/O to the LUN will fail until the storage
system becomes available again. As with the primary image LUN failure, the user may choose to promote
Production
Host
SPB
Primary
SPA
Secondary
SPB
SPA
Primary Secondary
Primary
SPB
Primary
SPA
Secondary
Secondary
SPB
SPA
Production
Host

the secondary image, and redirect server I/O to this image. However, if the secondary image is promoted
while communication to the original primary storage system is unavailable, it will not be possible to add
the original primary image in the new mirror as a secondary image. Instead, it is necessary to add
3
the
original primary device subsequently (when that storage system comes back online) to the new mirror and
then perform a full synchronization. Alternatively, a different LUN on the original primary array can be
added as the secondary image for the newly promoted primary (as shown in Figure 35), which likewise
would require a full synchronization.

Figure 34. Before the primary storage system failure: The primary image (on the primary
system) has mirror ID X

3
Before adding the original primary image to the new mirror, the old mirror must be force destroyed. In
this case, the force destroy option is used because changes were made to the mirror while to primary system
was unavailable.
Standby
Host
Primary
SPB
Primary
[Mirror ID X]
SPA
Primary
[Mirror ID Y]
Secondary
SPB
SPA
Production
Host
Secondary
[Mirror ID Y]
Primary
SPB
Primary
[Mirror ID X]
SPA
Secondary
[Mirror ID X]
Secondary
SPB
SPA
Secondary
Host
Production
Host

Figure 35. Following the primary storage system failure: The newly promoted primary
image (on the secondary system) has mirror ID Y
Secondary component failure and recovery
Loss of secondary components reduces or eliminates DR protection of the mirror. When a primary image
determines that it is not possible to communicate with a secondary image, it marks the secondary as
unreachable and discontinues attempts to write to the secondary. However, the secondary image remains a
member of the mirror.
Secondary image LUN failure
The I/O redirection capability (as described in the Primary image LUN failure section) allows mirroring
to continue if the LUN failure only affects the current owning SP. The primary image would continue
mirroring to the secondary image on the original SP. If the secondary image LUN fails in such a way that
affects both SPs, then the image is admin fractured. At that point, the administrator can choose whether to
repair the LUN or remove it from the MirrorView relationship altogether. If the LUN is repaired, it can be
resynchronized once it is available for use. If another LUN is selected to serve as the secondary image, it
must first be fully synchronized.
Storage processor (SP) controlling secondary image failure
If the SP owning the secondary image fails, it is system fractured until the SP comes back online. Once the
SP comes back online, the mirror is automatically resynchronizedprovided that the auto recovery policy
is selected. If auto restore is not enabled, then the administrator must intervene by explicitly starting the
synchronization
4
. Additionally, if the same SP on the primary storage system also failsresulting in the
trespassing of the primary LUN to the peer SP and, likewise, the trespassing of the secondary LUN to its
peer SPthe secondary image is automatically resynchronized (again, provided auto-restore is enabled).
Secondary image storage system (or link) failure
If the storage system containing the secondary image fails, the secondary image is system fractured.
Similarly, if the link between the primary and secondary storage system fails, the secondary image is also
system fractured. In either event, once the issue has been resolved and the secondary storage system is back
in communication with the primary storage system, the secondary image is automatically resynchronized if
auto recovery policy is enabled.

4
Users are given the option to have the resynchronization occur automatically by enabling auto restore. If
they prefer, they can manually initiate this themselves. This is a property of the mirror, and can be changed
at any time.


Figure 36. A failure of the link between storage systems or of secondary storage systems
temporarily suspends mirroring
Full reserved LUN (MirrorView/A only)
On the primary storage system
If the reserved LUN space for a mirror fills up during an update, MirrorView software aborts the update
operation and the mirror transitions into an admin-fractured state. For the MirrorView/A session, the point-
in-time view of the primary mirror LUN created at the start of the update operation is stopped while the
information in the tracking map is maintained. In this condition, the user has an option of adding more
reserved LUNs and manually starting the MirrorView/A session update operation. The contents of the
tracking map are persistently maintained. Starting the update operation will result in incremental update of
the secondary mirror with the changes on the primary mirror since the last successful update.
On the secondary storage system
The amount of reserved LUN capacity required on the secondary side equals the amount of changes applied
to the secondary. For example, if 20 percent of the contents of the primary LUN changes, the reserved
LUNs must have a minimum capacity equal to the 20 percent change.
If, during the update, the reserved LUNs on the secondary system are full, the MirrorView/A session will
transition into an admin-fractured state. The point-in-time view of the secondary mirror LUN in the form of
a gold copy is maintained. User intervention is required to allocate more storage to the reserved LUNs and
restart the update operation. The update will continue from the point it was interrupted.
Using SnapView with MirrorView
SnapView is storage-system-based replication software for local replicas. SnapView is licensed separately
from MirrorView/S and MirrorView/A. For VNX series platforms, SnapView is included in the Local
Protection Suite, Total Protection Pack, and the Total Efficiency Pack. The license can be purchased
separately for legacy CLARiiON/NS systems. SnapView supports both pointer-based replicas, called
snapshots, and full binary copies, called clones. SnapView benefits users by providing business
continuance copies for local rapid recovery and parallel processing operations such as back up, reporting,
or testing.

Production
Host
Primary
SPB
Primary
SPA
Secondary
Secondary
SPB
SPA

When used with MirrorView, SnapView can provide local replicas of primary and/or secondary images. It
allows for secondary access to data at either the primary location, secondary location, or both, without
taking production data offline.

Figure 37. Clones and snapshots of primary and secondary images

For in-depth information on SnapView architecture and basic operations, see the following white papers on
EMC.com and Powerlink:

EMC CLARiiON SnapView Clones A Detailed Review
EMC SnapView SnapShots and Snap Sessions Knowledgebook

SnapView replicas of MirrorView primary images follow standard operating guidelines as described in the
above white papers. SnapView replicas of MirrorView secondary images have to be produced very
carefully because secondary image states can change frequently.

All SnapView replicas of secondary images should represent points in time where the secondary image is
in the consistent or synchronized state. During MirrorView synchronizations, the secondary image LUN is
not in a usable state. Secondary images are in the synchronizing state during MirrorView/S
synchronizations and the updating state during MirrorView/A updates. You should not start SnapView
snapshots or fracture clones while the secondary images are in either state.

You can use the Manual MirrorView recovery policy to coordinate SnapView activities with fractured
mirrors. The Manual option requires user intervention to start synchronizations after a system fracture.
Snapshots can be started or clones fractured before initiating the mirror synchronization.

SnapView and MirrorView consistency features are also compatible. Use SnapViews consistent start
and consistent fracture operations when creating SnapView replicas of a MirrorView/S consistency
group. SnapView consistent operations cannot be performed on the consistency group, but can be
conducted across all members of the group. Consistent operations can also be used with MV/A, but are not
required if you are starting sessions or fracturing clones between updates. Replication Manager 5.1 and
later versions have support for creating SnapView replicas of MirrorView/S and MirrorView/A primary
images and MirrorView/S secondary images.

Snapshots of MirrorView image LUNs are available on all storage systems that support both SnapView
snapshots and MirrorView. Clone of a mirror is available on all VNX series systems and legacy systems
running release 24 or later. The AX4-5 currently runs release 23, so it does not offer this option.
LUN eligibility
Any mirror image can be a clone source; however, a clone image of another source cannot serve as a
mirror image. The LUN can become a clone source or mirror image in any order. For example, an existing
Secondary

Primary
10 AM Snap

4 PM Clone

1 PM Snap

10PM Clone

8 AM Clone
1 PM Snap

clone source could be added to a mirror as a secondary image. Alternately, a mirror secondary image could
also be made a clone source.

A snapshot can be taken of any MirrorView image. Snapshot images cannot serve as mirror images. In
other words, you cannot mirror a snap.
Limit dependencies
Clone and MirrorView/S limits are independent of one another. The number of mirror images and clones
for each LUN and each storage system are counted separately against the LUN and storage system limits.
While system limits for clones vary with storage system type, the number of clones per source LUN
remains eight for all storage system models.

MirrorView/A images count toward the LUN-level snap-session limit of eight. The LUN-level snap-session
limit is the same for all storage system models. MirrorView/A uses a reserved snap session on both the
primary and secondary images to track changes and maintain point-in-time copies. Therefore, users can
create up to seven SnapView snap sessions on a MirrorView/A primary or secondary image. There are no
such limit dependencies between MirrorView/S images and SnapView snapshots.
Instant restore
Both snapshots and clones offer instant restore capability. For clones, the reverse synchronization operation
is used for instant restore. For snap sessions, the rollback feature is used. In both cases, the source LUN is
instantly available and will appear to the host as the point in time that the SnapView replica represents. In
the background, SnapView moves the data from the SnapView replica back to the source LUN.

When used with MirrorView, instant restores can only be performed on primary image LUNs. During an
instant restore to a primary image, the secondary image must be fractured. If the mirror is part of a
consistency group, then the group must be fractured. The software enforces this to prevent MirrorView
from presenting a consistent secondary image state while the data itself isnt usable. Once the restore
process completes, a partial resync can be performed to move the changes to the secondary image.
Secondary image LUNs can be restored from a SnapView replica only after they are promoted to the role
of primary image.

Promoting a secondary image while the primary image is being restored is possible with the Local Only
promote option. This option is available for individual MirrorView/A mirrors and consistency groups for
both MirrorView/A and MirrorView/S. It is not available for individual MirrorView/S mirrors. The local
only promote option places the secondary image LUN in a new mirror as the primary image. The original
primary image LUN cannot be demoted to secondary while the restore process is active.

Finally, in the case of MirrorView/A only, an instant restore cannot be performed on a primary image if the
image is rolling back. An image is rolling back if it was recently promoted and MirrorView/A is
recovering it from the gold copy. It is possible to restore the primary image once the rollback process is
complete.
Clone state Clone Remote Mirror Synching
The Remote Mirror Synching clone state was added to help users coordinate mirror-sync and
clone-sync-and-fracture operations. During mirror sync operations the secondary image LUN is not in a
usable state. This is true for initial syncs, MirrorView/S partial syncs, and MirrorView/A updates when the
secondary image is in the synchronizing or updating states.

Clones that are in-sync during a mirror sync will be in the Clone Remote Mirror Synching state as shown
in Figure 38. This clone state indicates that the source LUN, also serving as a secondary image, is not in a
consistent state and should not be fractured.


Figure 38. Remote Mirror Syncing Clone state
Automation and reporting software
Several EMC and third-party software products are qualified to work with MirrorView to automate high-
availability and DR solutions. The following products are currently qualified and available for use with
MirrorView. Always check the latest EMC Support Matrix for the latest interoperability information.
VMware vSphere and Site Recovery Manager (SRM)
Both VMFS volumes and RDM volumes can be replicated with MirrorView. Some of the major
implementation guidelines for MirrorView and other replication applications are listed below.
RDM volumes must be in Physical compatibility mode when used with storage-system-based
replication.
When replicating an entire VMFS volume that contains a number of virtual disks on a single LUN,
the granularity of replication is the entire LUN with all of its virtual disks.
When making copies of VMFS volumes that span multiple LUNs, you must use the consistency
technology of SnapView/MirrorView
For VMFS-3 and RDM volumes, the replica can be presented to the same ESX server but not to
the same virtual machine.

VMware Site Recovery Manager (SRM) provides a framework for remote site recovery automation. SRM
works with storage vendor-provided Storage Replication Adapters (SRAs) to automate site recovery using
the storage vendors native replication software. The VNX series/CLARiiON SRA supports SRM
automation with MirrorView/A and MirrorView/S.

Please consult the E-Lab Navigator and/or the following references on Powerlink for detailed
implementation information:
Using EMC VNX Storage with VMware vSphere techbook
Using EMC CLARiiON Storage with VMware vSphere and VMware Infrastructure
EMC MirrorView Adapter for VMware Site Recovery Manager Release Notes

MirrorView Insight for VMware (MVIV) is a new tool bundled with the MirrorView Site Recovery
Adapter (SRA) that complements the Site Recovery Manager framework by providing failback capability
(experimental support only). MVIV also provides detailed mapping of VMware file systems and their
replication relationships. For more details, refer to the MirrorView Insight for VMware (MVIV) Technical
Note available on Powerlink.

EMC Replication Enabler for Microsoft Exchange Server 2010
The EMC Replication Enabler for Microsoft Exchange Server 2010 is a free software utility that integrates
EMC RecoverPoint and RecoverPoint/SE synchronous remote replication and MirrorView/S replication
with the Exchange Server 2010 data availability group (DAG) architecture. This allows customers to use
the same, consistent, array-based replication solutions for Exchange 2010 and other applications in the
environment. For more information, see the Replication Enabler for Microsoft Exchange Server 2010
Release Notes on EMC Powerlink.
EMC Data Protection Advisor (DPA)
EMC Data Protection Advisor helps users ensure their replication environment remains accurate and
effective in the face of constant change. It provides a scalable, enterprise-level solution for replication
analysis to ensure mission-critical applications are protected and recoverable. It discovers selected clients
applications, databases, and file systems, and maps them to physical storage devices. It maps all copies of
the primary data including snapshots, clones, and remote synchronous and asynchronous replicas. After
discovery, it correlates client, application, storage mapping, and other metadata to identify incomplete and
inconsistent replicas that would result in a failed recovery. It then provides an intuitive graphical map of the
relationship between host and storage. It represents any recoverability gaps and exposures in easy-to-
understand reports and views that can be used by administrators to resolve issues. For VNX series and
legacy CLARiiON/NS series systems, DPA supports MirrorView/A, MirrorView/S, SnapView, SAN
Copy, and RecoverPoint (CDP,CRR, CLR). Application integration includes Oracle, SQL Server,
PostgreSQL, Exchange, and file systems.

DPA eliminates the need for manual data collection, and collects data more frequently than would be
practical manually. With this information, it can actively alert administrators to any issues as well as reduce
the time it takes to conduct and audit by as much as 95 percent. This can reduce costs by eliminating the
need for third-party consulting services to perform these tasks. For more information on Data Protection
Advisor, the following white papers are available on Powerlink:

EMC Data Protection Advisor for Replication Analysis A Detailed Review
Increasing Recoverability of Critical Data with EMC Data Protection Advisor and Replication
Analysis
MirrorView/Cluster Enabler (MV/CE)
EMC MirrorView/Cluster Enabler is a replication automation product from EMC. MV/CE is host-based
software that integrates with Microsoft Failover Cluster software to allow geographically dispersed cluster
nodes across MirrorView links. MV/CE seamlessly manages all storage system processes necessary to facilitate
cluster node failover. MirrorView/A and MirrorView/S replication is supported.
MV/CE offers reduced RTO by allowing the Windows operating system and applications like Microsoft
Exchange and Microsoft SQL Server to automate resource failover between sites. MV/CE can also be used in
Hypervisor environments in host clustering configurations for Hyper-V and guest clustering configurations for
Hyper-V and VMware. For more information, please see the following resources on Powerlink:
EMC MirrorView/Cluster Enabler (CE) A Detailed Review white paper
Cluster Enabler Product Guide
MirrorView/Cluster Enabler Release Notes
MV/CE 4.1 supports VNX Series systems, CLARiiON/NS systems running FLARE releases 26-30, and AX4
systems running Release 23.
Replication Manager
Replication Manager (RM) is replica automation software that creates point-in-time replicas of databases
and file systems residing on VNX, CLARiiON, Symmetrix, or Celerra
storage systems. Replicas can be

used for repurposing, backup, and recovery, or as part of a DR plan. RM provides a single interface for

managing local and remote replicas across supported storage systems. Replication Manager supports
SnapView snapshot and clone replicas of MirrorView/S and MirrorView/A primary and secondary images.
For more information see the Replication Manager Product Guide on Powerlink.
AutoStart
AutoStart is high-availability software that enables clustering of enterprise applications. It safeguards
critical applications by automating the failover of applications such as ERP, database, e-mail, and web
applications. It also monitors application health and performance, provides alerting, and
reprovisions/restarts services as necessary in response to failures.

AutoStart is heterogeneous software that provides a consistent solution across a variety of operating
systems and platforms. AutoStart 5.3 adds support for applications being replicated by MirrorView/S and
MirrorView/A. This enables automated application failover between nodes across MirrorView links.

For more detailed product information, consult the EMC AutoStart Administrators Guide. For supported
environment information, consult the EMC Information Protection Software Compatibility Guide.
VNX for File and Celerra
LUNs allocated to VNX for File or legacy Celerra line of network-attached storage products can be
replicated with MirrorView/S. The following are high-level guidelines for using MirrorView/S with
Celerra. More detailed information is included in the technical modules Using MirrorView/Synchronous
with VNX for File for Disaster Recovery and Using MirrorView/Synchronous with Celerra for Disaster
Recovery found on Powerlink.)

All LUNs dedicated to VNX for File or Celerra must be managed within a consistency group.
Consistency groups are discussed in the Storage-system-based consistency groups section.
As part of the baseline configuration, control LUNs 0, 1, and 4 must be included in the
consistency group. The remainder of the LUNs in the consistency group can be allocated as user
LUNs.
The write intent log must be allocated. See more in the Write intent log section.
Existing configurations can implement MirrorView/S provided they can meet the first guideline.
Sybase Mirror Activator
Sybase Mirror Activator is a Sybase software solution that allows users to combine the benefits of
transaction replication and storage-based replication to deliver business continuity and DR for mission-
critical applications.

The combination of Sybase Mirror Activator and MirrorView/S provides a zero data loss solution that
significantly reduces RTO and improves return on investments from continued access to standby resources.

This solution is available for use with MirrorView/S. Sybase Mirror Activator is able to maintain an active
copy of the database at the DR site by having the replication server apply log files as they are replicated by
MirrorView/S.

For more information about this solution, see the EMC MirrorView/Synchronous with Sybase Mirror
Activator white paper on Powerlink.
Disk drive technologies and advanced data services
EMC midrange storage systems offer the widest range of disk drive technologies in the industry. Multiple
price points and performance profiles are needed to meet a diverse set of end-user application needs. Disk
drive offerings are categorized into three tiers based on price-performance attributes:

Tier 0 Flash drives are comprised of solid state memory technology. Flash drives are applicable
for very high I/O per second environments with low response time requirements. Flash drives can
offer many times the IOPs performance of other drive technologies, along with high reliability.
They also offer low power consumption per I/O and per GB as there are no moving parts.

Tier 1 Serial Attached SCSI (SAS) and Fibre Channel (FC) drives. SAS and FC drives consist
of traditional rotating drives, and are offered in 10k and 15k rpm varieties. They offer high I/O and
bandwidth performance with high reliability and high capacity.

Tier 2 Near Line SAS (NL-SAS) and Serial Advanced Technology Attach II (SATA II) drives.
NL-SAS and SATA II drives are best for applications with very high capacity requirements and
with duty cycles less than 100 percent. They are traditional rotating drives that are available in
7200 rpm and low-power 5400 rpm offerings. They have a lower IOPs profile than the other drive
offerings, but can offer comparable sequential stream bandwidth performance.

For more information on disk drive technologies available for midrange storage systems, see the white
paper An Introduction to EMC CLARiiON and Celerra Unified Platform Storage Device Technology on
Powerlink.

EMC midrange systems also offer the widest array of storage-system-based data services in the midrange
market. Fully Automated Storage Tiering for Virtual Pools (FAST VP) and FAST Cache work at the sub-
LUN level to optimize data placement and performance based on current activity. Compression allows
users to maximize capacity utilization by storing data in a smaller footprint than would normally be
possible.

When LUNs are deployed in RAID groups, they have a homogeneous drive type over the entire address
space. Pools can be deployed in homogeneous pools or heterogeneous pools. For heterogeneous pools,
FAST VP allows optimization of data placement on heterogeneous drive types at a sub-LUN level.

FAST Cache is available for both RAID group and pool LUNs. FAST Cache can boost performance of a
storage systems most active data by moving the most active components to Flash drives. It allows a
relatively small allotment of Flash drives (up to 2 TB on the VNX7500 and CX4-960) to boost performance
of the most active data in the entire storage system. Data movement via FAST VP and FAST Cache is
largely decided by the activity of the production application relative to other application activity on the
storage system.

Compression is an option for data that is relatively inactive but still requires five 9s of availability. It is
enabled at the LUN level and runs as a background process to reduce the data footprint of a given LUN.
New data is written uncompressed. The compression feature monitors the amount of uncompressed data
and processes it once enough has been written to surpass a system-defined threshold.

Storage system based replication is supported with any LUN type and in conjunction with any feature such
as FAST VP, FAST Cache, or compression. FAST VP and FAST Cache perform their analysis on a per-
array basis. When used with remote replication, any FAST VP data relocation or FAST Cache promotions
occur independently at each location. I/O performed by a replication product such as MirrorView or SAN
Copy is factored into the I/O analysis of the source/primary and target/secondary LUNs.
For example, consider the case where a synchronous mirror is set up between two thick LUNs. Both the
primary and secondary images reside in heterogeneous pools with FAST VP. FAST Cache is enabled on
the primary image LUN. The application workload is 80 percent reads and 20 percent writes. On the
primary volume, FAST VP and FAST Cache manage any data movement considering both the read and
write I/Os. FAST VP on the secondary storage system factors in only the write I/Os. Whether or not data is
moved between storage tiers via FAST VP depends on the other I/O activity on each storage system.

EMC recommends that that you disable FAST Cache on MirrorView secondary image LUNs for best
performance. FAST Cache typically doesnt improve the performance of secondary image LUNs, so fewer
system resources are used if its disabled. If using storage pools, secondary image LUNs should be placed

in a storage pool with FAST Cache disabled. If the secondary image LUNs are promoted, FAST Cache can
be enabled for the pool containing the newly promoted LUNs.

Compression analyzes data at the LUN level. Replication I/O can contribute to the uncompressed data
threshold used to trigger the compression process. For instance, if a mirror secondary or SAN Copy
destination is compressed, updates to those volumes will be written uncompressed. When enough data is
written, the compression process will start automatically. If both the source and target are compressed, their
respective compression processes run independently.

When choosing drive technologies for a DR site, users must consider if production applications will run at
the DR site for significant periods of time. If so, similar drive types and configurations should be used at
the DR location. Keep in mind that after promotion, FAST and FAST Cache will begin to react to the
production load running on that system. For instance, after promotion,FAST Cache will have a warming
period as the system analyzes the production workload. For more information on FAST VP and FAST
Cache, please see the following white papers on Powerlink

EMC CLARiiON, Celerra Unified, and VNX FAST Cache A Detailed Review
EMC FAST VP for Unified Storage Systems A Detailed Review
EMC VNX Virtual Provisioning Applied Technology
EMC CLARiiON Data Compression A Detailed Review

The remainder of this section describes the effect of how drive types factor into MirrorView
implementation from the perspective of server I/O and replication I/O. Replication I/O is I/O generated by
MirrorView, like synchronizations. The principles are the same no matter if the data was explicitly placed
on a drive type or it was automatically moved via FAST and/or FAST Cache.

Flash drives excel in transactional I/O profiles when compared to other drives, particularly when there is a
significant random read component. Random reads typically cannot be serviced by read-ahead algorithms
of the drive itself or by the storage system read cache. Therefore, the latency of a random read is directly
related to the seek time of the disk drive. For rotating drives, this is the mechanical movement of the disk
head to the desired area. Flash drives can perform this operation at solid-state memory speeds, which can
be an order of magnitude faster when compared to rotating drives.

Generally speaking, there is no major advantage in using Flash drives purely to improve replication I/O
performance, because replication I/O involves a high percentage of writes. However, applications that
benefit from Flash drives will continue to do so while using MirrorView for DR.

When using MirrorView/S, Flash drives still provide the same advantage to the production application for
random reads. Minimum write response times will probably be dictated by the replication over the link to
the secondary image.

Write intent log LUNs should always be on write-cache enabled LUNs as their I/O profile is almost
exclusively writes and it is required to take advantage of SP cache optimizations. Write intent log LUNs
use an optimization that keeps active data in SP cache. If placed on Flash drives, users must enable write
cache on those LUNs. There is no advantage to placing the write intent log LUNs on Flash drives over Tier
1 drives when write cache is enabled. For optimal performance, it is recommended that FAST Cache be
disabled on write intent log LUNs.

While using MirrorView/A, Flash drives continue to provide the same read-performance benefits to the
production application. In addition, when primary image LUNs are placed on flash, the impact of copy-on-
first-write operations on production volumes can be reduced. Part of the copy-on-first-write operation is a
read from the source LUN and a write to the reserved LUN. The read performance advantage of Flash
drives can provide benefits to this portion of the copy-onfirst-write operation, thereby reducing response
time impacts. Therefore, when source LUNs reside on Flash drives, copy-on-first-write activity has
minimal impact on the application.

The I/O profile for reserved LUNs is largely comprised of writes. Therefore, there is little to no advantage
to explicitly placing reserved LUNs on flash drives. We recommend that you use write-cache enabled
LUNs on Tier 1 drives for reserved LUNs. Reserved LUNs can be RAID-group-based LUNs and/or thick
LUNs.

Writes to reserved LUNs can be random in nature, particularly when there are several reserved LUNs on a
particular set of drives. Therefore, we do not recommend Tier 2 drives for reserved LUNs. In the case of
heterogeneous pools, it is possible that some percentage of a reserved LUN resides on Tier 2 drives. If the
reserved LUN is allocated for a long period of time, like for MirrorView/A primary images, FAST VP can
process the reserved LUN for tiering. For reserved LUN allocations of shorter duration, such as short-term
snapshots, the LUN may not be allocated long enough for FAST VP or FAST Cache to assist. In these
cases, the user may choose to explicitly place reserved LUNs on the preferred drive type by using RAID-
group-based LUNs or specifying tier placement in the pool.

iSCSI connections
iSCSI connections define initiator/target pairs for iSCSI remote replication between storage systems.
Similar to zoning in a Fibre Channel environment, they dictate which targets the initiators log in to. Since
all necessary iSCSI connections are automatically created with the MirrorView Wizard or the MirrorView
Connections dialog box, it is rare that its necessary to explicitly manage iSCSI connections for
MirrorView.

Release 29 adds support for VLAN tagging, which allows you to configure several virtual ports on each
physical iSCSI port. Enabling VLAN tagging is optional on a per-port basis. VNX series systems support
up to 8 virtual ports per 10 Gb/s and 1 Gb/s iSCSI port. CX4 and NS series systems support up to eight
virtual ports per 10 Gb/s port and up to two virtual ports per 1 Gb port. The next figure shows the iSCSI
port properties for a port with VLANs enabled and two virtual ports configured.

Figure 39. ISCSI Port Properties with VLAN tagging enabled

iSCSI connections are defined per physical front-end port for ports without VLAN tagging enabled or per
virtual port for ports with VLAN tagging enabled. For each MirrorView connection to another storage
system, an iSCSI connection will be defined. iSCSI connections must be made for the primary storage
system to the secondary system and for the secondary system back to the primary system. This is required
because mirroring can be bidirectional between systems and primary/secondary images can reverse roles,
resulting in a reversal of replication direction.

Figure 40 shows a connection defined for the storage system Site 1. This connection allows the
MirrorView ports (A-4, B-4)) to log in to target ports of the Site 2 system. The IP addresses listed in the
Target Portal column represent the MirrorView ports of the Site 2 system. The connections shown were
automatically generated by MirrorView when the MirrorView connection was enabled.

Figure 40. iSCSI Connections Between Storage Systems dialog box
When MirrorView automatically creates the iSCSI connection between storage systems, it will try to use a
non-routed (that is, same subnet) path between storage systems. If there are several non-routed options
available, it will choose the option with the lowest virtual port number.

If you do not want to use the default selection criteria for iSCSI connections, connections can be created
manually. To do so, use the Add Connection dialog box, which is shown in Figure 41. In this dialog,
initiator target pairs and CHAP authentication methods are identified. The dialog can be launched in the UI
by navigating to the dashboard; right-clicking the storage system of interest; going to > iSCSI >
Connections Between Storage Systems; and clicking the Add button. Checkboxes are used to choose
which front-end ports or virtual ports are wanted to log in to the target port. The target port is selected using
the drop-down menu. One or more ports can be assigned to log in to each target port. When manually
creating iSCSI connections, be sure to check the MirrorView (/A or /S) release notes for setting
recommendations.

When creating iSCSI connections, the user has three options for CHAP authentication:
Shared A general set of CHAP credentials that can be used by any or all of the connections of a
storage system
Connection Specific CHAP credentials that are defined specifically for the connection being
created
None No authentication


Figure 41. Add Connection dialog box

Connection-specific CHAP credentials are used when an iSCSI connection is created by the MirrorView
Wizard or MirrorView Connections dialog box. The connection shown in Figure 40 shows the connection
name and username format based on the system names used when automatically generated. A CHAP
username and secret is generated by the system when the connection is created.

System-generated CHAP secrets are unique for each connection created. Corresponding entries in the target
systems CHAP management are made for the user by the system when the iSCSI connection is created.
Users that must define their own CHAP username and secrets can edit the system-generated entries by
using the Modify button on the iSCSI Connections Between Storage Systems dialog box (Figure 40).
Corresponding changes must be made to the target systems CHAP management (Figure 43).

The need for CHAP credentials is determined by the target system. There is an option in the iSCSI port
properties page for requiring initiator authentication. Figure 42 shows the iSCSI Port Properties page,
which is launched from the storage system right-click menu and going to <Storage System Name> Settings
> Network > Settings for Block, selecting the desired port, and clicking Properties. The option for
requiring initiator authentication is at the bottom of the dialog box.


Figure 42. iSCSI Port Properties dialog box

When initiator authentication is required, initiators must be defined within the target systems CHAP
management dialog. Figure 43 shows the iSCSI CHAP Management dialog box for the Site 2 system. The
entries shown are the system-generated entries created for the MirrorView ports of the Site 1 storage
system. Initiator and CHAP user/secret entries can be manually added from this dialog, however, its rare
that manual entries are required for MirrorView ports, since the entries are automatically created as part of
creating the iSCSI connection.

Figure 43. iSCSI CHAP Management dialog box
When iSCSI connections are created by the system, CHAP credentials are always entered regardless of
whether they are required by the target system. This way, if the user did not initially have initiator
authentication required, the credentials are already in place if they were to enable it later.
Conclusion
MirrorView offers two products that can satisfy a wide range of recovery point requirements.
MirrorView/S offers a zero data loss solution typically implemented over high bandwidth, low latency
lines. MirrorView/A offers a periodic update solution with recovery points in minutes to hours.
MirrorView/A is typically implemented over long distances on low bandwidth, higher latency lines.

Both products offer a consistency group feature for managing write ordering over a set of volumes.
Consistency groups can lower RTO by maintaining restartable copies of a data set on the remote storage
system. Ease of management is achieved with the ability to manage all remote mirrors in the consistency
group as a single unit.

Several solution automation products such as VMware SRM, MirrorView/CE, and Replication Manager,
are available to simplify disaster recovery solutions for specific applications and platforms. They rely on
MirrorView to perform the replication options because of its flexibility, reliability, and performance.
References
White papers
The following papers are available on EMC.com and Powerlink, EMCs customer- and partner-only
extranet:

EMC VNX Virtual Provisioning
Using EMC VNX Storage with VMware vSphere techbook
EMC CLARiiON Reserved LUN Pool Configuration Considerations
CLARiiON Integration with VMware ESX
Navisphere Task Bar Explained
EMC CLARiiON SnapView Clones
EMC SnapView SnapShots and Snap Sessions Knowledgebook

Product documentation
VNX Open Systems Configuration Guide
EMC CLARiiON Open Systems Configuration Guide for CX4 Series, CX3 Series, CX Series, and AX4-
5 Series Storage Systems
Unisphere Help
MirrorView/Synchronous Release Notes
MirrorView/Asynchronous Release Notes
Using MirrorView/Synchronous with VNX for File for Disaster Recovery
Using MirrorView/Synchronous with Celerra for Disaster Recovery technical module
EMC VNX for Block Command Line Interface(CLI)Reference
MirrorView/Synchronous Command Line Interface (CLI) Reference
MirrorView/Asynchronous Command Line Interface (CLI) Reference

E-Lab Navigator

Appendix A: Remote mirror conditions and image states
Mirror states
State Meaning
Active The remote mirror is running normally.
Attention The mirrors secondary image is fractured, and the mirror is
configured to generate an alert in this case. The mirror
continues to accept server I/O in this state. The event code
ID for a mirror moving into the Attention state is
0x71050129.

Secondary image states
State Meaning
Synchronized

The secondary image is identical to the primary image. This
state persists only until the next write to the primary image,
at which time the image state becomes Consistent.
Consistent The secondary image is identical to either the current
primary image or to some previous instance of the primary
image. This means that the secondary image is available for
recovery when you promote it.
Synchronizing The software is applying changes to the secondary
image to mirror the primary image, but the current
contents of the secondary are not known and are not
usable for recovery.
Out-of-Sync The secondary image requires synchronization with the
primary image. The image is unusable for recovery.
Rolling Back (MirrorView/A only) A successful promotion occurred where there was an
unfinished update to the secondary image. This state persists
until the Rollback operation completes.

Image condition
Along with an image state, an image will have an image condition that provides more information.

Condition Meaning
Normal The normal processing state.
Admin Fractured The administrator has fractured the mirror, or a media failure
(such as a failed sector or a bad block) has occurred. An
administrator must initiate a synchronization.
System Fractured The mirror is system fractured
Synchronizing MirrorView/A or MirrorView/S is performing an initial
synchronization.
MirrorView/S is synchronizing after a fracture.
Updating (MirrorView/A) Mirror is performing periodic update.
Waiting on admin The mirror is no longer system fractured. It is a temporary
condition for automatic recovery mirrors. For manual
recovery mirrors, the administrator can now initiate the
synchronization command
Queued to be Synchronized
(MirrorView/S)
Synchronize command has been received, but the maximum
number of synchronizations are in progress. The mirror will
synchronize when one of the in-process synchronizations
completes. See the release notes for maximum
synchronizations per SP limits.

Appendix B: Consistency group states and conditions
Consistency group states
State Meaning
Synchronized All the secondary images are in the Synchronized state.
Consistent All the secondary images are either in the Synchronized or
Consistent state, and at least one is in the Consistent state.
Quasi Consistent (MirrorView/A) A new member that is not consistent with existing members
is added to the consistency group, which automatically starts
an update. After the update completes, the consistency group
is again consistent.
Synchronizing At least one mirror in the group is in the Synchronizing state,
and no member is in the Out-of-Sync state.
Out-of-Sync The group may be fractured, waiting for synchronization
(either automatic or via the administrator), or in the
synchronization queue. Administrative action may be
required to return the consistency group to having a
recoverable secondary group.
Scrambled There is a mixture of primary and secondary images in the
consistency group. During a promote, it is common for the
group to be in the scrambled state.
Empty The consistency group has no members.
Incomplete Some, but not all of the secondary images are missing, or
mirrors are missing. This is usually due to a failure during
group promotion. The group may also be scrambled.
Local Only The consistency group contains only primary images. No
mirrors in the group have a secondary image.

Rolling Back (MirrorView/A) A successful promotion occurred where there was an
unfinished update to the group. This state persists until the
Rollback operation completes.

Consistency group conditions
MirrorView/S
Condition Meaning
Active The normal processing state.
Inactive The group is not accepting I/O; this is normal during group
promotion.
Admin Fractured The administrator has fractured the group, or a media failure
administrator must initiate a group synchronization.
System Fractured Some or all of the members are system fractured.
Waiting on sync The group is waiting on a Synchronize command.
Consistency groups with the manual recovery option require
the user to initiate the synchronization. If after a system
fracture, it is only a temporary condition for automatic
recovery groups before the system initiates a
synchronization.
Invalid Temporary condition while a group fracture is in progress;
the group is partially fractured. If the state is incomplete, the

condition is irrelevant and is thus set to invalid. If this state
persists, try fracturing the group and synchronizing it.

MirrorView/A
Condition Meaning
Normal The normal processing state.
Initializing The group is performing an initial synchronization.
Updating The group is performing a periodic update.
Admin Fractured The administrator has fractured the group, or a media failure
administrator must initiate a group synchronization.
System Fractured Some or all of the members are system fractured.
Waiting on admin The group is no longer system fractured. It is a temporary
condition for automatic recovery groups. For manual
recovery groups, the administrator can now initiate the group
synchronization.

Appendix C: Storage-system failure scenarios
The following table details storage-system failure scenarios during various states or conditions. Primary
image failures are covered first, followed by secondary image failures.
Storage-system failure scenarios
Primary image failure
Event State/Condition Action
Primary storage system totally
fails.
Any Option 1:
Administrator promotes a secondary LUN on a
secondary storage system. After application data
recovery, applications on a standby server can start up
and access required data.
Note: Any writes that are in progress when the primary
storage system fails may not propagate to the secondary
storage system. Also, if the remote image was fractured
at the time of the failure, any writes since the fracture
will not have propagated.
Option 2:
Repair and reboot the primary storage system, then
synchronize the secondary LUN(s) using the write
intent log. If the write intent log is disabled, then a full
synchronization is necessary.
Primary storage systems
secondary SP fails.
Any Repair the failed SP to restore high-availability
protection for the data. Access to the mirrored LUN
data is uninterrupted.
controlling SP fails.
Server attempts I/O request to
the LUN.
The I/O request fails, and software on the server retries
the request to the secondary SP. This results in a
trespass to the secondary SP, which then synchronizes
the remote LUN (if necessary) based on the write intent
log. The I/O request is coordinated with the
synchronization.
controlling SP fails and reboots.
No server I/O attempted while the
SP is unavailable.
Any All primary LUNs are checked for a current
relationship with their secondary LUNs.
Primary LUN is in-sync with
secondary LUN.
No action
Primary LUN is synchronizing
with secondary LUN.
If a full synchronization is interrupted, then it continues
from the last checkpoint.
If a fracture log-based synchronization is interrupted,
then a full synchronization is necessary unless the
mirror is using the write intent log, in which case the
partial synchronization can be resumed.
In either case, if auto sync is enabled, then
synchronization starts automatically. Otherwise, an
administrator must start the synchronization.
Primary LUN is out-of-sync
with secondary LUN.
A full synchronization is necessary.
If auto sync is enabled, then synchronization starts
automatically. Otherwise, an administrator must start
the synchronization.

Primary LUN is consistent with
secondary LUN.
For a primary LUN using the write intent log, regions
in the log marked potentially out-of-sync are read from
the primary LUN and written to the secondary LUN.
For a primary LUN not using the write intent log, the
secondary LUN is marked out-of sync and a full
synchronization is necessary. If auto sync is enabled,
then synchronization starts automatically. Otherwise,
an administrator must start the synchronization.
Path failure - Primary LUN
trespass from controlling SP to
peer SP
LUN is consistent or in-sync. I/O is quiesced during the trespass. The fracture log
(MV/S) or Reserved LUNs (MV/A) are transferred to
the peer SP.
Primary LUN is synchronizing
with secondary LUN.
Synchronization continues on the new controlling SP.
Secondary LUN is fractured. Fracture log or Reserved LUNs transfer from the
previous controlling SP to the secondary SP.
Back end failure Any If I/O can be redirected to the other SP, host access and
mirroring continue on original SP.
Media error: data write An error is returned to the server. Any defined
secondary images are administratively fractured.
Media error: write intent log
modification (MV/S)
Disable use of write intent log for the mirror. Log the
error and alert an administrator to review. The mirror is
admin fractured.
Reserved LUNs full (MV/A) MV/A Update Current point-in-time image is stopped. Mirror
becomes admin fractured. User must add capacity to
RLP and resume update. Update will include all
changes made to the primary up to the restart of the
update.
Secondary image failure
Secondary storage system totally
fails
Any Repair and reboot the secondary storage system.
The secondary LUN is fractured. To rejoin the mirror,
synchronization (either full or based on a fracture log)
of the secondary LUN is necessary for all states except
in-sync.
Secondary storage systems SP
fails
Any No action
Repair the failed SP to restore high-availability
protection for the data.
Secondary storage systems
controlling SP fails or reboots
Primary storage system detects the failure and fractures
the secondary LUN.
If the failed SP is unavailable for an extended period,
an administrator should manually trespass the primary
LUN to its secondary SP so mirroring can continue.
When the failed SP returns to service, synchronization
is necessary (unless the LUN is in-sync). If the LUN is
consistent or synchronizing, the system uses the
fracture log to perform synchronization. Otherwise, a
full synchronization is necessary.
LUN trespass from the controlling
SP to the secondary SP
No action
This is the expected result when the primary storage
system trespasses for any reason.

Back end failure Any If I/O can be redirected to the other SP, host access and
mirroring continue on original SP.
Media error: data write Secondary image will be marked as administratively
fractured. When repairs are complete, administrator
starts synchronization.
Reserved LUNs Full (MV/A) MV/A Update Mirror becomes admin fractured. Point-in-time image
of secondary is maintained. User must add more
capacity to RLP and resume update. Update will
continue from where it was interrupted.

Appendix D: Data protection roles
The following table provides detailed control capabilities for each data protection role.

VNX Series Local Data
Protection
Data
Protection
Data Recovery
Legacy CLARiiON/NS Series Local Replication Replication Replication/Recovery
SnapView

Start a (consistent) snap session Yes Yes Yes
Stop a (consistent) snap session Yes Yes Yes
Activate a session to a snapshot LUN Yes Yes Yes
Deactivate a session from a snapshot LUN Yes Yes Yes
Synchronize a clone Yes Yes Yes
Fracture a clone Yes Yes Yes
Roll back a snap session No No Yes
Reverse synchronize a clone No No Yes
MirrorView

Synchronize a mirror / consistency group No Yes Yes
Fracture a mirror / consistency group No No Yes
Control the update parameters of an async mirror No Yes Yes
Modify the update frequency of an async mirror No Yes Yes
Throttle a mirror / consistency group No Yes Yes
Promote a sync or async secondary mirror / consistency group No No Yes
SAN Copy

Start a session No Yes Yes
Stop a session No Yes Yes
Pause a session No Yes Yes
Resume a session No Yes Yes
Mark a session No Yes Yes
Unmark a session No Yes Yes
Verify a session No Yes Yes
Throttle a session No Yes Yes

h2417 Mirrorview Know CX Series Flare WP LDV

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

h2417 Mirrorview Know CX Series Flare WP LDV

Diunggah oleh

Hak Cipta:

Format Tersedia

MirrorView Knowledgebook: Releases 30 - 31.

functionality, operations, and best practices. It

software offers two complementary storage-system-based remote mirroring products:

is another storage-system-based remote replication product. It is designed as a multipurpose

, trespasses the LUN to the peer SP. The remaining SP directly

storage systems. Replicas can be

Anda mungkin juga menyukai