Mirror View SAN Copy Foundations - Student Resource Guide - r30

Copyright 2010 EMC Corporation. Do not Copy - All Rights Reserved.
Welcome to MirrorView and SAN Copy Foundations.

Copyright 2010 EMC Corporation. All rights reserved. These materials may not be copied without EMC's written consent. 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. EMC , EMC, EMC ControlCenter, AdvantEdge, AlphaStor, ApplicationXtender, Avamar, Captiva, Catalog Solution, Celerra, Centera, CentraStar, ClaimPack, ClaimsEditor, ClaimsEditor, Professional, CLARalert, CLARiiON, ClientPak, CodeLink, Connectrix, Co-StandbyServer, Dantz, Direct Matrix Architecture, DiskXtender, DiskXtender 2000, Document Sciences, Documentum, EmailXaminer, EmailXtender, EmailXtract, enVision, eRoom, Event Explorer, FLARE, FormWare, HighRoad, InputAccel,InputAccel Express, Invista, ISIS, Max Retriever, Navisphere, NetWorker, nLayers, OpenScale, PixTools, Powerlink, PowerPath, Rainfinity, RepliStor, ResourcePak, Retrospect, RSA, RSA Secured, RSA Security, SecurID, SecurWorld, Smarts, SnapShotServer, SnapView/IP, SRDF, Symmetrix, TimeFinder, VisualSAN, VSAM-Assist, WebXtender, where information lives, xPression, xPresso, Xtender, Xtender Solutions; and EMC OnCourse, EMC Proven, EMC Snap, EMC Storage Administrator, Acartus, Access Logix, ArchiveXtender, Authentic Problems, Automated Resource Manager, AutoStart, AutoSwap, AVALONidm, C-Clip, Celerra Replicator, CLARevent, Codebook Correlation Technology, Common Information Model, CopyCross, CopyPoint, DatabaseXtender, Digital Mailroom, Direct Matrix, EDM, E-Lab, eInput, Enginuity, FarPoint, FirstPass, Fortress, Global File Virtualization, Graphic Visualization, InfoMover, Infoscape, MediaStor, MirrorView, Mozy, MozyEnterprise, MozyHome, MozyPro, NetWin, OnAlert, PowerSnap, QuickScan, RepliCare, SafeLine, SAN Advisor, SAN Copy, SAN Manager, SDMS, SnapImage, SnapSure, SnapView, StorageScope, SupportMate, SymmAPI, SymmEnabler, Symmetrix DMX, UltraFlex, UltraPoint, UltraScale, Viewlets, VisualSRM are trademarks of EMC Corporation. All other trademarks used herein are the property of their respective owners.
MirrorView and SAN Copy Foundations - 1
These are the learning objectives for this course. Please take a moment to read them.
The objectives for this lesson are shown here. Please take a moment to read them.
Provisioning for disaster recovery is the major benefit of MirrorView mirroring. Destruction of the data at the primary site would cripple or ruin many organizations. After a disaster, MirrorView lets data processing operations resume with minimal overhead. MirrorView enables a quick recovery by creating and maintaining a copy of the data on another storage system. The criticality of business applications and information defines the recovery objectives. RPO defines the amount of data loss in the event of a disaster. RTO defines the amount of time required to bring critical business applications back online after a disaster occurs.
MirrorView/S is a storage-based application that resides on the CLARiiON. It provides an online, host independent, mirrored data storage and protection solution that duplicates production site data (primary) to one or two secondary sites (secondary/secondaries) in a campus environment. The mirroring is synchronous, meaning that every time a host writes to the primary array, the secondary array mirrors the write before an acknowledgement is returned to the host. MirrorView ensures that there is an exact byte-for-byte copy at both the local CLARiiON and the remote CLARiiON. Since MirrorView is storage-based software, no host CPU cycles are used. MirrorView operates in the background, transparent to any hosts or applications. MirrorView is fully integrated with EMC SnapView, the CLARiiON-based software that creates consistent point-in-time copies. Those copies allow access to local or remote data. MirrorView is managed from within CLARiiONs Unisphere Management software. Remote replication is supported for both Fibre Channel and iSCSI connections.
MirrorView/A is a storage-based application that resides on the CLARiiON. Unlike MirrorView/S, the mirroring is not synchronous. It provides a host independent protection solution that duplicates changes in production site data (primary) to a secondary site (secondary) at regular intervals (after an initial full synchronization). Because MirrorView/A does not use a synchronous mechanism, it is distance-independent and allows replication over IP networks at extended distances. MirrorView/A ensures that there is a restartable, point-in-time copy of the data at the remote CLARiiON. MirrorView/A is storage-based software, thus uses no host CPU cycles. Host applications are unaffected by the latency of the network that connects the primary to the secondary. MirrorView/A operates in the background, transparent to any hosts or applications. MirrorView/A is fully integrated with EMC SnapView, EMC SAN Copy, and EMC MirrorView. It uses features from all three of the replication applications mentioned. MirrorView/A is managed from within CLARiiONs Unisphere Management software. That means that the same user-friendly Windows-like interface is common among all the CLARiiON software products.
Some MirrorView terms are described here and are used throughout the training. The primary image is the LUN on the production storage system that contains user data and is the source for the data copied to the secondary image. A remote mirror is ineffective for recovery, unless it has a secondary image. The secondary image is a LUN that contains a replica of the primary image LUN data. There can be zero or one secondary image. A secondary image must not be part of a Storage Group.
Mirror synchronization copies data from the primary to the secondary image. Logs can be used to avoid a full data copy.
Mirror Fracture stops the mirroring I/O from the primary image to the secondary mirror image. A fracture can occur either automatically, because of a failure in the path to the secondary images SPs, or manually, by an administrative action, or both.
The three mirror availability states are inactive, active, and attention. These states vary in the ways that they respond to read and write requests from a host. Transitions between the states is either automatic or by administrative control. While a mirror is in any state, normal administrative operations can occur, such as adding or deleting a secondary array. Promote is 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. The image data states are out-of-sync, in-sync, consistent, rolling back, and synchronizing. These states represent the relationships between the primary image and a secondary image.
With the release of FLARE 29, the CX4 MirrorView/A and MirrorView/S limits have increased. The amount that the number of MirrorView objects, consistency groups, and mirrors per consistency groups has increased is model dependent.
The MirrorView software must be loaded on both arrays, regardless of whether the customer wants to implement bi-directional mirroring or not. If only synchronous mirroring is required, only MirrorView/S needs to be active on the local and remote CLARiiON(s). If MirrorView/A is required, then it needs to be activated separately on both the local and remote CLARiiON. The secondary LUN must be the same size, though not necessarily the same RAID type or disk type, as the primary LUN.
The Host cannot attach to an active secondary LUN as long as it is configured as a secondary mirror image. You can promote the secondary mirror image to be the primary mirror image, or you can remove the secondary LUN as a secondary copy. Once this is done, a full resynchronization to any new secondary LUN has to be performed.
An alternative method of accessing data from a secondary LUN is to make a snapshot or clone of the LUN, and assign that to a host.
MirrorView (MV) operates over discrete paths between SPs of the primary system and secondary system. A path must exist between MirrorView ports of SP A on the primary and SP A of the secondary system. The same relationship must exist for SP B. MirrorView operates over one predetermined Fibre Channel and/or iSCSI port per SP. The port used by MV is model dependent and configuration dependent. Host attach protocols are unrelated to the protocol used by MirrorView, therefore either FC or iSCSI can be used with it. Ports used by MirrorView can be shared with server traffic, however, this may impact the performance of MirrorView and vice versa. SAN Copy ports cannot share MirrorView ports, so SAN Copy ports should be configured on any other front-end port not used by MirrorView. Although connections should exist between SP A MirrorView ports and SP B MirrorView ports, they should not cross connect. EMC recommends placing MirrorView ports for SP A and SP B in separate zones.
Synchronization is a copy operation MirrorView performs to copy the contents of the primary image to the secondary image. This is needed to establish newly created mirrors or to reestablish 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, this initial synchronization is required.
Primary images remain online during the sync process and until the synchronization is complete, the secondary image is unusable.
Synchronization rates are user selectable (medium is the default) and set a relative priority for completing updates.
A secondary image is promoted to the role of primary when it is necessary to run production applications at the disaster recovery site. This can only occur if the secondary image is in the consistent or synchronized state. When the promote occurs, the secondary image is placed in a new mirror as the primary image. This 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 still exists between the primary and secondary images.
A fracture stops MirrorView replication from the primary image to the secondary mirror image. Administrative fractures are initiated by the user typically to suspend replication, as opposed to a system fracture which is initiated by the MirrorView software when there is a communications failure between the primary and secondary systems. With MirrorView/S, writes continue to the primary image but are not replicated to the secondary. Replication can resume when the user issues a synchronize command.
With MirrorView/A, the current updates stop, 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.
The fracture log is a bitmap held in the memory of the storage processor that owns the primary image. The log indicates which physical areas of the primary have been updated since communication was interrupted with the secondary. The fracture log is automatically invoked when communication with the secondary image of a mirror is lost for any reason and the mirror becomes fractured. The fracture could be initiated by the administrator or system. The fracture log tracks changes on the primary image for as long as the secondary image is unreachable. When the secondary LUN returns to service, the secondary image must be synchronized with the primary. This is done by reading those areas of the primary addressed by the fracture log and writing them to the secondary image. This occurs in parallel with any writes coming into the primary and mirrored to the secondary.
A record of recent changes to the primary image is stored in persistent memory on a private LUN reserved for the mirroring software. If the primary storage system fails (not catastrophically), the optional write intent log can be used to quickly synchronize the secondary image(s) when the primary storage system becomes available. This eliminates the need for full synchronization of the secondary images, which can be a lengthy process on very large LUNs. The write intent log keeps track of writes that have not yet been made to the remote image for the mirror. It allows for fast recovery when the primary storage system fails. When the primary fails and is recovered, the write intent log is used to synchronize the data on the remote image. Otherwise, a full resynchronization would be required for the remote image.
CLARiiON Synchronous Mirroring occurs as follows: Data is sent from the production host to the source LUN (primary LUN) in the primary array. The data is loaded into cache or written to target disk if cache is not enabled. A copy of the hosts write data is sent to the Mirror LUN (secondary LUN) in the secondary array and either loaded into cache or written to target disk, if cache is disabled. Acknowledgement of write completion is sent from the secondary array to the primary array. Acknowledgement of write completion is sent from the primary array to the production host. Connected SPs must be the same designation: SP A to SP A, SP B to SP B. A single connection is supported. SPs use the CMI protocol over the link when communicating.
CLARiiON Synchronous Mirroring during fracture occurs as follows: Data is sent from the production host to the source LUN (primary LUN) in the primary array. The data is loaded into cache or written to target disk if cache is not enabled. If the secondary array cannot be reached, it is marked as fractured. The fracture log and, optionally, the write intent log, are updated with information about the changed data areas on the source LUN. Acknowledgement of write completion is sent from the primary array to the production host.
MirrorView/A uses SnapView technology for data protection on the primary and secondary systems. On the primary image, SnapView tracks changes and creates a point-in-time image that is the source for the data updates. On the secondary system, SnapView creates a protective copy of the secondary image during the update. This image or gold copy ensures that there is a usable copy on the secondary at all times. MirrorViews use of SnapView is autonomous and requires no user management by the user. Therefore, a SnapView license is not required to use MirrorView.
Utilizing MirrorViews bi-directional capability, any CLARiiON can be engaged in up to four relationships with other systems. This means you can have each system be both a source and a target. Relationships can be with different models of CLARiiONs. In this example, there are still four main locations and one remote location; however, instead of one failover location, you can have multiple locations protecting various data, depending on your business requirements. This also applies to MirrorView/A.
MirrorView can also be used to consolidate or fan-in information on one remote CLARiiON for purposes of consolidated backups, simplified failover, or consolidated remote processing activities. You can mirror up to four source CLARiiONs to a single CLARiiON target system. The source systems and target systems can be in any location you desire. The 4:1 ratio is also applicable to both MirrorView/S and MirrorView/A.
The example shows MirrorView/S concurrent mirroring or fan-out functionality. This enables the administrator to synchronously mirror one primary image to two different secondary images or in the case of MV/A, one primary image to a single secondary image. The secondary images are managed independently but must reside on separate CLARiiON storage systems. No secondary image can reside on the same storage system as a primary image of the same mirror.
MirrorView and SnapView for the CLARiiON storage system are tightly integrated. SnapView is licensed separately from MirrorView and supports both pointer based snapshots as well as full binary copies called clones. When used with MirrorView, snapshots and clones provide local replicas of primary and/or secondary images. They allow for secondary access to data at either the primary location, secondary location, or both, without the production data being offline.
Continuing with EMCs centralized management approach, MirrorView can be managed by Unisphere or Secure CLI software. Unisphere also includes a MirrorView Wizard to guide the user through the configuration. MV/S and MV/A have separate enabler packages that must be installed. Provided the enabler packages are installed, all relevant menus and dialogs become available to the user.
Consistency Groups allow all LUNs belonging to a given application, usually a database, to be treated as a single entity and managed as a whole. This helps to ensure that the remote images are consistent, i.e., all made at the same point in time. As a result, the remote images are always restartable copies of the local images, though they may contain data which is not as new as that on the primary images. It is a requirement that all the local images of a Consistency Group be on the same CLARiiON, and that all the remote images for a Consistency Group be on the same remote CLARiiON. All information related to the Consistency Group is sent to the remote CLARiiON from the local CLARiiON. The operations which can be performed on a Consistency Group match those which may be performed on a single mirror, and affect all mirrors in the Consistency Group. If, for some reason, an operation cannot be performed on one or more mirrors in the Consistency Group, then that operation fails and the images remain unchanged. Consistency Groups are supported for both MirrorView/A and MirrorView/S. See the latest CLARiiON Pocket Reference Guide for up-to-date min/max allowed.
This slide and the slide that follows describe the operations that may be performed on Consistency Groups. The Create operation creates a Consistency Group and allows it to be named. It does not add any group members. This operation is similar to the creation of a remote mirror in MirrorView/S. The Destroy operation destroys a Consistency Group if it has no members. It is similar to the MirrorView/S destroy a remote mirror operation.
The Remove operation removes a member image from the group. After the removal, the primary and secondary CLARiiONs will both be aware of the removal, and no longer require that the removed LUN participate in Consistency Group operations.
Fracturing a Consistency Group has the same effect as fracturing all the mirrors in the group simultaneously; all updates to the secondary images stop and no further updates are permitted. Because host access to the secondary image is not allowed at this stage, there is no danger of inconsistent data being presented to a host. The Synchronization operation synchronizes all members of the group. It can do so only if the group is administratively fractured (a system fractured group synchronizes automatically), or the Manual Update option has been chosen and the group is consistent, meaning that one or more mirrors have data to transfer. Finally, the Promote operation promotes all mirrors in the group. All secondary images are promoted to primaries, and, if the primaries are manageable, they are demoted to secondaries. If a promotion results in the need for the new secondaries to be fully synchronized, MirrorView/A requests confirmation, then issues a forced promote. If the group is neither in-sync nor consistent, then the data state cannot be guaranteed and promotion is a meaningless option.
With the release of Flare R29+, primary and secondary images can now be created on Thin LUNs. Once Flare 29+ is installed and committed, all combinations of Thin and R29+ Traditional LUNs are allowed. However, Thin LUNs and pre-29 LUNs cannot be in a mirror relationship because pre-29 LUNs cannot understand the unallocated areas of the Thin LUNs. Pre-29 traditional LUNs become R29+ traditional LUNs once Flare 29+ is committed.
Traditional LUNs refer to ordinary LUNs and metaLUNs. These tables show the valid LUN combinations for MirrorView/S and MirrorView/A. Please take a moment to review them.
When adding a secondary Thin LUN or synchronizing existing mirrors, make sure that the Thin Pool has enough capacity for the synchronization to complete. If there is not enough space to write new data, a Media Failure administrative fracture will occur. MirrorView/S checks the space available to the secondary before adding a secondary image to a mirror and before starting a synchronization on an existing mirror. This may help prevent a Media Failure fracture but space can still be exhausted due to new mirrored writes while syncing.
MirrorView/A does not have any checks for the Thin Pool space. If there is not enough space, it will be treated like a failed write and an administrative fracture will occur.
The objectives for this lesson are shown here. Please take a moment to read them.
EMC CLARiiON SAN Copy is the application solution for business applications. SAN Copy is useful for: Data migration Easily migrate from qualified storage systems to CLARiiON CX Series Data mobility Rapid recovery of data when you need it Eliminates impact on production activities Content distribution Daily consolidation of inventory data or pricing data to remote location Disaster Recovery Creation of point-in-time copies of local production data
SAN copy provides many benefits over host-based replication options. Performance is optimal because data is moved directly across the SAN. No host software has to be installed because SAN Copy executes on a CLARiiON storage system. This allows customers more flexibility in their operating system environments.
SAN Copy mobilizes business, removing the physical barriers to faster, better business decisions. In a traditional, retail environment, daily sales and inventory data is collected and sent back to the corporate data center to populate data warehouses and data marts. SAN Copy copies or moves that data utilizing the SAN and/or WAN infrastructure, increasing operational efficiencies while reducing costs and risk associated with data movement. SAN Copy can stop costly data errors and reduce backup costs by cost effectively mobilizing data to be managed centrally.
SAN Copy software runs on a SAN Copy storage system. SAN Copy copies data at a block level between CLARiiON storage systems, within CLARiiON storage systems, between CLARiiON and Symmetrix storage systems, or between qualified non-EMC storage systems. SAN Copy software copies data directly from a logical unit on one storage system to destination logical units on another, without using host resources. SAN Copy software can perform multiple copieseach in its own copy sessionsimultaneously. The RAID type of the logical units participating in a copy session does not matter; that is, the source and destination logical units can be any RAID type. SAN Copy sessions can be configured to run over Fibre Channel or iSCSI. You can use SAN Copy software to create full copies and incremental copies of a source logical unit.
SAN Copy basic terminology is presented here. The terms are used throughout the presentation to help you better understand how SAN Copy operates.
This slide presents additional SAN Copy terminology. The terms are used throughout the presentation to help you better understand how SAN Copy operates.
Customers can use SAN Copy to simultaneously move information, regardless of the host operating system or application. This is valuable for content distribution, moving applications, or supporting application data to distributed environments to aid in performance. It acts as the facilitator of data movement from system to system over the SAN or LAN/WAN infrastructure, eliminating the need for critical server CPU cycles and LAN bandwidth.
Before SAN Copy sessions can be created, the enabler must be installed on the CLARiiON. All connections must be established between storage systems that are participating in the session. A zone containing a host HBA port may also contain one and only one SAN Copy port. SAN Copy initiators must be added to a storage group. You can assign initiator ports to storage groups on the destination storage system. Multiple ports can be assigned to the same storage group.
SAN Copy uses SnapView to create a snapshot of the source LUN, and actually reads from the snapshot during the update, so there is a consistent point-in-time view of the data being transferred. When an incremental session is created, a reserved SnapView snapshot and SnapView session are created as well. These reserved objects are visible through Unisphere or CLI, but cannot be managed by a user. When the SAN Copy session is destroyed, the reserved objects are destroyed as well.
A Full SAN Copy session copies the entire contents to the destination LUN. In order to create a consistent copy, Writes must be quiesced on the source LUN for the duration of the session. If a full session is created from a snapshot or a clone LUN, the source LUN can be active during the transfer. Incremental SAN Copy (ISC) allows the transfer of changed data only from source to destination. ISC copies all changes made until a user-defined point in time, and uses SnapView snapshot technology as required to keep track of where those changes are. The source LUN is available to the host at all times.
Several parameters can be set for SAN Copy sessions to improve overall performance. Use the defaults unless specifically directed to do otherwise. The number of Concurrent sessions is the number of full and incremental sessions that can transfer data at the same time on that SP. Any additional sessions are queued for transfer. Checkpoint interval records the progress of a full session during the update by storing a pointer referencing the number of the last block successfully copied from the source to the destination.
Buffer settings define the amount of memory SAN Copy allocates to queue outgoing writes. Leave these at the defaults since SAN Copy automatically determines the correct number to use.
This slide shows SAN Copy management options for the creation, execution, and administration of SAN Copy objects. SAN Copy requires an enabler to be installed on the array. Unisphere includes a wizard for configuring SAN Copy objects. If multiple SAN Copy sessions are created, the sessions may span multiple domains.
SAN Copy supports Thin LUNs with Flare release R29 and greater. After the software has been committed, both the source and destination LUNs can be Thin LUNs. However, there is an exception to the case and that is with Pull copies. When the source is on the remote array, the Copy cannot be provisioned as Thin. It can only be provisioned as a traditional copy.
SAN Copy cannot use any SP port configured as a MirrorView port. Ports may be configured as MirrorView ports even if MirrorView is not licensed. SAN Copy can be used to make copies of MV mirror images. This feature allows for the creation of full binary copies of mirrors and pointer-based snapshots possible with SnapView. SnapView allows for several configurations: Maintains a local replica of a source LUN with a SnapView snapshot or clone while maintaining a remote replica of the same LUN on another storage system with SAN Copy Maintains a local replica of a source LUN with a SnapView clone while using the clone as a source for a SAN Copy session
EMC SAN Copy/E software runs on a SAN Copy/E storage system. The CLARiiON storage system that owns the copy session SAN Copy/E copies data from CX300 and AX Series storage systems to CX Series storage systems running SAN Copy. It copies data directly from a source logical unit on one storage system to destination logical units on other systems, without using host resources. It connects directly or through a SAN, and supports protocols that let you use the IP WAN to send data over extended distances. SAN Copy/E can perform multiple copies, each in its own copy session, simultaneously. The RAID type of the logical units participating in a copy session does not have to be the same; that is, the source and destination logical units can be different RAID types.
These are the key points covered in this training. Please take a moment to review them. This concludes the training. Please proceed to the Course Completion slide to take the assessment.

Mirror View SAN Copy Foundations - Student Resource Guide - r30

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Mirror View SAN Copy Foundations - Student Resource Guide - r30

Uploaded by

Copyright:

Available Formats

Copyright 2010 EMC Corporation. Do not Copy - All Rights Reserved.

Welcome to MirrorView and SAN Copy Foundations.

MirrorView and SAN Copy Foundations - 1

Copyright 2010 EMC Corporation. Do not Copy - All Rights Reserved.

MirrorView and SAN Copy Foundations - 2

Copyright 2010 EMC Corporation. Do not Copy - All Rights Reserved.

MirrorView and SAN Copy Foundations - 3

Copyright 2010 EMC Corporation. Do not Copy - All Rights Reserved.

MirrorView and SAN Copy Foundations - 4

Copyright 2010 EMC Corporation. Do not Copy - All Rights Reserved.

MirrorView and SAN Copy Foundations - 5

Copyright 2010 EMC Corporation. Do not Copy - All Rights Reserved.

MirrorView and SAN Copy Foundations - 6

Copyright 2010 EMC Corporation. Do not Copy - All Rights Reserved.

MirrorView and SAN Copy Foundations - 7

Copyright 2010 EMC Corporation. Do not Copy - All Rights Reserved.

MirrorView and SAN Copy Foundations - 8

Copyright 2010 EMC Corporation. Do not Copy - All Rights Reserved.

MirrorView and SAN Copy Foundations - 9

Copyright 2010 EMC Corporation. Do not Copy - All Rights Reserved.

MirrorView and SAN Copy Foundations - 10

Copyright 2010 EMC Corporation. Do not Copy - All Rights Reserved.

MirrorView and SAN Copy Foundations - 11

Copyright 2010 EMC Corporation. Do not Copy - All Rights Reserved.

MirrorView and SAN Copy Foundations - 12

Copyright 2010 EMC Corporation. Do not Copy - All Rights Reserved.

MirrorView and SAN Copy Foundations - 13

Copyright 2010 EMC Corporation. Do not Copy - All Rights Reserved.

MirrorView and SAN Copy Foundations - 14

Copyright 2010 EMC Corporation. Do not Copy - All Rights Reserved.

MirrorView and SAN Copy Foundations - 15

Copyright 2010 EMC Corporation. Do not Copy - All Rights Reserved.

MirrorView and SAN Copy Foundations - 16

Copyright 2010 EMC Corporation. Do not Copy - All Rights Reserved.

MirrorView and SAN Copy Foundations - 17

Copyright 2010 EMC Corporation. Do not Copy - All Rights Reserved.

MirrorView and SAN Copy Foundations - 18

Copyright 2010 EMC Corporation. Do not Copy - All Rights Reserved.

MirrorView and SAN Copy Foundations - 19

Copyright 2010 EMC Corporation. Do not Copy - All Rights Reserved.

MirrorView and SAN Copy Foundations - 20

Copyright 2010 EMC Corporation. Do not Copy - All Rights Reserved.

MirrorView and SAN Copy Foundations - 21

Copyright 2010 EMC Corporation. Do not Copy - All Rights Reserved.

MirrorView and SAN Copy Foundations - 22

Copyright 2010 EMC Corporation. Do not Copy - All Rights Reserved.

MirrorView and SAN Copy Foundations - 23

Copyright 2010 EMC Corporation. Do not Copy - All Rights Reserved.

MirrorView and SAN Copy Foundations - 24

Copyright 2010 EMC Corporation. Do not Copy - All Rights Reserved.

MirrorView and SAN Copy Foundations - 25

Copyright 2010 EMC Corporation. Do not Copy - All Rights Reserved.

MirrorView and SAN Copy Foundations - 26

Copyright 2010 EMC Corporation. Do not Copy - All Rights Reserved.

MirrorView and SAN Copy Foundations - 27

Copyright 2010 EMC Corporation. Do not Copy - All Rights Reserved.

MirrorView and SAN Copy Foundations - 28

Copyright 2010 EMC Corporation. Do not Copy - All Rights Reserved.

MirrorView and SAN Copy Foundations - 29

Copyright 2010 EMC Corporation. Do not Copy - All Rights Reserved.

MirrorView and SAN Copy Foundations - 30

Copyright 2010 EMC Corporation. Do not Copy - All Rights Reserved.