Mirro View and SAN Copy Foundations 2009 - r29

Copyright 2009 EMC Corporation. Do not Copy - All Rights Reserved.
MirrorView and SAN Copy Foundations
2009 EMC Corporation. All rights reserved.
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, CoStandbyServer, 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
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
2009 EMC Corporation. All rights reserved. MirrorView and SAN Copy Foundations - 5
Local or remote bidirectional mirroring
Production A
Mirror A
Mirror B
MirrorView Production B
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 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
Production A
Mirror A
Mirror B
MirrorView/A
Production 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 CLARiiONs 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 images 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 images 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 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.
MirrorView Replication Limits

CX4120
R28 R29
CX4240
R28 R29
CX4480
R28 R29
CX4960
R28 R29
MirrorView/A MirrorView/AObjects MV/AConsistencyGroups MV/AMirrorsper ConsistencyGroup MirrorView/S MV/SMirrorsperConsistency Group 16 32 16 32 32 64 32 64 100 50 8 256 64 32 100 256 100 50 8 64 32 50 16 256 100 256 64 64 50 16 64 64
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.
Synchronous Mirroring Operation
Primary
Secondary
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
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.
Protection of Mirrored Data during a Fracture
Log
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
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. MirrorViews 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
Target Location A Source Location B
Target A
Source AND Remote Target System

Source A Source B Target C Target B Source C Target D
Source D
Source Location D Target Location C

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 Fan-in Consolidation

One 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
Location A Location D Location B Location C
Source A
Remote Location
Target A Source B Source C Target B Target C Target D
Source D
4:1 Fan-in ratio
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 Mirroring

MV/S One primary mirroring to two secondary images
Target
MV/A One primary mirroring to one secondary image Secondary images are managed independently Secondary images must reside on separate CLARiiONs
Source Target
Target Location B
Source
Source Location A
Target
Target Snapshot
Target Location C
Backup
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

Production site is fully protected by remote mirror Provide local replicas Allow for distributed workgroup activities across locations
Primary Secondary
Production Host Secondary Host (Site A) (Site B)
Tape Backup Report Generation Decision Support Tools
Snapshot
Primary CLARiiON
Remote CLARiiON
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 EMCs 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 coexist 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 metaLUNs MirrorView/S valid LUN type combinations
Scenario Primary
1 2 3 4
Thin R29 Traditional R29 Traditional Pre-R29 Traditional
Secondary 1
Secondary 2
R29 Thin or R29 Traditional R29 Thin or R29 Traditional R29 Thin or R29 Traditional R29 Thin or R29 Traditional Traditional (R29 or Pre-R29)Traditional (R29 or PreR29) Traditional (R29 or Pre-R29)Traditional (R29 or PreR29)
MirrorView/A valid LUN type combinations
Scenario Primary Thin 1 R29 Traditional 2 R29 Traditional 3 Pre-R29 Traditional 4
Secondary
R29 Thin or R29 Traditional R29 Thin or R29 Traditional Traditional (R29 or Pre-R29) Traditional (R29 or Pre-R29)
Navisphere will enforce these combinations

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 Checks

When 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 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 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 Case

Enable better business decisions
Pull data from remote locations to data center Gather daily sales records and inventory updates
Atlanta
Corporate Data Center
Stop costly data errors

Push data to distributed locations Applications, daily pricing updates, and inventory updates
NYC
Data Data Data Data Boston
Reduce operational costs

Centralize data for easier management
LA
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 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 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

SYMMETRIX CLARiiON FC4700 Copy Manager HOST AGENT
Object Copied is LUN/Volume
Data
Data
Data
Data Data
SAN SAN
LAN Data
Management Stations (Navisphere)
Data
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 LUNs

SAN 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 Thin SAN 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 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
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.

Mirro View and SAN Copy Foundations 2009 - r29

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Mirro View and SAN Copy Foundations 2009 - r29

Încărcat de

Drepturi de autor:

Formate disponibile

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

MirrorView and SAN Copy Foundations

2009 EMC Corporation. All rights reserved.

Welcome to MirrorView and SAN Copy Foundations.

MirrorView and SAN Copy Foundations - 1

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

2009 EMC Corporation. All rights reserved.

MirrorView and SAN Copy Foundations - 2

MirrorView and SAN Copy Foundations - 2

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

2009 EMC Corporation. All rights reserved.

MirrorView and SAN Copy Foundations - 3

MirrorView and SAN Copy Foundations - 3

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

MirrorView Your Business Solution

Protects critical business information Helps meet service level agreements

2009 EMC Corporation. All rights reserved.

MirrorView and SAN Copy Foundations - 4

MirrorView and SAN Copy Foundations - 4

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

EMC MirrorView/S What is It?

Local or remote bidirectional mirroring

MirrorView and SAN Copy Foundations - 5

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

EMC MirrorView/A What is It?

MirrorView and SAN Copy Foundations - 6

MirrorView and SAN Copy Foundations - 6

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

Secondary Image (secondary)

MirrorView and SAN Copy Foundations - 7

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

MirrorView Terminology (Cont)

Mirror Data States

MirrorView and SAN Copy Foundations - 8

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

MirrorView Replication Limits

2009 EMC Corporation. All rights reserved.

MirrorView and SAN Copy Foundations - 9

MirrorView and SAN Copy Foundations - 9

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

2009 EMC Corporation. All rights reserved.

MirrorView and SAN Copy Foundations - 10

MirrorView and SAN Copy Foundations - 10

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

No cross connected ports

2009 EMC Corporation. All rights reserved.

MirrorView and SAN Copy Foundations - 11

MirrorView and SAN Copy Foundations - 11

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

MirrorView Common Operations Synchronization

2009 EMC Corporation. All rights reserved.

MirrorView and SAN Copy Foundations - 12

MirrorView and SAN Copy Foundations - 12

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

MirrorView Common Operations Promote

Secondary image is placed in a new mirror as a primary image

Existing mirror is maintained or destroyed

2009 EMC Corporation. All rights reserved.

MirrorView and SAN Copy Foundations - 13

MirrorView and SAN Copy Foundations - 13

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

MirrorView Common Operations Fracture

2009 EMC Corporation. All rights reserved.

MirrorView and SAN Copy Foundations - 14