SAVE Area Space Considerations for Virtual Device Restore

Technical Notes
P/N 300-011-878 REV A01 November 16, 2010

This technical notes document contains information on these topics:

Executive summary ................................................................................... 2 Introduction ................................................................................................ 2 Virtual device restore: Additional SAVE area space considerations .. 2 Adding restore considerations into sizing of the SAVE area ............... 5 Conclusion .................................................................................................. 7

Executive summary

Executive summary
The EMC TimeFinder SNAP Facility is a space-saving local replication technology. Part of implementation planning requires calculating the change rate of the source devices to be SNAPPED in order to calculate the size of the SAVE area. This is typically achieved using the change tracker tool. This document describes how extra data may be written to the SAVE area when a SNAP restore is performed and details the SAVE area planning considerations for SNAP restore.

Introduction
This technical notes document discusses the additional SAVE area overhead that can be generated by performing SNAP restore operations in a multi-SNAP environment; it further illustrates how to calculate how much overhead (number of tracks) will be created before a restore is performed. As there can be extra SAVE space used in restore processing, the final section in this document describes how to include restore processing overhead when calculating SAVE area requirements.

Audience
This document is intended for users and planners of TimeFinder SNAP technology.

Virtual device restore: Additional SAVE area space considerations

When a VDEV restore back to the original source device is performed, extra data can be written into the SAVE area. The additional SAVE area is used when the source device has multiple active SNAPs against it and the restore is performed from a VDEV that is not the latest SNAP. The reason that extra data is written to the SAVE area in a multi-virtual SNAP scenario is that a restore may be performed from any VDEV after the initial restore. So to maintain all possible restore points, post-SNAP updates to the source device must be written to the save area as part of the restore operation. This allows for second and subsequent restores from different points after an initial restore.

SAVE Area Space Considerations for Virtual Device Restore Technical Notes

Virtual device restore: Additional SAVE area space considerations

What happens if the SAVE area gets filled up because of a restore?

If the save area gets 100 percent full during a restore the following occurs: The restore pauses. The percent complete that can be seen in a SNAP QUERY remains static. Any SNAP session (VDEV) that is written to once the save area is full goes into a FAILED state. This includes the SNAP session that is being restored from.

To complete the restore, SNAP sessions must be terminated to free up space in the SAVE area or more SAVE space needs to be added. Do not terminate the SNAP being used for the restore! Once the SAVE area has been made available, the restore automatically continues until successful completion.

Calculating save area usage in a multi-SNAP restore

1. Run a SNAP query on the device/device group with the multi parameter. Note that the query sorts SNAPs from newest to oldest.

C:\Temp>symsnap -g testSC query multi Device Group (DG) Name: testSC DG's Type : REGULAR DG's Symmetrix ID : 000287970245 Source Device Target Device State Copy ------------------------- ------------------- ---------- ------------ --Protected Changed Logical Sym Tracks Logical Sym G Tracks source <=> TGT (%) ------------------------- ------------------- ---------- ------------ --DEV001 009C 137218 136390 135559 134727 -------543894 16996.7 VDEV004 VDEV003 VDEV002 VDEV001 00A1 00A0 009F 009E X X X X 842 1670 2501 3333 ---------8346 260.8 CopyOnWrite CopyOnWrite CopyOnWrite CopyOnWrite 0 1 1 2

Total Track(s) MB(s)

SAVE Area Space Considerations for Virtual Device Restore Technical Notes

Virtual device restore: Additional SAVE area space considerations

2.

Check how much space is used in the SAVE pool.

C:\Temp>symsnap -sid 245 -savedevs list Symmetrix ID: 000287970245 S N A P S A V E D E V I C E S --------------------------------------------------------------------Device SaveDevice Total Used Free Full Sym Emulation Pool Name Tracks Tracks Tracks (%) --------------------------------------------------------------------009A FBA Pool_Test 138060 3371 134689 2 Total --------- --------- -----------Tracks 138060 3371 134689 2 MB(s) 4314.4 105.3 4209.0

3.

Determine which VDEV is to be restored from. In this example we will restore from the oldest SNAP, which is VDEV001. Note the changed tracks (3333). The newest SNAP (VDEV004) used 842 tracks. Calculate the difference between the VDEV restore source and the newest SNAP: 3333 842 = 2491 tracks to be added to the SAVE area. The tracks used in the save area in the output above is 3371. After the restore the SAVE area should contain 3371 + 2491 = 5862 tracks.

4.

The following are results of an example restore:

C:\Temp>symsnap -g testSC query -multi Device Group (DG) Name: testSC DG's Type : REGULAR DG's Symmetrix ID : 000287970245 Source Device Target Device State Copy ------------------------- ------------------- ---------- ------------ --Protected Changed Logical Sym Tracks Logical Sym G Tracks source <=> TGT (%) ------------------------- ------------------- ---------- ------------ --DEV001 009C 0 VDEV001 009E X 0 Restored 100 134727 VDEV001 009E X 3333 CopyOnWrite 2 134727 VDEV004 00A1 X 3333 CopyOnWrite 2 134727 VDEV003 00A0 X 3333 CopyOnWrite 2 134727 VDEV002 009F X 3333 CopyOnWrite 2 Total ----------------Track(s) 538908 13332 MB(s) 16840.9 416.6 C:\Temp>symsnap -sid 245 -savedevs list Symmetrix ID: 000287970245 S N A P S A V E D E V I C E S --------------------------------------------------------------------Device SaveDevice Total Used Free Full Sym Emulation Pool Name Tracks Tracks Tracks (%)

SAVE Area Space Considerations for Virtual Device Restore Technical Notes

Adding restore considerations into sizing of the SAVE area

--------------------------------------------------------------------009A FBA Pool_Test 138060 5862 132198 4 Total --------- --------- -----------Tracks 138060 5862 132198 4 MB(s) 4314.4 183.2 4131.2

The SAVE area used before restore was 3371 tracks, After restore it was 5862 for a difference of 2491 tracks. This matches exactly the pre-restore calculation.

What do I do if the restore space calculation exceeds the available free space?
Preserving some free space in the SAVE areas is of paramount importance as filling the SAVE area FAILS ALL active SNAPs once they are written to when the SAVE area is full. If the restore space calculation exceeds the available free space, either more space is needed in the SAVE pool or some SNAP sessions must be terminated to increase available free space in the SAVE pool.

Adding restore considerations into sizing of the SAVE area

Now that we know that restore processing may use up additional SAVE area, we can see that considering restore space in the SAVE area is crucial in implementing a successful solution. Additional SAVE area space may be necessary for SNAP environments that, as part of the design criteria, have: Multiple SNAPs from a single source device The requirement to restore from any of the SNAPs back to the original source device

The additional SAVE area restore overhead may be 0 percent to 100 percent depending on the use of SNAP. In order to include restore space into the SAVE area calculations, perform the following: Determine the SAVE area requirements for the SNAPS as is currently best practice Of the total number of VDEVS to be used, determine the percentage that will be used as multi-SNAPs (more than one VDEV active to a standard device concurrently) Of the number of source devices using multi-SNAPs, estimate the percentage that may need to be restored concurrently Discount the amount of SAVE area used by the latest SNAP as this is
5

SAVE Area Space Considerations for Virtual Device Restore Technical Notes

Adding restore considerations into sizing of the SAVE area

not written into the SAVE area in a restore. Calculate the restore area using the details above as follows: TOTAL save area = Initial SAVE area calculation + (Initial SAVE area calculation x (# multi-SNAP VDEVs /total VDEVs ) x (# concurrent restore source devices x total multi-SNAP source devices)) Discount the space from the latest SNAP. The amount of space used by the latest SNAP as a percentage of the total space used for all VDEVS in a multi-SNAP is dependent on the number of multi-SNAPs being used by the source device(s). The following table is a guide to the percentage of space used by the latest SNAP in a multiSNAP environment. Table 1 Percentage of space used by the latest SNAP based on number of SNAPs Number of SNAPs per source device 2 3 4 5 6 7 8 9 10 Percentage of space used by the latest SNAP 25 11 6 4 3 2 2 1 1

SAVE area calculation with restore overhead

Example No. 1 The SAVE area for a new SNAP implementation was calculated to be 100 GB. There are a total of 400 VDEVs and 100 source devices. All of the source devices are to have four SNAPs active at any point. If there is a requirement to restore from a VDEV to the source device, all devices with SNAP sessions will need to be restored together. 100 GB + (100 GB x (400/400) x (100/100)) = 200 GB 200 GB 6 percent = 188 GB
6 SAVE Area Space Considerations for Virtual Device Restore Technical Notes

Conclusion

In this example, including the restore space has almost doubled the initial SAVE area requirement. Example No. 2 The SAVE area for a new SNAP implementation was calculated to be 100 GB. There are a total of 400 VDEVs and 100 source devices. Twenty of the source devices are to have five SNAPs active at any point. The remainder will only have one active SNAP. If there is a requirement to restore from a VDEV to the source device, half (10) of the devices with multi-SNAP sessions will need to be restored concurrently. 100 GB + (100 GB x ( 80/400) x (10/20)) = 110 GB 110 GB 4 percent = 105.6 GB In this example, including the restore space has added nearly 10 percent to the SAVE area requirement.

Conclusion
Performing SNAP restores in an environment that uses multi-SNAPs does write additional data into the SAVE area. The amount of SAVE overhead depends on the implementation and can be as little as 0 percent or as much as 100 percent. When sizing the SAVE area it is recommended to consider the additional sizing criteria described in this document in order to ensure a quality SNAP implementation.

SAVE Area Space Considerations for Virtual Device Restore Technical Notes

Conclusion

Copyright 2010 EMC Corporation. All Rights Reserved.

EMC believes the information in this publication is accurate as of its publication date. The information is subject to change without notice. THE INFORMATION IN THIS PUBLICATION IS PROVIDED "AS IS." EMC CORPORATION MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND WITH RESPECT TO THE INFORMATION IN THIS PUBLICATION, AND SPECIFICALLY DISCLAIMS IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Use, copying, and distribution of any EMC software described in this publication requires an applicable software license. For the most up-to-date listing of EMC product names, see EMC Corporation Trademarks on EMC.com. All other trademarks used herein are the property of their respective owners.

SAVE Area Space Considerations for Virtual Device Restore Technical Notes