Académique Documents
Professionnel Documents
Culture Documents
Abstract
This white paper discusses EMC Symmetrix VMAX TimeFinder VP
Snap functionality in the context of Microsoft server applications.
May 2012
Copyright 2012 EMC Corporation. All Rights Reserved.
For the most up-to-date listing of EMC product names, see EMC
Corporation Trademarks on EMC.com.
Terminology
Term Description
Device A logical unit of storage defined within a Symmetrix array.
Thin Device A host accessible device that has no storage directly
associated with it.
Data Device An internal device that provides storage capacity to be
used by thin devices.
Thin Device Extent The minimum quantum of storage that must be mapped
at a time to a thin device. Extent also is known as a
chunk.
Data Device Extent The minimum quantum of storage that is allocated at a
time when dedicating storage from a thin pool for use with
a specific thin device
Thin Pool A collection of data devices that provide storage capacity
for thin devices.
Bind The process by which one or more thin devices are
associated to a thin pool.
Unbind The process by which a thin device is disassociated from
a given thin pool. When unbound, all previous extent
allocations from the data devices are erased and returned
for reuse.
Pre-allocating or Pre-provisioning User specified operation performed against a thin device
for the purposes of reducing the operational impact of
allocating extents, or for guaranteeing a specified amount
of storage for a thin device in a thin pool
Recreating/Terminating VP Snaps
VP Snap sessions can be terminated or recreated. When sessions are terminated or
recreated, existing allocations within the target thin pool will be deallocated. Any
shared allocations will persist as required for the remaining VP Snap sessions. VP
Snap sessions can be recreated in several ways with Solutions Enabler. One method
requires two commands, a recreate followed by an activate. If no additional scripting
is required between the recreate and activate (for the purposes of application or host
level interaction) an establish command can be used, which will combine both the
recreate and activate automatically.
Recreating VP Snaps example
1. Recreate the relationship (device file example):
symclone sid <SymmID> -f <Devfile> recreate
2. Activate the VP Snap relationship (device file example):
symclone sid <SymmID> -f <DevFile> activate consistent
Terminating VP Snaps example
1. Terminate the relationship (device file example):
symclone sid <SymmID> -f <Devfile> terminate
Restoring VP Snaps
VP Snap sessions can be incrementally restored to their source devices. The restore
operation will create an additional clone session for the restore, while the existing
CopyOnWrite session will be maintained. The additional restore session will count
against the 16 total sessions allowed for traditional TimeFinder Clone. Unlike
traditional Timefinder Clone restore sessions, where the split command can be
used to complete the restore and separate the target from the source, VP Snap
requires a terminate of the restored session. The terminate command in
conjunction with the -restored flag is used for this purpose.
Restoring VP Snaps example
Performance
VP Snap, much like TimeFinder/Snap, is best used in relatively low write workload
environments. Each write to a protected source device will incur at least 3 times the
backend operations to preserve the point-in-times of the VP Snap copies. The
ACOFW behavior shown in Figure 1 will help to limit the direct response time impact
to host writes targeting VP Snap source devices. But there will be an additional
workload of reads against the source thin pool and writes against the target devices
thin pool based on the application write workload. This additional overhead on the
disks and back end disk adapters (DA) supporting the production workload may have
some impact on performance.
If the VP Snap target is accessed, the reads could be redirected to the source thin
pool which could also potentially impact production performance. If the goal is to
utilize a secondary copy of a database for streaming backup, reporting, development,
QA, etc. while not impacting production devices, full clones dedicated onto their own
thin pool should be considered.
Additionally, when VP Snap target devices are terminated or recreated, the existing
space used by those devices will be deallocated. The deallocation process will
consume CPU cycles on the back end disk adapters. Additionally if the source thin
devices in the VP Snap relationship are not pre-allocated, any extents which are not
allocated will be considered as copied to the thin target. No actual copy process will
occur, but the marking of extents as copied to the VP Snap target will cause CPU
cycles to be used on the back end disk adapters. These temporary overheads should
be taken into consideration if multiple VP Snap sessions will be recreated on a
regular basis throughout production time windows.
Space Utilization
As discussed in the Understanding thin pool allocations section, the nature of the
write workload against the VP Snap environment will impact storage allocations in the
target thin pool. In the context of database applications, like Microsoft Exchange
Server and SQL Server, differences can be seen when comparing the log file and
database file allocation patterns.
To provide an example, Figure 8 shows the Symmetrix devices supporting a single
SQL Server database that has an OLTP workload with small insert and update
The database devices (4D7 through 507) show a much larger difference between the
host write workload, the percent written and percent allocated totals. For this
example, each database device had seen roughly 5GB worth of writes according to
the SQL Server virtualfilestats table. Because the writes were small (8KB,) and
random, the VP Snap target exhibited the same pattern explained in Figure 4. For
each 8KB random write, a 64KB track was marked as written and a 768KB extent was
allocated. In total, for the 5GB written from the host, 15.4 GB was marked as written,
and ~84 GB was marked as allocated. It is important to keep in mind, that over time,
the difference in the allocations will diminish, as additional 8KB writes occur on
previously written tracks and previously allocated extents. But for some
environments, where VP Snap sessions are short lived, and the write workload is
extremely random, this kind of allocation pattern may be exhibited.