SAVE Area in Snap

1

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

2

Executive summary

SAVE Area Space Considerations for Virtual Device Restore Technical Notes

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.

3

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 VDEV004 00A1 X 842 CopyOnWrite 0

136390 VDEV003 00A0 X 1670 CopyOnWrite 1

135559 VDEV002 009F X 2501 CopyOnWrite 1

134727 VDEV001 009E X 3333 CopyOnWrite 2

Total -------- ----------

Track(s) 543894 8346

MB(s) 16996.7 260.8

4

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

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

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 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 (%)

5

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.


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

6



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 multi-SNAP environment.

Table 1 Percentage of space used by the latest SNAP based on number of SNAPs

Number of SNAPs per source device

Percentage of space used by the latest SNAP

2 25

3 11

4 6

5 4

6 3

7 2

8 2

9 1

10 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

7

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.

8

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 in Snap

Documents

Transcript of SAVE Area in Snap