SnapView Foundations

Copyright 2008 EMC Corporation. Do not Copy - All Rights Reserved.
SnapView Foundations
2008 EMC Corporation. All rights reserved.
Welcome to SnapView Foundations.

Copyright 2008 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. EMC2, EMC, EMC ControlCenter, AlphaStor, ApplicationXtender, Captiva, Catalog Solution, Celerra, CentraStar, CLARalert, CLARiiON, ClientPak, Connectrix, Co-StandbyServer, Dantz, Direct Matrix Architecture, DiskXtender, DiskXtender 2000, Documentum, EmailXaminer, EmailXtender, EmailXtract, eRoom, FLARE, HighRoad, InputAccel, Navisphere, OpenScale, PowerPath, Rainfinity, RepliStor, ResourcePak, Retrospect, Smarts, SnapShotServer, SnapView/IP, SRDF, Symmetrix, TimeFinder, VisualSAN, VSAM-Assist, WebXtender, where information lives, Xtender, Xtender Solutions are registered trademarks; and EMC Developers Program, 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, Centera, CLARevent, Codebook Correlation Technology, EMC Common Information Model, CopyCross, CopyPoint, DatabaseXtender, Direct Matrix, EDM, E-Lab, Enginuity, FarPoint, Global File Virtualization, Graphic Visualization, InfoMover, Infoscape, Invista, Max Retriever, MediaStor, MirrorView, NetWin, NetWorker, nLayers, OnAlert, Powerlink, PowerSnap, RecoverPoint, RepliCare, SafeLine, SAN Advisor, SAN Copy, SAN Manager, SDMS, SnapImage, SnapSure, SnapView, StorageScope, SupportMate, SymmAPI, SymmEnabler, Symmetrix DMX, UltraPoint, UltraScale, Viewlets, VisualSRM are trademarks of EMC Corporation. All other trademarks used herein are the property of their respective owners.
SnapView Foundations - 1
Course Objectives
Upon completion of this course, you will be able to: Identify SnapView business uses Identify SnapView terminology Identify SnapView products for CLARiiON Identify SnapView snapshot functions and operation Identify SnapView clone functions and operation
The objectives for this course are shown here. Please take a moment to read them.
EMC CLARiiON SnapView Business Uses

Backup and recovery Decision support and data testing Data warehousing Data reporting Data movement
EMC SnapView products (snapshots and clones) enable users to perform various tasks on a given data set as required in a typical business environment without having to compromise data access. SnapView allows parallel processing without impacting the performance of the production application. Tasks can include disk-based backup and recovery, decision support and data testing, data warehousing, data reporting, and data movement operations.
CLARiiON SnapView Snapshots What is It?

Software package on CLARiiON storage arrays Creates point-in-time copies of a LUN Can be made available to another host Uses a pointer-and-copy-based design Creates local full copies
SnapView is an array software product that runs on the EMC CLARiiON. Having the software resident on the array has several advantages over host-based products. Since SnapView executes on the storage system, no host processing cycles are spent managing information. EMC SnapView allows companies to make more effective use of their most valuable resource, information, by enabling parallel information access. SnapView allows multiple business processes to have concurrent, parallel access to information. SnapView creates logical point-in-time views of production information using snapshots, and point-intime copies using clones. Snapshots use only a fraction of the original disk space, while clones require the same amount of disk space as the source.
SnapView Terminology
Production host
Server where customer applications execute Source LUNs are accessed from production host
Backup (or secondary) host

Host where backup processing occurs Offloads backup processing from production host Snapshots are accessed from backup host
Admsnap utility
An executable program that runs interactively or with a script to manage clones and snapshots Resides on the servers connected to the storage system
Some SnapView terms are defined here. These terms are referred to throughout the training. The production host is where customer production applications are executed. The backup or secondary host is where the snapshot is accessed from. Any host may have only one view of a LUN active at any time. It may be the Source LUN itself, or one of the 8 permissible snapshots. No host may ever have a source LUN and a snapshot accessible to it at the same time. If the snapshot is to be used for testing or for backup using filesystem access, then the production host and secondary host must be running the same operating system. If raw backups are being performed, then the filesystem structure is irrelevant, and the backup host need not be running the same operating system as the production host. The admsnap utility is an executable program that runs interactively or with a script to manage clones and snapshots. The admsnap utility resides on the servers connected to the storage system.
SnapView Terminology (Cont)

Source LUN
Production LUN the LUN from which snapshots are made
Activate
Maps a snapshot to an available snapshot session
Snapshot
Snapshot is a frozen in time copy of a source LUN
Reserved LUN Pool (RLP)

Private area used to contain Copy on First Write (COFW) data Total number of reserved LUNs is limited
The Source LUN is the production LUN that will be snapped. This is the LUN that is in use by the application, and is not visible to secondary hosts. When a snapshot is activated, it is made available to a SnapView session. The snapshot is a point-in-time view of the LUN and can be made accessible to a secondary host, but not to the primary host, once a SnapView session has been started on that LUN. The Reserved LUN Pool holds all the original data from the source LUN when the host writes to a chunk for the first time. The area may be grown if extra space is needed, or, if it has been configured as too large an area, it may be reduced in size. Note that the total number of reserved LUNs is limited and is model-dependent.

SnapView session
Defines a point in time designation by invoking COFW activity for updates to the source LUN
SnapView session name

Sessions should have meaningful names
Chunk
Granularity at which data is copied from the source LUN to a reserved area
Copy on First Write (COFW)

When a chunk is changed on the source LUN for the first time, data is copied to a reserved area
To start the tracking mechanism and create a virtual copy that has the potential to be seen by a host, we need to start a session. A session is associated with one or more snapshots, each of which is associated with a unique source LUN. Once a session has been started, data is moved to the Reserved LUN Pool as required by the COFW (Copy on First Write) mechanism. To make the snapshot appear online to the host, it is necessary to activate the snapshot. Sessions are identified by a session name, which should identify the session in a meaningful way. These names may be up to 64 characters long and consist of any mix of characters. Chunks are an aggregate of multiple disk blocks that SnapView uses to perform COFW operations. The chunk size is set to 64K (128 blocks). You cannot change this value.

Fracture
The process of breaking off a clone from its source Once a clone is fractured, it can receive server I/O requests
Clone group
Contains a source LUN and all of its clones
Clone private LUNs

Clone private LUNs record information that identifies data chunks on the source LUN and clone LUN that have been modified after you fractured the clone
When you fracture a clone, you break it off from its source LUN. Any server I/O requests made to the source LUN, after you fractured the clone, are not copied to the clone unless you manually perform a synchronization. Synchronizing a fractured clone unfractures the clone and updates the contents on the clone with its source LUN. A clone group contains a source LUN and all of its clones. When you create a clone group you specify a LUN to be cloned. This LUN is referred to as the source LUN. Once you create the clone group, the SnapView software assigns a unique ID to the group. No clones of the specified source LUN exist until you add a clone to the clone group. The purpose of creating a clone group is to designate a source LUN that you want to clone at some time. Clone private LUNs record information that identifies modified data chunks made to the source LUN and clone LUN after you have fractured the clone. A modified data chunk is a chunk of data that a server changes by writing to the clone or source LUN. A log in the clone private LUN records this information. This log reduces the time it takes to synchronize or reverse synchronize a clone with its source LUN since the software copies only modified (changed) chunks.
Reserved LUN Pool (RLP) Considerations

Requirements vary per installation Rate of change
Read/write ratio on the source LUN Date locality
Expected concurrent session count

Multiple sessions up to eight
Expected duration of sessions

Longer sessions may incur a larger number of COFWs
Requirements for sizing the RLP vary based on the environment. As a guide, consider small LUNs, keeping in mind that at least one LIN must be allocated per every source LUN that has a running session. SnapView write activity must be considered. The R/W radio and locality of the data affects the amount of data that needs to be copied to the reserved areas. If data has a high locality of reference, the data is copied only once and subsequent writes will not incur further COFWs. Multiple sessions require additional resources in the RLP. The longer the session is active, the more likely COFW activity will continue consuming addition space.
Reserved LUN Recommendations

Total number of reserved LUNs is limited
Limit is model-dependent
Reserved LUNs may be different sizes

Source LUNs are usually different sizes
Reserved LUNs are assigned as required

No checking of size, disk type, or RAID type
Due to the dynamic nature of reserved LUN assignment per source LUN, it may be better to have many smaller LUNs that can be used as a pool of individual resources. A limiting factor is that the total number of reserved LUNs allowed varies by storage system model. Each reserved LUN can be a different size and allocation to source LUNs, and is based on which is the next available reserved LUN, without regard to size. This means that there is no mechanism to ensure that a specified reserved LUN will be allocated to a specified source LUN. Because of the dynamic nature of the SnapView environment, assignment may be regarded as a random event (though, in fact, there are rules governing the assignment of reserved LUNs).
Reserved LUN Recommendations (Cont)

Determine average source LUN size
Total size of source LUNs / number of source LUNs
Reserved LUN size = 10% average source LUN size

COFW factor
Create 2x as many reserved LUNs as source LUNs

Overflow LUN factor
Example
LUNs to be snapped: 10 GB, 20 GB, 30 GB, 100 GB Average LUN size = 160 GB/4 = 40 GB Make each reserved LUN 4 GB in size Make 8 reserved LUNs
2008 EMC Corporation. All rights reserved. SnapView Foundations - 11
The COFW factor mentioned is a rough rule of thumb. It is expected that 10% of the data on the source LUN changes while the session is active. The overflow LUN factor of 2 is a safety margin. It allows twice the expected size, for a total of 20%. This example shows a total of 160 GB to be snapped, with eight reserved LUNs totaling 32 GB. Note that the calculation shown here is a compromise. Different results are obtained if the goal is to minimize the number of reserved LUNs or to minimize the wasted space in the reserved LUN pool. Also note that the Snapshot Wizard creates larger reserved LUNs. It is dealing with a potentially less experienced user and leaves more overhead for safety.
Snapshot Prerequisites
Source LUNs must be bound Source LUN must be presented to the Virtual Machine Assign the snapshot to a storage group
Enable data access control
Reserved LUNs must be bound Configure the event monitor
Source LUNs must be bound. For a client or production server to access a source LUN, you must assign the source LUN to a storage group and connect the storage group to the production server. To do this, you must enable data access control on the storage system. For VMware ESX Servers, verify that the source LUN is presented to the Virtual Machine (guest operating system running on the virtual machine). The storage group must be connected to the secondary server that will activate the snapshot. You must assign the snapshot to a storage group other than the storage group that holds the source LUN. EMC supports placing a snapshot in the same storage group as its source LUN only if you use RM/Local, RM/SE, or VMware ESX Server to put the snapshot in the storage group. This software or server provides same host access to the snapshot and the source LUN. You must add a reserved LUN to the global reserved LUN pool. Event monitor is part of the Navisphere Agent and is available on many operating systems. Once configured, the event monitor runs continuously as a service or daemon, observing the state of all specified storage systems and notifying you when selected events occur.
SnapView Sessions
Point-in-time copy of a source LUN Keeps track of how the source LUN looks at a particular point in time Software stores a copy of the original data in the reserved LUN pool in chunks Secondary server can then activate (map) a snapshot to the SnapView session Must give each session a name
A SnapView session is a point-in-time copy of a source LUN. The session keeps track of how the source LUN looks at a particular point in time. After you start a SnapView session and as the production server writes to the source LUN(s), the software stores a copy of the original data in the reserved LUN pool in chunks. This copy is referred to as copy-on-first-write and occurs only once, which is when the server first modifies a data chunk on the source LUN(s). A secondary server then activates (maps) a snapshot to the SnapView session. The snapshot views the original source LUN data chunks that have been modified since you started the session from the reserved LUN pool and unmodified data chunks from the source LUN(s). You must give each session a name when you start the session. The name persists throughout the session and is viewable through Navisphere Manager. Use the name to determine session status and to stop the session.
SnapView Sessions Start / Stop

Start/Stop snapshot sessions
Can be started/stopped from Manager/CLI or from production host Requires a session name Single or multi-LUN
Snapshot session administration

List of active sessions available Session statistics
Once the Reserved LUN Pool is configured and snapshots are created on the selected source LUNs, the user can start a Snapshot session. That procedure may be performed from the Navisphere GUI, CLI, or admsnap utility on the production host. The user must supply a session name. This name is used later to activate a snapshot. Sessions can be created for either a single source LUN or, for consistency purposes, on multiple source LUNs. When sessions are running, they may be viewed from the GUI or information may be gathered by using the CLI. All sessions are displayed under the sessions container in the GUI.
SnapView Session Modes Persistent vs Consistent
Persistent
Enabled on a session by default Survives failures and trespasses Available per session
Consistent
Preserves the point-in-time restartable copy across a set of source LUNs Available on a per-session basis Counts as one of the eight sessions per source LUN limit Not available on AX Series storage systems
Navisphere Manager enables persistent mode as the default. Persistent mode creates a session that can withstand the following failures and trespasses: SP reboot or failure Storage-system reboot or power failure A server I/O trespassing to the peer SP The persistence feature is available on a per session basis (not per snapshot or source LUN). In the event of a failure, source LUNs trespass to the other SP. Depending on your failover software, once the failed SP is running, you may need to issue a restore command in order to restore the proper source LUNs back to their original SP. For the appropriate restore command, refer to the documentation that shipped with your failover software. Consistent mode preserves the point-in-time restartable copy across a set of source LUNs. SnapView delays any I/O request to the set of source LUNs until the session has started on all LUNs. In the event of a failure, the software does not start the session on any source LUN and displays an error message. Consistent mode also prevents you from adding other LUNs to the session. It is not available on AX Series storage systems.
Snapshot Session Example

View into active LUN
Active LUN Chunk A Chunk B Chunk C
Application I/O Continues
View into Snapshot LUN
Access to SnapView
Reserved LUN Pool is a fraction of Source LUN size

Reserved LUN Pool
A SnapView session is a point-in-time copy of a source LUN. The session keeps track of how the source LUN looks at a particular point in time. A secondary server can then activate (map) a snapshot to the SnapView session. The snapshot views the original source LUN data chunks that have been modified since you started the session from the reserved LUN pool and unmodified data chunks from the source LUN(s). You must give each session a name when you start the session. The name persists throughout the session and is viewable through Navisphere Manager. Use the name to determine session status and to stop the session.
SnapView Copy on First Write (COFW)

Allows efficient utilization of copy space
Uses a dedicated Reserved LUN Pool LUN pool typically a fraction of source LUN size for a single snapshot
Saves original data chunks once only

Chunks are a fixed size 64 KB Chunks are saved when they are modified for the first time
Allows consistent point in time views of LUN(s)
The Copy on First Write mechanism involves saving an original data block into the Reserved LUN Pool when that data block in the active filesystem is changed for the first time. The chunk is saved only once per snapshot. SnapView allows multiple snapshots of the same LUN. This ensures that the view of the LUN is consistent and, unless writes are made to the snapshot, are always a true indication of what the LUN looked like at the time it was snapped. Saving only chunks that have been changed allows efficient use of the disk space available; whereas a full copy of the LUN would use additional space equal in size to the active LUN. A snap may use as little as 10% of the space, on average.
Copy on First Write Example

First write to Chunk C View into active LUN
Active LUN Chunk A Chunk B Updated Chunk C
Copy On First Write is invoked
View into Snapshot LUN
Access to SnapView
Original Chunk C Reserved LUN Pool

SnapView uses Copy On First Write process, and the original chunk data is copied to the LUN Pool.
SnapView uses a process called Copy on First Write (COFW) when handling writes to the production data during a running session. The example shows that a snapshot is active on the production LUN. When a host attempts to write to the data on the production LUN, the original Chunk C is first copied to the Reserved LUN Pool, then the write is processed against the production LUN. This maintains the consistent, point-in-time copy of the data for the ongoing snapshot. A view of the snapshot points to both the unchanged data on the active LUN, plus the original data that was copied to the RLP.
SnapView Activating/Deactivating Snapshots

Activating a snapshot
Maps a SnapView snapshot to a snapshot session Makes it visible to secondary host
Initiated from the GUI or admsnap utility

Admsnap utility has an activate command
Deactivating a snapshot
Makes it inaccessible (off-line) to secondary host Does not flush host buffers (unless performed with admsnap) Keeps COFW process active
Once you have at least one SnapView session running and a snapshot created for a given source LUN, you can activate a snapshot to a session. To make the snapshot visible to the host as a LUN, the snapshot must be activated. Activation may be performed from the GUI, from the CLI, or via admsnap on the backup host. The activate function, when administered from the admsnap server utility, also scans the secondary servers system buses for storage system devices and determine if any device is part of a SnapView session. You can then access these devices from the secondary server but you must specify the session name and the session must be active. Deactivation of a snapshot makes it inaccessible to the backup host. Normal data tracking continues, so if the snapshot is reactivated at a later stage, it will still be valid for the time that the session was started.
SnapView Rollback
Process to recover data on the source LUN Reverses the pointer-and-copy process
Non-destructive to the source LUNs other sessions/snapshots Original data is copied back to the source LUN
Independent of other sessions and snapshots Restores the contents of the source LUN to a point in time
Any session for the source LUN that was started
In addition to providing point-in-time views of data for concurrent access, these sessions also provide a way to recover data in the event of data corruption on the source LUN. Rollbacks copy the original data on the reserved LUN back to the source LUN in a non-destructive manner. Rollbacks operate independently of any other sessions or snapshots that may be defined in the source LUN. The SnapView rollback feature allows the user to restore the contents of a source LUN almost instantaneously to the point in time that any of the SnapView sessions for that source LUN were started.
SnapView Rollback Host Access

Source LUN is available for read and writes
Copy happens in the background
User should flush host buffers

Admsnap utility
Source device should be off-line to start

Bring online after rollback starts
Snapshot should be taken off-line

Allows snapshot to remain activated
Source LUN appears instantly restored All sessions continue as normal

Activated snapshots remain accessible for host I/O
During a rollback, the source LUN remains available for reads and writes while the rollback process takes place in the background. At the start of the rollback, you should flush the host buffers as well as the activated snapshot with the admsnap utility. The user must take the source off-line and bring it back online after the rollback session starts. In addition, if a snapshot is to remain activated to the session that is used for the rollback, that snapshot must be taken off-line until the rollback completes to prevent data inconsistency due to writes to the secondary server. Reads to areas that have been identified for copying back to the source are redirected to the reserved LUN and read directly from that LUN. Writes to areas that have been identified for copying back to the source generate a process by which the corresponding chunks are immediately copied from the reserved LUN to the source. The write is then satisfied from the source LUN. This way, new data written to the host supersedes the data being rolled back. All sessions and snapshots continue as normal.
Snapshots with other CLARiiON Replication Software
SnapView snapshots can used with: SnapView clones

Local recovery Create snapshots of clones
SAN Copy
Snapshots can be used as a source for a full SAN Copy session Source LUN can remain online during the copy operation Snapshot of the destination SAN Copy LUN for incremental SAN Copy
MirrorView
Snapshots can be used with both primary and secondary MirrorView images Rollback provides extra protection
SnapView snapshots can be used in conjunction with clones. Users can replicate a source production LUN using a SnapView clone to create a full recoverable copy of their production data. The clone can be used as a source for starting a SnapView session. Multiple copies can be taken. A snapshot activated on a SnapView session of the source LUN can be used as a source for a full SAN Copy session. This allows for the source LUN to remain online during the copy operation. SnapView snapshots can be used with both MirrorView primary and secondary images. SnapView rollback feature provides an extra level of protection for MirrorView. If a failure occurs on the primary image, SnapView sessions running on the primary or secondary images can restore the image by performing a rollback.
EMC CLARiiON SnapView Clone What is It?

Fully populated point-in-time copies of LUNs Allows incremental synchronization between the source and destination LUNs Uses a pointer-and-copy-based design Creates local full copies within a single storage system Minimal impact to production host
A clone is a complete copy of a source LUN that uses pointer-and-copy based technology. You specify a source LUN when you create a clone group. The copy of the source LUN begins when you add a clone LUN to the clone group. The software assigns each clone a clone group ID. This ID remains with the clone until you remove the clone from its group. While the clone is part of the clone group and unfractured, any production write requests made to the source LUN are simultaneously copied to the clone. Once the clone contains the desired data, you can fracture the clone. Fracturing the clone separates it from its source LUN, after which you can make it available to a secondary server. This technology allows users to perform additional storage management functions with minimal impact to the production host.
SnapView Clones Benefits

Overall highest service level for backup and recovery Removes performance impact on production volume Accelerates application recovery
Clones offer several advantages in certain situations. Because copies are physically separate, and reside on different disks and RAID groups from the source LUN, there is no impact from competing I/Os. Different I/O characteristics, such as database applications with highly random I/O patterns or backup applications with highly sequential I/O patterns running at the same time, do not compete for spindles. Physical or logical (human or application error) loss of one does not affect the data contained in the other.
Source LUN and Clone Relationships

Adding clones
Must be exactly equal size to source LUN
Removing Clones
Cannot be in active sync or reverse-sync process
Termination of clone relationship

Renders source and clone as independent LUNs
Does not affect data
When you add a clone to a group, the source LUNs and their clones must be exactly the same size. When removing a clone from the clone group, it cannot be in the process of synching or reverse synching. Once the clone is removed from the group, the source and clone are reverted back to independent LUNs, this process does not affect the data on the LUNs. Any LUN is eligible to be cloned, except for the following: Hot spare LUNs Remote mirror LUNs (LUNs participating as either a primary or secondary image) Clone LUNs (LUNs participating in any clone group as either a source LUN or a clone LUN) Snapshot LUNs Private LUNs (LUNs reserved as clone private LUNs or for the reserved LUN pool)
Clone Synchronization Rules

Synchronize from source to clone Clone private LUNs used for incremental syncs
Saved persistently on disk Two LUNs minimum of 250,000 blocks
Host access
Source can accept I/O at all times Clone cannot accept I/O during sync
Clone synchronization copies source data to the clone. Any data on the clone is overwritten with source data. Clone private LUNs record information that identifies data chunks on the source LUN and clone LUN that have been modified after you fractured the clone. These LUNs are a minimum of 250,000 blocks and are created one per SP. A modified data chunk is a chunk of data that a production or secondary server changes by writing to the source LUN or clone. A log in the clone private LUN records this information, but no actual data is written to the clone private LUN. This log reduces the time it takes to synchronize or reverse synchronize a clone and its source LUN since the software copies only modified chunks. Source LUN access is allowed during sync with use of mirroring. The clone, however, is inaccessible during sync. Any attempted host I/Os are rejected. Clones must be manually fractured following synchronization. This allows the administrator to pick the time that the clone should be fractured, depending on the data state. Once fractured, the clone is available to the secondary host.
Clone Reverse Synchronization Rules

Source LUN is taken off-line before initiating the reverse sync Restores the source LUN with contents of the clone
Overwrites source with clone data Host access allowed to source once online, but not to clone
The purpose of reverse synchronizing a fractured clone is to replace the data on the source LUN with the data on the clone. This allows you to revert to an earlier copy of the source LUN if, for instance, the source becomes corrupted or if new source LUN writes are not desired. To ensure that there is no data corruption on the source LUN, you have to take the source LUN offline before you initiate the reverse synchronization. Once the operation begins, you can bring the source LUN back online. During a reverse synchronization, the software automatically copies to the clone any incoming server writes to the source LUN.
Clone Reverse Synchronization Instant Restore

Copy on demand
Host requests I/O to source Data is immediately copied from clone Host I/O is allowed to source Copying of data from clone continues
Reverse synchronization has the effect of making the source appear as if it is identical to the clone at the beginning of the synchronization. Since this copy on demand mechanism is designed to coordinate the host I/Os to the source (rather than to the clone), host I/Os cannot be received by the clone during synchronization.
Clone Reverse Synchronization Protected Restore
Protected restore
Host source writes not mirrored to clone Configure via individual clone property
Non-protected restore
Host source writes mirrored to clone
The Protected Restore feature protects the data on a clone during a reverse synchronization. When you select this feature during a reverse synchronization, the software will not copy to the clone any server writes made to the source LUN. Instead, the software records information in the clone private LUN to identify the source LUN writes for subsequent synchronizations. Once you initiate a reverse synchronization, the software immediately unfractures the clone that initiated the reverse synchronization. Then the software fractures any other clone in the clone group to protect it from corruption should the reverse synchronization operation fail. The software then begins to copy its data to its source LUN. After the reverse synchronization is complete, the software fractures the clone that initiated the reverse synchronization. You enable the Protected Restore feature on a per-clone basis and not on a per-clone-group basis. During a reverse synchronization, the software automatically copies to the clone any incoming server writes to the source LUN under a non-protected restore scenario. If you do not want source writes copied to the clone during a reverse synchronization, you must check the Use the Protected Restore option in the Add Clone dialog box before initiating a reverse synchronization.
Reverse Synchronization Example

Restore source LUN with contents of clone
Overwrites source with clone data Host access allowed to source, not to clone
Source instantly appears to contain clone data
Production Server instantly sees Clone 1 data
Source LUN
Source LUN restored to Clone 1 state
X
Clone 2
X
Other clones fractured from Source LUN
Production Server
X
Backup Server
Clone 1
...
Clone 8
Reverse synchronization copies clone data to the source LUN. Data on the source is overwritten with clone data. As soon as the reverse-sync begins, the source LUN seems to be identical to the clone. This feature is known as an instant restore. Note: You can have up to eight clones per source LUN.
SnapView Clone Consistent Operations

Allows a set of replicas to maintain dependent writeordered consistency
Provides a restartable point-in-time replica of multi-datasets
Initiated from Navisphere Manager or CLI

Can be scripted or done manually
Clone consistent fractures

User defines set of clone LUNs at beginning of fracture User defines set of source LUNs at beginning of start
A consistent fracture is when you fracture more than one clone at the same time in order to preserve the point-in-time restartable copy across the set of clones. A restartable copy is a data state having dependent write consistency and where all internal database/application control information is consistent with a Database Management System/application image. Consistent operations can be initiated from either the Navisphere Management GUI or CLI. The clones you want to fracture must be in different clone groups. You cannot perform a consistent fracture between different storage systems. If there is a failure on any of the clones, the consistent fracture fails on all of the clones. If any clones within the group were fractured prior to the failure, the software re-synchronizes those clones.
Clone Consistent Fractures

Source LUN for each clone must be unique
Cannot fracture multiple clones belonging to the same source User cannot consistently fracture a set of clone LUNs if one of them is already fractured
Clones appear as administratively fractured

Examine clone properties
Failures during a consistent fracture affect all clones in the group
Since a consistent fracture refers to fracturing a set of clones belonging to a write-ordered dependent source LUN, the associated source LUN for each clone must be unique. The user cannot perform a consistent fracture on multiple clones belonging to the same source LUN. Once fractured, the clone appears under the clone properties container in Navisphere Manager as administratively fractured. If there is a failure on any of the clones, the consistent fracture fails on all of the clones. If any clones within the group were fractured prior to the failure, the software re-synchronizes those clones.
Clones with other CLARiiON Replication Software

Clones can used with: Snapshots
Can use the same source LUN Create snapshots of clones
SAN Copy
Copy from the source LUN or clone
MirrorView (MV/S and MV/A)

Create clones of mirrors Cannot mirror a clone Share the same source LUN
Clones can be used with SnapView snapshots, SAN Copy, and both MirrorView/S and MirrorView/A (with some restrictions). Users can create clones and snapshots of the same source LUN, but they can also create snapshots of clones as well. This functionality provides users with multiple copies of their data. In addition to having a copy of data within the same storage system, users can have the added benefit of having another copy on another storage system using SAN Copy. Users have the ability to create a clone of a mirror, using the same source LUN at either the local or remote site. Users may: Clone a MirrorView primary image having the primary image serve as a clone source on the local storage system Clone a secondary image and have the secondary image serve as a clone source on the remote storage system Clone a primary and secondary image Note: You may not mirror a clone.
Managing Clones and Snapshots

Navisphere Manager Navisphere Secure CLI Navisphere Taskbar Wizard Admsnap Utility
SnapView can be configured and managed using the management GUI, Secure CLI, Taskbar Wizard, or the admsnap command. The Secure CLI uses the same security features embodied in Navisphere Manager. Users are authenticated via a username/password/scope combination associated with each CLI command sent to the storage system. A mechanism exists to bypass this requirement which is especially useful in scripting. The admsnap command is host-resident; there is a different version for each platform.
Course Summary
Key points covered in this course: SnapView addresses business needs SnapView terminology SnapView products for CLARiiON SnapView snapshot functions and operation SnapView clone functions and operation
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.

SnapView Foundations

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SnapView Foundations

Uploaded by

Copyright:

Available Formats

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

2008 EMC Corporation. All rights reserved.

Welcome to SnapView Foundations.

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

2008 EMC Corporation. All rights reserved.

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

EMC CLARiiON SnapView Business Uses

2008 EMC Corporation. All rights reserved.

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

CLARiiON SnapView Snapshots What is It?

2008 EMC Corporation. All rights reserved.

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

Backup (or secondary) host

2008 EMC Corporation. All rights reserved.

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

SnapView Terminology (Cont)

Reserved LUN Pool (RLP)

2008 EMC Corporation. All rights reserved.

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

SnapView Terminology (Cont)

SnapView session name

Copy on First Write (COFW)

2008 EMC Corporation. All rights reserved.

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

SnapView Terminology (Cont)

Clone private LUNs

2008 EMC Corporation. All rights reserved.

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

Reserved LUN Pool (RLP) Considerations

Expected concurrent session count

Expected duration of sessions

2008 EMC Corporation. All rights reserved.

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

Reserved LUN Recommendations

Reserved LUNs may be different sizes

Reserved LUNs are assigned as required

2008 EMC Corporation. All rights reserved.

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

Reserved LUN Recommendations (Cont)

Reserved LUN size = 10% average source LUN size

Create 2x as many reserved LUNs as source LUNs

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

Reserved LUNs must be bound Configure the event monitor

2008 EMC Corporation. All rights reserved.

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

2008 EMC Corporation. All rights reserved.

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

SnapView Sessions Start / Stop

Snapshot session administration

2008 EMC Corporation. All rights reserved.

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

SnapView Session Modes Persistent vs Consistent

2008 EMC Corporation. All rights reserved.

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

Snapshot Session Example

Application I/O Continues

View into Snapshot LUN

Reserved LUN Pool is a fraction of Source LUN size

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

SnapView Copy on First Write (COFW)

Saves original data chunks once only

Allows consistent point in time views of LUN(s)

2008 EMC Corporation. All rights reserved.

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