Engineering White Paper

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

EMC CONFIDENTIAL

6/24/2003

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 EMC SnapView Basics Revision 2.0 and Above

EMC CONFIDENTIAL

6/24/2003

Table of Contents
Executive Summary ............................................................................................4 Intended Audience ..............................................................................................4 Introduction .........................................................................................................4 SnapView Terminology.......................................................................................5
Limits ............................................................................................................................................ 6 Installation .................................................................................................................................... 6 ConfigurationSnapshots ........................................................................................................... 7 Setting Up Persistence ............................................................................................................. 8 ConfigurationBCVs ................................................................................................................... 8 Using SnapView Snapshots ....................................................................................................... 10 Reactivating Snapshots .......................................................................................................... 17 Using SnapView BCVs............................................................................................................... 17 Rules and Recommendations .................................................................................................... 18 Performance Considerations...................................................................................................... 20 Performance Considerations for BCVs................................................................................... 21 SnapView and SAN Copy .......................................................................................................... 21 Troubleshooting.......................................................................................................................... 21

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

EMC SnapView Basics Revision 2.0 and Above

EMC CONFIDENTIAL

6/24/2003

Executive Summary
This 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 clarifies differences between some of the implemented features of prior revisions.

Intended Audience
This 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.

Introduction
SnapView 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 processing without 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 on first 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. The synchronize 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, are full copies of the data, whereas snapshots are essentially views of the data. Those familiar with Symmetrix TimeFinder will see that SnapView BCVs 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.

EMC SnapView Basics Revision 2.0 and Above

EMC CONFIDENTIAL

6/24/2003

SnapView Terminology
The 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 well as 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 is allocated, 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 titled Persistent 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

EMC SnapView Basics Revision 2.0 and Above

EMC CONFIDENTIAL

6/24/2003

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.

Limits
The 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
Snapshot LUNs per storage system Snapshot cache LUNs per storage system Concurrent sessions per storage system Snapshot LUNs per source LUN Active snapshot sessions per source LUN Number of BCVs per storage system Number of BCVs per LUN Number of snapshots per BCV

CX600, FC4700
300 100 100 8 8 100 2 8 8

CX400
150 50 50 8 8 50 2 8 8

Installation
SnapView 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 also required, 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 the EMC SnapView 2.X for EMC ControlCenter Navisphere 6.X Administrator's Guide (069001180) and EMC SnapView Version 2.X Command Line Interfaces Reference (069001181).

This total includes sources and BCVs. It also includes the MirrorView primary and secondary images on a storage system.

EMC SnapView Basics Revision 2.0 and Above

EMC CONFIDENTIAL

6/24/2003

ConfigurationSnapshots
After 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.

EMC SnapView Basics Revision 2.0 and Above

EMC CONFIDENTIAL

6/24/2003

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.

ConfigurationBCVs
After 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.

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

EMC SnapView Basics Revision 2.0 and Above

EMC CONFIDENTIAL

6/24/2003

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

EMC SnapView Basics Revision 2.0 and Above

EMC CONFIDENTIAL

6/24/2003

Using SnapView Snapshots

Now 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 the EMC SnapView 2.X for EMC Control Center Navisphere 6.X Administrator's Guide (069001180) and the EMC SnapView Version 2.X Command Line Interfaces Reference (069001181). For the purposes of this 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. 2. 3. 4. Right-click on the desired LUN. Select Start Session. Enter a session name Click OK.

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. 2. 3. 4. Right-click on the storage system. Select Start Session. In the dialog box that appears, select the source LUNs you want in this session and give the session a name. Click OK to 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.

EMC SnapView Basics Revision 2.0 and Above

10

EMC CONFIDENTIAL

6/24/2003

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 <SP-A-IP-address> snapview startsession test2_snap -luns 8 11 0 navicli h <SP-B-IP-address> snapview startsession test3_snap 12 1 -luns 9

Up to two separate startsession commands may be required when using the CLI, one for each source LUN owner 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.

EMC SnapView Basics Revision 2.0 and Above

11

EMC CONFIDENTIAL

6/24/2003

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 <SP-A-IP-address> snapview createsnapshot 0 new_snap snapshotname

EMC SnapView Basics Revision 2.0 and Above

12

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

6/24/2003

Figure 6. Storage Group Properties Dialog Box The appropriate NaviCLI command to perform the same function is: navicli h <SP-IP-address> storagegroup addsnapshot gname SUN1snapshotname 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.

EMC SnapView Basics Revision 2.0 and Above

13

EMC CONFIDENTIAL

6/24/2003

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 connected host 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. The appropriate NaviCLI command to perform the same function is: navicli h <SP-IP-address> 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.

EMC SnapView Basics Revision 2.0 and Above

14

EMC CONFIDENTIAL Figure 8 shows a summary of all sessions running.

6/24/2003

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 the EMC SnapView 2.X for EMC ControlCenter Navisphere 6.X Administrator's Guide (069001180) and the EMC SnapView Version 2.X Command Line Interfaces Reference (069001181) for more details on admsnap. 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.

EMC SnapView Basics Revision 2.0 and Above

15

EMC CONFIDENTIAL

6/24/2003

Figure 9. Stop Session The appropriate NaviCLI command to perform the same function is: navicli h <SP-IP-address> 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.

EMC SnapView Basics Revision 2.0 and Above

16

EMC CONFIDENTIAL

6/24/2003

Figure 10. Destroy Snapshot The appropriate NaviCLI command to perform the same function is: navicli h <SP-IP-address> 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 the snapshot 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 BCVs

To 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.

EMC SnapView Basics Revision 2.0 and Above

17

EMC CONFIDENTIAL

6/24/2003

Figure 11. Splitting a BCV from the Source LUN

Rules and Recommendations

The 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 to their 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 EMC SnapView Basics Revision 2.0 and Above

18

EMC CONFIDENTIAL

6/24/2003

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 file system 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, you may need to reboot the host to allocate HBA resources before you can access the snapshot. To use BCVs, a Clone Private LUN must 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 regular LUN. 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.

EMC SnapView Basics Revision 2.0 and Above

19

EMC CONFIDENTIAL

6/24/2003

Performance Considerations
When 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 the secondary 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 production LUN 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.

EMC SnapView Basics Revision 2.0 and Above

20

EMC CONFIDENTIAL
Snapshot Cache LUN I/O over Time
500 450

6/24/2003

C h u n k W r i t e s / S e c

400 350 300 250 200 150 100 50 0 14:38:24 14:45:36 14:52:48 15:00:00 15:07:12 15:14:24
Time

15:21:36

15:28:48

15:36:00

15:43:12

15:50:24

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 Copy

SnapView 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.

Troubleshooting
When 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 or fsck (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. EMC SnapView Basics Revision 2.0 and Above

21

EMC CONFIDENTIAL

6/24/2003

Conclusion
SnapView 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 perform management using the Navisphere GUI, or scripted using NaviCLI or admsnap. 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.

EMC SnapView Basics Revision 2.0 and Above

22