1Snapview Basics

7/30/2019 1Snapview Basics

1/22

EMC SnapView Basics

Revision 2.0 and Above

Abstract

This white paper defines the EMC SnapView product, as well as its associated terminology and operational

characteristics. Performance considerations and troubleshooting ideas are also discussed.

Published 6/24/2003

Engineering White Paper


2/22

EMC CONFIDENTIAL 6/24/2003

EMC SnapView Basics

Revision 2.0 and Above 2

Copyright 2003 EMC Corporation. All rights reserved.

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.

Part Number C1040


3/22


EMC SnapView Basics


Table of Contents

Executive Summary ............................................................................................4

Intended Audience ..............................................................................................4

Introduction .........................................................................................................4SnapView Terminology.......................................................................................5

Limits ............................................................................................................................................ 6

Installation .................................................................................................................................... 6

ConfigurationSnapshots ........................................................................................................... 7

Setting Up Persistence ............................................................................................................. 8ConfigurationBCVs ...................................................................................................................8

Using SnapView Snapshots ....................................................................................................... 10

Reactivating Snapshots .......................................................................................................... 17Using SnapView BCVs............................................................................................................... 17

Rules and Recommendations .................................................................................................... 18

Performance Considerations...................................................................................................... 20Performance Considerations for BCVs................................................................................... 21

SnapView and SAN Copy ..........................................................................................................21

Troubleshooting.......................................................................................................................... 21

Conclusion.........................................................................................................22


4/22


EMC SnapView Basics


Executive SummaryThis white paper provides details on the functionality of the EMC SnapView product and associated

terminology. The focus is on operational characteristics. The following pages offer a clear description of

what SnapView is, how it works, and the benefits it can bring to storage area network (SAN) environments.

The document also describes the characteristics associated with SnapView 2.0 and above, and clarifiesdifferences between some of the implemented features of prior revisions.

Intended AudienceThis white paper is intended for members of the EMC field community who interact with customers and

need to understand and demonstrate the use of SnapView.

IntroductionSnapView is an optional software package for the EMC CLARiiON CX400, CX600, and FC4700 storage

systems. Using SnapView, users can create a point-in-time view or multiple views of a logical unit (LUN),

which can subsequently be made accessible to another host. For instance, a system administrator can make

the snapshot session accessible to a backup host, so that the production host can continue processingwithout the downtime and processing demands traditionally associated with backup processes. You can

also use SnapView in conjunction with decision support applications, by providing a view of the

production data that can be used without impacting the data on the active LUN.

SnapView provides two different ways to get the point-in-time replica. The first method is called the

snapshot copy, which provides the user with a view of the point-in-time copy that uses a fraction of the

space used by the original data. The second is called a SnapView business continuance volume (BCV),

which is a full-sized copy of the original data.

SnapView snapshots function on a copy-and-pointer-based design, where a memory map keeps track of

chunks (groups of blocks) of data in the state in which they existed at a given point in time. As write

requests are made to the active LUNcalled the source LUNthe chunks are copied to a save area

composed of nonvolatile space on private LUNscalled the Snapshot Cacheand the memory map is

updated with the new location of each of these chunks in the snapshot. This process, referred to as copy onfirst write (COFW), occurs for each chunk only when the first write request is made to a block in the source

LUN. Once the original data is safely copied to the snapshot cache LUN, any number of writes can be

made to that chunk on the source LUN without losing the original view of the data. The source LUN, the

snapshot cache, and the memory map work together to create the snapshot LUN. Starting a session

activates the point-in-time COFW capability for a source LUN and snapshot LUN pair. The snapshot LUN

is made visible to a secondary host when the SnapView session is activated (assuming that a snapshot LUN

has been defined and has been added to a storage group connected to a host).

SnapView BCVs provide users with the ability to create fully populated binary copies of LUNs within a

single storage system. Users familiar with MirrorView can think of BCVs as mirrors within storage

systems, as opposed to across storage systems. Thesynchronize feature of mirroring is used to populate the

BCVs. Once populated, BCVs are similar to snapshots in that they can be fractured from the source and

thus provide point-in-time replicas of data. BCVs, however, arefull copies of the data, whereas snapshots

are essentially views of the data. Those familiar with Symmetrix TimeFinder will see that SnapViewBCVs share many of the same features and capabilities of TimeFinder BCVs.

The memory/bitmaps described above are critical to the entire function since they contain the metadata that

describes the snapshot LUN or BCVs. Persistence allows the session to survive a failure by storing the

memory maps to disk.


5/22


EMC SnapView Basics


SnapView TerminologyThe following terms will help in understanding SnapView functionality:

Source LUNThe LUN containing production data on which we want to start at least one SnapView

session, and then activate at least one snapshot LUN, or from which we want to create one BCV. Previous

revisions of SnapView did not allow BCVs, but with SnapView 2.0 and above, up to eight BCVs (as wellas up to eight snapshots) are allowed per source LUN. BCVs themselves are also allowed up to eight

snapshots each.

SnapView snapshot sessionStarting a snapshot session invokes assignment of a cache LUN to the

source LUN if no other sessions are running on this same source LUN. It also starts tracking the session

with SP memory and cache LUN resources, and invokes copy on first write activity for updates to the

source LUN. Note that a snapshot isnt actually visible as far as this session is concerned until it is

activated, but we are tracking the source LUN so we can, at any time in the future, activate a snapshot LUN

to give us the point-in-time image of when the SnapView session was started. This is different than prior

releases of SnapView, as multiple sessions can be started at different times on the same source LUN.

Snapshot cacheComprised of private LUNs allocated to each storage processor (SP). As new SnapView

sessions are started on new source LUNs, each source LUN is initially assigned one snapshot cache LUN.

If a SnapView session runs long enough for the assigned cache LUN to be filled, another cache LUN isallocated, if available, to that SnapView session for the same source LUN. In previous revisions of

SnapView, a pool area of snapshot cache was allocated to each storage processor such that all running

SnapView sessions on one storage processor would use the same allocated cache LUNs. The main reason

for this change in cache LUN allocation was to support snapshot persistence (see below).

SnapshotThe defined pseudo-device that is presented to a host and enables visibility into running

sessions. The snapshot is defined under a source LUN such that activation of that snapshot is only allowed

on any running sessions on that same source LUN. This is as long as the session in which you want to

activate the snapshot does not already have a snapshot activated in it for this same source LUN. This

essentially means that to have two active snapshots for the same source LUN, you must have two separate

sessions running in which to activate two separate snapshots. Active snapshots are fully read/write capable.

However, once the snapshot is de-activated, all changes written directly to the snapshot are lost.

Chunk SizeThe size that SnapView uses in copy-on-first-write operations and subsequent memory

tracking (that is, memory map granularity). Each map reference in SnapView storage processor memory

maps a SnapView session to an area equal to the chunk size setting. In previous versions of SnapView, this

was user-settable but in revision 2.0 and above, it is fixed at 128 blocks (64 KB). Multiple references

comprise the snapshot and tell the storage processor that the data to be accessed for any given snapshot

LUN I/O is either on the source LUN or the snapshot cache LUN. See the Performance Considerations

section for more details on chunk size.

PersistenceEnables active SnapView sessions to ride through certain storage system operations such as

source LUN trespasses and reboots. See the white paper titledPersistent Snapshot Sessions on Powerlink1

for full details on the SnapView persistence feature.

SnapView BCVA full-size copy of the source LUN. The BCV is a mirror that can be fractured at a

point-in-time. While fractured, a bitmap is maintained reflecting changes to both the BCV and the source

LUN. You can reunite a BCV with the source LUN using a synchronize operation or a reverse synchronize

operation. You can also disassociate BCVs from the source LUN, making the BCV a new source LUN.Snapshot operations can also be created for BCVs. Navisphere uses the term Clone on some screens.

Clone and BCV are synonymous in the SnapView context.

SynchronizeAn operation that moves data from the source to the target LUN. The source can be either a

BCV or the source LUN, depending upon the direction of the synchronize operation. A synchronize

overwrites data on the target with source data. The synchronization can be a full copy or a partial copy

based on the changes bitmap.

1 https://powerlink.EMC.com/login/login.jhtml?clear=false&_requestid=4316


6/22


EMC SnapView Basics


Reverse synchronizeAn operation that moves data from the target LUN to the source. A reverse

synchronize overwrites data on the source with target data. The reverse synchronization can be a full copy

or a partial copy based on the changes bitmap.

RestoreA reverse synchronize operation is called a restore. A normal restore will reflect changes that

occur on the source LUN during the restore. A protected restore option is available to the user to protect the

BCV after the restore. The protected restore does not modify the BCV during or after the restore.

LimitsThe SnapView implementation has certain limits, for instance, the number of snapshots allowed. Table 1

lists the SnapView implementation limits.

Table 1. SnapView Implementation Limits

Resource CX600, FC4700 CX400

Snapshot LUNs per storage system 300 150

Snapshot cache LUNs per storage system 100 50

Concurrent sessions per storage system 100 50

Snapshot LUNs per source LUN 8 8Active snapshot sessions per source LUN 8 8

Number of BCVs per storage system 100 2 50 2

Number of BCVs per LUN 8 8

Number of snapshots per BCV 8 8

InstallationSnapView software resides on the CLARiiON CX400, CX600, or FC4700 storage systems. Its installed

with a nondisruptive upgrade (NDU) process that initially copies data to the Persistent Storage Manager

(PSM) LUN, and then propagates the SnapView Core code and Navisphere 6.x UI (if required) to each

storage processor. Management software requirements depend on what method of management you

employ. Using Navisphere CLI or Navisphere 6.x, all features are available to set up and use SnapView.

However, different revisions of Navisphere 6.x UI will support different features. Access Logix is alsorequired, as snapshots and BCVs are presented to independent hosts as production data LUNs.

SnapView has an additional utility, called admsnap, which enables additional host-based facilities for

starting and stopping SnapView sessions, and activating snapshots. For further information about

admsnap, refer to theEMC SnapView 2.X for EMC ControlCenter Navisphere 6.X Administrator's Guide

(069001180) and EMC SnapView Version 2.X Command Line Interfaces Reference (069001181).

2 This total includes sources and BCVs. It also includes the MirrorView primary and secondary images on

a storage system.


7/22


EMC SnapView Basics


ConfigurationSnapshotsAfter installation of SnapView on the CLARiiON storage system, you need to determine how many and

what size LUNs you will add to the snapshot cache. The recommendations are always different for each

installation, as the numbers required relate to the environment. Consider the following when determining

how to allocate snapshot cache:

Rate of change of source LUN data

Expected duration of SnapView sessions

Expected concurrent session count

In previous versions of the software, the snapshot cache existed as a pool of LUNs for each SP, essentially

aggregated together and shared by all of the active snapshot sessions running on each SP respectively in a

many-to-many relationship. In order to ensure persistence, the relationship between source LUNs and the

corresponding snapshot cache LUNs has been changed, so that now there is a one-to-many correspondence

between source LUNs and their associated snapshot cache LUNs. With this modification, a snapshot cache

LUN is assigned to the source LUN when the session is started; and additional snapshot cache LUNs are

assigned to the source LUN as needed (i.e., when more space is needed to accommodate the COFW data

being saved in the snapshot cache LUN). In this way, the concept of a pool of LUNs composing the

snapshot cache still exists; but now the concept applies at the source LUN level, rather than at the SP level.

Thus when you start the first session on a source LUN, one snapshot cache LUN is assigned to that source

LUN. If, during the length of time this session is running, the snapshot cache LUN gets full, another LUN

is automatically assigned to the same source LUN if any are available in the resource pool of snapshot

cache LUNs for the same storage processor. If no more LUNs are available, then the session that

encountered the snapshot cache LUN full is automatically terminated, and any snapshot cache LUNs used

by that session go back to be available for other sessions running on the same storage processor.

As a guide, consider creating relatively small LUNs for the SnapView cache (also called Save Area), on the

order of 2 GB to 10 GB. Remember, though, that at least one LUN is assigned to any source LUN that has

a running SnapView session. Cache LUNs are allocated on a per storage processor basis. Figure 1 shows all

un-allocated LUNs available to select for the snapshot cache. Even if you select a LUN with default

ownership on SP A, it will be trespassed by the system if you place that LUN in the snapshot cache pool for

SP B.


8/22


EMC SnapView Basics


Figure 1. Configure Snapshot Cache Dialog Box

Setting Up Persistence

Because of the potential performance overhead of flushing the memory map data to the snapshot cache

LUN; snapshot sessions are not persistent by default. Users who desire that sessions be persistent across

trespasses or SP failures must explicitly make this selection. If persistence is not selected, this simply

means that the chunk map will not be copied from volatile SP memory to the snapshot cache when the

COFW completes.3 This means that for a given source LUN, some snapshot sessions may be persistent,

while others are not.

ConfigurationBCVsAfter installing the Snap Clone provider with the NDU process, set up to use BCVs by assigning a private

LUN for management of the changes bitmaps. Figure 2 shows the popup screen used to make some LUNS

private to support BCVs in the system.

3 To reduce the performance penalty, ensure that FLARE write cache is enabled on all LUNs allocated to

the snapshot cache.


9/22


EMC SnapView Basics


Figure 2. Clone Feature Properties Dialog Box

Create the clone group. A clone group is a set that contains the source LUN and all its clones. If a BCV is

removed from the clone group, it becomes a regular LUN and no longer tracks changes between the

original source LUN. Figure 2 shows the allocation of a private LUN for use with BCVs. Figure 3 shows

the Navisphere screen used to set up a clone group.

Figure 3. Create Clone Group Dialog Box


10/22


EMC SnapView Basics


Using SnapView SnapshotsNow that we have the necessary software components installed and have allocated snapshot cache LUNs to

each storage processor, we can start using the feature. Remember that you should quiesce any applications

before taking any snapshots. (See the trouble shooting section for more information.) The first thing to do is

start a session. Do this using one of three methods: Navisphere Manager GUI, NaviCLI, or admsnap.

Admsnap has specific requirements depending on the operating system. These requirements are covered in

theEMC SnapView 2.X for EMC Control Center Navisphere 6.X Administrator's Guide (069001180) andtheEMC SnapView Version 2.XCommand Line Interfaces Reference (069001181). For the purposes ofthis paper, the following dialog focuses on using the Navisphere GUI or Command Line Interface (CLI).

When starting a session, you have two options, depending on the session characteristics you want. You can

have a session running on one source LUN. Do the following:

1. Right-click on the desired LUN.

2. Select Start Session.

3. Enter a session name

4. ClickOK.

The session starts.

Alternatively, if you want to start a session containing multiple source LUNs such as an interdependent

data set, for instance, with a database consisting of several LUNs, do the following:

1. Right-click on the storage system.

2. Select Start Session.

3. In the dialog box that appears, select the source LUNs you want in this session and give the session a

name.

4. ClickOKto start (Figure 4).

The function of starting the session has the following effect:

If no other session is already running on that source LUN, each source LUN gets a snapshot cache LUN

assigned to it.

The storage system starts tracking the source LUN, invoking copy-on-first-write operations for data areas

being changed on the source LUN. This uses memory resource on the owner storage processor. However,

this is reserved feature space, so you dont need to be concerned about losing allocated cache memory.


11/22


EMC SnapView Basics


Notice that Figure 4 depicts a session containing multiple source LUNs, even though some of the LUNs do

not have any snapshots created. Remember, starting the session starts the process of tracking changes and

preserving data. You can perform that process at any time, and then create a snapshot and activate it to

enable visibility into that data point.

Figure 4. Start a Session and Select LUNs

The appropriate NaviCLI commands to perform the same function are:

navicli h snapview startsession test2_snap -luns 8

11 0

navicli h snapview startsession test3_snap -luns 9

12 1

Up to two separate startsession commands may be required when using the CLI, one for each source LUNowner storage processor.

Now that you have started a session, you can define a snapshot. You can also do this before starting a

session. The snapshot merely enables the allocation of an offline device to a storage group, ready to be

activated anytime you want as long as that same source LUN has a running SnapView session.

In the Navisphere GUI, right-click on a source LUN and select Create Snapshot. The dialog box shown in

Figure 5 appears.


12/22


EMC SnapView Basics


In this dialog box, you create or define a snapshot for source LUN 0. This snapshot is offline until activated

to a running SnapView session.

By assigning this snapshot to a storage group, you can also select which host sees this snapshot when either

offline or activated and online. You put the snapshot into a storage group at snapshot creation time

(Figure 6). The storage group assignment is none. You can also assign the snapshot to a storage group

later.

Figure 5. Create a Snapshot

The appropriate NaviCLI command to perform the same function is:

navicli h snapview createsnapshot 0 snapshotname

new_snap


13/22


EMC SnapView Basics


Here we can see available LUNs, including snapshots, to add to this storage group.

Figure 6. Storage Group Properties Dialog Box


navicli h storagegroup addsnapshot gname SUN1-

snapshotname SQL1_snap_of_BCV

Now that there is at least one SnapView session running, you can activate a snapshot to a session. To do

this, right-click on the snapshot and select activate.


14/22


EMC SnapView Basics


Figure 7. Activating a Snapshot Session

This dialog box shows two running sessions on the same source LUN. Each has its start date and time to

indicate which view of data will be presented when accessing the activated snapshot.

The snapshot could already be in a storage group and allocated to a host. After activation, the connectedhost should be able to see this point-in-time copy of data from source LUN Exchange1_Source.

Each host has different requirements to see the new online device, from a simple rescan or import to a

reboot. Refer to your host type administration guide. Guidelines can also be found in the admsnap

administration guide for supported platforms.


navicli h snapview activatesnapshot snapshotname

test 1snapshot

Figure 7 shows multiple sessions running with different start times. You can choose to activate a snapshot

that gives you visibility of any of these sessions as long as the source LUN has a defined snapshot available

that is not activated for another session. Also, for example, you can start a session on a source LUN for

each day of the week. If at some point you want to recover a file that was created on Tuesday but was either

deleted or became corrupt after Thursday, you can activate a snapshot for the session started on Wednesday

and copy the file from the available snapshot for online file recovery. Typically, you would do this with

another host accessing the snapshot, as described in the next section.


15/22


EMC SnapView Basics


Figure 8 shows a summary of all sessions running.

Figure 8. SnapView Summary Dialog Box

Once you have finished accessing the snapshot, you should stop the SnapView session if you have no

further use of it. First, ensure you dont have the snapshot mounted on your operating system. Since the

snapshot effectively goes offline, this may have unpredictable results when you stop the session. The

operating system accessing the snapshot may have buffered information it expects to write to the snapshot.

See theEMC SnapView 2.X for EMC ControlCenter Navisphere 6.X Administrator's Guide (069001180)

and theEMC SnapView Version 2.XCommand Line Interfaces Reference (069001181) for more details onadmsnap.When you stop the session, you may leave the snapshot in the storage group and allocated to the host. As

mentioned earlier, this just takes the snapshot device offline.

In the Navisphere GUI, expand the SnapView icon to reveal the snapshot sessions. Right-click on the

session to see the Stop Session option shown in Figure 9.


16/22


EMC SnapView Basics


Figure 9. Stop Session


navicli h snapview stopsession test 1snapshot

This is the CLI command version of the stop session command shown in Figure 9.

To destroy a snapshot, select and right-click on the snapshot, then select the Destroy Snapshot option

shown in Figure 10. Note you cannot destroy a snapshot that is part of a storage group. You must remove

the snapshot from the storage group prior to destroying the snapshot.


17/22


EMC SnapView Basics


Figure 10. Destroy Snapshot


navicli h snapview rmsnapshot snapshotname test1

snap

Reactivating Snapshots

If you have a running session thats being used for software testing (such that the access to the snapshot

may result in corrupted data due to the nature of the test being performed), you may decide to revert thesnapshot back to the state it was in when you first activated it. You can do this simply by deactivating the

snapshot, then activating it again to the original session name. Any changes that were made to the snapshot

by the test environment are lost, and youre back to the starting point of the data as it was when the session

was created.

Using SnapView BCVsTo create a point-in-time copy of BCVs, you should first break the BCV source LUN relationship.

Breaking the BCV/source LUN synchronization is called a split or a fracture. The UI uses the term

fracture. A split merely breaks the mirror and starts recording changes in the bitmap for the BCV. Figure

11 shows how you split a BCV from a source using fracture.


18/22


EMC SnapView Basics


Figure 11. Splitting a BCV from the Source LUN

Rules and RecommendationsThe basic rules and recommendations associated with the use of SnapView are:

Snapshots are defined under a single source LUN. Up to eight snapshots can be defined. However, there is

no differentiation between snapshots that are inactive, other than the name you may assign to each. The

differentiation comes when activating snapshots to running SnapView sessions on the same source LUN.

Snapshots were designed to provide users the ability to present identical copies of data to hosts other than

the host connected to the source LUN, such as a separate backup server. This allows users parallel access totheir data and, thus, greater efficiency of use. EMC recommends that snapshots not be added to the same

storage group containing that snapshots source LUN, due to potential file system labeling conflicts.

Remember, the snapshot is an identical copy of the source LUN when its activated, and some operating

systems may have difficulty differentiating between two or more devices or volumes with identical labels

and, thus, allow writes to go to either device, which could result in mounting the wrong copy. This is only a

recommendation; nothing prevents you from doing this. You can define snapshots under expected source

LUNs, then add these snapshots into storage groups and connect these to hosts. These snapshots, while

inactive, are seen as offline devices by the connected operating system, and only come online when

activated to a running SnapView session. As noted in the last recommendation, when you expect to activate

multiple snapshots for the same source LUN, we expect these will be presented to different hosts (that is,

added to separate storage groups.).

We recommend performing the operations in this order:

Define your snapshots

Allocate to a storage group and host

Reboot the host to pick up the offline device

Then any time afterwards, when you activate the snapshot, you can bring it online to the operating system

without having to reboot.

This is mostly applicable when using the admsnap utility, since this performs import/export functions of

raw device, volume, and/or file system information on the activated snapshot. It is not necessary to use the


19/22


EMC SnapView Basics


admsnap utility to import/export snapshots; however, you will be required to perform all necessary steps

within the particular operating system prior to and after activating the snapshot yourself to make the device

useable by the operating system. You may have to reboot between separate snapshot accesses due to filesystem buffers buffering old file system data related to deactivated snapshots.

Another option is to begin by starting a SnapView session, then activating a snapshot and allocating this to

a storage group to be able to present this device to a backup host. It should be noted that if that storage

group wasnt already connected to the host with LUNs that had previously been presented to that host, youmay need to reboot the host to allocate HBA resources before you can access the snapshot.

To use BCVs, a Clone Private LUNmust be allocated on each SP for the added data protection of a

persistent fracture log. The clone private LUN functions similarly to the write intent log with MirrorView.

Like the write intent log, its size is 128 MB per SP (256 MB total). Figure 2 shows the process of

allocating the clone private LUNs.

SnapView BCVs must be part of a Clone Group if you wish to keep track of changes to either the source or

the BCV. This includes golden copies. Once you remove a BCV from the Clone Group, the BCV becomes

a regularLUN. There is a limit of eight BCVs per source. Additionally eight snapshots are allowed for

each BCV up to the snapshot limit for the storage system.

When a BCV is resynchronized with the source LUN, it is no longer a visible LUN. Therefore, the BCV

must be removed from any storage group before a re-synchronize operation can be performed. The BCV

will be available again upon split (fracture) and put into a storage group. You may have to reboot the host

using the BCV before the re-synchronizations, due to file system buffers buffering old file system data

related to the previous BCV version.

For more detailed information on SnapView persistence and BCVs, please refer to the documents below:

Persistent SnapView Sessions

CLARiiON BCVs

For application environment use of SnapView, please refer to the following documents:

Using EMC SnapView with Microsoft SQL Server 2000

VERITAS NetBackup Solutions for EMC CLARiiON Storage Systems in SAN Environments

LEGATO NetWorker Solutions for CLARiiON FC4700 Storage Systems in SAN Environments

Using FC4700 and SnapView with Oracle8i

found on Powerlink at http://powerlink.EMC.com.
http://powerlink.emc.com/common/downloadredirect.jhtml?DownloadUrl=%2FHighFreq%2FUsingEMCSnapViewTMwithMicrosoftSQLServer2000Revised3_14.pdfhttp://powerlink.emc.com/common/downloadredirect.jhtml?DownloadUrl=%2FHighFreq%2FH550_VERITAS_NetBackup_Solutions_for_EMC_CLARiiONStorage_Systems_in_SAN_Environments_3_24_02.pdfhttp://powerlink.emc.com/common/downloadredirect.jhtml?DownloadUrl=%2FHighFreq%2FH498_LegatoNetWorkerSol_EMC_CLARiiONinSAN_Environments.pdfhttp://powerlink.emc.com/common/downloadredirect.jhtml?DownloadUrl=%2FHighFreq%2FH630_Using_EMC_CLARiiON_FC4700_and_SnapView_with_Oracle8iLDV.pdfhttp://powerlink.emc.com/common/downloadredirect.jhtml?DownloadUrl=%2FHighFreq%2FH630_Using_EMC_CLARiiON_FC4700_and_SnapView_with_Oracle8iLDV.pdfhttp://powerlink.emc.com/common/downloadredirect.jhtml?DownloadUrl=%2FHighFreq%2FH630_Using_EMC_CLARiiON_FC4700_and_SnapView_with_Oracle8iLDV.pdfhttp://powerlink.emc.com/common/downloadredirect.jhtml?DownloadUrl=%2FHighFreq%2FH498_LegatoNetWorkerSol_EMC_CLARiiONinSAN_Environments.pdfhttp://powerlink.emc.com/common/downloadredirect.jhtml?DownloadUrl=%2FHighFreq%2FH550_VERITAS_NetBackup_Solutions_for_EMC_CLARiiONStorage_Systems_in_SAN_Environments_3_24_02.pdfhttp://powerlink.emc.com/common/downloadredirect.jhtml?DownloadUrl=%2FHighFreq%2FUsingEMCSnapViewTMwithMicrosoftSQLServer2000Revised3_14.pdf


20/22


EMC SnapView Basics


Performance ConsiderationsWhen implementing SnapView, performance considerations include:

I/O load

I/O profile

LUN placement

Additional load on storage processor

Additional LUNs

Additional IO

Consider each of these factors when appraising performance with layered software on the storage system.

Remember that SnapView works using a copy-on-first-write method. This means that if you are doing a

number of writes to the source LUN during a running SnapView session, more load is placed on the storage

processor, as it is performing additional reads from the source LUN and writes to the snapshot cache LUN

assigned to that source LUN. Response time may be affected for the production host. MirrorView works in

a way that writes are only acknowledged to the production host when the secondary write is complete. The

secondary write may incur a pre-read of data in a copy-on-first-write operation for a SnapView session

increasing the response time back at the production host. In this environment (where you want to use thesecondary for backup type operations) the enhanced capabilities of MirrorView may help. For example, if

MirrorView is used solely for secondary site backup operations, then while you have the SnapView session

running you can just administratively fracture the secondary, enabling backup of the secondary by taking a

snapshot of the mirror. This actually reduces the impact MirrorView has on the source LUN access by

removing the secondary write requirement while changes are tracked on the primary storage system by the

fracture log. After the backup of the snapshot is complete, stop the SnapView session and then reestablish

the mirror. The mirror only requires partial synchronization to come back in sync.

SnapView copy-on-first-writes work on a granularity called chunks. The chunk size is 64 KB. Each write

to a SnapView source LUN initially invokes this pre-read of data (minimum of 64 KB) and writes to the

snapshot cache LUN. Any subsequent writes to the source LUN that fall within chunks that have already

been written to the snapshot cache LUN do not incur a copy-on-first-write. That way, over time, the

amount of pre-reading and writing chunks diminishes. In the same way, over time, as more data is read

from the source LUN and written to the snapshot cache LUN, access to the snapshot affects the productionLUN less as reads and writes to the snapshot go directly to the saved data in the snapshot cache LUN(s).

Figure 12 shows chunk writes per second mapped over time. Here you can clearly see that as more data is

written to the snapshot cache LUN, fewer copy-on-first-writes occur.

Characterizing I/O from the host enables you to characterize I/O with SnapView sessions. Random writes

incur more copy-on-first-write with SnapView. Re-writes have reduced impact, as explained below. Its

worth noting that over time, the longer a SnapView session is running, the less copying-on-first-writes take

place.


21/22


EMC SnapView Basics


Figure 12. Snapshot Cache LUN I/O over Time

Performance Considerations for BCVs

Initial and subsequent full sync or restore operations are the only performance considerations for BCVs.

The initial synchronization renders the BCV identical to the source LUN. This is a physical copying of all

the data on the source LUN. This may impact performance on the source LUN for the duration of the

synchronization. The possible performance impact of a restore is directly proportional to the amount of data

that has changed. When the BCV is fractured from the source LUN, there is no performance impact to the

host.

SnapView and SAN CopySnapView snapshots and BCVs can be used as sources for SAN Copy operations. SAN Copy migrates

data from a storage system to another. The storage system can be either a CLARiiON or a Symmetrix

system. SAN Copy requires that the user quiesce the source data creating a stable image. SnapView

provides the quiesce capability that allows the administrator to SAN Copy live data to other systems for

backup, testing, or other purposes.

TroubleshootingWhen troubleshooting SnapView, there are several things to be aware of. Please reference the latest release

notes on the product for further information and warnings. The rest of this section covers potential issues

that have been discovered. This information may be helpful to customers.

Snapshot is allocated to a backup host and data appears corrupted.

This is most likely due to starting the session without putting the production data in a quiescent state. The

application should be suspended and all file system and application buffers flushed to the source LUN prior

to starting the SnapView session. If this is not done, at best youll need to run a chkdsk orfsck (file

system check) prior to accessing the snapshot, or you may find the data is not useable. This problem may

also be attributed to not using admsnap to import the snapshot to the backup server. The workaround is to

either reboot (to clear file system buffers) or use admsnap to cleanly export snapshots before re-activating

new snapshots.

Snapshot Cache LUN I/O over Time

0

50

100

150

200

250

300

350

400

450

500

14:38:24 14:45:36 14:52:48 15:00:00 15:07:12 15:14:24 15:21:36 15:28:48 15:36:00 15:43:12 15:50:24

Time

C

h

u

nk

W

r

i

t

e

s

/

S

e

c


22/22


EMC SnapView Basics

ConclusionSnapView provides flexible options to enable parallel data access facilities with low impact to production

data access. This instant capability reduces the time that production environments normally have to be

offline for backups or decision support operations. As this is storage system-based layered software,

production host impact is kept to a minimum, without loss of functionality.

This paper discussed both snapshots and BCVs used at the same time. You can also manually performmanagement using the Navisphere GUI, or scripted using NaviCLI oradmsnap. This script capability

facilitates automated operation that assists in tasks such as lights-out backup operations where production

data needs to be maintained and available during backup windows.

SnapView leverages the power of the EMC CLARiiON product line, adding functionality without

compromise.

1Snapview Basics

Documents

Transcript of 1Snapview Basics