Mirro View and SAN Copy Foundations 2009 - r29

Copyright © 2009 EMC Corporation. Do not Copy - All Rights Reserved.

MirrorView and SAN Copy Foundations - 1

© 2009 EMC Corporation. All rights reserved.

MirrorView and SAN Copy FoundationsMirrorView and SAN Copy Foundations

Welcome to MirrorView and SAN Copy Foundations.

Copyright © 2009 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.



© 2009 EMC Corporation. All rights reserved. MirrorView and SAN Copy Foundations - 2

Course Objectives

Upon completion of this course, you will be able to:

Identify remote replication product uses

Identify the terminology associated with remote replication software

Identify remote replication functions and operations

Identify the management options for remote replication software

Identify a business case for remote replication products

These are the learning objectives for this course. Please take a moment to read them.




Lesson 1: MirrorView

Upon completion of this lesson, you will be able to:

Define MirrorView terminology

Describe MirrorView operations

Describe MirrorView Consistency Group operations

The objectives for this lesson are shown here. Please take a moment to read them.




MirrorView – Your Business Solution

Disaster Recovery (DR) solutions– Provides end-to-end protection of data– MirrorView/S and MirrorView/A

Protects critical business information

Helps meet service level agreements– Recovery point objectives (RPO)– Recovery time objectives (RTO)

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.




EMC MirrorView/S – What is It?

Synchronous remote mirroring between two CLARiiONs

Independent of server, operating system, network, applications, and database

Centralized, simplified management via EMC Navisphere

Concurrent information access when used with SnapView

Fibre Channel or iSCSI replication

MirrorView

Production A

Production B

Mirror A

Mirror B

Local or remote bidirectional mirroring

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 Navisphere Management software. Remote replication is supported for both Fibre Channel and iSCSI connections.




EMC MirrorView/A – What is It?

Incremental remote mirroring between two CLARiiONs

Independent of server, operating system, network, applications, and database

Centralized, simplified management via EMC Navisphere

Concurrent information access when used with SnapView

MirrorView/A

Production A

Production B

Mirror A

Mirror B

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 Navisphere Management software. That means that the same user-friendly Windows-like interface is common among all the CLARiiON software products.




MirrorView Terminology

Primary Image (primary)– LUN containing production data whose contents will be replicated

Secondary Image (secondary)– LUN that contains a replica of the primary LUN data

Mirror Synchronization– Mechanism to copy data from the primary LUN to a secondary LUN– Mechanism may use fracture log/write intent log to avoid full data

copy

Mirror Fracture– Condition when a secondary is unreachable by the primary– Can be invoked by administrative command

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.




MirrorView Terminology (Cont)Mirror Availability States– Inactive – admin control to stop mirror processing– Active – I/O allowed (normal state)– Attention – admin action required

Mirror Promote– Changes an image’s role

Mirror Data States– Out of sync – full sync needed– In sync (synchronized) – primary LUN and secondary LUN contain identical

data– Rolling back – primary LUN is returned to state at a previously defined point

in time– Consistent – write intent log, or fracture log, may be needed– Synchronizing – mirror sync operation in progress

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.




MirrorView Replication Limits

R29R28R29R28R29R28R29R28

CX4‐960CX4‐480CX4‐240CX4‐120

6432643232163216MV/S Mirrors per Consistency Group

MirrorView/S

64166416328328MV/A Mirrors per Consistency Group

6450645064506450MV/A Consistency Groups

256100256100256100256100MirrorView/A Objects

MirrorView/A

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.




MirrorView Configuration

MirrorView software must be loaded on both Primary and Secondary arrays

Secondary LUN must be the same size as Primary LUN

Secondary LUN need not be the same RAID type as Primary

Secondary LUN not accessible to host(s)

Bi-directional mirroring fully supported

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 Ports

Uses discrete paths between SPs

Operates over one predetermined FC and/or iSCSi port per SP

Model dependent

Host protocol is unrelated to MirrorView protocol

Ports can share traffic with server– Cannot share with SAN Copy

No cross connected ports

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.




MirrorView Common Operations – Synchronization

Copies the contents of the primary image to the secondary image

Initial sync required for new mirrors

Primary images remain online during sync

Secondary image is not usable– Must complete synchronization process first

Synchronization rate– Mirror property value that sets a priority for completing updates

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.




MirrorView Common Operations – Promote

Secondary image can be promoted to primary– Must be in a consistent or synchronized state

Secondary image is placed in a new mirror as a primary image– New mirror has the same mirror name– New mirror has a different mirror ID

Existing mirror is maintained or destroyed– Depends on the failure– Maintained if in-band communication still available between the

primary and secondary images

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.




MirrorView Common Operations – Fracture

Stops replication from the primary image to the secondary mirror image

Administrative– Initiated by the user

System– Initiated by the MirrorView software

MirrorView/S– Writes continue to the primary, not replicated to secondary

MirrorView/A– Current updates stop, no further updates start

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.




MirrorView/Synchronous – Fracture Log

Memory resident bitmap– Resides on the SP that owns the primary image– Indicates which physical areas (extents) on the primary have been

updated since communication was interrupted with the secondary

Automatically invoked when– Secondary image of a mirror is unreachable and becomes fractured– Fracture can be initiated by either the Administrator or system

Tracks the changes on the primary image– As long as the secondary is unreachable

Helps the secondary image synchronize with the primary– Reads the areas in the fracture log and writes them to the secondary

image

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.




MirrorView/Synchronous – Write Intent Log (WIL)

Record stored in persistent memory– Located on the storage system on which the primary LUN resides

Two LUNs– LUNs are 128 MB, one for each SP– Each LUN services all mirrors owned by that SP that have the WIL

option selected

Tracks write to both primary and secondary images

MV makes an entry of its intent to update the primary image at a particular location

Used to determine which regions must be synchronized

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.




I/O write received from host into write cache of primary array

I/O is transmitted to the write cache of the secondary array

Acknowledgment is sent by secondary array back to primary

Write Acknowledgement is presented to host

Primary Secondary

Synchronous Mirroring – Operation

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.




Primary Secondary

I/O write received from host into write cache of primary array

If secondary array is not reachable, mirror marked as fractured

Acknowledgment is sent by primary array back to production host

Protection of Mirrored Data during a Fracture

Log

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/Asynchronous – Data Protection

Use SnapView Technology– Creates point-in-time image that is the source for transfers

Creates a protective copy of the secondary image during updates– Referred to as a gold copy– Ensures a useable copy on the secondary at all times

No license required to use SnapView– MirrorView use of SnapView requires no user management

therefore, requires no additional license

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.




MirrorView Relationships One CLARiiON can be both a source and a target to other systems

Up to four relationships per CLARiiON

Enables bi-directional remote mirroring for maximum protection of all information

Source AND Remote

Target System

TargetLocation

A

Source A

Target B

SourceLocation

B Target Location

C

Source C

SourceLocation

D

Target D

Target A

Source B

Target C

Source D

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 Fan-in ConsolidationOne CLARiiON can be a target for up to four other systems

Consolidate multiple business locations to one disaster recovery/business continuity site

Centralized processing efficiencies

Remote Location

4:1 Fan-inratio

Location A

Target A

Target B

Location B

Location C

Target C

Location D

Target D

Source A

Source B

Source C

Source D

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.




MirrorView Fan-out MirroringMV/S – One primary mirroring to two secondary images

MV/A – One primary mirroring to one secondary image

Secondary images are managed independently

Secondary images must reside on separate CLARiiONs

Source

Source

Backup

SourceLocation

A

TargetLocation

BTarget

Target

TargetLocation

CTarget

Target

Snapshot

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 SnapViewProduction site is fully protected by remote mirror

Provide local replicas

Allow for distributed workgroup activities across locations

Production Host(Site A)

Secondary Host (Site B)

PrimaryCLARiiON

Primary

RemoteCLARiiON

Secondary

Snapshot

Report Generation

Decision Support Tools

Tape Backup

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.




MirrorView Management

Centralized and simplified management

Managed through Navisphere Manager or Secure CLI

Navisphere Wizard for easy configuration

Requires enabler packages

Remote management capabilities

Continuing with EMC’s centralized management approach, MirrorView can be managed by Navisphere Management or Navisphere Secure CLI software. Navisphere Manager 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.




MirrorView Consistency Groups

Group of secondary images treated as a unit

Available for both MirrorView/A and MirrorView/S

Local LUNs must be on the same CLARiiON

Remote LUNs must be on the same CLARiiON

Operations happen on all LUNs

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.




MirrorView Consistency Group Operations

Create a Consistency Group– Defines the group– Does not add group members

Destroy a Consistency Group– Allowed only if it has no members

Add a member to a group– Adds MV/A or MV/S secondary image to a group– Creates the group, if this is the first image added

Remove a member from a group– Removes MV/A secondary image from a group

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.




MirrorView Consistency Group Operations (Cont)

Fracture a Consistency Group– Administratively fractures all mirrors in the group– Stops updates to secondary images

Synchronize a Consistency Group– Synchronizes all mirrors in the group– Group must be administratively fractured, OR– Group must be consistent and set to Manual Update

Promote a Consistency Group– Promote all mirrors in the group– Command must be directed at the secondary CLARiiON– Group must be in-sync or consistent

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.




MirrorView Thin LUNs

With R29, primary and secondary images can be created on Thin LUNs– R29 software bundle needs to be committed

All combinations of Thin and R29 Traditional LUNs are allowed – R29 software bundle needs to be committed

Thin LUNs and pre-R29 LUNs are NOT allowed to co-exist in any mirror relationship– Pre-R29 LUNs cannot understand unallocated areas (holes) of the

Thin LUNs – Once the R29 software package is committed, all pre-R29

Traditional LUNs become R29 Traditional LUNs

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.




MirrorView Valid Thin LUN Combinations“Traditional” refers to ordinary LUNs and metaLUNsMirrorView/S valid LUN type combinations

MirrorView/A valid LUN type combinations

Navisphere will enforce these combinations

Traditional (R29 or Pre-R29)Pre-R29 Traditional4Traditional (R29 or Pre-R29)R29 Traditional3R29 Thin or R29 TraditionalR29 Traditional2R29 Thin or R29 TraditionalThin1SecondaryPrimaryScenario

Traditional (R29 or Pre-R29)

Traditional (R29 or Pre-R29)Pre-R29 Traditional4

Traditional (R29 or Pre-R29)

Traditional (R29 or Pre-R29)R29 Traditional3

R29 Thin or R29 Traditional

R29 Thin or R29 TraditionalR29 Traditional2

R29 Thin or R29 Traditional

R29 Thin or R29 TraditionalThin1Secondary 2Secondary 1PrimaryScenario

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.




MirrorView Thin LUN ChecksWhen adding a secondary Thin LUN or synchronizing existing mirrors, ensure that the Thin Pool has enough capacity for the synchronization to complete– If no space exists to write new data, a “Media Failure” administrative

Fracture will occur

MV/S has checks added to consider the pool space available to the secondary– Before adding a secondary image to a mirror – Before starting a synchronization on an existing mirror

MV/S checks are not a guarantee that the synchronization will complete– Space can still be exhausted due to new mirrored writes while

syncing

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 Thin LUN Checks (Cont)

MV/A does NOT have any checks to consider the Thin Pool space– A failed update due to out of space conditions will be treated like a

failed write on the secondary causing an admin fracture to the mirror

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.




Lesson 2: SAN Copy

Upon completion of this lesson, you will be able to:

Define SAN Copy terminology

Describe SAN Copy configurations

Describe SAN Copy management

The objectives for this lesson are shown here. Please take a moment to read them.




SAN Copy – Business Uses

Data migration

Data mobility

Content distribution

Disaster recovery

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 SeriesData 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 locationDisaster Recovery – Creation of point-in-time copies of local production data




SAN Copy – Benefits

Performance– Replicated data moves across the SAN only once– Processing takes place at the storage system

No host software– Requires no involvement by the host OS– Transfers are independent of Host operations and file system types

Interoperability– Supports connections to many non-CLARiiON storage systems

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 – A Business CaseEnable better business decisions– Pull data from remote locations to

data center – Gather daily sales records and

inventory updates

Stop costly data errors– Push data to distributed

locations– Applications, daily pricing

updates, and inventory updates

Reduce operational costs– Centralize data for easier

management

Atlanta

Boston

NYC

Data

Data

Data

Data

LA

Corporate Data Center

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 – What is It?

CLARiiON storage-based application

Full or incremental options

Copies data at a block level across the SAN

Writes data from single source to multiple destinations

Reads from single source, writes to single destination

Transfers to/from CLARiiON, Symmetrix, or third-party arrays

Independent of RAID type and disk type

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 – Terminology

LUN– CLARiiON logical unit

Source LUN– The LUN to be replicated

Destination LUN– The LUN where the data will be replicated

SAN Copy session– Persistent definition consisting of a source and destination

LUN/LUNs

SAN Copy storage system– System on which SAN Copy is licensed

SAN Copy basic terminology is presented here. The terms are used throughout the presentation to help you better understand how SAN Copy operates.




SAN Copy – Terminology (Cont)SAN Copy port– CLARiiON storage processor port/s used by SAN Copy

Quiesce– Halt all I/O on a LUN

Block level copy– Reads and writes at the block level (whole LUN)

Push– SAN Copy storage system reads data from one of its LUNs, writes

data to destination LUN(s)

Pull – SAN Copy system reads from a source LUN, writes data to one of its

LUNs

This slide presents additional SAN Copy terminology. The terms are used throughout the presentation to help you better understand how SAN Copy operates.




SAN Copy Topology Example

DataData

SANSAN

CLARiiON

FC4700

SYMMETRIX

LAN

ManagementStations

(Navisphere)

CopyManager

Data

Data

Data

Data

Data

HOSTAGENT

Object Copiedis LUN/Volume

DataData

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.




SAN Copy Configuration

Enabler must be installed

Physical connections must be established between storage systems– FC, iSCSI, or both

Zoning (FC) or connection set (iSCSI) is correct– Each SAN Copy port participating in a session must be zoned to one

or more ports of each SP that participates in the session– Recommended one port per SP

Logical connections must be established between storage systems– SAN Copy initiators must be added to a storage group– Multiple SAN Copy ports can be assigned to the same storage group

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.




Incremental SAN Copy and SnapView

SAN Copy uses SnapView technology– SnapView technology is used to create snapshots of the source LUN– Reads from the snapshot during updates– Creates a consistent point-in-time view of the data

When an incremental session is created– Reserved snapshot and session are created – Visible through Navisphere– Not manageable by the user

Reserved LUN pool– Uses RLP resources– Must be configured before starting a session

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 Navisphere Manager or CLI, but cannot be managed by a user. When the SAN Copy session is destroyed, the reserved objects are destroyed as well.




SAN Copy Full and Incremental Sessions

Full SAN Copy session copies the entire contents of the source LUN to the destination LUN– Writes must be quiesced on the source LUN during the session– Can use a snapshot or clone to allow source LUN to be active

Incremental SAN Copy (ISC) copies only changed data to the destination LUN– I/O can resume once the ISC session is stated– Source is available to the host at all times– Uses SnapView technology to track changes

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.




SAN Copy Sessions – Global Settings

Use the default settings

Concurrent sessions– Number of full or incremental sessions that can transfer data at one

time– Additional sessions are queued

Checkpoint Interval– Records the progress of a full session during updates

Buffers per session and size– Amount of memory SAN Copy allocates to queue outgoing writes

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.




SAN Copy – Management

Navisphere Secure CLI– SAN Copy can use Secure CLI to manage full and incremental SAN

Copy sessions

Navisphere Manager– Enabler must be installed, allowing the user to create, execute, and

control SAN Copy sessions– Includes a wizard

Management with Replication Manager– Simplifies management of SAN Copy for Exchange and SQL servers

Management domains– SAN Copy sessions can span Navisphere domains

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. The Navisphere Manager includes a wizard for configuring SAN Copy objects. If multiple SAN Copy sessions are created, the sessions may span multiple domains.




SAN Copy – Thin LUNsSAN Copy now supports Thin LUNs with R29– R29 software bundle needs to be committed– Navisphere will provide warnings

Where does Thin Replication apply– Where both the source and destinations are Thin– Exception case: Pull copies

Where the source is on the remote array, the Copy will not be provisioned as ThinSAN Copy can only perform a traditional copy when the source is located on a remote system

The following operations will result in a fully provisioned Thin LUN– Creating a copy session with Traditional source and a Thin destination– Creating PULL copy session– Creating a copy session with Thin destination on pre-R29 array

SAN Copy now supports Thin LUNs with Flare release R29. 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 Interoperability with Replication Software

Allows for both local and remote replicas of the same LUN

MirrorView– Cannot use a MirrorView port for SAN Copy– Can be used to make replicas of MV images

SnapView– Can use SnapView replicas as a source LUN– Can operate on the same source and destination LUNs

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 CopyMaintains a local replica of a source LUN with a SnapView clone while using the clone as a source for a SAN Copy session




SAN Copy Ext (SANCopy/E) Overview

Objective– Extend core-to-edge replication options– Includes WAN implementations

Provides incremental copy from CX300/AX100 array to larger CX arrays running full SAN Copy– Allows bi-directional data replication between CX300/AX100 array

and larger CX arrays running full SAN Copy– Larger CX = CX400 > CX700

Replication Options– Source or destination on SAN Copy Ext array (CX300/AX100)– Incremental replication supported

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.




Course Summary

Key points covered in this course:

Remote replication product uses

Terminology associated with remote replication software

Remote replication functions and operations

Management options for remote replication software

A business case for remote replication products

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.

Documents

Mirro View and SAN Copy Foundations 2009 - r29