VNX Local Protection Suite Foundations

Welcome to VNX Local Protection Suite Foundations.
Copyright 2011 EMC Corporation. All rights reserved. These materials may not be copied without EMC's written consent. EMC believes the information in this publication is accurate as of its publication date. The information is subject to change without notice. THE INFORMATION IN THIS PUBLICATION IS PROVIDED AS IS. EMC CORPORATION MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND WITH RESPECT TO THE INFORMATION IN THIS PUBLICATION, AND SPECIFICALLY DISCLAIMS IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Use, copying, and distribution of any EMC software described in this publication requires an applicable software license. EMC , EMC, EMC ControlCenter, AdvantEdge, AlphaStor, ApplicationXtender, Avamar, Captiva, Catalog Solution, Celerra, Centera, CentraStar, ClaimPack, ClaimsEditor, ClaimsEditor, Professional, CLARalert, CLARiiON, ClientPak, CodeLink, Connectrix, Co-StandbyServer, Dantz, Direct Matrix Architecture, DiskXtender, DiskXtender 2000, Document Sciences, Documentum, EmailXaminer, EmailXtender, EmailXtract, enVision, eRoom, Event Explorer, FLARE, FormWare, HighRoad, InputAccel,InputAccel Express, Invista, ISIS, Max Retriever, Navisphere, NetWorker, nLayers, OpenScale, PixTools, Powerlink, PowerPath, Rainfinity, RepliStor, ResourcePak, Retrospect, RSA, RSA Secured, RSA Security, SecurID, SecurWorld, Smarts, SnapShotServer, SnapView/IP, SRDF, Symmetrix, TimeFinder, VisualSAN, VSAM-Assist, WebXtender, where information lives, xPression, xPresso, Xtender, Xtender Solutions; and EMC OnCourse, EMC Proven, EMC Snap, EMC Storage Administrator, Acartus, Access Logix, ArchiveXtender, Authentic Problems, Automated Resource Manager, AutoStart, AutoSwap, AVALONidm, C-Clip, Celerra Replicator, CLARevent, Codebook Correlation Technology, Common Information Model, CopyCross, CopyPoint, DatabaseXtender, Digital Mailroom, Direct Matrix, EDM, E-Lab, eInput, Enginuity, FarPoint, FirstPass, Fortress, Global File Virtualization, Graphic Visualization, InfoMover, Infoscape, MediaStor, MirrorView, Mozy, MozyEnterprise, MozyHome, MozyPro, NetWin, OnAlert, PowerSnap, QuickScan, RepliCare, SafeLine, SAN Advisor, SAN Copy, SAN Manager, SDMS, SnapImage, SnapSure, SnapView, StorageScope, SupportMate, SymmAPI, SymmEnabler, Symmetrix DMX, UltraFlex, UltraPoint, UltraScale, Viewlets, VisualSRM are trademarks of EMC Corporation. All other trademarks used herein are the property of their respective owners.
Copyright 2011 EMC Corporation. Do not Copy - All Rights Reserved.
This foundation level course provides participants with an understanding of VNX Local Protection Suite solutions. This course provides an overview of VNX SnapView, VNX SnapSure, and RecoverPoint/SE CDP architecture, functionality, and theory of operation.
This lesson familiarizes the student with the VNX Family Local Protection Suite.
Local replication can significantly enhance your current business and technical operations by providing you with access points to production data; enabling parallel-processing activities like backups, as well as disk-based recovery after logical corruptions; and creating test environments for faster time to revenue for applications.
Every business strives to increase productivity and usage of its most important resource information. This asset is key to finding the right customers, building the right products, and offering the best service. The greater the extent to which corporate information can be shared, re-used, and taken advantage of, the greater competitive advantage a company can gain.
EMC offers local snapshots for Block (VNX SnapView) and File (VNX SnapSure) as well as a Continuous Data Protection software option (RecoverPoint/SE), to provide the broadest set of native local replication capabilities in the market. It should be noted that the suite includes RecoverPoint/SE software only. However, to use RecoverPoint/SE with the VNX solution also requires RecoverPoint/SE hardware appliances, which will need to be ordered separately.
VNX SnapView is a group of software products that run on the VNX. Having the software present on the array has several advantages over host-based products. Since SnapView snapshots execute on the storage system, no host processing cycles are spent managing information.
Snapshots allow companies to make efficient use of their most valuable resource - information - by enabling parallel information access. Snapshots allow multiple business processes to have concurrent, parallel access to information.
SnapView creates block based logical point-in-time views of production information using snapshots, and point-in-time 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.
This lesson familiarizes the student with an overview on the VNX SnapView block-based replication features.
VNX SnapView allows companies to make more effective use of their most valuable IT resources by enabling parallel information access. Instead of traditional sequential information accessforcing applications to queue for information accessSnapView allows multiple business processes to have concurrent, parallel access to information.
SnapView is a single product for point-in-time snapshots and full image clones. Replicas can be made readable and writeable by assigning them to the storage group of a chosen host and then using the logical volume management of that host to mount the drives.
VNX SnapView products (snapshots and clones) enable users to perform various tasks on a given data set as required in a typical business environment without compromising the access to data. SnapView technologies have a wide variety of business uses. SnapView is designed to allow system backups to run concurrently with application processing. Even though backups are the primary use of SnapView, it is versatile enough to be used in other ways. For critical applications, point-in-time copies may be taken every hour. This allows easy recovery from corrupted or damaged files. Decision support systems may also use point-in-time copies, and thus real data, with minimal effect to the application. Other uses for point-in-time copies include local data replication and making copies of data to be used as a source for remote data replication. For backup purposes, consistent data must be written to the backup medium. This requires host buffers to be flushed and I/O to be halted until such time as the backup is completed. Without the use of point-in-time technology, that downtime could be several hours. If the application uses several related LUNs for storage say tables and logs are all on separate LUNs then all those LUNs must be in the same state when the backup is performed. SnapView can take care of this as well. Consistency support is part of the feature set for SnapView snapshots and SnapView clones.
SnapView allows the user the choice of snapshots and/or clones. The choice of which method to use depends on the specifics of the environment. Some considerations are the performance impact of the chosen method and whether or not the copy is required to be available immediately. All snapshot sessions are automatically persistent and save metadata to their Reserved LUNs. An advantage of snapshots over clones is if there is logical corruption of the data, e.g., if someone formats the disk (Source-LUN), this would be distributed to the clone(s) immediately if they are still synchronized. In this example, the data on both the source and the clone would be lost. However, on the snapshot the data would not have changed at all. Point-in-time copies are also useful for backups and other operations. If there is a need to return the Source LUN to a previous data state, both clones and snapshots are capable of doing so. Clones, however, achieve their persistence by tracking changed data extents using Clone Private LUNs. They can therefore survive planned and unplanned events, such as component failures, and the loss of power. Snapshots and clones have an optional consistency feature which allows data to be copied from multiple Source LUNs at exactly the same point in time. This ensures that data stored across several LUNs, such as database data and database logs, can be used to create a useable pointin-time copy. Unisphere allows easy management of SnapView features. Unisphere has been simplified by the addition of two wizards, one each for clones and snapshots. The wizards allow the user to create point-in-time copies without having to get involved in complex details.
SnapView gives the user access to both snapshot and clone technology. The two methods of making point-in time copies are independent. They use vastly different block based replication mechanisms and have limits which are independent of each other. SnapView snapshots use pointers to indicate where data is currently located. It may be on the Source LUN (Traditional, Thin, or Thick) or may have been copied to the Reserved LUN Pool. As a result of the Copy on First Write (COFW) technology used, SnapView snapshots may use appreciably less additional space than a full copy, such as a SnapView clone, would use. As a rough guide, a snapshot will use around 20% of the space occupied by its Source LUN. SnapView clones, on the other hand, make a full copy of the Source LUN data, and therefore use additional disk space equal to 100% of the space occupied by the Source LUN. Because clone data can be copied back to the Source LUN, there is a requirement that Source LUN and clone be exactly the same size. When a clone is fractured, changes to the clone or its Source LUN are tracked in the Fracture Log. The operation of the Fracture Log will be discussed later. Management of clones and snapshots can be performed through Unisphere or Navisphere Secure CLI. A host-based utility, admsnap, can perform a subset of the SnapView management operations as well. The Secure CLI uses the same security features embodied in Unisphere. Users are authenticated via a username, password, and 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 and there is a different version for each operating system platform.
Copyright 2011 EMC Corporation. Do not Copy - All Rights Reserved. 10
Some snapshot terms are defined here. These terms are referred to throughout the training. Note that any host may have only one view of a LUN active at any time (except as noted previously). It may be the Source LUN itself, or one of the eight permissible snapshots or clones. If the SnapView copy is to be used for testing, or for backup using file system access, then the production host and secondary host must be running the same operating system. If raw backups are being performed, then the file system structure is irrelevant, and the backup host need not be running the same operating system as the production host. The production host is where customer production applications are executed. The backup or secondary host is where the snapshot or clone is accessed from. Note that certain software, such as Replication Manager, and some operating systems, such as ESX Server, have mechanisms built in that allow a host to view two or more replicas of a LUN without conflict. 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.
11
The Source LUN is the production LUN that will be replicated. This is the LUN that is in use by the application and it is not visible to secondary hosts. The Source LUN is the LUN which is in use by the application. It is not visible to secondary hosts. Source LUNs can be traditional LUNs, that is, a LUN built on a RAID Group, or Thin LUNs or thick, LUNs that are built on a Pool.
When a snapshot is activated, it is made available to a snapshot 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 snapshot 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 by adding LUNs if additional space is needed. If the RLP has been configured too large, then the area may also be reduced in size by removing unused LUNs. Note that the total number of Reserved LUNs is limited and is model-dependent.
12
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 Copy on First Write (CoFW) 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 snapshot uses to perform CoFW operations. The chunk size is set to 64 KB (128 blocks). You cannot change this value.
13
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 synchronization. Synchronizing a fractured clone, updates the contents on the clone with its Source LUN and left clone on synchronize status. 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 about data extents modified in the Source LUN and clone LUN after you have fractured the clone. A modified data extent is a section 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 as the software copies only modified (changed) extents.
14
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 Storage Groups on the storage system. The storage group must be connected to the secondary server that activates 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 Replication Manager or VMware ESX Server to put the snapshot in the storage group. This software or server provides the same host access to the snapshot and the Source LUN. You must add one or more Reserved LUNs to the global Reserved LUN Pool.
15
In our example shown here, after creation of SnapView point-in-time copies of data, the replica LUNs can be made accessible to hosts. The point-in-time copy is made available to the backup host by being placed into the backup hosts storage group. Of course, multiple point -in-time copies are allowed, so the total number of LUNs may be greater than the two mentioned. The scenario shown here shows a Source LUN and three point-in-time images of the data. Image 3 is used by the test host, while the backup host has a choice of Image 1 or Image 2 for performing the backup. It may use only one of the two at any given time. Allowing simultaneous access to two or more views of the same LUN is not supported. The exception is when they are managed by EMC Replication Manager or other software which explicitly allows multiple data images to be visible to a host. A snapshot or clone is a perfect copy of the Source, and will have the same operating system signature as the Source LUN. As a result, presenting the image back to the host that owns the Source LUN causes problems at the operating system level most operating systems cannot successfully handle accessibility to multiple copies of the same volume. One exception is VMwares ESX Server, because of its ability to natively resignature volumes.
16
This slide compares SnapView clones to SnapView snapshots. While both clones and snapshots are each point-in-time views of a Source LUN, the essential difference between them is that clones are exact copies of their sources (with fully populated data in the LUNs), and are not based on pointers. It should be noted that creating clones takes more time than creating snapshots, since the former requires actually copying data. A clone can be described as a copy of the data, whereas a snapshot is a view of the data. Another benefit to the clones having actual data, rather than pointers to the data, is that the performance penalty associated with the Copy-on-First-Write mechanism is avoided. Clones generate a much smaller performance load on the source LUN than do snapshots. If the source LUN has a heavy write load, especially if those writes are randomly distributed on the LUN, then a clone has a lower performance impact than a snapshot. Because clones are exact replicas of their source LUNs, they generally take more space than SnapView Reserved LUNs, since the Reserved LUNs only store the Copy-on-First-Write data. The exception is where every chunk on the source LUN is written to and must be copied into the reserved LUN. In that case, the entire LUN is copied and the copied data, in addition to the metadata describing it, results in the contents of the Reserved LUN being larger than the Source LUN itself. An additional clone advantage is that a clone can be moved to the peer SP for load balancing. It is automatically trespassed back to the owning SP for synchronization operations. Since only part of the data used by a snapshot is saved in the Reserved LUN Pool, it requires that the Source LUN be present and healthy for its operation. If the Source LUN suffers a catastrophic failure, the snapshot is worthless. A clone, in contrast, is independent of the source LUN once it is fractured. If it has been created on separate physical disks, as per best practice, then even a catastrophic Source LUN failure leaves clone data available for use.
17
This lesson familiarizes the student with VNX SnapView features and functionality.
18
The VNX storage system has been configured to use a reserved LUN Pool in order to take advantage of its SnapView snapshot features. The Reserved LUN Pool is global to the VNX storage system, though in general use some LUNs are used by SPA and other LUNs are used by SPB. The LUNs that are used in the Reserved LUN Pool are created in the typical manner, but instead of being placed in Storage Groups and allocated to hosts, they are used internally by the storage system software. The graphic here shows the LUNs referred to as private LUNs private in this case indicating that they cannot be used, or seen, by attached hosts. A Reserved LUN, like any other LUN, is owned by only one SP at any time and may be trespassed if necessary, for example, should an SP should fail. Each storage system model has a maximum number of LUNs it will support and therefore each also has a maximum number of LUNs which may be added to the Reserved LUN Pool. Those limits define the maximum number of snapshot Source LUNs on the storage system. See the latest VNX Release Notes for these limits. The first step in SnapView is usually the assignment of LUNs to the reserved LUN Pool. Only then are SnapView sessions allowed to start. Remember that as snapable LUNs are added to the storage system, the Reserved LUN Pool size may have to be reviewed. Changes may be made online. LUNs used in the Reserved LUN Pool are not host-visible, but they do count towards the maximum number of LUNs allowed on a storage system.
19
In this slide, LUN 1 and LUN 2 have been changed to Source LUNs by the creation of one or more snapshots on each. Three sessions will be started on those Source LUNs. Once a session starts, the SnapView mechanism is tracking changes to the LUN and Reserved LUN Pool space is required. Well look at how that happens in the example above:
Session 1a is started on Source LUN 1, and associated with snapshot 1a Private LUN 5 in the reserved LUN Pool is immediately allocated to Source LUN 1, and
changes made to that source LUN are placed in Private LUN 5
A second session, session 1b, is started on the Source LUN and associated with
snapshot 1b; changes to the Source LUN are still saved in Private LUN 5
When Private LUN 5 fills up, SnapView allocates the next available LUN, Private LUN 6,
to source LUN 1, and the process continues
Sessions 1a and 1b now store information in Private LUN 6 as well as Private LUN 5 A session is then started on Source LUN 2, and Private LUN 7. A new Reserved LUN is
allocated to it, since Source LUNs cannot share a Private LUN
Once that LUN fills, Private LUN 8 is allocated

If, in this example, all private LUNs have been allocated and session 1b causes Private LUN 6 to become full, then session 1b is terminated by SnapView. SnapView notifies the user via the SP Event Log (and if Event Monitor is active, in other user-configurable ways) that the reserved LUN Pool is filling up. This notification allows ample time to correct the condition. Notification takes place when the reserved LUN Pool is 50% full, then again at 75%, and every 5% thereafter.
Copyright 2011 EMC Corporation. Do not Copy - All Rights Reserved. 20
Rules that govern the RLP are as follows: When a Reserved LUN fills to capacity then SnapView will allocate another currently unused Reserved LUN to the source LUN. If there are no Reserved LUNs available then the session that initiated the copy-on-first-write (COFW) will be terminated. This means that the point-in-time (PIT) copy will be lost. All space in the RLP that was allocated to this session will now be freed up. This may, but will not necessarily, free one or more Reserved LUNs. The reason why it may not necessarily free up one or more Reserved LUNs is because there may be multiple sessions sharing the LUNs. Space that has been freed up is available for other sessions currently in use that are using those Reserved LUNs. Example four (4) sessions are running on a Source LUN (LUN1) to which Reserved LUN LUN5 has been allocated. The fourth session fills up the capacity of the LUN5 and there are no other LUNs available in the RLP to continue. At this point session #4 will terminate. The space that was in use by it will be freed up and can be used by the other sessions (sessions 1-3) if they are in need of extra space. Any other sessions, that are using different Source LUNs, will not be able to use this extra space that has been made available. However, a new session create on the same Source LUN (LUN1) could use this space.
21
Requirements for sizing the RLP vary based on the environment. As a guide, consider small LUNs, keeping in mind that at least one LUN must be allocated for every Source LUN that has a running session. Snapshot write activity must also be considered. The read-write ratio 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 that CoFW activity will continue consuming additional space.
22
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 of a different size, although a compromise is to make them all identical. Allocation of Reserved LUNs to Source LUNs is based on the next available Reserved LUN, without regard to size. This means that there is no mechanism to ensure that a specified Reserved LUN is allocated to a specified Source LUN. Due to the dynamic nature of the snapshot environment, an assignment may be regarded as a random event (although, in fact, there are rules governing the assignment of Reserved LUNs).
23
The Copy on First Write (or CoFW) factor 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%. The example on the slide 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. Note: If a session is active while data is being migrated to the source LUN, then the snap requires the same space as the amount of data being migrated to the source LUN. The calculations on this slide are based on a change rate of 10% to the source LUN only. Therefore it is a good practice to start snap sessions only after a data migration has finished to the source LUN.
24
A VNX snapshot session is a point-in-time copy of a Source LUN. The session keeps track of how the Source LUN looks like at a particular point in time. After you start a snapshot session and as the production server writes to the Source LUN, the software stores a copy of the original data in the Reserved LUN pool in chunks. This process 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. A secondary server then activates (maps) a snapshot to the snapshot session. The snapshot views the original Source LUN data chunks that have been modified since the user started the session from the Reserved LUN pool and the unmodified data chunks from the Source LUNs. You must give each session a name when you start the session. The name persists throughout the session and is viewable through Unisphere. Use the name to determine session status and to stop the session.
25
Once the Reserved LUN Pool is configured and snapshots are created on the selected Source LUNs, the user can start a snapshot session. This procedure may be performed from Unisphere, Navisphere Secure CLI, or the admsnap utility on the production host. The user must provide a session name. This name is used later to activate a snapshot.
Sessions can be created on a single Source LUN or, for consistency purposes, on multiple Source LUNs. When sessions are running, they may be viewed from Unisphere, or information may be gathered by using Navisphere Secure CLI. All sessions are displayed under the sessions container in the GUI.
26
All sessions are created as persistent sessions and the persistence cannot be disabled. The 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 applies to sessions only, not to snapshots or Source LUNs. In the event of a failure, Source LUNs trespass to the other SP. Depending on the 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. The Consistent mode preserves the point-in-time restartable copy across a set of Source LUNs. This 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. The Consistent mode also prevents you from adding other LUNs to the session.
27
In this slide a Snapshot session has been activated and started but no information has changed as of yet on the Source LUN. A secondary server can activate (map) a snapshot to the snapshot 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 LUNs. You must give each session a name when you start the session. The name persists throughout the session and is viewable through Unisphere. Use the name to determine session status and to stop the session.
28
The Copy on First Write mechanism involves saving an original data block into the Reserved LUN Pool when that data block is changed for the first time on the Source LUN. The chunk is saved only once per snapshot. Multiple snapshots are allowed of the same LUN. This ensures that the view of the LUN is consistent and, unless writes are made to the snapshot, it is 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 available disk space; 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.
29
VNX snapshots use the CoFW process to handle writes to the production data during a running session. In our example on this slide, our snapshot session is still active and started on the production LUN. When the host, that owns the Source LUN, attempts to write to the data on the production LUN, the original Chunk C, in this example, is first copied to the Reserved LUN Pool, then the write is processed against the production LUN. This maintains the consistent, point-intime copy of the data for the ongoing snapshot. A view by the mount host of the mounted snapshot would point to both the unchanged data on the active LUN, plus the original data that was copied to the RLP.
30
Once you have at least one snapshot 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 Navisphere Secure 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 determines if any device is part of a snapshot 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.
31
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 nondestructive manner. Rollbacks operate independently of any other sessions or snapshots that may be defined in the Source LUN. The Snapshot rollback feature allows the user to restore the contents of a Source LUN almost instantaneously to the point in time that any of the snapshot sessions for that Source LUN were started.
32
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.
33
SnapView can be used in conjunction with clones. Users can replicate a source production LUN using a clone to create a fully recoverable copy of their production data. The clone can be used as a source for starting a session. Multiple copies can be taken. A snapshot activated on a snapshot 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. Snapshots can be used with both MirrorView primary and secondary images. The Snapshot rollback feature provides an extra level of protection for VNX MirrorView. If a failure occurs on the primary image, sessions running on the primary or secondary images can restore the image by performing a rollback.
34
A clone is a complete copy of a Source LUN that uses copy-based technology. You need to specify a Source LUN when you create a clone group. The copy process 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 a 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.
35
VNX Clones offer several advantages in certain situations. As 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 loss of one (due to human or application error) does not affect the data contained in the other. Clone Time of Fracture allows the user to know the date and time when the clones were administratively fractured.
36
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 synchronizing or reverse synchronizing. 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 Clone LUNs (LUNs participating in any clone group as either a Source LUN or a clone) Snapshot LUNs Private LUNs (LUNs reserved as Clone Private LUNs or for the Reserved LUN Pool)
37
Clone synchronization copies source data to the clone. Any data on the clone is overwritten with source data. A Clone Private LUN is a LUN of at least 1 GB that is allocated to an SP and must be created before any other clone operations can commence. Clone Private LUNs record information about modified data extents on the Source LUN and clone LUN after the clone is fractured. A modified data extent is an extent 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. The log reduces the time it takes to synchronize or reverse synchronize a clone and its Source LUN as the software copies only modified extents. Source LUN access is allowed during synchronization with the use of mirroring. The clone, however, is inaccessible during synchronization. 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.
38
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 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 reverse synchronization, the software automatically copies to the clone any incoming server writes to the Source LUN.
39
The Protected Restore feature protects the data on a clone during reverse synchronization. When you select this feature during 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 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 the data to its Source LUN. After the reverse synchronization is complete, the software fractures the clone that initiated the reverse synchronization.
You can enable the Protected Restore feature on a per-clone basis, but not on a per-clonegroup basis. During 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 to be copied to the clone during reverse synchronization, you must check the Use the Protected Restore check box in the Add Clone dialog box before initiating reverse synchronization.
40
Reverse synchronization copies clone data to the Source LUN. Data on the source is overwritten with clone data. As soon as the reverse synchronization 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.
41
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 Unisphere or Navisphere Secure CLI. The clones that 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 clone within the group was fractured prior to the failure, the software re-synchronizes that clone.
42
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 Unisphere as administratively fractured. If there is a failure on any of the clones, the consistent fracture fails on all of the clones. If any clone within the group was fractured prior to the failure, the software re-synchronizes that clone.
43
Clones can be used with snapshots as well as other VNX block based replication software such as 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.
44
This lesson familiarizes the student with SnapSure terminology and operating principles.
45
VNX SnapSure saves disk space and time by allowing multiple snapshot versions of a VNX file system. These logical views are called snapshots. SnapSure snapshots can be read-only or read/write. SnapSure is not a discrete copy product and does not maintain a mirror relationship between source and target volumes. It maintains pointers to track changes to the primary file system and reads data from either the primary file system or from a specified copy area. The copy area is referred to as a savVol, and is defined as a VNX Metavolume.
46
VNX SnapSure creates a point-in-time view of a file system. SnapSure creates snapshot (previously referred to as a checkpoint) file system that is not actually a copy or a mirror image of the original file system. Rather, the snapshot file system is a point -in-time copy of what the production file system looked like at a particular time and is not an actual file system at all. The snapshot is a read only view of the production file system prior to changes at that particular time.
47
VNX SnapSure is part of the VNX and VNXe Local Protection Suite. The Local Protection Suite provides snapshots for instant recovery on file and block storage.
48
VNX SnapSure snapshots provide users with multiple point-in-time views of their data. In the illustration above the users live-production data is my_file. If they need to access what that file looked like on previous days, they can easily access read-only versions of that file as viewed from different times. This can be useful for restoring lost files or simply for checking what the data looked like previously. In this example, snapshots were taken on each day of the week.
49
Some business applications benefit from the ability to work from a file system that is not in a state of change. Fuzzy backups can occur when performing backups from a live file system. Performing backups from a snapshot of a file system provides a consistent point-in-time source and eliminates fuzzy backups. Applications such as Replicator require a baseline copy of the production file system during setup. This baseline requires a consistent point-in-time, read-only file system from which to copy the data. A writeable snap allows the modification of data within the Snapshot for testing purposes.
50
Read-only and writeable snapshots can serve as a direct data source for applications that require point-in-time data. Such applications include simulation testing, data warehouse population, and automated backup engines performing backup to tape or disk. You can also use a read-only or a writeable snapshot to restore a PFS or part of a file system, such as a file or directory, to the state in which it existed when the snapshot was created. Writeable snapshots can also serve as a source for applications that requires incremental, temporary changes. For example, a writeable snapshot of a database hosted on a share can be subjected to data processing and warehousing without committing the changes to the production database. Another example is that of a software patch applied on a database. An administrator first applies the patch on the databases writeable snapshot and tests it before applying the patch on the production database.
51
PFS The PFS is NAS file system. The PFS must be mounted, and is usually exported for client read and write access. Applications that require access to the PFS are referred to as PFS Applications. Snapshot A logical point-in-time view of the PFS. VNX SnapSure uses a combination of live PFS data and saved data to display what the file system looked like at a particular point-in-time. A snapshot is thus dependent on the PFS and is not a disaster recovery solution. It is NOT a physical copy of a file system; its is a logical copy that depends on the integrity of the PFS. SavVol Each PFS with a snapshot has an associated save volume, or SavVol. The first change made to each PFS data block following a snapshot triggers VNX SnapSure to copy that data block to the SavVol. It also holds the changes made to a writeable snapshot. Bitmap VNX SnapSure creates and maintains a bitmap that holds one bit for every data block in the PFS. The bit values are initialized to zero, which indicates that the value of the corresponding PFS block has not changed since the Checkpoint was established. Bit values are changed to one after the first write has been made to a data block. An individual Bitmap for a each writeable snapshot is used to track the changes made to it. Blockmap A blockmap of the SavVol is maintained to record the address in the SavVol of each saved data block. Writeable snapshots use a blockmap as well. Baseline Checkpoint Read-only snapshot from which a writeable snapshot can be created.
52
This lesson familiarizes the student with SnapSure architecture, functionality, and components.
53
In the next few slides, we will see how SnapSure works in capturing data from file system modifications and providing data to users and applications. Displayed on this slide is a PFS with data blocks containing the letters A through F. When the first file system snapshot is created, a SavVol is also created on disk to hold the bitmap, the original data from the PFS, and that particular snapshots blockmap. Each bit of the bitmap will reference a block on the PFS.
54
Next, we are going to have a user or application make some modifications to the PFS. In this case, we are writing an H in the place of the B, and a K in the place of the E. Before these writes can take place, SnapSure will place a hold on the I/Os and copy the B and E to the SavVol. Then the blockmap will be updated with the location of the data in the SavVol. In this example, the first column of the blockmap refers to the block address in the PFS, and the left column refers to the block address in the SavVol. Next, the bitmap is updated with 1s wherever a block has changed in the PFS. A 0 means that there were no changes for that block. After all this process takes place, SnapSure will then release the hold and the writes can be established. If these same two blocks are modified once again, the writes will go through and nothing will be saved in the SavVol. This is true because the Copy on First Write principal - we already saved the original data from that point in time and anything after that is not Snap1s responsibility.
55
When a second snapshot is created, another blockmap will be created in the same SavVol as the old snapshot. The bitmap is then reset to all 0s and now refers to Snap2, which is the newest snapshot.
56
For our next example, we have an application modifying the first, second, and sixth blocks in the PFS with the letters J, L, and S. SnapSure will hold these writes, copy the original data in the SavVol, and update the bitmap and Snap2s blockmap.
57
If a user or application decides to access Snap2, SnapSure will check the bitmap for any PFS blocks that were modified. In this case, the first, second, and sixth blocks were modified. The data for these blocks will come from the SavVol. Everything else will be read from the PFS.
58
When an older snapshot is accessed, like Snap1 for example, SnapSure cannot depend solely on the bitmap because it refers to the newest snapshot. SnapSure will have to access the desired snapshots blockmap to check for any data that has been copied to the SavVol. In this case, well take the first and second blocks from the SavVol and use the data to fill the second and fifth blocks of Snap1. SnapSure will continue to read all of the old blockmaps in the order of creation as it makes its way to the newest snapshot.
59
Once SnapSure arrives at the newest snapshot, the bitmap can then be utilized to determine any other blocks that have changed in the PFS. In the example above, the bitmap says that the first, second, and sixth blocks have changed in the PFS. Notice that we already have the second block in the PFS accounted for with a B from the previous slide due to blockmap1. If SnapSure finds blocks that already have been accounted for, it will simply skip it and go to the next block that is represented in the bitmap.
60
The VNX allows up to 1 GB of physical RAM per Data Mover to page the bitmap and blockmaps for all the PFS that have snapshots. The 1 GB also ensures that sufficient Data Mover memory is available for VNX file Replicator. For systems with less than 4 GB of memory, a total of 512 MB of physical RAM per Data Mover is allocated for the blockmap storage. Each time a snapshot is read, the system queries it to find the required data blocks location. For any snapshot, blockmap entries needed by the system, but not resident in main memory are paged in from the SavVol. The entries stay in main memory until system memory consumption requires them to be purged. A bitmap will consume 1 bit for every block (8 KiB) in the PFS. The blockmap will consume 8 bytes for every block (8 KiB) in the snapshot. Once a second snapshot is created, still one bitmap exists. There is one bitmap for the most recent snapshot only. Blockmaps exist for every snapshot created. The server_sysstat command with the -blockmap switch will provide the Data Mover memory space currently being consumed by all of the blockmaps. The following slide shows an example of calculating the SnapSure memory requirements for a 10 GB PFS that has two snapshots created.
61
VNX SnapSure requires a SavVol to hold data. When you create the first snapshot of a PFS, VNX SnapSure will create and manage the SavVol automatically. SavVol sizes The following criteria is used for automatic SavVol creation:
If PFS > 20GB, then SavVol = 20GB If PFS < 20GB and PFS > 64MB, then SavVol = PFS size If PFS < 64MB, then SavVol = 64MB
Extends by 20GB if snapshot reaches a high water mark
If you create another snapshot, VNX SnapSure uses the same SavVol, but logically separates the point-in-time data using unique snapshot names. Custom SavVol Creation The SavVol can be manually created and managed. Please see Using VNX SnapSure on NAS for planning considerations.
62
If the VNX SnapSure SavVol reaches a full state it will become inactive. All snapshots using that SavVol are then invalid and cannot be accessed. Therefore, VNX SnapSure employs a High Water Mark (HWM) as a point at which the SavVol will be automatically extend. The HWM is expressed as a percentage of the total size of the SavVol. The default HWM is 90%. When the SavVol High Water Mark (HWM) is reached, VNX SnapSure will extend the SavVol in 20GB increments. However, VNX SnapSure will not be able to consume more than 20% of the space available to the NAS. This HWM of 20% can be changed in the param file /nas/sys/nas_param.
63
If you set the HWM to 0% when you create a snapshot, this tells VNX SnapSure not to extend the SavVol when a snapshot reaches near-full capacity. Instead, VNX SnapSure deletes the data in the oldest snapshot and recycles the space to keep the most recent snapshot active. It repeats this behavior each time a snapshot needs space. If you use this setting and have a critical need for the snapshot information, periodically check the SavVol space and before it becomes full, copy the snapshot to tape, read it with snapshot applications, or extend it to keep it active. In summary, if you plan to use the 0% HWM option at creation time, auditing and extending the SavVol yourself are important snapshot management tasks to consider.
64
For file systems with SnapSure you can do an online instant restore of the production file system from any snap. SnapSure freezes the production file system, which flushes and suspends all activity (read and write) before immediately starting the restore; then thaws the production file system. This operation is required because the restore operation modifies the production file system structure. Then, in the background, SnapSure restores the production file system to the snap, copying the required data blocks back while the production file system continues its activity for read and write operations. When a restore is started, a new snap is automatically created on the production file system in case a rollback is requested.
65
VNX SnapSure Limitations are dependent on the hardware and VNX OE for File code in use. Please refer to online documentation to verify the limits that apply to your environment.
66
Quiesce is used to describe pausing or altering the state of running processes on a computer particularly those that might modify information stored on disk during a backup in order to guarantee a consistent and usable backup. Since many applications may not be aware of VNX OE for Files ability to create a snapshot of a filesystem, changes kept in memory may not be captured by the snap. In order to ensure a clean snapshot, an application must be quiesced to quiet data changes, so that a clean copy can be captured. Various database and application vendor implement schemes to provide support for this feature including Oracle, Microsoft SQL and SharePoint to name a few.
67
What could be a reason to use a writeable snapshot? DB environments
A VNX file system may host an Oracle database on which a customer wants to test
changes without actually applying those changes back to the production view. Another database implementation example is an administrator applying a database patch. It is first applied to the writeable snap and tested. If everything works, then a snap Restore is used to commit the changes from the writeable snap back to the PFS. FSCK
An administrator may want to sanity check the PFS, without taking it offline, by running
FSCK against a writeable snap.
68
Writeable Snapshots (previously called Writeable Checkpoints)
Can be mounted and exported as a read-write file systems Share the same SavVol with read-only snapshots Add write capabilities to both local and remote snapshots
Writeable snapshots share the same SavVol with read-only Snapshots. The amount of space used is proportional to the amount of data written to the writeable snapshot file system. Block overwrites do not consume more space. There is no SavVol shrink. The SavVol will grow to accommodate a busy writeable snapshot file system. The space cannot be returned to the cabinet until all snaps of a file system are deleted. A deleted writeable snap returns its space to the SavVol.
69
You can create, delete, and restore writeable snapshots. Writeable snapshots are branched from baseline read-only snapshots. A baseline snap exists for the lifetime of the writeable snap. Any writeable snap must be deleted before the baseline is deleted. Writeable snaps cannot be refreshed, or be part of a snapshot schedule. This feature provides full support in CLI and Unisphere.
70
You can have only one writeable snap per baseline read-only snap. There is a maximum of 16 writeable snapshots per PFS. Writeable snapshots do not count against the 96 user snap limit. So, all together there could a total of 112 user snaps per PFS. Writeable snaps count towards the maximum number of file systems per cabinet (4096) and the maximum number of mounted file systems per Data Mover (2048). You cannot create a snap from a writeable snapshots. You can create a writeable snap from a scheduled r/o snap. However, if the writeable snap exists when the schedule executes a refresh, it will fail.
Warnings are displayed in Unisphere when creating a writeable snap on a scheduled snap. No warning is displayed using the CLI.
71
While Writeable Snaps have some limitations, currently Writeable Snaps do not work with the following VNX features: 1) Replicator 2) File System extension of writeable snaps 3) VTLU 4) TimeFinder F/S
72
Checkpoint Virtual File System (CVFS) is a navigation feature that provides NFS and CIFS clients with automatic read-only access to all read-only snapshots from within a automatically created hidden directory in the PFS. This reduces or eliminates the need for help-desk involvement in user-level files and directory restore requests, and minimizes the necessity of using the backup saveset for these small restore requests.
73
CVFS naming convention Naming of hidden link In addition to the .ckpt_mountpoint entry at the root of the PFS, VNX SnapSure also creates virtual links within each directory of the PFS. All of these hidden links are named ".ckpt" (by default) and can be accessed from within every directory, as well as the root, of a PFS. You can change the name of the virtual snapshot name from .ckpt to a name of your choosing by using a parameter in the slot_(x)/param file. For example you could change the name from .ckpt to .snapshot. The .ckpt hidden link cannot be listed in any way and can only be accessed by manually changing into that link. After changing into .ckpt, listing the contents will display links to all Checkpoint views of that directory. The names of these links will reflect the date of the Checkpoint followed by the time zone of the Control Station. Naming of snapshot display name You can change the snapshot name presented to NFS/CIFS clients when they list the .ckpt directory, to a custom name, if desired. The default format of snapshot names is: yyyy_mm_dd_hh.mm.ss_<Data_Mover_timezone>. You can customize the default snapshot names shown in the .ckpt directory to names such as Monday, or Jan_week4_2009, and so on. You can only change the name when you mount the snapshot. For example; to change the name of snapshot pfs04_ckpt1 of pfs_04 to Monday while mounting the snapshot on Data Mover 2 on mountpoint /pfs04_ckpt1, use the following CLI command: server_mount server_2 -o cvfsname=Monday pfs04_ckpt1 /pfs04_ckpt1
74
ShadowCopyClient is a Microsoft Windows feature that allows Windows users to access previous versions of a file via the Microsoft Volume Shadow Copy Server. ShadowCopyClient is also supported by EMC VNX to enable Windows clients to list, view, copy, and restore from files in snapshots created with VNX SnapSure. All read-only snapshots of the PFS are immediately visible to VSS clients as previous versions. This allows current users of the VSS client to seamlessly integrate with VNX SnapSure.
75
An automated snapshot refresh solution can be configured using Unisphere Manager or a Linux cron job script. There is no CLI equivalent. Using the Checkpoints > Schedules tab in Unisphere Manager, you can schedule snapshot creation and refreshes on arbitrary, multiple hours of a day, days of a week, or days of a month. You can also specify multiple hours of a day on multiple days of a week to further simplify administrative tasks. More than one schedule per PFS is supported, as is the ability to name scheduled snapshots, name and describe each schedule, and to query the schedule associated with a snapshot. You can also create a schedule of a PFS that already has a snapshot created on it, and modify existing schedules. You can also create a basic snapshot schedule without some of the customization options by clicking on any mounted PFS listed in Unisphere Manager and click properties > Schedules tab. This tab enables hourly, daily, weekly, or monthly snapshots to be created using default snapshot and schedule names and no ending date for the schedule. VNX SnapSure allows multiple snapshot schedules to be created for each PFS. However, EMC supports a total of 96 snapshots (scheduled or otherwise) per PFS, as system resources permit. Because VNX OE for File backs up its database at one minute past every hour, snapshots should not be scheduled to occur at these times.
76
Refreshing Snapshots When you refresh a snapshot, VNX SnapSure deletes the snapshot and creates a new snapshot, recycling SavVol space while maintaining the old file system name, ID, and mount state. Scheduled snapshots that are baselines of writeable snapshots will not refresh until the writeable snapshot is deleted. Checkpoint refresh of a writeable snapshot is not supported. Refreshing a snapshot requires the snapshot to be frozen. If an NFS client is attempting to access the snapshot during a refresh, the system continuously tries to connect indefinitely. When the system thaws, the file system automatically remounts. If a CIFS client is attempting to access a snapshot during a refresh, depending on the application, or if the system freezes for more than 45 seconds, the Windows application may drop the link. The share may need to be remapped
77
When you delete a snapshot that is not the oldest, SnapSure compacts the deleted snapshot and merges the needed blockmap entries to the next older snapshot before the delete completes. This causes the older snapshot to grow, and to experience slightly worse read performance. Repeated out-of-order deletes compounds this effect. Deleting a snapshot requires the PFS to be paused. Therefore, PFS write activity suspends momentarily while the system deletes the snapshot (read activity continues).
78
This lesson familiarizes the student with RecoverPoint/SE architecture and describes common data protection challenges and the benefits of RecoverPoint/SE replication.
79
As you investigate various replication solutions, you notice that with each approach to replication, be it synchronous or asynchronous, several key areas must be discussed and understood. EMC typically refers to these as the pain points of remote replication. They are:
The impact on response time of your production application. For example, with a
remote-synchronous solution, your application must wait for the acknowledgement from the remote system before proceeding with the next dependent write. You also have speed-of-light issues, which impact the maximum distance your locations can be from each other.
The infrastructure -What additional equipment do you require to support the

replication process?
The communication links - How big and how expensive will the communication link
need to be in order to support the process?
And, most importantly, what is the recovery point at the target? That is, how much data
exposure do you experience as part of the operation; none, seconds, minutes, hours?
Each of these pain points must be carefully balanced. Without choice and flexibility, you cannot begin to architect a solution that meets your particular replication service levels.
80
EMC RecoverPoint/SE (RP/SE) is an enterprise-scale solution designed to protect application data on heterogeneous SAN-attached servers and storage arrays. RecoverPoint/SE runs on an out-of-band appliance and combines industry-leading continuous data protection technology with a bandwidth efficient, no-data-loss replication technology. RecoverPoint/SE provides local and remote data protection, enabling reliable replication of data over any distance; that is, locally within the same Site, and remotely to another Site. Specifically in the Local Protect Suite, RecoverPoint/SE protects and supports the replication of data within local storage. RecoverPoint/SE can use either existing Fibre Channel or IP infrastructure to integrate seamlessly with existing host applications and data storage subsystems. It should be noted that RecoverPoint/SE with VNX for File refers to file systems and the File environment and not individual files. RecoverPoint/SE and RecoverPoint/SE version 3.4 can now replicate block LUNs from all supported EMC and non-EMC arrays as well as the NAS file systems of a VNX series array. RecoverPoint/SE supports bi-directional replication of NAS file systems for disaster recovery. The feature provides NAS file system and virtual data mover remote replication to a secondary site by implementing data mover-level replication and cabinet-level failover. This functionality will be discussed further in the Remote Protection Suite module.
81
RecoverPoint/SE is ideal for homogeneous VNX environments. Additionally, it only supports the Windows Server (2000, 2003, and 2008) platforms in IA64, x86-64, or x86-32 versions with a host splitter, it also supports AIX, HP-UX, Linux, Solaris, Windows, and VMware with an Array splitter. RecoverPoint/SE is limited in function compared to RecoverPoint. If you require a host-driver on open server platforms, such as AIX, or support for arrays other than VNX, then the full version of RecoverPoint is the more ideal solution than RecoverPoint/SE. It also supports both Brocade SAS and Cisco SANTap as fabric-splitter types.
82
RecoverPoint/SE CDP is part of the Local Protection Suite for VNX Arrays.
83
RecoverPoint/SE CDP is a continuous synchronous product that mirrors SAN volumes in real time between one or more arrays at a local site. RecoverPoint/SE CDP maintains a history journal of all changes that can be used to roll back the mirrors to any point in time. RecoverPoint/SE CRR provides bidirectional, heterogeneous block-level replication across any distance using asynchronous, synchronous, and snapshot technologies across FC and IP networks. It periodically distributes updates to the remote copy of the data with all changes that occurred on the local copy since the last update. RecoverPoint/SE CRR maintains a history journal of all the distribution changes that can be used to roll back the mirrors to a prior distribution point in time. While RecoverPoint/SE CLR can provide both CDP and CRR protection for the same production volume(s). The Local Protection Suite incorporates RecoverPoint/SE CDP into its collection.
84
Policy-based management enables Administrators to set up service-level policies that optimize storage and IP-network resources by managing replication lag, data compression, and IP prioritization. Additionally, RecoverPoint/SE enables existing information lifecycle management policies by implementing multiple storage tiers for data protection. This allows you to establish policies to manage your recovery-time and recovery-point objectives (RTOs and RPOs). RecoverPoint/SE will manage and allocate the resources necessary to achieve these policies, or will let the Administrator know when a policy cannot be met due to resource limitations. Intelligent recovery is enabled with application-specific integration.
Flexible recovery allows users to select any image from any point in time for recovery
use based on application bookmarks at the local or remote site.
RecoverPoint/SE uses multiple Consistency Groups that can span storage arrays and
hosts, enabling the software to protect multi-tiered applications.
Finally, RecoverPoint/SE target-side processing capability allows read/write access to

any point-in-time copy of a LUN without consuming additional storage resources.
85
RecoverPoint/SE family replication and CDP are also policy-driven. A replication policy, based on the particular business needs of your company, is uniquely specified for each Consistency Group. The policy comprises a set of parameters that collectively governs the way in which replication is carried out. Replication behavior changes dynamically during system operation in light of the policy, the level of system activity, and the availability of network resources. Replication by RecoverPoint/SE is based on a logical entity called a Consistency Group. SANattached storage volumes at the primary and secondary sites (or sides), called replication volumes by RecoverPoint/SE, are each assigned to a Consistency Group to define the set of data to be replicated. Data consistency and write-order fidelity are maintained across all volumes assigned to a Consistency Group, including across volumes on different storage systems. The RecoverPoint/SE family supports multiple Consistency Groups. Multiple policies give you flexibility in managing RPO and RTO among different groups, and RecoverPoint/SE's advanced policy options allow you to fine-tune these policies on a group-bygroup basis. In addition, policies can be dynamically changed, allowing for updates based on feedback from real-time operations.
86
RecoverPoint/SE offers flexible recovery of all your data to any point in time. It does this by intercepting all writes to a source volume, and mirroring a copy of that write to the RecoverPoint/SE appliance, which stores a compressed copy of the data in the Journal, then writes it to the replica LUN. The source, Journal, and replica LUNs can be on different storage arrays, from different vendors.
87
The RecoverPoint/SE Journal stores all changes to all LUNs in a Consistency Group. It also stores metadata that allows an Administrator to quickly identify the correct image to be used for recovery. Time and Date are attributes of the saved data. For a value to be in the Bookmark field, a RecoverPoint/SE CLI script must issue a command with a bookmark parameter specified, or the RecoverPoint/SE Virtual Device Interface (VDI) must be run with a bookmark field. The RecoverPoint/SE CLI could also be used to create a bookmark, or you could also use the RecoverPoint/SE Management Application to create a bookmark; the text entered for the bookmark would be in the Bookmarks column. The Journal provides time-stamped recovery points with application-consistent bookmarks. It also correlates system-wide events (port failure, system error, etc.) with potential corruption events, very useful when performing root-cause analysis. These application and system bookmarks are automatic, but users can also enter their own bookmarks into the system.
88
The RecoverPoint/SE Appliance (RPA) is the data-protection controller for RecoverPoint. RPA nodes utilize private LAN and shared RPA volumes for communications using standard TCP protocol. The set of RPAs at any site constitutes an RPA cluster, where each cluster can include between one and eight RPAs, as set during RecoverPoint/SE system installation. The cluster size must be the same at any site in an installation. In normal operation, all RPAs in a cluster are active all of the time. Consequently, if one of the RPAs in a cluster goes down, the RecoverPoint/SE system supports immediate switchover of the functions of that box to another RPA in the cluster. Appliance hardware is subject to change without notification. The current RPA hardware platform (Gen4) includes a single quad port QLE25xx 8 Gb HBA and supporting native 8 Gb/s Fibre Channel connectivity. The previous RPA platform (Gen3), that includes two dual-ported 4 Gb QLE2462 HBA cards, a PCI-E bus and support for native 4 Gb/s Fibre Channel.
89
In deploying a RecoverPoint/SE environment, the RPA Repository and journals must be configured. The size limits are listed.
Repository Volume - Stores pertinent replication environment information.

This volume must be seen only by the appliances on the same site as this volume. It should be 3 GB; capacity beyond 3 GB is not used.
Journal Volumes - Stores the consistent point in time images for the target site.
There is at least one Journal volume on each site per consistency group. These volumes should only be seen by the appliances. The minimum size for a groups journal at each copy is 5 GB.
Replication Volumes - Data volumes to be replicated.

Target volumes must be the same size (or larger) than the source volumes. Any excess size (above the source sites size) is not replicated or visible to the host. The reason for saying larger is to guarantee that the target site volumes are not accidentally configured smaller by accident.
90
Repository Volumes are volumes created on existing storage arrays in the SAN environment. The Repository volume contains consistency group meta-data. The minimum size for a Repository volume is 3 GB. The Repository volume serves all RPAs and associated splitters for each cluster at a particular site. The Repository volumes are created as part of the installation process.
91
At least one journal volume must exist for each configured consistency groups. Journal volumes hold snapshots of data to be replicated. Each Journal volume holds as many snapshots as its capacity allows, after which the oldest snapshot is removed to make space for the newest snapshot. The size of a Journal volume is based on the length of time the user wishes to recover to for a specific consistency group. For instance, if snapshots for a consistency group must be stored for 24 hours, the journal volume must be at least as large as the amount of expected snapshot writes for a day. Typical estimate is 20% of the size of all the data disks, but the true size can only be determined by analyzing the environment. Best practice when creating Journal volumes are: Mirrored for protection Striped and Mirrored on target side for reliability and speed 5 I/Os for each replicated write (Journal volume is not full) Flexible Journal volume pool and application tolerance for sizing Able to sustain 2X sequential writes, and X sequential reads
92
Replication volumes, or Replicas, are the production storage volumes and their matching target volumes which are used during replication. Target volumes must be the same size (or larger) than the source volumes. Any excess size (above the source sites size) will not be replicated or visible to the host. This is an important design consideration for heterogeneous storage environments.
93
This slide shows the available methods of write splitting for RecoverPoint/SE.
94
The kdriver is proprietary software that you install on hosts that access replication volumes; i.e., volumes that contain data to be replicated. The primary function of the kdriver is to split application writes so that they are sent not only to their normally designated storage volumes, but also to the RPA. The kdriver (or splitter, as it is most often called in RecoverPoint) carries out this activity efficiently, with little perceptible impact on host performance, since all CPUintensive processing necessary for replication is performed by the RPA. The RecoverPoint/SE proprietary host-based utility, kutils, enables you to manage host splitters across all platforms. It is installed automatically when you install the kdriver on a host machine. When the splitting function is performed by an intelligent fabric switch, a standalone version of kutils can be installed separately on the host machines.
95
RecoverPoint/SE supports the Array-based splitter. This splitter runs in each storage processor of a VNX array and splits all writes to a volume, sending one copy to the original target and the other copy to the RecoverPoint/SE appliance. The Array-based splitter is supported on VNX arrays. Splitter types can be mixed in the same site subject to some restrictions:
All of the volumes in a single consistency group must utilize the same splitting
technology per site, however the type of splitting technology can be different between sites.
All volumes attached to the same host must use the same splitting technology.
96
The multi-cluster Array-based splitter is designed for customers who require DR for multiple clients on the same storage, or larger customers who have many RecoverPoint/SE clusters that share common arrays. An example of this could be an organization hosting storage protection solutions for multiple companies. This solution will allow the hosting organization to consolidate data to a single array platform. It allows a single Array-based splitter to be used by up to four RecoverPoint/SE clusters. Each LUN can only be attached to one cluster at a time, and there is as maximum of 2048 LUNs across all clusters.
97
This lesson familiarizes the student with RecoverPoint/SE CDP features and operational concepts.
98
RecoverPoint/SE operating in CDP mode does not use the WAN to replicate data. Instead of compressing the data and sending it over an IP network to a remote volume, it writes the data to a local volume. As there is no IP network involved, and hence no latency concern, RecoverPoint/SE CDP can synchronously track every write in the local Journal and distribute the write to the target volume, without impacting the application servers performance. The steps to CDP replications are: 1) An application server issues a write to a LUN that is being protected by RecoverPoint. This write is split, then sent to the RecoverPoint/SE appliance through the splitter.
2) When the copy of the write is received by the RecoverPoint/SE appliance it is acknowledged back. This ack is received by the Host splitter, where it is held until the ack is received back from the production LUN. Once both acks are received, the ack is sent back to the host, and I/O continues normally.
3) Once the appliance has acknowledged the write, it moves the data into the local journal volume, along with a timestamp and any application, event, or user-generated bookmarks for the write. 4) Once the data is safely in the journal, it is distributed to the target volumes ensuring that write order is preserved during this distribution.
99
Every SAN-attached storage volume in the production storage must have a corresponding volume at each copy. A production volume and its associated replica volumes is called a replication set. Each consistency group contains as many replication sets as there are volumes in the production storage to replicate. Data consistency and write-order fidelity are maintained across all volumes assigned to a consistency group, including volumes on different storage systems. At least one volume should be added to the journal of each copy in a replication set.
100
A consistency group consists of one or more replication sets. Each replication set consists of a production volume and the replica volumes to which it is replicating. The consistency group ensures that updates to the replicas are always consistent and in correct write order; that is, the replicas can always be used to continue working or to restore the production source, in case it is damaged. The consistency group monitors all the volumes added to it to ensure consistency and write-order fidelity. If two data sets are dependent on one another (for instance, a database and a database log), they must be in the same consistency group. Imagine a motion picture film. The video frames are saved on one volume, the audio on another. But neither will make sense without the other. The saves must be coordinated so that they will always be consistent with one another. In other words, the volumes must be replicated together in one consistency group. That will guarantee that at any point, the saved data will represent a true state of the film.
101
Distributed Consistency Groups (DCGs) function just like regular consistency groups, except they can span up to four RPAs at once. One RPA is designated the primary RPA, which receives all incoming data from the splitter. The primary RPA then examines the target and block# and will either process the I/O itself or forward it to the secondary RPAs within the group via FC. The individual RPAs then replicate that data normally. DCGs need much larger journals than normal consistency groups. While 5GB was the minimum for regular consistency groups, 20GB is needed for DCGs. If the journal is already at least 20GB in size, then there is only a short pause is replication when converting to a DCG. If the journal is less that 20GB the user must increase the size of the journal manually before the conversion can successfully complete. Converting a Consistency Group in either direction causes the contents of the journal to be lost. Changing the secondary RPAs will not delete the contents of the journal. DCGs are only supported with Gen 3 or Gen 4 RPAs, to a maximum of 8 distributed CGs per cluster.
102
Each consistency group can be in one of the following replication modes:
Replicating The consistency group is enabled, the splitter is replicating to the RPAs,
the RPAs are transferring to the replica journal or journals. If Image access is disabled (default state), the journal also distributes snapshots to the replica storage.
Marking The consistency group is enabled, the splitter is replicating to the RPAs, but
the RPAs are unable to transfer to the replica journal. The location of the changes is stored in RPA1, RPA2, as well as on the production journal volume. When contact with the remote site is restored, the remote replica is synchronized, but only at those locations that were marked as having changed. Then transfer and replication can resume.
Disabled In this state, the splitter does not split writes to the RPAs. Typically this state
is caused by consistency group being set to disable or by a disaster (for example all appliances at the site are not available).
103
When a consistency group is initialized for the first time, the RecoverPoint/SE system cannot identify which blocks are identical between the two groups, and must therefore mark all blocks for that volume. This is true both following creation of a new consistency group and following the addition of a volume (or volumes) to an existing group. While initializing, the RecoverPoint/SE system efficiently determines which blocks are actually different between the sides, and sends only the data for those blocks, as the initialization snapshot, to the target side. The volumes at the two sides can be initialized while the host application either is or is not running. First-time initialization - During a first-time initialization, snapshots are not stored in the journal, and changes are written directly to storage. Initialization of one consistency group should not interfere with the operation of other consistency groups. Initialization - Signifies that an event occurred where the replication has been forced to perform re-sync of the replication pair(s) for the group. This can be initiated for several reasons and can range from a short re-sync (from Marking Mode), a partial sync (from a Volume Sweep) or a complete re-sync (from a Full Sweep). Marking Mode - Replication is always marking the location of the data that changes, but when a component in the flow between the source appliance and the target replication volume fails or otherwise misbehaves, the replication enters Marking Mode. Every consistency group has a bitmap on the local Journal volume which records the location of the data on the source replication volume that has changed. When replication enters marking mode, data transfer to the target site is paused for this group and the bitmap for the group is used to record where the data that has changed is located.
104
An initialization may result if an event occurred where RecoverPoint/SE is forced to perform a re-sync of the replication set(s) for the group. This can be initiated for several reasons and can range from a short re-sync (from Marking Mode), a partial sync (from a Volume Sweep) or a complete re-sync (from a Full Sweep).
Short re-sync occurs when there is a disaster or some bottleneck in the system. The RPA transfers to marking mode, and after the disaster is over the snapshots are replicated to the source RPA. Long re-sync occurs when the amount of data in the snapshot created from initialization is larger than the snapshot portion of the journal volume. During a long re-sync, the snapshot is divided into smaller pieces so each piece can fit on the journal volume individually. The first piece is then transferred to the remote site and written to the journal volume, then distributed immediately to the target replication volume. Once the distribution of the first piece is completed, the replication moves to the next piece and so on until all pieces have been distributed.
105
In continuous synchronous replication, the replica must acknowledge the write transaction before an acknowledge can be returned to the host application that initiated the write. Replication in synchronous mode produces a replica that is 100% up to date with the production source. Synchronous communications is efficient within the local SAN environment for CDP (local replication).
106
Asynchronous replication does not conserve bandwidth. Furthermore, and particularly as volumes increase, it is increasingly susceptible to data loss, as more and more data that has been acknowledged at the source may not have been delivered to the target. RecoverPoint/SE can limit the use of asynchronous replication to those situations in which it enables superior host performance but does not result in an unacceptable level of potential data loss.
107
Snapshot mode for block only transfers data that has changed between one consistent image of the storage subsystem and the next. By definition, snapshot replication produces a copy that is not up-to-date. The use of high-frequency, or small-aperture, snapshots largely overcomes the shortcomings of the snapshot not being up-to-date. By reducing the lag between writing data to storage at the source and writing the same data at the copy, the extent to which the copy is not up-to-date is dramatically reduced. The RecoverPoint/SE appliance can continue to operate independent of local hosts and storage. RecoverPoint/SE can be located at a distance that allows synchronous communication with the hosts and storage, and at the same time, it can be far enough away to protect against local disaster. Were a disaster to occur at the local storage, the data on the RecoverPoint/SE appliance could still be replicated to the copy, thereby eliminating the impact of the fact that the copy is not up-to-date at the time of the disaster.
108
A snapshot for block is the difference between one consistent image of stored data and the next. Snapshots are taken seconds apart. The application writes to storage; at the same time, the splitter provides a second copy of the writes to the RecoverPoint/SE appliance. In asynchronous replication, the appliance gathers several writes into a single snapshot. The exact time for closing the snapshot is determined dynamically depending on replication policies and the journal of the consistency group. In synchronous replication, each write is a snapshot. When the snapshot is distributed to a replica, it is stored in the journal volume so that is it possible to revert to previous snapshots and recover the state of the data at a previous time.
109
A bookmark is a named snapshot. The bookmark uniquely identifies an image. Bookmarks can be set and named manually; they can also be created automatically by the system either at regular intervals or in response to a system event. Bookmarked images are listed by name. You may bookmark a snapshot at any time. Bookmarks are useful to mark particular points in time, such as an event in an application, or a point in time you wish to fail over to.
110
RecoverPoint/SE is designed to capture every write which enables users to recover data from any point in time without needing to worry about application consistency. It utilizes bookmarks to track application consistent recovery points. Keeping days to weeks of every recovery point requires very large journals. RecoverPoint/SE allows users to specify how long they want to retain their data and how it should consolidate their recovery points. RecoverPoint/SE has a snapshot consolidation policy that lets the user decide how long to retain every write captured, and at what point to consolidate their changes to a daily, weekly or monthly recovery point. This feature lets the user optimize the journal space used by RecoverPoint/SE on a consistency group basis so that only a part of it is used to track every write and the remaining space is used for the daily, weekly or monthly images. The slide shows an example of a policy that keeps every write for 2 days and after 2 days it keeps 5 daily and then 4 weekly recover points. After one month and one week, RecoverPoint/SE retains monthly recovery points in the journal up to the capacity of the journal.
111
Under normal operations, the journal does not fill up as old snapshots are distributed to the target replication volume as new snapshots arrive. Placing the target site in logged image access mode or any situation making the target site replication volume inaccessible for distribution of snapshots while a large change rate is occurring
If logged image access is enabled or the replication volume is inaccessible to RPAs for some other reason, then the journal fills and replication is paused by the system and the source site goes into marking mode. When logged image access mode is disabled or the access from the RPAs to the Replication volumes is restored, distribution of snapshots continues and replication will be un-paused, as long as the change is not larger than the journal all is handled normally. If however the change is larger than the journal capacity, the handling depends on the Consistency Group policy setting allow_long_resync, which sets a flag that governs whether or not the system can continue with the resync, even when it requires the deletion of the last snapshot from the journal.
112
With RecoverPoint/SE, recovering an image to any point in time is a simple operation from the Management Application, but there are many processes which occur: The Administrator first selects an appropriate image to recover. This can be done by selecting an image based on a certain time/date or by a user, environmental, or application bookmark. There is also a search capability that allows the Administrator to view all the images in a specific set of time stamps that contain one or more values in the bookmark or application field.
113
This lesson familiarizes the student with RecoverPoint/SE management.
114
Launch the RecoverPoint/SE Management Application from a web browser using the management IP address for the RPA cluster. The first time you log in, use the User ID admin and the Password admin. You can change this and other default passwords after you log in. Additionally, you can create new users. After logging in for the first time, a shortcut is created on your desktop.
115
The Management Application allows you to manage the RecoverPoint/SE system. Site management provides access to all boxes in the local RPA cluster, as well as to the RPA cluster at the other site (i.e., to which the local cluster is joined). Almost all of the information necessary for routine monitoring of the RecoverPoint/SE system appears on the Management Application. The System pane provides an overview of system health at a glance. The pane shows the status of major components of the RecoverPoint/SE system environment, including the hosts, switches, storage devices, RPAs at two sites, and the WAN connection. The Traffic pane displays the amount of SAN and WAN traffic passing through the RPAs. The Navigation pane allows you to navigate to the different views available in the Component pane. In the Navigation pane, click the component on which you wish to focus. The corresponding view appears in the Components pane.
116
The Management Application displays information and provides access to commands and parameters. The information, commands, and parameters are displayed in numerous panes. The Navigation pane does not display monitoring information, but it does give access to a very large number of management commands by right-clicking on the icons. Many of the same options are available from the drop-down menus available above the System pane. Common tasks are made available as quick access icons above the Component pane. Note that the menu options and the quick access icons are context sensitive and change based on which item is highlighted in the Navigation pane.
117
The System pane provides an overview of system health at a glance. The pane shows the status of major components of the RecoverPoint/SE system environment, including the hosts, switches, storage devices, RPAs at two sites, and the WAN connection. When the system detects a problem with one of these major components, the System Status pane displays:
An icon (red triangle with exclamation point) on each component that is not functioning
properly. For a warning, this icon is yellow.
A message, Error...(or Warning...) next to the name of the currently faulty component at
the right side of the pane.
You can click on Error... to display additional details about the specific error (or on Warning...for details about the warning). Alternatively, you can get the same information by clicking directly on the faulty component. The status of a component, particularly until you have completed logging in to the system, may also be Unknown. In that case, the icon appears on the component.
118
Each RecoverPoint/SE user is defined by a user name, a password, and a set of permissions. Additional security measures can be applied to the RPA. You cannot delete any of the default users or change the default permissions for those users. However, you can change the default passwords.
119
RecoverPoint/SE supports the hardware generation reporting feature which enables RPAs to determine what generation of hardware they are running on.
120
These are the key points covered in this course. This concludes the training. Please proceed to the course assessment.
121
122

VNX Local Protection Suite Foundations

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

VNX Local Protection Suite Foundations

Загружено:

Авторское право:

Доступные форматы

Welcome to VNX Local Protection Suite Foundations.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Once that LUN fills, Private LUN 8 is allocated

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Clone a primary and secondary image

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Extends by 20GB if snapshot reaches a high water mark

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