Module 3 TF Snap

Copyright © 2009 EMC Corporation. Do not Copy - All Rights Reserved.

Module 3 - TimeFinder/Snap Operations - 1

© 2009 EMC Corporation. All rights reserved. Module 3 - TimeFinder/Snap Operations - 1

Module 3: TimeFinder/Snap Operations

Upon completion of this module, you will be able to:

ü Describe TimeFinder/Snap functionality

ü Describe TimeFinder/Snap “Copy on First Write” process

ü Describe the Create, Activate, Terminate and Restore TimeFinder/Snap operations

ü Identify and describe Virtual Devices used for TimeFinder/Snap operations

ü Describe the SYMCLI symsnap command set to Monitor, Create, Activate, and Query TimeFinder/Snap sessions

The objectives for this module are shown here. Please take a moment to read them.

Compa

ny C

onfid

entia

l

PDF created with pdfFactory Pro trial version www.pdffactory.com

http://www.pdffactory.com





ü TimeFinder/Snap creates “logical”point-in-time images of a source volume

ü Requires only a fraction of the source volume’s capacity

ü Up to 128 Snap sessions can be created from a source volume and are available immediately

ü Complements TimeFinder/Clone and provides unmatched replication flexibility

VDEV Device

Production Host A

Target Host B

ProductionVolume

Snap SavePool

ProductionSnapshot

----Pointers onThe VDEV

TimeFinder/Snap

TimeFinder/Snap creates space-saving, logical point-in-time images. The Snaps are not a full copies of data; they are logical images of the original information, based on the time the Snap was created. A set of pointers to the source volume data tracks is created upon activation of the Snap. These pointers are stored in the Virtual Device. Target host is given access to the Virtual Device.

The default maximum number of Snaps is 16. If a restore from a Snap is planned, one session is reserved for the restore session. This reduces the default maximum number of Snaps to 15.

Setting the following SYMCLI environment variable: SYMCLI_MULTI_VIRTUAL_SNAP = ENABLED, increases the maximum number of Snap sessions to 128.

Compa

ny C

onfid

entia

l







SourceR/W

R/WTargetBackup

Host

Controlling Production

HostPointers from

Virtual to Original Data

Original Data Copied to Snap Pool

“CopyOnFirstWrite”

ProductionVolume

VDEV Device

Snap SavePool

Target

TimeFinder/Snap Operations Overview

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

A copy session must first be Created that defines the Snap devices in the copy operation. When the session is subsequently activated, the target virtual devices then become accessible to its host. When sessions are no longer required they can be terminated.

Snap operations are controlled from the host by using the symsnap command to create, activate, terminate, and restore the Snap copy sessions.

Compa

ny C

onfid

entia

l







TimeFinder/Snap

ü TimeFinder/Snap captures a point-in-time view of a source volume by copying only the original data prior to it being changed on the source device or the target device:– The target is a virtual device that contains pointers to tracks on the

original source data– The target can be mounted like any other volume– Copying only occurs when there are writes to the source

or target– Only the original data that has to be changed is copied to a SAVE

device, consuming a fraction of the space required to copy the entire source

– Copying is controlled by copy sessions, which are created, activated, queried, listed, and terminated using the symsnap command

TimeFinder/Snap allows you to make copies of data simultaneously on multiple target devices from a single source device. The data is available to a target host instantly. This source device can be a Standard or a BCV device. (BCV in a Split State). A target device is a virtual device (VDEV) that consumes no physical storage.

Compa

ny C

onfid

entia

l







Once the TimeFinder/Snap session is activated– The first time a track on the source is written to, the original data on the

source is copied to the save device, the VDEV pointer is changed to point to the save device; “then” the source is changed.

– “Copy on First Write” applies to writes to the VDEV as well.

Source Vol Save Device

Modified Tracks / Original Data

VDEV deviceContains Pointers to the

Original Data

0

000

1000

1

Snap SavePool

Production Host A Target

Host B

TimeFinder/Snap – Copying Data

TimeFinder/Snap uses a process called “Copy on First Write” when a Snap session is activated. When a host attempts to write to a track on the Source volume for the first time after activation, the original track is copied from the Source volume to the Save Area, the pointer is updated to reference the Save Area, then the Source volume is updated with the new write. Subsequent writes to the same track on the Source volume will not invoke a data copy. Likewise, when a write is issued to a track on the VDEV for the first time, the original data is copied from the Source volume to the Save Area, the pointer is updated, and the new write to the VDEV is stored in the Save Area.

Compa

ny C

onfid

entia

l







ü The copy-on-write is repeated every time a different track on the source is first written to

ü Tracks are striped in a round-robin manner to the Save Devices to improve performance

Source Virtual Device Save Pool

Host A

Host B

VDEV

Original Data

Modified Tracks

Striping the Save Device

The save pool device is not host accessible, but accessed only through the virtual devices that point to it. Save devices provide a pool of physical space to store snap-copy data to which virtual devices point.

Tracks are striped in a round-robin manner to save devices to improve performance. When savedevs are configured across the backend, they are separated first by director, then channel, and then by disk.

Compa

ny C

onfid

entia

l







Terminating a Copy Session

ü When a Copy Session is Terminated:– The virtual device is made not ready– Tracks on the save device(s) are reclaimed if they are not

referenced by any other copy session– The copy session structures are freed-up

Source Virtual Device Save Pool

Host A

Host B

VDEV

As sessions are terminated, the space in the Save Area is released and available for re-use by other snap sessions.

Compa

ny C

onfid

entia

l







DEV001

DEV001

VDEV001

ControllingHost Source VDEV001

Host B Target

Device Group(1) ProdDB

Device Group(2) BackupDB

Host A Source

“Default” Pool

“Training” Pool

Multiple Save Device Pools

Symmetrix SAVE devices are specially configured devices (not mapped to the host) that provide pooled physical storage space used to store pre-update images or changed tracks during a virtual copy session. Multiple named SAVE device pools can be created and sessions can be specified to use a specific SAVE pool

Save Area capacity can also be allocated based on application requirements. For example:ü Allocate more space for Write-intensive applicationsü Allocate more space for long duration snapshots

The -svp option can be used with the create action to specify which SAVE device pool to use for an operation.

Compa

ny C

onfid

entia

l







Consistent Activationü Four methods to execute “Consistent Activation”ü Specify -ppath and PowerPath STD devices that hold

the database– Specific devices; supply the device name– All devices using keyword SRCDEVS– Use –rdb for automatic mapping of DB devices

ü Specify –consistentü Specify –vxfs for VxFS filesystem (Solaris and HP only)

ü Consistent activate command -both_sides– For devices with an RDF State of Synchronized– Ability to generate a consistent activate for both the local and remote

VDEVS at the same time

There are four types of consistent activation available; each offers a restartable copy on target VDEVs: ü PowerPathü ECAü Veritas File Systemü -both_sides

Compa

ny C

onfid

entia

l







ü Common Snap operations:– Create– Activate – Restore – Terminate– Recreate VDEV Device

Production Host A

Target Host B

ProductionVolume

Snap SavePool

Snapshot ofProduction

testdg3

symsnap Operations

Compa

ny C

onfid

entia

l







Configuration Considerations

ü Cache– There is some additional cache required for TimeFinder Snap

snapshots– Total number of VDEVs (snapshots) must be accounted for in cache

calculations

ü VDEV (snapshots)– Are persistent– Cache only devices– Consume SYM device ID– Are not convertible to / from other device types

Additional Cache is required for Snap snapshots. The number of VDEVs must be included in cache calculations.

VDEVs can be configured using Symmetrix Management Console or SYMCLI. VDEVs take device IDs.

Compa

ny C

onfid

entia

l







Configuration Considerations (continued)

ü SaveDev (Save Area)– SaveDevs should be spread over as many physical volumes as

possible

ü SaveDev (Save Area) Monitoring– SaveDev thresholds can be set and notifications can be sent– SaveDev can be added dynamically– When Save Area fills, sessions that require free tracks in the Save

Pool are placed in a failed stated

For best performance the Save Devices should be spread across as many physical volumes as possible. When the Save Area is full, any active session that requires a free track in the Save Pool will be placed in a failed state. This is because, the original data has to be copied to the Save Area before changing the data on the Source devices. How ever if there is no more space in the Save Area, then this operation cannot complete. Hence the session is placed in a failed state.

Compa

ny C

onfid

entia

l







Save Device Space Considerations

ü Virtual Devices do not pre-allocate space for all potential copy-on-write tracks

ü It is possible to run out of free space on save devices

ü If Writes cannot complete due to no free space:– The target VDEV goes Not Ready (NR)– Copy-on-write is disabled and the source track is changed

ü Draining Save DevicesØPermits a disable command to work on an active save deviceØAll active tracks copied (drained) to other devices in the save poolØProtections against disabling the last device or causing the pool to

overflow and terminate snap sessionv disable dev SymDevName[:SymDevName] in pool <poolname>, type = snap

Use symsnap monitor to track the amount of available space of the save area. The symsnap monitor command can also be used to automatically run an action if a predetermined threshold for space has been crossed. Use -percent nn –action script_pathname to specify the percentage full threshold and script associated with it.

Compa

ny C

onfid

entia

l







ü Use symsnap monitor to automatically run an action:C:\>symsnap monitor -sid 24 -percent 80 –action one_percent_script.sh

–svp DEFAULT_POOL -i 60 –c 5

ü The above command will monitor the default save pool (“DEFAULT_POOL”) every 60 seconds for 5 iterations. If the save pool usage reaches 80 percent, then the command will execute the one_percent_script.sh script.

Monitoring Save Device Space

You can monitor SAVE devices by using the symsnap monitor command to check the percentage full. When devices reach the specified percentage, an optional action script can be executed by the application to preserve the data or terminate sessions. The following is an example of the monitor command:

symsnap monitor -percent 80 -action SaveScript -norepeat -i 60 –svp AccountingIn the above example, the SAVE device pool “Accounting” will be monitored every minute for percentage full. When the percentage of the SAVE devices are 80 percent full, the associated action script SaveScript will be executed each time the threshold of 80 percent is met.

Compa

ny C

onfid

entia

l







List Available VDEVsC:\>symdev list -vdevSymmetrix ID: 000194900180

Device Name Directors Device

Device Name Directors Device--------------------------- ------------- -------------------------------------

CapSym Physical SA :P DA :IT Config Attribute Sts (MB)--------------------------- ------------- -------------------------------------

0131 Not Visible ***:* NA:NA VDEV N/Asst'd NR 10780132 Not Visible ***:* NA:NA VDEV N/Asst'd NR 10780133 Not Visible ***:* NA:NA VDEV N/Asst'd NR 10780134 Not Visible ***:* NA:NA VDEV N/Asst'd NR 10780135 Not Visible ***:* NA:NA VDEV N/Asst'd NR 1078

The list of available VDEVs can be obtained with the command shown.

Compa

ny C

onfid

entia

l







List All the Save Pools

C:\>symsnap list -pools

Symmetrix ID: 000194900180

S A V E D E V I C E P O O L S--------------------------------------------------------------------------------

Dev Total Enabled Used Free Full Pool SessionPool Name Emul Tracks Tracks Tracks Tracks (%) State Status--------------------------------------------------------------------------------DEFAULT_POOL FBA 276000 276000 0 276000 0 Enabled InactiveDEFAULT_POOL 3390 0 0 0 0 0 Disabled InactiveDEFAULT_POOL 3380 0 0 0 0 0 Disabled InactiveDEFAULT_POOL AS400 0 0 0 0 0 Disabled Inactive

In this example there is a DEFAULT_POOL of device emulation type FBA, with a number of devices in it.

Compa

ny C

onfid

entia

l







List All the Save Devices in a Save PoolC:\>symsnap list -svp DEFAULT_POOL -savedevs


S N A P S A V E D E V I C E S---------------------------------------------------------------------

Device SaveDevice Total Used Free FullSym Emulation Pool Name Tracks Tracks Tracks (%)---------------------------------------------------------------------017D FBA DEFAULT_POOL 17250 0 17250 0017E FBA DEFAULT_POOL 17250 0 17250 0017F FBA DEFAULT_POOL 17250 0 17250 00180 FBA DEFAULT_POOL 17250 0 17250 0-----Output Truncated-----------Total --------- --------- --------- ----

Tracks 276000 0 276000 0MB(s) 17250.0 0.0 17250.0

The individual Symmetrix devices that constitute the Save Pool can be listed as well.

Compa

ny C

onfid

entia

l







Create New Save Pool and Add Save DevicesC:\>symconfigure –sid 80 –f create_pool.txt commit –nopC:\>symconfigure –sid 80 –f disable_devs.txt commit –nopC:\>symconfigure –sid 80 –f add_dev_to_pool.txt commit –nopC:\>symsnap list -svp appn_a_pool -savedevSymmetrix ID: 000194900180

S N A P S A V E D E V I C E S---------------------------------------------------------------------

Device SaveDevice Total Used Free FullSym Emulation Pool Name Tracks Tracks Tracks (%)---------------------------------------------------------------------017D FBA appn_a_pool 17250 0 17250 0017E FBA appn_a_pool 17250 0 17250 0017F FBA appn_a_pool 17250 0 17250 00180 FBA appn_a_pool 17250 0 17250 0Total --------- --------- --------- ----

Tracks 69000 0 69000 0MB(s) 4312.5 0.0 4312.5

The symconfigure command is used to create a new Save Pool and add Save Devices to it. The action and the devices are specified in the *.txt files. In this example we are moving devices 17D:180 out of the DEFAULT_POOL, into a new Save pool – appn_a_pool.

create_pool.txt: create pool appn_a_pool, type=SAVEDEV; This creates Save Pool named appn_a_pool.

disable_devs.txt: disable dev 17D:180 in pool DEFAULT_POOL, type=SAVEDEV; This disables the devices 17D:180 currently in the DEFAULT_POOL

add_dev_to_pool.txt: add dev 17D:180 to pool appn_a_pool, type=SAVEDEV, member_state=ENABLE; This adds the devices 17D:180 to the appn_a_pool, and enables the devices as well.Com

pany

Con

fiden

tial







Show Device GroupC:\>symdg show snapdg

Group Name: snapdgNumber of STD Devices in Group : 2Number of Associated GK's : 0Number of Locally-associated BCV's : 0Number of Locally-associated VDEV's : 2

Standard (STD) Devices (2):{--------------------------------------------------------------------

Sym CapLdevName PdevName Dev Att. Sts (MB)--------------------------------------------------------------------DEV001 \\.\PHYSICALDRIVE7 013F RW 1078DEV002 \\.\PHYSICALDRIVE8 0140 RW 1078}

A SYMCLI Device Group has been created, two STD devices have been added as Source for Snap sessions and two VDEVs have been added as Targets for Snap sessions.

symdg create snapdgset SYMCLI_DG=snapdgsymld addall dev –range 13F:140symld addall dev –range 131:132 –vdev

Compa

ny C

onfid

entia

l







Show Device Group (continued)C:\>symdg show snapdg

VDEV Devices Locally-associated (2):{--------------------------------------------------------------------

Sym CapLdevName PdevName Dev Att. Sts (MB)--------------------------------------------------------------------VDEV001 N/A 0131 NR 1078VDEV002 N/A 0132 NR 1078}

Note that the VDEVs are given the Logical Devices Names VDEV001 and VDEV002 respectively.

Compa

ny C

onfid

entia

l







Create Snap SessionsC:\>symsnap create -svp appn_a_pool

C:\>symsnap query-----------Output Truncated----------

Source Device Target Device State Copy------------------------- ------------------- ---------- ------------ ----

Protected ChangedLogical Sym Tracks Logical Sym G Tracks SRC <=> TGT (%)------------------------- ------------------- ---------- ------------ ----

DEV001 013F 17250 VDEV001 0131 X 0 Created 0DEV002 0140 17250 VDEV002 0132 X 0 Created 0

Total -------- ----------Track(s) 34500 0MB(s) 2156.3 0.0

In this example, Snap sessions have been created between the source and the target VDEVs. The symsnap create command sets up the track protection bitmap. As can be seen in the output, all tracks on the Source devices have been protected. The state of the Source – Target device pair goes to Created.

Legend:

(G): X = The Target device is associated with this group,. = The Target device is not associated with this group.

Compa

ny C

onfid

entia

l







Create Snap Sessions (continued)C:\>symsnap list


Source Device Target Device Status SaveDev------------------------- -------------------- ------------- -----------

ProtectedSym Tracks Sym G SRC <=> TGT PoolName------------------------- -------------------- ------------- -----------013F 17250 0131 X Created appn_a_pool0140 17250 0132 X Created appn_a_pool

Total --------Tracks 34500MB(s) 2156.3

A “hold” is placed on the VDEVs and they remain in a Not Ready state. We can also see that the Save Pool named appn_a_pool is used for these Snap sessions.

C:\>symdev list -held


Device Name Directors Device--------------------------- ------------- -------------------------------------

CapSym Physical SA :P DA :IT Config Attribute Sts (MB)--------------------------- ------------- -------------------------------------

0131 Not Visible ***:* NA:NA VDEV Asst'd NR10780132 Not Visible ***:* NA:NA VDEV Asst'd NR1078

Compa

ny C

onfid

entia

l







Activate Snap SessionsC:\>symsnap activate –consistent -nop

C:\>symsnap query----Output Truncated-----



DEV001 013F 17250 VDEV001 0131 X 0 CopyOnWrite 0DEV002 0140 17250 VDEV002 0132 X 0 CopyOnWrite 0

Total -------- ----------Track(s) 34500 0MB(s) 2156.3 0.0

The symsnap activate command places the snap pair in the CopyOnWrite (copy-on-first-write) state and the target virtual device in a Read/Write (RW) state. The actual copying of data occurs when a track is written to either on the Source device or on the VDEV.

Compa

ny C

onfid

entia

l







Querying Multiple Snap SessionsC:\>symsnap query –multi

---Output Truncated------



DEV001 013F 17246 VDEV003 0133 X 4 CopyOnWrite 017121 VDEV001 0131 X 129 CopyOnWrite 0

DEV002 0140 17246 VDEV004 0134 X 4 CopyOnWrite 017121 VDEV002 0132 X 129 CopyOnWrite 0

Total -------- ----------Track(s) 68734 266MB(s) 4295.9 16.6

For this example two additional VDEVs (133:134) were added to the device group snapdg.

symsnap create –svp appn_a_pool – Creates the first Snap session between 13F:131 and 140:132symsnap activate –consistent – Activates the first Snap session

symsnap create –svp appn_a_pool –concurrent – Creates the second Snap session between 13F:133 and 140:134symsnap activate –consistent – Activates the second Snap session

Compa

ny C

onfid

entia

l







symsnap restore

ü Three types of restore operations can be performed for virtual device copy sessions:– Incremental restore back to the original source device– Incremental restore to a split TimeFinder/Clone BCV or a

TimeFInder/Mirror BCV– Full restore to any standard or split TimeFinder/Clone BCV or a

TimeFinder/Mirror BCV

Three types of restore operations can be performed for virtual device copy sessions:1. Incremental restore back to the original source device.2. Incremental restore to a TimeFinder/Clone BCV or a TimeFinder/Mirror BCV, which has

been split from its original standard source device but maintains the incremental relationship with the source.

3. Full restore to any standard or split TimeFinder/Clone BCV or a TimeFinder/Mirror BCvdevice outside of the existing copy session. The target device of the restore must the same size and emulation type as the source device.

All original Snap copy sessions are maintained when performing a restore operation. A new restore copy session between the source device and VDEV is created. A restore operation can only be performed if an additional copy session is available for use.

Compa

ny C

onfid

entia

l







Restore a Snap SessionC:\>symsnap restore -nop

C:\>symsnap query----Output Truncated-----



DEV001 013F 0 VDEV001 0131 X 0 Restored 100DEV002 0140 0 VDEV002 0132 X 0 Restored 100

Total -------- ----------Track(s) 0 0MB(s) 0.0 0.0

When a restore command is issued, both the VDEVs and the Source devices are set to Not Ready. Once the restore operation starts the Source devices are automatically set to Ready. But the VDEVs will remain Not Ready. Hence it would be best practice to stop access to the VDEVsand the Source devices when initiating a restore operation. After the restore comples the VDEVscan be made ready again by symdev ready 131 –sid 80; symdev ready 132 –sid 80

The restore command initiates an incremental restore by default.

Compa

ny C

onfid

entia

l







List Sessions after RestoreC:\>symsnap list


Source Device Target Device Status SaveDev------------------------- -------------------- ------------- -----------

ProtectedSym Tracks Sym G SRC <=> TGT PoolName------------------------- -------------------- ------------- -----------013F 0 0131 X Restored appn_a_pool013F 17250 0131 X CopyOnWrite appn_a_pool0140 0 0132 X Restored appn_a_pool0140 17250 0132 X CopyOnWrite appn_a_pool

Total --------Tracks 34500MB(s) 2156.3

Note that even after the restore operation, the original Snap session is still maintained. If this original session should now be recreated or terminated, the restored session should first be terminated with symsnap terminate –restored operation.

Compa

ny C

onfid

entia

l







TimeFinder/Snap with Thin Devices

ü Thin devices can be snapped like regular devices

ü Thin device sources can be snapped to virtual device targets

ü VDEV targets can be made ready and updated

ü VDEVs can be restored back to the source thin devices

Thin devices can be used with TimeFinder/Snap in the same way that other types of Symmetrix devices can be used. Point-in-time snap copies of thin devices can be created on virtual devices (VDEVs), which can subsequently be presented to a host. The VDEVs can also be updated and the changes on the VDEVs can be restored back to the source thin devices or to different thin devices.

Thin devices are classified as standard devices and can be added to Symmetrix device groups or put in device files.

Compa

ny C

onfid

entia

l







TimeFinder/Snap Recreate

– Create snap– Activate snap– Recreate snap– Activate snap– Repeat recreate/activate snap

Enginuity 5874

1. Create snap2. Activate snap3. Terminate snap4. Repeat the cycle

Prior to Enginuity 5874

Prior to Enginuity 5874, taking a new point-in-time TimeFinder/Snap copy required terminating the previously activated Snap session between the source volume and the target virtual volume (VDEV). Recreate operation will now be allowed with TimeFinder/Snap symsnap command. After activation of a Snap session, the session can be recreated and then activated, as and when new point-in-time image is required. As the recreate will lead to the replacement of the old image on the VDEV, all used tracks in the SAVE pool associated with the previous session will be released. The query output will show a recreated state. The recreate function is not supported with Multi-Virtual snap.

Compa

ny C

onfid

entia

l







Snap of a Clone Target

ü Target of a Clone session can be the Source for one or more Snap sessions

ü The original Clone session must be in the copied state

üWhen Snap session starts using the Clone target, the only action permitted on the original Clone session is terminate. All other actions are blocked until all the Snap sessions are terminated

ü The only actions permitted on the Snap session with Clone target as the source are activate and terminate. All other actions are blocked until the original Clone session is terminated

Note that with Solutions Enabler 7.0 and Enginuity 5874, a symsnap recreate operation can also be performed on the Snap session with Clone target as the source.

Compa

ny C

onfid

entia

l







Module SummaryKey points covered in this module:

ü Described TimeFinder/Snap functionality

ü Described TimeFinder/Snap “Copy on First Write”process

ü Described the Create, Activate, Terminate and Restore TimeFinder Snap operations

ü Identified and described Virtual Devices used for TimeFinder/Snap operationsü Described the SYMCLI symsnap command set to

Monitor, Create, Activate, and Query TimeFinder/Snap sessions

These are the key points covered in this module. Please take a moment to review them.

Compa

ny C

onfid

entia

l







This slide intentionally left blank.

Compa

ny C

onfid

entia

l




Documents

Module 3 TF Snap