WHAT S NEW WITH TIMEFINDER FOR EMC SYMMETRIX VMAX

Transcription

1 White Paper WHAT S NEW WITH TIMEFINDER FOR EMC SYMMETRIX VMAX Applied Technology for traditional and virtual environments Abstract This white paper describes the latest EMC TimeFinder features available for traditional and virtual environments running open systems and using Symmetrix VMAX. Throughout this paper the basis for traditional environments will describe hard disk drive or thick device technologies, and the basis for virtual environments will describe virtually provisioned thin device environments. June 2014

2 Copyright 2014 EMC Corporation. All Rights Reserved. EMC believes the information in this publication is accurate 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. For the most up-to-date listing of EMC product names, see EMC Corporation Trademarks on EMC.com. VMware is a registered trademark of VMware, Inc. All other trademarks used herein are the property of their respective owners. Part Number h8264 2

3 Table of Contents Executive summary... 4 EMC TimeFinder in traditional environments... 4 EMC TimeFinder/Clone overview... 4 Clone copy sessions... 5 EMC TimeFinder/Snap overview... 6 Snap copy sessions... 7 EMC TimeFinder in virtual environments... 7 EMC Virtual Provisioning overview... 8 TimeFinder/Clone for thin devices TimeFinder/Clone using copy/precopy TimeFinder/Clone using nocopy Cloning a TDEV to a larger TDEV Cloning between traditional (thick) devices and virtual (thin) devices Cascading TimeFinder/Clone TF/Clone emulation in support of thin devices TimeFinder/Snap for thin devices Multi-virtual snap Duplicate snap EMC TimeFinder/VP Snap Conclusion References Appendix A: TimeFinder Session Limits

4 Executive summary This white paper describes the latest EMC TimeFinder technologies and how they can be used in traditional (thick device) and virtual (virtually provisioned thin device) environments. EMC TimeFinder is a Symmetrix product that provides local and remote replication solutions designed to nondisruptively create point-in-time and/or full copies of critical data. This versatile product provides a business continuance solution for customers requiring 7x24x365 uptime for business applications. TimeFinder is used to initiate replicas, offload backups, and refresh test and development environments from any host running EMC Symmetrix Solutions Enabler (SE) software. Available since EMC Enginuity release 5773, Virtual Provisioning provides increased storage utilization and optimization. EMC Virtual Provisioning, generally known in the industry as thin provisioning, enables organizations to improve ease of use, enhance performance, and increase capacity utilization for certain applications and workloads. Both of the TimeFinder and Virtual Provisioning technologies are controlled and performed within the Enginuity Operating Environment running on the Symmetrix VMAX storage system. A variety of host-based software products such as the Solutions Enabler Symmetrix command line interface (SYMCLI), Symmetrix Management Console (SMC), Replication Manager, and EMC Ionix ControlCenter (ECC) are used to manage and execute the TimeFinder features and functionality. The EMC SMC graphical user interface and the SYMCLI will be used throughout this paper to exhibit the features discussed herein. EMC TimeFinder in traditional environments TimeFinder supports an array of features in traditional provisioning HDD environments, as well as virtually provisioned (or thin) environments. TimeFinder is one of EMC s most mature and feature-rich products. Both TimeFinder/Clone and TimeFinder/Snap provide a vast array of features and functionality for all device types and sizes. EMC TimeFinder/Clone overview TimeFinder/Clone provides point-in-time copies of critical data that can be used for backups, decision support, data warehouse refreshes, or any other process that requires multi-application access to data. Each clone keeps its own copy of the source volume s information at the point in time that it was activated. TimeFinder/Clone allows users to make copies of data simultaneously on multiple target devices from a single source device. The data is copied from the source device, creating a physical backup copy called a clone. The data can be available to a target device s host immediately upon activation of the TimeFinder copy session even if the copy process has not completed. 4

5 When TimeFinder/Clone is used with the nocopy option, snapshot-like clones are created. They are logical images of the original information, based on the time of clone activation. Data is only copied from source to target upon access or update. EMC TimeFinder/Clone operations have been available since the earliest versions of the Enginuity 1 operating environment. TimeFinder/Clone can create up to 16 copies from a source device onto target devices. Unlike TimeFinder/Mirror, TimeFinder/Clone does not require the traditional standard to BCV device pairing. Instead, TimeFinder/Clone allows any combination of source and target devices. There are a few requirements for implementing clone source and target devices as follows: Source and target devices must be the same emulation type (FBA or CKD). The target device must be of equal or greater size than the source. Clone copies of striped or concatenated metavolumes can also be created, as long as the source and target metavolumes are identical in configuration; same type (striped or concatenated) and same number of members. Clone copy sessions TimeFinder/Clone functionality is controlled via copy sessions that pair the source and target devices. Sessions are maintained on the Symmetrix array and can be queried to verify the current state of the device pairs. A copy session must first be created to define and set up the TimeFinder/Clone source and target devices. The session is then activated, enabling the target device to be accessed by its host. When necessary, an incremental restore operation allows the clone session to swap the role of source and target device. A full restore can use the target as the source for a new session with a new target. Whenever the session is finally terminated, the data on the clone remains persistent. TimeFinder/Clone operations are controlled from the host by using symclone commands to create, activate, restore, and terminate the copy sessions. Figure 1 illustrates a copy session where the controlling host creates a TimeFinder/Clone copy of standard device DEV001 on target device DEV005, using the symclone command. 1 The Enginuity operating environment is the operating system that drives the VMAX storage array. 5

6 Figure 1. Creating a copy session using symclone EMC TimeFinder/Snap overview TimeFinder/Snap creates space-saving, logical point-in-time images called snapshots. It allows the creation of multiple snapshots simultaneously on multiple target devices from a single source device. Snapshots are not full copies of data; they are logical images of the original information, based on the time the snapshot was created. In contrast to a full device copy, a snapshot only needs to store as much data as was written after the point-in-time was taken. Multiple snapshots can be created to suit the needs of multiple business processes. Secondary servers see the snapshot as an additional device and have full read/write capabilities to that device and the data is instantly available. TimeFinder/Snap allows data to be copied from a single source device to as many as 128 target devices. A source device can be either a standard device or a BCV device controlled by TimeFinder/Mirror. Specifically with TimeFinder/Snap technology, the target device is a VDEV that consumes negligible physical storage through the use of pointers to track changed data. VDEVs allow the allocation of space based on the amount of changes to a device. A virtual device (VDEV) is a Symmetrix host-addressable cache device used in TimeFinder/Snap operations to keep pointers to point-in-time copies of the source device. Virtual devices are space-efficient since they contain only address pointers to the actual data tracks stored on the source device or in a pool of SAVE devices. Virtual devices can be metadevices as long as the source device is also a metadevice. In other words, a VDEV is a host-addressable Symmetrix device with special attributes. However, unlike a clone or BCV that contains a full volume of data, a VDEV is a logical-image device. Any updates to a source device after its activation with a VDEV cause the pre-update image of the changed tracks to be copied to a save device as shown in Figure 2. A VDEV is accessible only after a snap session has been activated. 6

7 It is important to distinguish that a VDEV is a cache device and is not to be confused with Virtual Provisioning thin device technology. Snap copy sessions TimeFinder/Snap functionality is managed via copy sessions which pair the source and target devices. Sessions are maintained on the Symmetrix array and can be queried to verify the current state of the devices. A copy session must first be created via the command line create process that defines the snap devices in the operation. Next, the session is activated and the target VDEVs become accessible to their host. Unless the data is changed by the host accessing the VDEV, this device always presents a frozen point-in-time copy of the source device at the point of activation. When the information is no longer needed, the session can be terminated. Figure 2 illustrates a TimeFinder/Snap copy session where the controlling host creates a copy of standard device DEV001 on target device VDEV005. Figure 2. TimeFinder/Snap copy of a standard device to a VDEV TimeFinder/Snap uses both the COFW and the Asynchronous Copy on First Write techniques. For more information on Asynchronous Copy on First Write and COFW technologies, refer to the EMC TimeFinder Product Guide. EMC TimeFinder in virtual environments TimeFinder supports many features in environments that have been configured to use EMC Virtual Provisioning technology. TimeFinder is one of EMC s oldest and most mature products; however Virtual Provisioning technology is relatively new and was introduced in Enginuity release TimeFinder/Clone and TimeFinder/Snap provide a full set of features and functionality for thin device environments. This next section will focus on TimeFinder for virtually provisioned environments. 7

8 EMC Virtual Provisioning overview EMC Virtual Provisioning provides the capability to provision more storage to a host or application than is physically available. More importantly, Virtual Provisioning will consume physical storage only when the thin device is actually written to. This allows more flexibility in predicting future growth and reduces the initial costs of provisioning storage to an application. Virtual Provisioning helps eliminate the waste incurred when administrators over allocate storage that may never be used, while minimizing the administrative management of storage allocations. Thin devices Symmetrix thin devices are logical devices that can be used in many of the same ways that Symmetrix devices have traditionally been used. They are provisioned in the same way as traditional (or thick) devices. EMC Auto-provisioning is used to create a masking view that will allow the user to map thin devices to a front-end Symmetrix director and port, and then mask them to the WWN of an HBA in the server requiring the storage. Figure 3 is a visual representation of the components that comprise a masking view: The initiator group contains the host HBA information, the port group contains the front-end director port (FA) information, and the storage group contains the storage devices on the back end. Figure 3. Auto-provisioning masking view components For more information on EMC Auto-provisioning functionality and creating masking views, refer to the EMC Solutions Enabler Symmetrix Array Controls Product Guide. Thin pool Unlike traditional (thick) Symmetrix devices, thin devices do not need to have physical storage completely allocated at the time the device is created and presented to a host. The physical storage that is used to supply disk space to thin devices comes from a shared storage pool called a thin pool. A thin pool is a Symmetrix construct that provides the underlying storage that supports thin devices. Thin pools are created by the end user where up to 512 thin pools can be defined. A thin storage pool is made up of data devices that are storage devices that provide storage capacity to be used by the thin devices. Data devices Data devices are specific devices in the Symmetrix that are not addressable to a host, but they provide capacity for a thin pool. One or more data devices can be related to a thin pool. When data devices are added to a thin pool they can be in an enabled or 8

9 disabled state. In order for the data device to be used for thin extent allocation into a thin pool, it needs to be in the enabled state. For a data device to be removed from the thin pool, it needs to be in a disabled state. I/O activity to a thin device When a write is performed to a part of the thin device for which physical storage has not yet been allocated, the Symmetrix allocates physical storage from the thin pool for that portion of the thin device only. The Enginuity Operating Environment satisfies the requirement by providing a block of storage from the thin pool called a thin device extent. This approach reduces the amount of storage that is actually consumed. A thin device extent is the minimum amount of physical storage that can be reserved at a time for the dedicated use of a thin device. The entire thin device extent is physically allocated to the thin device at the time the thin storage allocation is made. The thin device extent is allocated from any one of the data devices in the associated thin pool. When a read is performed on a thin device, the data being read is retrieved from the appropriate data device in the thin pool. When more physical data storage is required to service existing or future thin devices, data devices can be added to existing thin pools dynamically without requiring any system outage. New thin devices can also be created and associated with existing thin pools. Figure 4 depicts the relationships between thin devices and their associated thin pools. There are nine devices associated with thin pool A and three thin devices associated with thin pool B. Figure 4. Virtual Provisioning components Thin devices and TimeFinder operations With Enginuity 5874 and later, TimeFinder supports the use of thin devices to create both thin extent snaps and full device clones, with certain restrictions. For TimeFinder operations, the Symmetrix device that keeps the original data is the source device and the device that keeps the point-in-time copy is the target device. Where Virtual Provisioning is concerned, either the source device or the target device, or both, can be thin devices. 9

10 TimeFinder/Clone for thin devices The following section describes TimeFinder/Clone features and functionality that are available on a VMAX storage array and can be implemented with virtually provisioned devices. Clones in thick environments require the same capacity as the source; however, in the evolution of functionality for TimeFinder and features related to storage capacity consumption, thin TimeFinder/Clones only consume the allocated capacity of the source in the thin pool. TimeFinder/Clone using copy/precopy TimeFinder/Clone allows users to create a full replica using either copy (on by default) or precopy options. Copy and precopy allow for differential (incremental) synchronization and restore capability between source and target. In addition, using copy/precopy will only consume the used (written to) capacity of the source in the virtual pool of devices. Figure 5 depicts a TimeFinder/Clone source and target that have been created using the copy option. We see that 5 GB has been written on the source device, therefore 5 GB will also be written to each of the associated target devices up to 16 copies. Figure 5. TimeFinder/Clone full replica The copy operation performs the device copy in the background. When a create copy operation is invoked, the state of the device pair is created; for precopy, the state is precopy. After the session has been activated, the state displayed is Copyinprogress. When all tracks are eventually moved to the target device, the state then changes to Copied. Copy/precopy modes are typically used to create full source device replicas on the target device. The data can then be kept intact on the target device for recovery purposes (also called a gold copy) or used for testing or other purposes. The precopy operation performs the device copy in the background before the 10

11 activate starts. Normally, tracks are not copied until activation occurs; however, the precopy process continuously runs in the background until the clone is activated. Precopy implies a copy operation. TimeFinder/Clone using nocopy Unlike the copy option, using TimeFinder/Clone with the nocopy option does not allow the background process; data is copied from the source device to the target device only if triggered by a host I/O. However, the point-in-time image is instantly available to the host accessing the target device immediately after the session is activated. Creating thin TimeFinder/Clones using nocopy consumes only the allocated capacity on writes to source and target. Source and target updates are written into the storage pool for which the thin device has been bound. Clone nocopy has two modes; Copy-on-Write and Copy-on-Access. Copy-on-Write mode will copy data from a source device to a target device only if triggered by a host write I/O. Copy-on-Access mode will also copy data from a source device to a target device during a host write I/O, as well as during read I/Os to protected tracks on a target. The default mode of operation for Clone nocopy is Copy-on-Access. This can be changed by editing the options file as shown below: Clone nocopy sessions are not differential sessions, meaning that it is not possible to perform incremental restores or recreates. TimeFinder/VP Snap provides this functionality and offers even more space-saving benefits than Clone nocopy. More info on TimeFinder/VP Snap is provided on Page

12 Cloning a TDEV to a larger TDEV Minimum Requirements Enginuity Solutions Enabler Clone TDEV to larger TDEV TimeFinder/Clone copy operations only move data, not free space. This creates a more space-efficient method for cloning thin devices. Cloning a thin device to a device that is larger than the source is allowed, however, users cannot restore data from the target to the original source device. The SYMCLI_CLONE_LARGER_TGT environment variable must be set to ENABLED in order to use this feature. Cloning to a larger target device limits the use of the differential and nocopy options. The No Diff or symcli -nodiff (non-incremental) copy option is required when cloning a smaller TDEV to a larger one, and only the precopy and copy options may be selected for this feature. Table 1 describes the valid parameter options for this feature. Table 1. Option selections for this feature Mode Options Notes -precopy -nodiff Differential not valid -copy -nodiff Differential not valid -nocopy N/A N/A Using SMC, Figure 6 depicts the two TDEVs used in this example. Notice that device 05CF is half the size of TDEV 01CE. Figure 6. Smaller TDEV 05CF and larger TDEV 01CE 12

13 These TDEVs must be bound to a thin pool before attempting any cloning operation. The following graphic depicts devices 01CE and 05CF and displays the pool name for which they are bound. Figure 7. TDEVs are bound to the pool R53_FC_Pool In the following example, the Symmetrix Command Line Interface symclone commands were used to create, activate, and terminate the TimeFinder/Clones. 1. Identify the source and target devices by pairing the devices symclone sid 1554 create file clonetest.txt precopy nodiff -nop 2. Display the file clonetest.txt that contains the TDEVs 05CF and 01CE. 3. Create the replica by activating a TimeFinder/Clone session. symclone sid 1554 activate file clonetest.txt nop 4. To sever or split the paired relationship between source and target, terminate the session. symclone sid 1554 terminate file clonetest.txt nop 13

14 Cloning between traditional (thick) devices and virtual (thin) devices Minimum Requirements Enginuity Solutions Enabler Clone Thick to TDEV Clone TDEV to Thick Solutions Enabler 7.1 and Enginuity 5874 introduced the ability to clone from traditional (thick) to virtual (thin) devices using TimeFinder/Clone. Thick to thin TimeFinder/Clone allows application data to be moved from traditional Symmetrix volumes to virtually provisioned storage within the same array. TimeFinder/Clone provides an easy way to move and/or migrate data from thick to thin environments. Migration from thin devices back to fully provisioned (thick) devices is also possible. The source and target of the migration may be of different protection types and disk technologies. However, cloning from a TDEV to a smaller thick device is not allowed. Cloning from the source TDEV to a thick device of the same size (or larger) is required. Thick to thin TimeFinder/Clone will not disrupt hosts or internal array replication sessions during the copy process. The following table defines the cloning options and valid parameter settings when cloning thin and thick devices. Table 2. Describes the valid parameter options for this feature Mode Options Notes -precopy -nodiff allowed for clone to larger TGT -copy -precopy -copy -nodiff -diff -diff allowed for clone to larger TGT valid if SRC and TGT are same size valid if SRC and TGT are same size -nocopy N/A N/A Restoring to and from traditional (thick) and virtual (thin) devices An incremental restore is allowed if the source and target devices are of the same size and the copy session was created by using the differential (-diff) parameter. The following screenshots highlight the TimeFinder/Clone operations that can be used as an example. In this test case, the source device is a TDEV (05CF) and the target device is a 2-Way Mir thick device (02D6). These devices are the exact same size; therefore creating a differential clone is valid, which enables the ability to perform a restore. The devices paired are 05CF (TDEV) and 02D6 (STD) as defined in the file thinthickrstr.txt. 14

15 Create the clone pair with precopy and diff, and then activate. Perform a query to review the current state of the devices. Restore to the source device, and query again. 15

16 When the TimeFinder operation is complete, terminate the clone session. Cascading TimeFinder/Clone Minimum Requirements Enginuity Solutions Enabler Cascading clones Restore to Target The cascaded clone feature allows the creation of two full-device clone sessions using the same device as both source and target. Both sessions can run concurrently, as long as the copy process is executed sequentially. Figure 8. Cascading clone from clone target With cascading clone, a user would activate session 1 to copy data from device A to device B. Then, session 2 may be activated (after the copy is complete) to clone from device B to device C. The relationship between device A and B is preserved, allowing for differential resynchronization following session 2. A copy session from device B to C is allowed after the session 1 copy has completed. When using this TimeFinder feature, all devices must either be thick or thin as a mixture is not allowed. New cascaded clone sessions may not be created while a restore is active. For example, if devices A and B are in the midst of a restore, a new clone session may not be activated using device A. Restore to target (RTT) is supported in environments running 5875 or later. This feature of cascaded clone allows an incremental restore to a cascaded clone target. For example, devices involved in an A -> B -> C cascaded clone session can copy data from device C to device A, but must use device B as a pass-thru device as shown in the following graphic. 16

17 Figure 9. Restore to a cascaded clone target The numbered items described in Figure 9 outline the restore process for RTT (restore to target) as follows. 1. Restore device C to device B 2. Restore device B to device A 3. Split clone session 1 (A -> B) 4. Re-create clone session 1 (A -> B) Creating thin cascaded clones (using SMC) The following example demonstrates SMC and the cascaded TimeFinder/Clone feature using devices 0197, 0198, and 0199 as shown in Figure 10. Figure 10.Cascaded example clone devices A device group named ctest was created and the three devices were added to form the group. Using SMC, right-click on the device group ctest, then select Replication and TimeFinder/Clone 17

18 By selecting the source (SRC) and target (TGT) devices, create the device pair ( ) for the first leg of the cascaded clone session. Click Select All and Next to continue. Choose the copy option to determine the type of cloning session. Click Finish when complete. 18

19 In viewing the Properties of the device group ctest, review the State of the copy session. Again, right-click on the device group ctest and select the TimeFinder/Clone Replication options. Click Select all and Next to continue. To activate consistent cascaded clones, select the Consistent checkbox. Then click Finish to activate the session. Choosing the Consistent option guarantees that a consistent point-in-time image exists on the target device. 19

20 Now, the query properties displays that the pair state is 100% copied after the activation is complete. Next, it is necessary to create the session for the cascaded clone (or second leg) that includes devices DEV002 (0198) DEV003 (0199). Once again, right-click on ctest and click Edit Pairs. Choose the Source device (0198) and replica (0199) in order to create the device pair. Click Add to include this pairing in the Device Pair List. The create screen will appear; click Select All to create the second pair for the cascaded cloning session. Click Next to continue. Again, select the copy options for the second clone session, and then click Finish when complete. 20

21 The query properties display the second pair in a Precopy state because this session has not yet been activated. Right-click on ctest and choose Select All to activate the session. Click Next to continue. Select the Consistent checkbox and click Finish to activate this session. Finally, we see that the cascaded clone sessions are both activated. 21

22 Restoring thin cascaded clones (using SMC) The TimeFinder/Clone cascaded cloning RTT (restore to target) feature details were described in Figure 9. Using SMC, the RTT steps will be re-created. Select Incremental Restore for the device pair DEV002 and DEV003. Click Next to continue. The Clone Query for device group ctest displays a Restored state for device In the next step, the first session pair (devices 0197:1098) is selected, and the available options are displayed (Terminate, Incremental Restore, and Split). Select Incremental Restore, click the device pair to select, and click Next to continue. Click Finish and OK when complete. 22

23 In the final review of the device group ctest, we see that both legs of the cascaded clone session have been restored. At this point, the cascaded clone sessions may be re-created or terminated. The 2012 Q Service Release provided Cascaded TimeFinder/Snap with all of the capabilities of Cascaded TimeFinder/Clone, including Restore-to-Target (RTT). TF/Clone emulation in support of thin devices Minimum Requirements Enginuity Solutions Enabler Clone Emulation for TDEV Note: The Thin BCV cannot be in any SRDF relationship TimeFinder/Mirror is not supported on Symmetrix VMAX series systems, but Clone Emulation mode allows symmir commands to run TimeFinder/Clone operations. If users wish to run existing scripts that use TimeFinder/Mirror commands, they will still work, but the underlying mechanism is TimeFinder/Clone. When a symmir command is issued, clone emulation mode is automatically invoked. The following commands describe the process for creating, establishing, and splitting BCV pairs in Clone Emulation mode using TimeFinder/Mirror. 1. To associate one device with a single BCV device: symbcv g dgname sid symmid associate DEV001 BCV The first initial synchronization must be a full establish in order to synchronize every track on the source with the target device: symmir g dgname sid symmid full establish DEV Once a full establish has been performed, incremental resynchronization is possible from this time forward by simply removing the full parameter: symmir g dgname sid symmid establish DEV To sever the relationship between source and target, use the split command: symmir g dgname sid symmid split DEV001 23

24 TimeFinder/Snap for thin devices The following sections describe TimeFinder/Snap features and functionality that are available on a VMAX storage array, and can be implemented with virtually provisioned thin devices. Multi-virtual snap Minimum Requirements Enginuity Solutions Enabler Multi-Virtual Snap Enginuity versions 5774 and higher support multi-virtual TimeFinder/Snap sessions for thin devices used as source devices in the TimeFinder/Snap session. Multi-virtual sessions (referred to as multi-virtual mode) are created when a single TimeFinder/Snap session involving one source device maintains up to 128 VDEV point-in-time copy targets. An additional protection session runs on each VDEV associated with a point-in-time copy. Only one type of a VDEV session can be run against a single source device. To use multi-virtual mode, the environment variable MULTI_VIRTUAL_SNAP must be set to ENABLED on the controlling host. Duplicate snap Minimum Requirements Enginuity Solutions Enabler Duplicate Snap Duplicate snap functionality allows users to create a new Snap session that is a point-intime copy of a virtual device that is already paired in a previously activated snap session. Some restrictions apply for duplicate snap functionality; The virtual device duplicates must be created from STD source devices. Create and activate operations cannot be mixed between normal snap sessions and duplicate snap sessions. The maximum number of duplicate sessions in the created state is two. When a duplicate snap session is in the created state, the original session cannot be terminated or recreated until the duplicate session is activated. The following screenshots were derived using a combination of both the symcli and SMC. Using basic text files as shown in Figure 11, the source (SRC) devices and VDEV (TGT) devices are defined for the duplicate snap sessions. The first file defines the pairing for SRC devices (812:815) and target VDEVs (58C:58F). The second file defines the device pairings for SRC (812:815) and a second set of target VDEVs (590:593). 24

25 Figure 11. SRC and VDEV TGT definitions In the next step, the pairing relationship between source and target VDEVs must be defined via the create command as shown below. Query the result. 25

26 Create the pairing relationship between the source devices and the duplicate snaps, and query the result again. Using the symcli or SMC, users have a visual representation of what s happening with TimeFinder/Snap and the duplicate snaps at this point. Figure 12 displays device 812, which now has two duplicate snapshots (590 and 58C) in the created state. Figure 12. SMC depicting SRC 812 and its duplicate snaps Once activated, writes to each source device will update the duplicate snaps using COFW technology. 26

27 An SMC screenshot displays the eight duplicate snap VDEVs and their corresponding source devices. When the user is ready to terminate the pairing relationship, use the following commands. The terminate command severs the relationship between the source and target devices. Figure 13 shows that the pair state is Not Created and the device status are Not Ready. In order to bring these devices back into a paired relationship, they must be once again activated. Figure 13. Terminate the SRC and TGT sessions 27

28 EMC TimeFinder/VP Snap Minimum Requirements Enginuity Solutions Enabler VP Snap TimeFinder/VP Snap allows multiple snaps to share capacity allocations within a thin pool, thus reducing the storage required for saved tracks. TimeFinder/VP Snap is designed to create point-in-time replicas that are conceptually similar to those created by TF/Snap. Both source and target devices must be thin, and the copied data resides on allocations in a thin pool. TimeFinder/VP Snap sessions copy data from a source device to a target device only if triggered by a host write I/O; read I/Os to protected tracks on a target device do not result in data being copied. VP Snap sessions are unique because thin-pool allocations can be shared amongst target devices. For example, source updates that are new to multiple point-in-time copies are saved in a single set of allocations that are shared by two or more target devices. When data being copied from a source device is needed by more than one target, only a single shared copy will be moved to the target thin pool. Allowing multiple targets to reference the same shared copy provides cost-effective space savings. This space savings is increased when VP Snap sessions are terminated. The target device is removed from any shared allocations that were part of the session, and any non-shared allocations for that device are deallocated. When all but one of the VP Snap sessions are terminated, the last remaining session uses the same space in the thin pool, but is no longer shared. Upon termination of the last session, the space is deallocated. Figure 14 depicts a source device with three targets that are sharing a single-track allocation within the thin pool. Figure 14. VP Snap track-allocation sharing TimeFinder/VP Snap sessions support incremental recreates and restores, and can also be cascaded from Clone targets. TimeFinder/VP Snap is available with Enginuity 5876 and Solutions Enabler 7.4 and higher. For more information on TimeFinder/VP Snap, please visit support.emc.com for the white paper Implementing TimeFinder VP Snap for Local Replication. 28

29 Conclusion TimeFinder provides enhanced capabilities for organizations that must ensure that critical business functions will be available to customers 7x24x365. Backup, restore, data warehousing, and data refresh (for development and test environments) are the main business use cases. TimeFinder/Clone and TimeFinder/Snap provide features and functionality for both traditional (thick) and virtual (thin) environments. TimeFinder/VP Snap is a costeffective, space-saving option available for thin environments. TimeFinder s various copy modes (or copy options) give users the flexibility to determine when the point-in-time image is produced and how it will be used in the future. TimeFinder is simple to implement and easy to use. References The following documents can be found on support.emc.com EMC Solutions Enabler Symmetrix Array Controls Product Guide EMC TimeFinder Product Guide Using VMware vstorage APIs for Array Integration with EMC Symmetrix VMAX Implementing TimeFinder VP Snap for Local Replication 29

30 Appendix A: TimeFinder Session Limits Table 3 lists the allowed TimeFinder session limits per source volume. Feature Limit per Source Volume Comments Snap 16 Default Snap Functionality. Multi-Virtual Snap 128 Enabled by setting a host environment variable in a command shell session: SET SYMCLI_MULTI_VIRTUAL_SNAP=ENABLED Clone (differential) 8 Default Clone Functionality. Each differential Clone consumes one extra session to track updates that will be used during incremental recreate or restore. Clone (non-differential) VP Snap Specified at session creation time via nodiff option. Note: The total Clone session limit per source volume of Differential Clones plus Non-differential Clones is 16. For example, if you created 8 differential clone sessions, you could not then create any non-differential sessions. Cascaded Hops 2 Snap, Clone, and VP Snap sessions can be cascaded from a fully-copied Clone Target. Table 3. TimeFinder Session Limits per Source Volume The session limits and rules for intermixing session types from a Clone target are same limits as any other source volume. No mixing of Thick and Thin volumes are allowed when cascading: Snap sessions can be cascaded from either Thick-Thick or Thin-Thin Clone pair. Thick Clones can only be cascaded from a Thick-Thick Clone pair. Thin Clones can only be cascaded from a Thin-Thin Clone pair. VP Snap sessions can only be cascaded from a Thin-Thin Clone pair. 30