Mirror View SAN Copy Foundations_Student Resource Guide_r30

MirrorView and SAN Copy Foundations - 1

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.



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 CLARiiON‘s 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 CLARiiON‘s 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 image‘s 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 image‘s 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 host‘s 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.

MirrorView‘s use of SnapView is autonomous and requires no user management by the user.

Therefore, a SnapView license is not required to use MirrorView.



Utilizing MirrorView‘s 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 EMC‘s 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

copies—each in its own copy session—simultaneously. 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

Documents